Symphony

---

​

Existing consensus protocols

Most blockchains today operate on a simple principle: replicated execution, where all nodes re-execute each block to achieve two goals:

1. Verify transactions through re-execution
2. Compute and apply state updates to their local state

This model has traditionally worked well because most computations were simple and had homogeneous resource consumption (e.g., basic arithmetic operations or hash functions).

---

​

Symphony

To address this heterogeneous workload challenge, we developed an optimized execution and verification model via a new consensus protocol, dubbed Symphony.

Symphony builds upon an Execute-Once-Verify-Many-Times (EOVMT) model by which select compute nodes act as sole executors of workloads, generating succinct sub-proofs for executed compute.

---

​

Execute Once

Ritual executes inference SPC opcodes externally to the EVM, with the resulting outputs seamlessly integrated back into the EVM. Inference SPC opcodes can take several minutes and even hours to execute, and synchronously processing them in a replicated fashion would drastically increase block times, potentially bringing block production to a halt and severely impacting the chain’s performance and liveness.

To address this, we adopt an Execute-Once model for inference opcodes.

In this approach, these opcodes are executed asynchronously off-chain by selected compute nodes in a specialized environment.

To eliminate the need for verification of off-chain computations through replicated execution, we use succinct proofs that can be efficiently verified by validators.

Notably, since SPC opcode execution and proof generation occur asynchronously off-chain, proof generation does not impact the on-chain critical path.

With this Execute-Once semantic, inference opcodes are executed once by the designated compute node, and validators efficiently verify the proofs to accept the results, without redundant re-execution.

---

​

Verify Many Times

Although Execute Once addresses the unscalability of replicated execution, verifying proofs for complete model inference opcodes poses significant scalability challenges.

Replicated verification, akin to traditional blockchains where all validators verify all proofs on-chain, significantly slows block processing, compromising network liveness.

To overcome these challenges, Ritual employs a four-pronged scalability strategy for verification that defines the Verify Many Times primitive as an improvement over replicated verification.

---

​

Partitioned proofs

To further optimize proof generation, gossip, and verification, we introduce novel optimizations:

1. Model partitioning: large models are partitioned into smaller sub-models, with separate sub-proofs generated for each partition. This produces smaller sub-proofs that are easier to propagate, handle, and verify.

2. Proof sharding: depending on the proof system being utilized, each sub-proof can be further divided into proof shards by breaking the computation trace of the original proof into smaller fragments, leveraging the inherent structure of the proof system.

3. Storing proof shards off-chain: instead of embedding these proof shards (for each SPC opcode of an inference transaction) directly on-chain, they are stored off-chain. Blocks include only the outputs of inference SPC opcodes and references to the corresponding proofs, keeping verification metadata minimal.

4. Distributed verification: instead of requiring all validator nodes to verify every proof shard for every transaction (replicated verification bottleneck), Ritual distributes the verification workload. Each proof shard is assigned to a subset of validators through uniform deterministic assignment. A quorum of these assigned validators verifies each proof shard, and their consensus is accepted by the network. The output of an inference SPC opcode is considered trusted and fully validated when all of its associated proof shards validated by the quorum of assigned validators. It is worth noting that, in addition to uniform deterministic assignment, EOVMT is compatible with broker-based solutions for verifier assignment, such as Resonance.

---

​

Lifecycle

Putting it all together, EOVMT works as follows:

---

​

Flexible proof systems

Symphony’s EOVMT approach supports multiple proof systems to balance performance and security:

1. TEE Attestations: Our initial implementation uses Trusted Execution Environments for rapid verification. TEEs provide hardware-backed security guarantees and enable quick transaction confirmation.

2. Zero-Knowledge Proofs: We are developing ZK-based implementations in parallel, which will offer stronger cryptographic guarantees for computations requiring enhanced privacy and security.

3. Hybrid Solutions: Future implementations may combine both approaches— using TEEs for fast transaction confirmation while adding ZK proofs for additional security guarantees.

This flexibility allows us to optimize for different use cases while maintaining Symphony’s core benefits of reduced execution overhead and efficient verification.

---

​

Key benefits

With EOVMT, consensus is:

This approach eliminates the inefficiencies of replicated execution (where all nodes re-execute) and replicated verification (where all nodes verify all proofs). It also introduces native support for node specialization, allowing the network to operate more efficiently and at scale.

---

​

Safety and Liveness

Liveness guarantees that the system continues to operate without halting. Symphony achieves this through its incentive mechanism, which ensures that compute and validator nodes are economically motivated to perform their roles.

This economic liveness mechanism is similar to Ethereum 2.0, where rewards and penalties maintain the participation of network actors.

Safety ensures that the protocol remains free of vulnerabilities that could lead to incorrect state transitions. Symphony adopts a probabilistic (computational) safety approach. With at least $\frac{2}{3}$ of the total staked value controlled by honest participants and uniformly staked validators, Symphony leaves only a negligible chance of safety violation, comparable to the probability of a secure hash collision. This ensures that the system’s integrity is preserved with near-absolute certainty.