Confidential Blockchain Benchmarking Report: Zama vs. Octra

Date: December 5, 2025 Author: Antigravity (AI Assistant)

1. Executive Summary

This report details the performance benchmarks of two leading confidential blockchain networks: Zama (running on Ethereum Sepolia) and Octra (Testnet). The study focuses on network latency, block/epoch times, and the client-side cryptographic overhead required to generate private transactions.

Key Findings:

• Network Latency: Zama (via Sepolia RPC) offers significantly faster read times (~63ms) compared to Octra's current REST API (~490ms).
• Throughput/Finality: Zama is bound by Ethereum's ~12s block time. Octra uses "epochs" which are currently several minutes long on testnet, though targeted to be seconds on mainnet.
• Client Overhead: Octra's client-side cryptography (Ed25519/Chacha20) is extremely lightweight (< 0.2ms), making privacy features effectively free in terms of generation time. Zama's Ethereum-based transaction generation is slightly heavier (~1ms) but still negligible.

2. Methodology

Benchmarks were conducted using custom Python and Node.js scripts running on a local macOS environment.

• Zama: Benchmarked using web3.py for RPC latency and fhevmjs/ethers (Node.js) for transaction generation.
• Octra: Benchmarked using requests (Python) for API latency and the official octra_pre_client (Python) for transaction generation.

3. Network Performance

Measures the responsiveness of the public endpoints and the speed of network consensus.

Metric	Zama (Sepolia)	Octra (Testnet)	Notes
RPC/API Latency	62.70 ms	490.32 ms	Zama benefits from mature Ethereum infra. Octra uses a custom REST API.
Block/Epoch Time	~11.08 s	> 300 s	Octra uses "Epochs" for key rotation. Testnet epochs are deliberately long.
Protocol	JSON-RPC (HTTP)	REST API (HTTP)

4. Transaction Overhead (Client-Side)

Measures the time required to construct, sign, and encrypt a transaction locally before broadcasting. This isolates the cost of privacy features.

4.1. Comparative Results

Transaction Type	Octra (Python)	Zama (Node.js)	Comparison
Standard Transfer	0.15 ms	0.68 ms	Octra's Ed25519 signing is faster than Eth's ECDSA/RLP.
Swap (Simulated)	0.14 ms	1.07 ms	Larger payloads add minimal cost to Octra.
Private Transfer	0.14 ms	N/A	Octra's ECDH+AES adds negligible cost (<0.01ms) over standard signing.
Decryption	0.002 ms	N/A	AES-GCM decryption is instantaneous.

4.2. Privacy Cost Analysis

• Octra: The overhead for enabling privacy (encryption) is statistically negligible. The transition from a public transfer to a private one adds less than 0.05ms of computation.
• Zama: While full FHE encryption benchmarks require a live KMS connection (which was unavailable), literature suggests client-side TFHE encryption takes 10-100ms per input. This is significantly higher than Octra's AES-based approach but enables different capabilities (homomorphic computation vs. encrypted transport).

5. End-to-End Latency Analysis

This section estimates the total time from user action (click) to transaction finalization. Formula: Client Gen Time + Network Propagation (RTT) + Consensus Time (Block/Epoch)

5.1. Transfer Transaction

Component	Zama (Sepolia)	Octra (Testnet)
1. Client Generation	~0.7 ms	~0.15 ms
2. Network Propagation	~63 ms	~490 ms
3. Finalization	~12,000 ms (1 Block)	> 60,000 ms (Current Epochs)
TOTAL ESTIMATE	~12.1 Seconds	> 1 Minute

5.2. Swap Transaction

Component	Zama (Sepolia)	Octra (Testnet)
1. Client Generation	~1.1 ms	~0.14 ms
2. Network Propagation	~63 ms	~490 ms
3. Finalization	~12,000 ms (1 Block)	> 60,000 ms (Current Epochs)
TOTAL ESTIMATE	~12.1 Seconds	> 1 Minute

Analysis:

• Client Impact: The client-side generation time (< 2ms for both) is completely negligible in the end-to-end flow. It represents less than 0.01% of the total wait time.
• Bottleneck: The bottleneck for both networks is the Consensus Time (Block/Epoch time).
  • Zama: Bound by Ethereum's 12-second heartbeat.
  • Octra: Currently bound by the long testnet epoch settings. If Octra achieves its mainnet target of "seconds" per epoch, it could theoretically rival or beat Zama's finality time.

6. Conclusion

Zama provides a familiar Ethereum developer experience with standard block times, but its FHE operations likely incur higher computational overheads (gas and generation time) that were not fully measured due to testnet constraints.

Octra demonstrates an extremely lightweight client architecture where privacy is "cheap" to generate. However, its current testnet network performance (latency and epoch times) is significantly slower than the mature Ethereum ecosystem Zama relies on.

6. Recommendations

• For High-Frequency Trading: Neither is currently suitable due to block/epoch times. Zama is faster (12s) but still slow for HFT.
• For Privacy-Preserving dApps:
  • Choose Zama if you need complex on-chain computation over encrypted data (e.g., blind auctions, private voting) and want EVM compatibility.

7. Testing Programs & Codes

The following scripts were developed and executed to gather the data for this report.

7.1. Zama Benchmarks

• benchmark_zama_sepolia.py (Python):
  • Purpose: Measures network latency and block times.
  • Libraries: web3.py.
  • Method: Connects to public Sepolia RPCs, sends eth_blockNumber requests to measure RTT, and polls for new blocks to calculate average block time.
• zama_benchmark/benchmark_zama_tx.js (Node.js):
  • Purpose: Measures client-side transaction generation overhead.
  • Libraries: ethers, fhevmjs.
  • Method: Uses performance.now() to time the creation, signing, and payload construction of standard and simulated FHE transactions.

7.2. Octra Benchmarks

• benchmark_octra.py (Python):
  • Purpose: Measures REST API latency and estimates epoch times.
  • Libraries: requests.
  • Method: Sends repeated GET requests to https://octra.network/staging to measure HTTP latency and monitor the transaction pool for epoch flushes.
• octra_pre_client/benchmark_tx.py (Python):
  • Purpose: Measures client-side cryptographic overhead.
  • Libraries: nacl (Ed25519), cryptography (AES-GCM).
  • Method: Imports the official cli.py logic to generate wallets and construct full transaction payloads (Standard, Encrypted, Private, Swap) locally, measuring the execution time of key derivation and encryption functions.