Distributed Sequencer Technology — A Path Towards Decentralized Sequencing

by: Dougie DeLuca

Figment Capital
12 min readMay 24, 2023

Rollups are centralized, but they don’t have to be.

The vision of Ethereum has always been to serve as a global, decentralized network that allows individuals and organizations to transact without the need for intermediaries or centralized control. However, the network has struggled to meet the demands of its growing user base, and is unable to serve as a viable option for everyday transactions.

Ethereum solves for scalability by using rollups (L2s) as the network’s primary execution layer. L2s are designed to provide an inexpensive and scalable alternative to the L1 without compromising economic security. Rollups have successfully provided scalability and affordability, but currently fail to offer sufficient decentralization, the very same problem blockchains were designed to help solve.

Optimistic rollups are one promising solution to Ethereum’s scalability challenges, with teams like Arbitrum and Optimism leading the charge. However, today’s rollups only maintain a single sequencer that is responsible for building and proposing blocks. While this centralized approach offers a simple solution to scale Ethereum in the short term, it is important to consider the implications of sequencer centralization as transaction volume migrates away from Ethereum to L2s.

Creating a fast, decentralized blockchain on top of a slow, decentralized blockchain is a challenging task. Nonetheless, as more L2s launch and a rollup centric Ethereum ecosystem matures, concerns surrounding sequencer centralization will grow louder. To ensure appropriate censorship resistance and liveness guarantees, L2s must be sufficiently decentralized.

Despite the critical importance of decentralization, until very recently, there has been limited public discourse on how to best decentralize the Ethereum L2 infrastructure stack. Given the growing regulatory scrutiny, increased transaction volumes, and technical maturity of many L2s in production, we believe now is the opportune time to push L2s towards decentralization. By doing so, we can ensure the long-term sustainability and security of the Ethereum ecosystem.

Decentralized sequencing can be a difficult topic to cover. In recent weeks, the term “sequencing” has devolved into a convoluted catchall that encompasses various meanings and interpretations. For the purposes of this article, we will be focused on sequencing as it currently exists today: sequencers perform both the role of block builder and block proposer.

Teams and researchers across the space view decentralizing sequencers as a critical issue that requires significant attention. With many projects focused on this challenge, it is unlikely that a prevailing “one-size-fits-all” solution will emerge. Design choices depend on individual preferences, and the resulting tradeoffs can impact system performance.

For instance, general-purpose optimistic rollups such as Optimism may prioritize maximum decentralization by designing their system(s) to handle thousands of independently operated sequencers while also implementing a form of PBS. In contrast, large gaming studios may launch rollups that prioritize flexibility and care less about decentralization. Lastly, application-specific rollups may outsource sequencing to a third party, such as Astria, to provide decentralized sequencing services through a “shared sequencer network.”

Regardless of developer preferences, relying on a single sequencer is not a viable solution; it introduces a central point of failure. Increasing the sequencer count is an essential step towards decentralization, but is also a challenging technical problem. We believe that progressive decentralization using Distributed Validator Technology (DVT), an existing primitive, can provide a more pragmatic solution. Henceforth, we will refer to any use of DVT for decentralizing L2 sequencers as Distributed Sequencer Technology (DST).

In summary, we recognize that there is no one-size-fits-all solution for decentralizing sequencers and that design choices must consider individual preferences and their associated tradeoffs. With the increasing importance of decentralization, we propose using DST to decentralize L2s progressively, taking into account technical feasibility and practicality.

Our rough mental model for how we think about the different offerings today in sequencing

An Overview on Distributed Validator Technology

DVT is an open-source primitive that distributes the duties of a validator by allowing a group of network validators (run by an individual, group, or community of operators) to act as a single validator together. In Obol’s solution, which this piece will focus on, the private validator key is split into pieces and distributed amongst each sub-validator in a Distributed Validator (DV) “cluster.” Once a validator is activated, each node within the DV cluster signs independent attestations using their fractional share of the validator key. These attestations are then aggregated to attest as a full validator node.

In order for a DV cluster to propose a block as a full validator node, each participating cluster member must sign the same data. DV clusters maintain their own coordination layer before coming to consensus and proposing a block.

Obol Network’s DVT framework uses a GoLang-based middleware solution called Charon to facilitate validator coordination within a DV cluster. Multiple Charon clients are configured to communicate with each other to reach consensus and act as a single, unified Proof-of-Stake (PoS) validator. DV clusters are Byzantine fault-tolerant, utilize QBFT consensus, and continue to propose blocks assuming a supermajority of working/honest nodes are present.

Obol effectively eliminates the single point of failure risk for an individual validator. As long as a supermajority of the DV cluster is online and behaving honestly, the full validator node will continue to produce blocks. Adopting DVT promotes greater geographic diversity, reducing the network’s susceptibility to regulatory attacks and other systemic risks, such as power grid failures. It also allows each validator to run many consensus and execution clients, improving validator resilience through client diversity. Lastly, DVT lowers the financial barrier of entry by allowing participating sub-validators to collectively fund any minimum self-bond requirements.

In summary, Obol has the potential to reduce many of the technical, geographic, and financial barriers to validating Proof-of-Stake networks while improving validator uptime and decentralization. Distributed Sequencer Technology can play an equally important role in decentralizing rollups and L2s. It is a solution to the problem of rollup centralization.

DST improves liveness.

In distributed systems, network availability, reliability, and redundancy are paramount. To ensure services and resources are accessible when needed, a network must be consistently available to users. Redundancy and reliability provide the foundation for liveness guarantees, ensuring the network can continue to function even in the face of failures or errors.

DST builds on the foundation laid by DVT to eliminate single points of failure in L2 rollups. Rather than relying on a single machine to operate as the sequencer, DST distributes the responsibility to a cluster of machines — a “DS Cluster.” This approach offers the same benefits as a distributed validator, such as fault tolerance, the potential for client diversity, and geographic distribution to mitigate the risks of outages, malicious behavior, and other systematic risks.

By distributing sequencer clients across a cluster, DST ensures L2 rollups continue to operate even when one or more components fail. It offers a mechanism for ensuring network liveness, which is essential for providing a fast, efficient, and reliable user experience. DST’s redundancy of sequencer clients ensures that the sequencer is always operational and that a supermajority can process transactions, even if one sequencer in the cluster goes offline or becomes unavailable. As a result, DST provides a fault-tolerant and reliable mechanism for ensuring that the network can continue to operate.

DST decentralizes rollups sooner.

When it comes to L2 scalability solutions for Ethereum, achieving “sufficient decentralization” is a crucial goal. However, designing and implementing a system that can seamlessly transition from a single-sequencer to a multi-sequencer setup is a significant challenge that requires extensive research. DST offers a more feasible approach to progressive decentralization, providing a smoother transition towards L2 decentralization and scale-ready liveness.

Progressive decentralization involves gradually distributing block building and block production across multiple sub-sequencers within a single DS cluster. By having multiple sub-sequencers positioned in different locations around the world and potentially run by different entities, the risks associated with a single sequencer setup, such as regulation, latency games, MEV, and censorship, are significantly reduced.

DST increases geographic distribution.

One benefit DST offers L2s is greater geographic distribution. Geographic distribution is a crucial consideration in the design of distributed systems. For example, Ethereum validators using DVT can choose to include an operator on each continent. Similarly, if sequencers using DST were to become distributed, it could also benefit from globally distributed clients. This would be particularly advantageous when a given sequencer is tasked with producing numerous consecutive blocks for a rollup.

While geographic distribution introduces latency, it remains a valuable tool that can be leveraged as needed. As teams are designing their rollups, it is important to carefully consider the implications of geographic distribution and use it strategically to optimize system performance.

DST ≈ PoA

The consensus mechanism utilized in Obol’s DVT framework bears a striking resemblance to Proof of Authority (PoA). PoA is a consensus mechanism that relies on a limited number of nodes authorized to validate and add transactions to the blockchain, thereby relying on the reputation of the validators and trusting the operators to behave honestly. Since the identity of validators is known, any malicious or dishonest entity can be held accountable. However, PoA is more susceptible to centralization risks because the validators are permissioned and have greater control over the network.

A PoA setup with multiple sequencers is practically identical to a single, distributed sequencer with a DS cluster, assuming the number of sequencers and operators in the DS cluster are the same. Both solutions require an identical number of copies of the chain state and a supermajority to arrive at consensus. In multi-sequencer PoA, considerations today often involve a round robin-style rotation for leader election. With DST, something similar might be implemented. As a whole, DST inherits many of PoA’s attributes. It provides an important initial step towards sequencer decentralization by increasing operator accountability, network reliability, and censorship resistance.

Distributed Sequencer Technology for Centralized Rollups

In the world of rollup designs, some teams may prefer greater centralization. However, even if core development teams decide to control and operate every sequencer within the sequencer set, there are benefits to using DST that are worth considering. By using a DS cluster, teams can optimize for liveness without necessarily compromising the benefits that centralization can offer, such as greater flexibility to adapt to changing market dynamics, lower latency, and the ability to capture or share value.

For rollups with no intention to decentralize, maintaining liveness is still a crucial factor to consider. A single sequencer is simply unable to ensure uninterrupted service. DST offers a solution for centralized rollups to remain in control of sequencing while ensuring liveness. Core teams can manage every sequencer in the DS cluster and guarantee near 100% uptime. This is particularly relevant for rollups focused on gaming applications, which require low latency and high reliability. Currently, there is no solution that offers rollups the flexibility to increase the sequencer set while improving reliability and redundancy. DST is best suited to become an immediate solution and serve as a common implementation across centralized rollups seeking some form of distributed sequencing, regardless of Nakamoto Coefficient.

Implementing DST

The benefits DST offers to rollups warrant more research into potential DST implementations. With DVT already active on Ethereum’s L1, the blueprint for its L2 implementation is largely in place and will be easiest for rollups with a high degree of “Ethereum equivalence.”

Rollups achieve Ethereum equivalence by adopting Ethereum’s existing infrastructure and code. Optimism serves as a prime example of a team that prioritizes maximal Ethereum compatibility, as evidenced by its recent Bedrock upgrade. Bedrock leverages the existing Ethereum execution engine API, which enables the rollup’s consensus client, op-node, to use the battle-tested Ethereum L1 execution clients with minimal changes. This design decision not only makes it easier for developers to add support for other execution clients like Erigon, but also allows the OP Stack to benefit from and contribute back to the L1 ecosystem. Optimism’s close resemblance to Ethereum offers user experiences that are nearly identical for anyone interacting with the chain.

Optimism can facilitate the implementation of DST by introducing a streamlined Beacon-API server on its op-node client. This server emulates the equivalent Layer 1 API found on consensus clients, allowing for the segregation of state transition validation from its calculation. Such a pattern is commonly observed at L1, where consensus clients and dedicated validator clients are separate entities. The latter are designed with specific purposes in mind, such as preventing slashing, safeguarding private keys, and prioritizing simplicity and security. Adopting an API that includes L2 validator clients as a building block for distributed sequencer sets would allow the OP Stack to once again tap into the tooling developed for Ethereum’s L1. In this case it is the Ethereum staking tooling they could leverage and re-purpose.

As teams begin to close the Ethereum equivalence gap, L2 state transition designs will incrementally bear greater resemblance to the L1 API. This would allow L2 sequencers to be run identically to an L1 validating node. With enough time and testing, the operational experience should allow L2s to achieve the same scale of decentralization as the underlying L1.

It should be noted that changes to Optimism (and potentially L1 validator clients) would be needed to implement Ethereum equivalence at the sequencer/validator layer as described above. However the network effect of re-using L1 key management in our eyes would be valuable. One major effect of adopting this model would be rollups’ adoption of Boneh-Lynn-Shacham (BLS) signature support. So far, Optimism’s architecture has only needed the Secp256k1 elliptic curve and the ECDSA signature scheme, cryptographic primitives used in the Bitcoin and Ethereum execution layers.

BLS signatures allow for efficient signature aggregation and verification using Elliptic Curve cryptography. The cryptographic signature was originally popularized by Dfinity who utilized it to create a source of distributed randomness through a mechanism called “threshold relaying.” Ethereum uses the BLS signature scheme to facilitate secure cryptography within the protocol at a scale unachievable with Secp256k1. The BLS signature scheme allows validators to sign messages that can subsequently be aggregated and verified at scale, enabling a pure PoS system with a massive number of validators to run on consumer grade hardware. More on the BLS specifications used by Ethereum can be found in the official specifications repository.

If Optimism’s plan to become fully compatible with Ethereum’s consensus layer is achieved, BLS signature support will be required. As rollup teams compete for Ethereum equivalency in all aspects, transitioning to support BLS signatures and the beacon chain API is a significant step towards achieving this goal.

Incorporating Ethereum’s schemes, code, and infrastructure allows rollups to stay current with the network and inherit new innovations adopted by the L1. Further discussion about the importance of Ethereum equivalence is outside the scope of this article. That said, we think DST compatibility will provide added benefits to teams seeking to build L2s with a high degree of Ethereum equivalency.

Final Thoughts

Distributed Sequencer Technology offers L2s a promising new way to incrementally decentralize. Regardless of the features a rollup is optimizing for, the benefits from adopting DST span across several preferences. As a standalone solution, DST empowers L2s by enhancing liveness guarantees, censorship resistance, geographic distribution, and increased decentralization. In a multi-sequencer setup, DST aligns with the principles of Distributed Validator Technology (DVT) at the L1 consensus layer, further decentralizing the network and bolstering system resilience. DST has the potential to expand the design space of L2 sequencing and adds another viable solution to the L2 decentralization toolkit. Currently, DVT is best positioned to support Ethereum Equivalent rollups, but the Obol team has begun to set its sights beyond Ethereum. The team has recently announced plans to expand into the Cosmos ecosystem as well.

The majority of large scale, general purpose rollups should not rely on a single sequencer in the future. While maximal decentralization is not a fit for all rollup applications, having a single point of failure isn’t either. By leveraging DST, that vulnerability can be eliminated. We eagerly anticipate the evolution and growth of the DST design space.

Further analysis should be conducted to better understand the implications of implementing DST and how it can impact latency, throughput, and other performance-related metrics. We hope this article first brings attention to DVT and some of the problems DST could potentially solve but also understand it may raise other important questions that remain unanswered. Our goal is to start a dialogue and consider whether DST is a concept worth exploring further.

If you share an interest in decentralizing Layer 2s, exploring DVT, or engaging in related discussions, we would be delighted to connect and exchange ideas.

Acknowledgements: Special thanks to Oisín Kyne and Collin Myers from Obol Network for the great discussions and feedback which contributed to this piece. Also many thanks to Neel Somani (Eclipse), 0xkrane, Yuki Yuminaga (Fenbushi Capital), James Parillo (Figment Capital), and many others for their feedback and contributions.

--

--