Proof-of-Execution: Reaching Consensus through Fault-Tolerant Speculation

Multi-party data management and blockchain systems require data sharing among participants. To provide resilient and consistent data sharing, transactions engines rely on Byzantine FaultTolerant consensus (BFT), which enables operations during failures and malicious behavior. Unfortunately, existing BFT protocols are unsuitable for high-throughput applications due to their high computational costs, high communication costs, high client latencies, and/or reliance on twin-paths and non-faulty clients. In this paper, we present the Proof-of-Execution consensus protocol (PoE) that alleviates these challenges. At the core of PoE are out-of-order processing and speculative execution, which allow PoE to execute transactions before consensus is reached among the replicas. With these techniques, PoE manages to reduce the costs of BFT in normal cases, while guaranteeing reliable consensus for clients in all cases. We envision the use of PoE in high-throughput multi-party data-management and blockchain systems. To validate this vision, we implement PoE in our efficient ResilientDB fabric and extensively evaluate PoE against several state-of-the-art BFT protocols. Our evaluation showcases that PoE achieves up-to-80% higher throughputs than existing BFT protocols in the presence of failures.

💡 Research Summary

The paper introduces Proof‑of‑Execution (PoE), a Byzantine Fault‑Tolerant (BFT) consensus protocol designed for high‑throughput multi‑party data‑management and permissioned blockchain systems. Traditional BFT protocols such as PBFT, Zyzzyva, SBFT, and HSBFT suffer from high computational and communication overhead, multiple communication rounds, reliance on trusted clients or collectors, and poor scalability under failures. PoE tackles these limitations through four key design principles.

1. Non‑Divergent Speculative Execution (I1) – Replicas execute a transaction as soon as they receive a “prepared” certificate from a majority, rather than waiting for a final commit phase. This speculative execution is “non‑divergent” because the preparation step already guarantees that a sufficient number of non‑faulty replicas agree on the request, preventing divergent state among honest nodes.

2. Safe Rollbacks and Robustness (I2) – If a malicious primary causes only a subset of replicas to execute a request, the protocol allows those replicas to roll back. Clients must collect a “Proof‑of‑Execution” (PoE) consisting of responses from at least nf ≥ 2f + 1 replicas (instead of the classic f + 1). Once this proof is obtained, the request is irrevocably committed; otherwise, the request is discarded and may be retried in a later view.

3. Signature‑Scheme Agnosticism (I3) – PoE can operate with either symmetric MACs for small clusters (low computational cost) or threshold signatures (TS) for larger deployments. MACs give cheap authentication when n ≤ 16, while TS enable linear‑communication complexity by collapsing an all‑to‑all broadcast into two linear phases, preserving security without the quadratic cost of PBFT.

4. Avoidance of Response Aggregation (I4) – Unlike SBFT or Zyzzyva, PoE does not rely on a single executor or collector to aggregate replies. Every replica directly sends its signed response to the client, eliminating an extra communication round and a single point of failure.

PoE also incorporates out‑of‑order processing: the primary continuously proposes requests within a sliding window bounded by low‑ and high‑watermarks. Replicas may execute any request whose sequence number lies inside the window, allowing pipelined processing and mitigating the impact of high network latency.

The protocol proceeds in two (or three when TS are used) linear communication phases: (1) the primary broadcasts the client request; (2) backups broadcast prepared messages and, upon receiving a majority, speculatively execute the request; (3) each replica sends its execution result and a signature (or signature share) directly to the client. The client assembles nf matching responses to form a PoE proof, guaranteeing that the transaction will survive any subsequent view change.

When a primary fails or is detected as malicious, PoE triggers a view‑change procedure that rolls back any un‑proven speculative executions, synchronizes state among the remaining replicas, and elects a new primary. The view‑change also respects the signature‑scheme choice, preserving linear communication.

Implementation and evaluation were performed on the ResilientDB fabric, a high‑performance permissioned blockchain platform. PoE was compared against Zyzzyva, PBFT, SBFT, and HSBFT in a Google Cloud deployment with 91 replicas and up to 320 k concurrent clients. Experiments covered (i) no‑failure baseline, (ii) backup failure, (iii) primary failure, (iv) request batching, (v) zero‑payload workloads, and (vi) scaling the number of replicas. Results show that PoE achieves 30 %–80 % higher throughput than the best existing BFT protocols across all scenarios, while maintaining comparable latency. Even under failure conditions, PoE retains at least a 50 % performance advantage.

In summary, PoE demonstrates that by speculatively executing transactions, decoupling response aggregation, and allowing flexible cryptographic primitives, a BFT system can drastically reduce normal‑case overhead while still providing strong safety and liveness guarantees. The protocol’s two‑phase normal operation, combined with robust rollback‑enabled view changes, makes it a compelling drop‑in replacement for PBFT‑style consensus in high‑throughput federated databases and permissioned blockchains.