Consensus at Ritual

Modern blockchains spend the overwhelming majority of their consensus efforts on maximizing TPS via minimizing latency and maximizing throughput. These efforts have borne fruit over recent years, as state of the art consensus protocols such as Minimmit, MonadBFT, and Alpenglow exhibit highly impressive performance benchmarks for latency and throughput.

But that roadmap hides a deeper assumption about what a blockchain is for. If autonomous intelligence is going to become a first-class citizen of the chain, consensus can no longer treat execution as an opaque afterthought. It has to reason directly about heterogeneous, expensive, and sometimes non-deterministic computation. We think autonomous intelligence is one of the most important problems of the century, with the long-run horizon of autonomous intelligence indistinguishable from humans. Consensus is one of the places where that broader thesis becomes concrete.

The implicit assumption

Given the fact that existing protocols are likely approaching an endgame state in terms of latency and throughput, one might think that existing infrastructure already suffices for a scalable decentralized world computer. But that roadmap hides an implicit assumption: that execution costs are subsumed by communication costs.

Present landscape

Most protocols implicitly assume that the expensive part of consensus is peer-to-peer interaction: gossiping, voting, and not computation. Transactions are treated as opaque payloads, and consensus is largely oblivious to their content, semantic meaning, and, in particular, execution cost. Such a mental model is justified for lightweight applications such as payments, but it breaks once one aims to support heterogeneous compute on-chain. LLM inference, model training, and more general agentic workloads are computationally demanding tasks, and convoluted dependencies can arise between payloads whose execution latency far exceeds the cost of round-trip communication.

As such, at Ritual we have had to confront a different desideratum: endowing consensus itself with execution-aware properties. This is not just a performance preference. It is part of what it takes to make computational sovereignty real for systems whose cognition cannot be reduced to cheap, deterministic state transitions.

Execution-aware consensus

Execution-aware consensus treats slow execution as a central constraint in consensus. Such a refocusing introduces novel challenges that force protocol changes, and simultaneously unlock new possibilities that provide improved UX. While the full richness of the design space is beyond the scope of this write-up, here we discuss several preliminary observations on execution-aware consensus, along with specific design choices we have made at Ritual and future directions for exploration.

A naive and straightforward solution to handling expensive payloads is simply more time: increase the view length of, for example, Simplex (the base protocol we employ at Ritual) to comfortably allow proposers to execute an expensive payload and broadcast it to the network. The downsides are obvious:

1. Liveness of the chain is bottlenecked by expensive payloads.
2. Latency cost is borne even during periods of low execution demand.

Ideally, we want a consensus protocol that enjoys execution properties in the same spirit as common network properties. In other words, execution-responsiveness: consensus latency should be competitive with the current workload’s execution costs, not worst-case costs. This north star guides several of the design choices at Ritual, the first of which, superposition of execution, is already in production.

Superposition of execution

By far, the two most common approaches to maintaining state consistency between validators are replicated execution, in which all validators re-execute a workload and compare the resulting state, and proof-based approaches, in which execution is delegated to a single party and the remaining validators verify that computation. We refer to the latter approach as Execute-Once-Verify-Many-Times (EOVMT). This distinction matters for Ritual because EOVMT is not merely an optimization over replicated execution. For many of the workloads we care about, especially expensive or randomized ones, it becomes the only coherent way to preserve correctness without requiring every validator to reproduce computation that is either prohibitively costly or structurally non-reproducible.

Interpolating between these extremes yields a rich design space. At Ritual, we combine both approaches in a single consensus system, allowing us to support traditional workloads alongside compute-heavy ones over shared state. Concretely, we separate workloads into two lanes: synchronous (sync) and asynchronous (async).

Sync transactions

The sync lane is the standard lane for canonical EVM transactions, such as payments. Ritual’s approach to sync workloads mirrors the industry standard of replicated execution: all validators re-execute the workload upon block arrival and compare the resulting states.

Async transactions

Async transactions are where execution-aware consensus becomes unavoidable. Some transactions are too computationally demanding, or too poorly matched to replicated execution, to sit on the consensus critical path. This includes expensive ML-related workloads such as LLM inference, as well as non-deterministic workloads more broadly. We therefore handle async workloads with EOVMT, which we further optimize by allowing validators to skip verification of certain work once enough attestations have been collected, allowing slower validators to catch up more quickly.

EOVMT alone, however, is still not sufficient. We also want to decouple chain progress from the completion of async workloads, so that consensus can continue while expensive computation finishes off the critical path. For that purpose, we introduce async commitments and settlements.

Async commitments and settlements

Async workloads are divided into two parts: an async commit, which commits to the input of the workload, and an async settlement, which is included in a block once the computation result is retrieved from the SNARK or TEE prover responsible for execution. This allows consensus to continue seamlessly while waiting for the result of the async call.

This commit-settle structure matters for more than throughput. It gives long-lived computation a clean lifecycle on-chain. A workflow can begin in one block, continue while the chain advances, and settle later without stalling the rest of the system. That kind of temporal continuity is one of the practical preconditions for autonomy.

Ritual’s vision of heterogeneous compute also involves dual safety: allowing users to choose the level of security they desire for each async call, from full TEE attestation to cryptographically secure SNARK proofs. In that sense, finality is partly in the eye of the beholder. Different applications can demand different assurance-latency tradeoffs, rather than inheriting a single global trust model.

While on its surface EOVMT may appear to be an efficiency tool, facilitating delegation of expensive computation to a single validator, it unlocks a much richer design space for modern workloads, particularly those that are non-deterministic. LLM inference, for example, is not merely computation of a fixed circuit, but often a sampling process from a distribution. In that setting, tools that prove correctness are lifted from optional optimizations to necessary infrastructure. Replicated execution is not only wasteful for such workloads; in many cases it is no longer a valid way to guarantee correctness.

Several additional designs and future directions also directly address execution-responsiveness, but before discussing them it is worth turning to the other main facet of the applications enabled by execution-aware consensus.

Capability reclaiming: Extended External Validity (EEV)

Unlike Web2 systems, modern blockchains still suffer from significant UX limitations. A user’s fine-grained control over how their transactions interact with the chain is limited: they often lack control over ordering, inclusion, exclusion, and more complicated preferences over execution. As is now well known, these UX gaps leave users open to significant economic exploitation, including MEV.

At Ritual, we aim to build a blockchain that is much closer to the Web2 experience with respect to UX, while preserving the guarantees that make blockchains worth using in the first place. In particular, we want to reclaim many of the capabilities currently concentrated in block proposers and reassign them to users and applications. The main tool for doing that is validity constraints.

Extended External Validity

External validity is a ubiquitous requirement in blockchains. It often takes the form of syntactic checks on the structure and contents of a proposed block, such as well-formed transactions and verified signatures. At Ritual, we push that notion further and use it to endow users and applications with much more fine-grained control over their interaction with the chain, including scheduled transactions, sequencing rights, and forced exclusion.

In that sense, these constraints are not an auxiliary feature. They are the mechanism through which parts of proposer power are transferred from validators to users and applications, while still remaining inside the consensus safety and liveness envelope. This is one of the clearest ways in which consensus contributes to something like emancipation for autonomous systems: important execution rights are enforced by protocol rules rather than left to proposer discretion.

Scheduled transactions

Execution-aware consensus finds one of its most user-facing expressions in scheduled transactions. Users submit work for future execution, and the chain guarantees when it runs based on a predicate provided by the user. Crucially, this is enshrined in the protocol: inclusion of scheduled transactions is mandatory for block validity, and enforcement happens during consensus at the block-building level.

From a user’s perspective, this begins to resemble a Web2-style flow while still preserving stronger censorship-resistance guarantees. From a consensus perspective, scheduled transactions are enabled by predictable validity: the property that the proposer and validators can agree on the state against which these predicates are evaluated when the block is built. Without that property, state-dependent guarantees of this kind cannot be enforced reliably.

Scheduled transactions also matter for autonomy because they give applications temporal continuity. A workflow can move forward under protocol guarantees without requiring a human to resubmit intent at every step. When combined with asynchronous computation, that begins to look much more like infrastructure for agents than infrastructure for one-off user actions.

Sequencing constraints

Order-based MEV is perhaps the most notorious example of proposer discretion becoming user harm, and the benefits of allowing users to specify more complex constraints over the order in which their transactions may appear with respect to one another are straightforward. A canonical example is cancel priority. Similarly to scheduled transactions, we enshrine sequencing constraints expressed by users and applications; blocks that do not satisfy them are deemed invalid.

Forced exclusion

Forced exclusion allows users to express conditions under which they demand that their submitted transactions be excluded from the current block. While this might initially seem subsumed by scheduled transactions, it is meaningfully different: forced exclusion can express constraints over the block currently being built. In other words, it requires state staleness of 0, whereas scheduled transactions in the form described above require state staleness of 1. We will discuss state staleness in consensus, and its interaction with other properties of interest, in a future post.

Future directions

Dynamic timeouts

This is the other side of the execution-responsiveness coin. Superposition of execution moves expensive workloads off the consensus critical path and allows synchronous traffic to continue flowing, but block proposers still face another important computational burden: satisfying EEV constraints. As soon as one is serious about supporting sophisticated user and application validity constraints on block assembly, the proposer’s search problem becomes materially harder.

This creates a direct consensus challenge. Block proposers have only a limited window of time to construct a valid block before other validators time out and vote to skip the current view. At best, this slows the chain down and makes the proposer’s work obsolete. At worst, if the issue persists across views, it can threaten liveness.

Naively, one could address this by setting the proposer’s search window to a conservatively large fixed value that accommodates any traffic pattern we expect to see on-chain. The downside is that such a setting would make the chain impractically slow in the common case. In practice, we expect the complexity of block assembly to be relatively stable most of the time, with occasional spikes when demand or sophistication rises sharply, such as during MEV opportunities. A more elegant approach is to determine this search window dynamically, in the hope of anticipating the cost and complexity of block assembly in a given view. That approach presents several challenges from a consensus perspective, which we will elaborate on in a future post.

Heterogeneous failures

Traditionally, deployed consensus protocols assume an uncorrelated adversary structure: the protocol is secure against any set of corrupt parties so long as its size remains below the relevant threshold. In practice, however, failures are rarely random. Knowledge about the location, hardware, or identity of validators can help us model correlated failures that better reflect the network we actually have.

The consensus literature contains a long, far from settled line of work on correlated families of adversaries, with feasibility and impossibility boundaries depending on the family considered. At Ritual, we aim to incorporate security against correlated failure structures without inheriting the full complexity of that literature wholesale. The idea is to empirically extract the kinds of correlated failures we should expect from our validator distribution and tailor the protocol accordingly. If autonomous systems are to depend on this substrate for long-lived operation, robustness to real failure structure matters as much as nominal fault thresholds.

Network routing

The overwhelming majority of consensus literature, both in theory and in practice, abstracts away the network layer and treats the network as a peer-to-peer clique in which any pair of validators has a direct communication link. In practice, communication is often carried out through gossip protocols of various kinds, and the actual communication graph looks very different.

Arguably, one reason this modeling choice has persisted is that routing in the presence of adversarial participants is highly non-trivial. Recent lines of work even show deep connections between such questions and PCPs and proof systems. At Ritual, we aim to investigate simple ways to incorporate network routing into consensus latency considerations, with the goal of pushing round-trip latency lower still.

Comparison to the space

Most chains treat execution as an afterthought and spend most of their effort perfecting peer-to-peer latency and throughput.

• Minimmit, a top candidate for adoption by Tempo, adopts the fast-path Simplex protocol, reaching consensus via a single round-trip of votes. It also incorporates continued block-building, allowing chain growth even with only 40% of active stake.
• Solana’s Alpenglow incorporates a fast-path/slow-path approach, providing blocks two avenues to reach finalization: 60% of stake in two round-trips of votes, or 80% of stake in one round-trip of votes, leading to significant latency reduction in practice. Its Rotor mechanism further enables rapid block propagation using erasure codes and Merkle proofs.
• MonadBFT sticks with the two-round-trip approach, which allows for optimal resilience to Byzantine faults. It further optimizes the protocol by pipelining block proposals while remaining resilient to reorgs, and provides optimistic finality with accountability guarantees.
• Hyperliquid has incorporated aspects of EEV into its chain, specifically those related to financial applications such as cancel priority.

Endgame for execution-aware consensus

The north star of the execution-aware approach to blockchains is to provide a user experience that is increasingly indistinguishable from Web2 platforms: allowing users and applications to express heterogeneous and arbitrary preferences and constraints on their actions and interactions with the chain in an enshrined manner. But the deeper point is not UX polish alone. It is to make the chain capable of hosting sophisticated software that can express, preserve, and enforce meaningful preferences over its own execution. That is part of what it would take for autonomous intelligence to operate on-chain with real independence.