Rollups are centralized, although this isn't a requirement for them in any way. Ethereum's goal from the beginning has been to become a worldwide, decentralized network that eliminates the need for middlemen and centralized control, making it possible for individuals and organizations to conduct transactions directly with one another. However, the network has had trouble keeping up with the demands of its expanding user base, and as a result, it is unable to function as a viable choice for transactions that occur on a daily basis.

Rollups, also known as L2s, are used as the primary execution layer on Ethereum's network, which allows it to scale efficiently. The L2 is intended to be a low-cost and scalable alternative to the L1 that does not compromise the economy's safety in any way. Rollups have been able to successfully provide scalability and affordability, but they are unable to give sufficient decentralization at this time. This is precisely the issue that blockchains were developed to overcome.

Teams like Arbitrum and Optimism are leading the push in the implementation of optimistic rollups, which is one of the more promising solutions to Ethereum's scalability concerns. However, rollups of today simply maintain track of a single sequencer, which is tasked with the responsibility of constructing and presenting blocks. It is vital to evaluate the consequences of sequencer centralization as transaction volume shifts away from Ethereum and toward L2s. Although this centralized approach provides a straightforward solution to scale Ethereum in the short term, it is important to note that the mechanism is not decentralized.

It is a tough effort to create a blockchain that is both fast and decentralized on top of an existing blockchain that is slow and decentralized. Concerns over sequencer centralization will become more prevalent despite the emergence of additional L2s and the maturation of an Ethereum economy focused on rollups. The level of decentralization of L2s must be sufficient if they are to offer acceptable resistance to censorship and assurances of liveness.

In spite of the paramount significance of decentralization, there has been a paucity of public dialogue up until very recently on the topic of how to decentralize the Ethereum L2 infrastructure stack in the most effective manner. We feel that now is the appropriate time to push L2s toward decentralization as a result of the increasing regulatory scrutiny, greater transaction volumes, and technical maturity of many L2s that are already in production. If we follow this course of action, we will be able to assure the long-term viability and safety of the Ethereum ecosystem.

Covering a subject like decentralized sequencing might be challenging at times. In the most recent weeks, the definition of "sequencing" has morphed into a vague catchall phrase that can be interpreted in a variety of ways and incorporates a wide range of meanings. For the sake of this article, we will be focusing on the sequencing process as it exists at the present time, which means that sequencers serve as both the block constructor and the block proposer.

The decentralization of sequencers is seen as an important subject that calls for a large amount of attention from teams and researchers all across the area. Given the number of projects being worked on to find a solution to this problem, it is highly improbable that a "one-size-fits-all" answer will emerge. Individual preferences heavily influence design decisions, and the tradeoffs that arise can have an effect on how well a system functions.

For example, general-purpose optimistic rollups like Optimism may prioritize maximal decentralization by developing their system to handle thousands of independently operated sequencers while also implementing a form of PBS. This can be accomplished by constructing their system to handle thousands of independently operated sequencers. On the other hand, huge gaming studios may launch rollups that place a higher priority on adaptability and concern themselves less with decentralization. In conclusion, application-specific rollups may choose to contract out the sequencing process to a third party, such as Astria, in order to deliver decentralized sequencing services via a "shared sequencer network."

Regardless of the desires of the developers, reliance on a single sequencer is not a workable approach because it creates a single point of failure for the entire system. Increasing the number of sequencers is a necessary step toward decentralization, but it also presents a significant technical problem to be solved. We think that an existing primitive called Distributed Validator Technology (DVT), when combined with gradual decentralization, could give a solution that is more applicable to real-world situations. From this point forward, any implementation of DVT that involves decentralizing L2 sequencers will be referred to as Distributed Sequencer Technology (DST).

Simply put, we acknowledge that decentralizing sequencers does not have a single, universally applicable solution and that design decisions must take into account both individual preferences and the tradeoffs that are associated with them. In light of the growing significance of decentralization, we propose making use of DST in order to gradually decentralize L2s, taking into account both the technical feasibility and the practicality of the approach.

Distributed Validator Technology (DVT) Overview

DVT is a basic that is open-source and allows for the distribution of the tasks of a validator by making it possible for a collection of network validators to operate as a single validator collectively. These network validators may be controlled by an individual, a group, or a community of operators. This section will concentrate on Obol's method, which involves dividing the private validator key into pieces and distributing those pieces to all of the sub-validators that make up a Distributed Validator (DV) "cluster." After a validator has been engaged, every node that is part of the DV cluster will sign independent attestations with their respective fractional share of the validator key. After that, all of these attestation are compiled into a single comprehensive validator node attestation.

Source: Obol network

Each participant in a DV cluster needs to sign the same data in order for the cluster to be able to propose a block for use as a full validator node. Before reaching a consensus and putting out a block proposal, DV clusters keep their own coordination layer operational.

To facilitate validator cooperation inside a DV cluster, Obol Network's DVT architecture makes use of a middleware solution named Charon that is based on the GoLang programming language. Multiple Charon clients can be set to communicate with one another in order to arrive at a consensus and to perform the functions of a single, unified Proof-of-Stake (PoS) validator. DV clusters are fault-tolerant in the case of Byzantine faults, use QBFT consensus, and will continue to propose blocks even in the event that a supermajority of working and honest nodes are present.

The possibility of having a single point of failure in an individual validator is effectively removed, thanks to Obol. The entire validator node will keep producing blocks so long as an overwhelming majority of the distributed validator cluster is online and acting in a trustworthy manner. Adopting DVT encourages increased geographic variation, which in turn lowers the network's sensitivity to regulatory threats and other systemic risks, such as the failure of power grids. In addition to this, it enables each validator to manage a large number of consensus and execution clients, hence enhancing the validator's resistance to failure through increased client variety. Lastly, DVT lowers the financial barrier to entry by allowing participating sub-validators to jointly cover any minimum self-bond requirements. This eliminates the need for individual sub-validators to individually fund these requirements.

In the end, Obol has the prospective to eliminate a significant number of the technological, geographical, and monetary obstacles that exist in the way of verifying Proof-of-Stake networks while simultaneously enhancing uptime for validators and fostering decentralization. When it comes to decentralizing rollups and L2s, Distributed Sequencer Technology has the potential to play an equally vital role. It is an answer to the issue of rollup centralization that has been occurring.

Distributed sequencers Tech (DST): A dive into

DST enhances the liveliness of the network

Network availability, reliability, and redundancy are of the utmost importance in distributed system architectures. A network must always be available to its users in order to guarantee that its services and resources can be accessed when they are required. The foundation for liveness assurances is provided by redundancy and dependability, which ensures that the network can continue to function normally even in the event of malfunctions or mistakes.

DVT lays the groundwork for DST, which then builds upon that foundation to remove single points of failure in L2 rollups. DST does not rely on a single system to serve as the sequencer; rather, the task is distributed among a cluster of devices that together are referred to as a "DS Cluster." This strategy has the same advantages as a distributed validator, including fault tolerance, the possibility of client variety, and geographic spread, all of which help to reduce the risk of outages, malicious conduct, and other systematic dangers.

dst enhance liveness

Source: Figment

DST assures that L2 rollups will continue to function even in the event that one or more of the components fails by dispersing sequencer client processes throughout a cluster. It provides a technique for assuring network liveness, which is vital for offering a user experience that is quick, efficient, and dependable. The redundancy of sequencer clients provided by DST ensures that the sequencer is always active and that a supermajority can process transactions, even if one sequencer in the cluster goes offline or becomes inaccessible. This is the case even if one sequencer in the cluster goes offline or becomes unavailable. As a consequence of this, DST offers a technique that is both fault-tolerant and reliable in order to guarantee that the network will be able to continue operating.

DST decentralizes rollups.

When it comes to finding answers for Ethereum's L2 scalability issues, achieving "sufficient decentralization" is an important goal to work toward. However, building and implementing a system that can seamlessly transition from a single-sequencer setup to a multi-sequencer setup is a huge issue that requires thorough research. This can be accomplished by designing a system that can transition from a single-sequencer arrangement to a multi-sequencer setup. DST provides a more seamless transition towards L2 decentralization and scale-ready liveness. This makes it a more practical method for progressive decentralization, which is one of the benefits it offers.

The process of gradually dispersing block building and block production over several sub-sequencers inside a single DS cluster is what we mean when we talk about progressive decentralization. Risks associated with a single sequencer configuration, such as regulation, latency games, MEV, and censorship, are considerably reduced when many sub-sequencers are positioned in different locations throughout the world. These sub-sequencers could be managed by different groups.

The transition to DST helps boost the geographic spread.

Greater geographic spread is one of the advantages that DST provides for L2s. When designing distributed systems, geographic distribution is one of the most important factors to take into account. For instance, Ethereum validators that make use of DVT have the option to incorporate an operator on each continent. In a similar vein, if sequencers that use DST were to become distributed, the system might likewise benefit from having clients located all over the world. This would be of particular use when a particular sequencer is charged with constructing a rollup that consists of a number of blocks that are produced in succession.

Even if geographic dispersion results in latency, it is nevertheless a valuable tool that can be utilized whenever it is required to do so. When developing their rollups, teams need to make sure to give careful thought to the implications of geographic distribution and employ it strategically in order to achieve the highest possible level of system performance.

Proof of Authority

Proof of Authority (PoA) is strikingly similar to the consensus process that Obol's DVT framework employs, and this similarity is not coincidental. PoA is a consensus technique that relies on the reputation of the validators and trusts the operators to operate honestly. It does this by relying on a restricted number of nodes that are authorized to validate and add transactions to the blockchain. Because the identities of the validators are publicly available, any entity that is dishonest or evil can be held accountable. On the other hand, Proof of Authority is more prone to centralization problems due to the fact that validators in this model are granted permissions and have a greater degree of influence over the network.

Source: Figment

If the number of sequencers and operators in the DS cluster is the same, then a PoA configuration with numerous sequencers is nearly equivalent to a single distributed sequencer with a DS cluster. This is the case providing that the number of sequencers in the PoA arrangement is the same. In order to reach a consensus, each of these solutions necessitates the use of a supermajority as well as the same number of copies of the chain state. Considerations for today's multi-sequencer PoAs sometimes include a rotational format similar to round robin for the choosing of a leader. It's possible that something comparable will be adopted with DST. Many of PoA's characteristics are passed down to DST. It increases operator responsibility, network reliability, and censorship resistance, which are all critical initial steps toward the decentralization of sequencers.

DST Implementation

Some teams may choose greater centralization in the world of rollup designs. Even if core development teams elect to control and run each sequencer in the sequencer set, there are advantages to employing DST that should be considered. Teams may optimize for liveness while retaining the benefits of centralization, such as better flexibility to adjust to changing market dynamics, lower latency, and the opportunity to collect or share revenue, by employing a DS cluster.

Maintaining liveness is still an important consideration for rollups that do not want to decentralize. A single sequencer just cannot provide continuous service. DST provides a method for centralized rollups to maintain sequencing control while remaining live. Core teams can control every sequencer in the DS cluster while ensuring near-perfect uptime. This is especially true for rollups geared at gaming applications, which demand minimal latency and excellent reliability. There is currently no technology that allows rollups to expand their sequencer set while boosting reliability and redundancy. Regardless of Nakamoto Coefficient, DST is best suited to become a quick solution and serve as a standard implementation across centralized rollups wanting some type of distributed sequencing.

The advantages that DST provides to rollups justify more investigation into prospective DST deployments. DVT is already operational on Ethereum's L1. Therefore, the plan for its L2 implementation is mostly in place and will be most convenient for rollups with a high degree of "Ethereum equivalence."

By utilizing Ethereum's current infrastructure and programming, rollups achieve Ethereum equivalence. As indicated by its latest Bedrock update, Optimism is a perfect example of a team that targets maximum Ethereum compatibility. Bedrock makes use of the current Ethereum execution engine API, allowing the rollup's consensus client, op-node, to utilize the battle-tested Ethereum L1 execution clients with little modifications. This design choice not only makes it easy for developers to add support for different execution clients, such as Erigon, but it also allows the OP Stack to benefit from and contribute to the L1 ecosystem. Optimism's strong similarity to Ethereum provides virtually equal user experiences for everyone dealing with the chain.

Optimism can help with DST implementation by offering a simplified Beacon-API server on its op-node client. This server emulates the analogous Layer 1 API seen on consensus clients, allowing state transition validation to be separated from its computation. This is a frequent pattern at L1, where consensus clients and specialized validator clients are distinct entities. The latter are built with specific goals in mind, such as avoiding slashing, protecting private keys, and emphasizing simplicity and security. Adopting an API with L2 validator clients as a building block for distributed sequencer sets would allow the OP Stack to re-use the technology built for Ethereum's L1. In this situation, they could use and repurpose Ethereum staking tooling.

As teams work to narrow the Ethereum equivalence gap, L2 state transition designs will become more similar to the L1 API. This would allow L2 sequencers to execute in the same manner as an L1 validating node. With enough time and testing, L2s should be able to reach the same level of decentralization as the underlying L1.

Changes to Optimism (and maybe L1 validator clients) would be required to enable Ethereum equivalence at the sequencer/validator layer, as stated above. However, we believe that the network impact of reusing L1 key management will be beneficial. Adopting this strategy would have a significant impact on rollups' adoption of Boneh-Lynn-Shacham (BLS) signature support. Optimism's design has thus far only required the Secp256k1 elliptic curve and the ECDSA signature technique, which are cryptographic primitives utilized in the Bitcoin and Ethereum execution levels.

Using Elliptic Curve cryptography, BLS signatures provide quick signature aggregation and verification. Dfinity popularized the cryptographic signature by using it to provide a source of distributed randomness via a method known as "threshold relaying." Ethereum employs the BLS signature technique to enable safe cryptography within the protocol on a scale that Secp256k1 cannot. The BLS signature mechanism enables validators to sign messages, which can then be aggregated and validated at scale, allowing a pure PoS system with a large number of validators to function on consumer-grade hardware. The official specs repository contains further information on the BLS specifications utilized by Ethereum.

BLS signature support will be necessary if Optimism's ambition to become completely compatible with Ethereum's consensus layer becomes a reality. As rollup teams fight for Ethereum equivalence in all respects, supporting BLS signatures and the beacon chain API is an important step toward that aim.

Rollups may stay current with the network and inherit new innovations accepted by the L1 by incorporating Ethereum's schemes, code, and infrastructure. This article does not go into further detail on the significance of Ethereum equivalency. Having said that, we believe DST compatibility will help companies looking to construct L2s with a high degree of Ethereum equivalence.

Conclusion

Distributed Sequencer Technology provides a potential new technique for L2s to gradually decentralize. Regardless of the qualities a rollup optimizes for, the advantages of using DST cover various preferences. DST empowers L2s as a standalone solution by improving liveness guarantees, censorship resistance, geographic dispersion, and improved decentralization. DST aligns with the ideas of Distributed Validator Technology (DVT) at the L1 consensus layer in a multi-sequencer setting, further decentralizing the network and increasing system resilience. DST has the ability to broaden the L2 sequencing design field and offer another feasible option to the L2 decentralization toolset. DVT is now best positioned to enable Ethereum Equivalent rollups, but the Obol team has begun to look outside Ethereum. Recently, the team declared ambitions to grow into the Cosmos ecosystem as well.

In the future, the bulk of large-scale, general-purpose rollups should not rely on a single sequencer. While maximum decentralization is not appropriate for all roll-up applications, neither is a single point of failure. That vulnerability can be removed by utilizing DST. We are excited to see how the DST design space evolves and grows.

Disclaimer:
This article is intended for and only to be used for reference purposes only. No such information provided constitutes advice or a recommendation that any investment or trading strategy is suitable for any specific name.

Distributed sequencers tech: The key to make rollups decentralized