Symphony

---

​

Architecture

Symphony is a new consensus protocol that leverages dual proof sharding, distributed verification, and optimized committee election to reduce replicated execution and enable high-performance, resource-intensive workloads.

​

Background

​

Consensus in Ethereum 2.0

Ethereum 2.0 Proof-of-Stake (PoS) consensus is powered by a combination of the Casper Friendly Finality Gadget (FFG), responsible for block proposal, validation, and finalization and the Last Message Driven Greedy Heaviest Observed Sub-Tree (LMD-GHOST) fork-choice rule that, given a subtree of blocks, determines the canonical chain.

Ethereum consensus clients implement these two protocols in a peer-to-peer network responsible for handling block gossip and consensus logic, dubbed the Beacon Chain.

This chain runs in tandem to the execution layer, powered by execution clients, responsible for running the Ethereum Virtual Machine (EVM) to execute smart contracts and manage the Execution State, which tracks account balances, contract code, and storage.

​

Consensus in CometBFT

CometBFT implements a Byzantine Fault Tolerant (BFT) consensus protocol that enables state machine replication across a distributed network of validators. The protocol is based on the original Tendermint consensus algorithm, providing both safety and liveness guarantees when less than one-third of validators are Byzantine.

The consensus process follows a round-based approach where validators take turns:

1. Proposing blocks of transactions
2. Voting in two phases (pre-vote and pre-commit)
3. Committing blocks when more than two-thirds of validators pre-commit for the same block

Unlike Ethereum’s Gasper which relies on a hybrid PoS system, CometBFT is a pure BFT protocol that achieves finality in a single shot - when a block receives pre-commits from more than 2/3 of validators, it is immediately finalized with no possibility of reversion.

The protocol is mostly asynchronous, only relying on weak synchrony assumptions for liveness through timeouts that allow skipping unresponsive proposers. This makes it particularly well-suited for networks where validator sets are known and relatively stable.

​

Symphony

While originally designed as an extension to Gasper, Symphony is consensus-gadget agnostic and can be used in conjunction with, e.g., aBFT protocols, which we initially target rather than Gasper.

​

Why Symphony?

Ethereum transactions consist of a sequence of opcodes executed sequentially by the EVM. Today, these transactions (and thus, opcodes) are executed in a replicated fashion, where all execution clients, of all validators, execute all transaction opcodes to come consensus over execution state.

The EVM is purposefully optimized for homogeneous, resource-constrained computation with strict resource limits (see: block gasLimit). This homogeneity is what affords Ethereum the ability to perform synchronous replicated execution across all nodes.

Ritual enables heterogeneous compute to enrich what users can do on-chain. We enhance the EVM by introducing new operations that enable AI Inference, ZK Proving & Verification, TEE Execution, and more. Executing these operations, unlike all EVM opcodes today, requires heterogeneous resources that not only exceed the typical capabilities of validator nodes, but may also take upwards of minutes or even hours to execute.

To support these heterogeneous operations, while preserving the guarantees offered by the Ethereum blockchain, Symphony introduces three key innovations:

1. Execute-once semantics
2. Distributed verification via partitioned proofs
3. Optimized committee election

​

Execute-once semantics

Symphony adopts an execute-once model for heterogeneous operations.

Transaction operations are partitioned into two sets:

1. Homogeneous operations (existing opcodes)
2. Heterogeneous operations (unique Ritual functionality)

Heterogeneous operations are executed only once by selected, staked executor nodes, who gossip their execution outputs to other validators.

When transactions containing these operations appear in a block proposal, rather than re-executing the resource-intensive computation, validators directly slot in the gossiped execution outputs into their EVM state.

To ensure correctness of these gossiped outputs without recomputation, Symphony employs succinct non-interactive proofs of execution, which are prover-optimized (making it much more efficient to assert correctness).

​

Distributed verification via partitioned proofs

While the execute-once model resolves scalability issues in execution, verifying proofs for heterogeneous operations remains challenging. Taking LLM Inference as an example:

1. Proof sizes, though succinct, grow polylogarithmically with model complexity
2. Single blocks may contain many transactions, each generating multiple proofs
3. This inflates block sizes, hinders network propagation, and increases verification overhead

To address these challenges, Symphony introduces three key innovations in distributed verification:

1. Large models are divided into smaller sub-models, each with their own sub-proofs
2. Blocks contain only outputs with off-chain references to associated proofs
3. Validators are assigned sub-proofs deterministically, ensuring that only a subset of validators verify each sub-proof. The network accepts sub-proofs as valid when its assigned validators agree to quorum validity

This approach improves propagation and verification efficiency, minimizes block sizes, and reduces the per-validator verification load while still upholding trust properties.

​

Optimized committee election

Optimized committee election allows Symphony to handle scenarios where no succinct proof system exists or where verifying such a system would be prohibitively expensive.

In these situations, the protocol designates a smaller group of validators who work together to validate the operation outputs, forming a quorum on correctness. Quorum results can be adopted quickly—serving as a fast-path to justified execution—while still remaining compatible with Symphony’s broader principle of execute-once-verify-many-times.