Decentralizing the Warp Sequencer

The Warp sequencer serves as a crucial component of the Warp contracts, a data-driven smart contracts protocol built on the Arweave blockchain. Its primary role is to receive and order transactions from clients, preparing them for further processing (e.g., state evaluation) and sending them to Arweave. This provides both quick finality and inherent security guaranteed by the underlying layer.

Currently, the Warp sequencer operates in a centralized manner, offering simplicity and high performance. However, this approach is considered temporary, as it lacks the necessary guarantees of security, transparency, fairness, scalability, and resilience. Consequently, the decentralization of the Warp sequencer is a prominent goal on the roadmap of the Warp project.

This article outlines the decentralization of the sequencing process. We will cover the key criteria for selecting a suitable solution, dive into the sequencer’s functionality and its collaboration with other elements, outline the decentralization plan for the roles involved, and finally, unveil the subsequent stages of implementing this comprehensive approach.

Criteria

The selection of a new sequencer solution is guided by several crucial criteria, ensuring a robust and efficient system. These standards include:

• Decentralization — The transition to a decentralized model is essential to foster transparency and accountability. Rather than relying on a single entity, the ordering of transactions should be distributed among multiple nodes. This decentralization eliminates a single point of control (i.e. the Warp team) and enhances the overall resilience of the system.
• Security — Security is of paramount importance when decentralizing the sequencer. By distributing the transaction processing across a network of nodes, the risk of a single point of failure is significantly reduced. The design must prioritize the implementation of robust security measures to protect against potential attacks.
• Performance — Ensuring low latency is crucial to enable swift and efficient transaction processing. The Warp sequencer benefits from not burdening itself with contract state evaluation, simplifying the performance requirements. However, a timely confirmation process remains a top priority when designing the solution to maintain a seamless user experience.
• Simplicity — While decentralization introduces complexity, it is essential to strive for simplicity in the final solution. A streamlined approach minimizes implementation time, mitigates technical risks, and enhances stability. Furthermore, a simpler system is easier to maintain and less prone to vulnerabilities, ensuring a reliable and secure environment.

Functionality

The transaction life cycle encompasses various stages beyond setting the order within a block. Once decentralization is achieved, the entire process unfolds as follows:

1. Utilizing the Warp Contracts SDK, users create and sign Arweave transactions that are interactions with contracts. The SDK currently supports “Arweave” and “EVM” wallets. Upon signing, the transaction is transmitted to the sequencer network.
2. Network nodes receive and validate incoming transactions. Valid transactions are propagated to other nodes, initiating the consensus process. Nodes collaborate to agree on a block containing a list of transactions arranged in a certain order.
3. Transactions within the block are forwarded to Bundlr, responsible for ensuring their finality by delivering them to Arweave. Block metadata undergoes a similar transmission process.
4. The blocks generated by the sequencer network are fetched and retrieved for further processing, which includes the evaluation of contract states.
5. Transactions sent directly to L1 (Arweave) without passing through the sequencer are retrieved and merged with the list of L2 transactions that underwent sequencing. Considering the potential occurrence of forks in Arweave, L1 transactions experience a delay in retrieval to safeguard against such scenarios.

Distributed Warp Sequencer Overview

Roles

Considering the aforementioned functionality, we can identify several distinct roles within the process.

Validator

Validators form the sequencing network and play a critical role in ensuring the security and integrity of the decentralized mechanism. Their responsibilities include validating incoming Arweave transactions and broadcasting them to other network nodes. Validators also participate in the consensus process, where they independently validate blocks and ensure they have agreed upon the same value consistent with the protocol rules. To become a validator, individuals must hold a certain amount of the network’s native token as a stake, which can be slashed if they engage in misconduct or fail to fulfill their obligations. Among the active validators, the roles of proposer and relayer are selected.

In the initial version, validators will not verify the transaction order in a block and will accept the order specified by the proposer. In subsequent versions, solutions for collective agreement on the transaction order in a block will be considered.

During the initial phase of implementation, the management of validators will be carried out by the Warp team. However, as the entire solution is developed, implemented, and thoroughly tested, the network will gradually transition towards a more open and decentralized state.

Proposer

The role of the proposer within the sequencing network is vital for the creation of new blocks. Selected from the pool of active validators, the proposer is chosen using a weighted round-robin algorithm. In other words, validators who stake more tokens have a higher chance of proposing a block. However, every validator eventually gets a chance to become a proposer. This promotes fairness while still incentivizing validators to hold more tokens.

The primary responsibility of the proposer is to construct a block containing an ordered list of transactions and propose it to the other validators. If the remaining nodes reach a consensus by voting with at least 2/3 of the votes, the proposed block is committed to the blockchain.

During the initial phase of the implementation, the proposer has the freedom to select and determine the order of transactions within a block. However, the default implementation follows the first come, first served (FCFS) principle. Subsequent phases will introduce measures to limit this freedom. Transaction encryption will be implemented to prevent content-based attacks by the proposer. Additionally, alternative approaches, such as imposing order based on the Arweave mining hash or achieving consensus on the transaction order among all participating validators, are currently under consideration.

Relayer

Transactions pass through the sequencer to establish their order before being sent to Arweave. The relayer plays a crucial role in this process by facilitating the transmission of transactions from the sequencer to Arweave. Instead of directly sending data to Arweave, the relayer leverages Bundlr, which guarantees the reliable delivery of data to the blockchain.

The relayer’s task is to send the original user-signed transactions and including information about the sequencer chain’s block where the transactions were placed, particularly the transaction order within the block.

Initially, the relayer will operate as an external application outside the sequencer network, monitoring and forwarding produced blocks to Bundlr. In the subsequent stage, the relayer will become decentralized, and sequencer nodes will take on its role. The entire process looks as follows:

• Only one validator from the sequencer network serves as the relayer at a given time.
• The relayer is selected among the validators using the same algorithm as the proposer. The difference is that the proposer is selected every block, while the relayer is selected for a certain number of blocks (e.g. 10 blocks).
• The selected relayer is responsible for transmitting data from the sequencer chain to Bundlr. After sending the data, the relayer presents a receipt signed by Bundlr to the remaining validators.
• The network verifies the relayer’s adherence to their obligations by ensuring the delivery of valid receipts. The relayer is incentivized through rewards to maximize the amount of data sent and faces penalties, including token slashing, for misbehavior. In case of non-compliance, the responsibility is transferred to the next designated relayer.

This technique enables the decentralized ordering and transmission of transactions, contributing to the overall functioning of the system.

Syncer

Warp Contracts support both L2 transactions, which go through the sequencer, and L1 transactions, which are sent directly to Arweave. L2 transactions are processed immediately upon inclusion in the sequencer chain, while L1 transactions experience a delay due to the potential for forks.

In the current solution, transactions are sorted based on a “sort key” value, taking into account the Arweave block height and the time of transaction receipt by the centralized sequencer. However, in the new solution, where transactions are retrieved from two blockchains with different block heights, this value cannot serve as the determining factor. Fortunately, both blockchains validate block timestamps, providing reliable values for merging the two chains. Therefore, in the new approach, transaction order is determined based on the block timestamp. The order within blocks will depend on the type of transaction. L1 transactions will retain the existing order based on the hash of the concatenated transaction id and block hash. L2 transactions will be ordered according to their sequence in the sequencer block.

The syncer retrieves and merges transactions, which are then saved in Warp’s database, served by the Warp Gateway and downloaded by the Warp D.R.E. nodes.

Implementation plan

The implementation plan for decentralizing the Warp sequencer involves a gradual transition from a centralized architecture to a distributed system. This plan encompasses several key steps, including adopting a BFT consensus engine, decentralizing the relayer, implementing transaction encryption, introducing order mechanisms, and opening up to external participants.

1. The initial step focuses on building the new sequencer network using the Tendermint BFT consensus engine. However, during this phase, the relayer and syncer components will remain centralized. This approach allows for coordinated testing and evaluation of the system’s performance before proceeding with further decentralization. It provides a controlled environment to ensure the smooth transition towards a fully decentralized architecture.
2. The second step involves decentralizing the relayer component. Sequencer nodes gradually take over the relayer’s role of transmitting data from the sequencer chain to the Bundlr. This decentralization distributes the responsibility among multiple sequencer nodes, enhancing system resilience and reducing reliance on a single point of failure. It contributes to a more distributed and robust system architecture.
3. The next stage focuses on implementing transaction encryption to protect against content-based attacks. Encryption mechanisms are introduced to safeguard the confidentiality of transaction data. This strengthens the overall security of the system by making it more difficult for the proposer to manipulate the order of transactions for malicious purposes.
4. The plan’s fourth step aims to restrict the proposer’s freedom in selecting and sequencing transactions. This is achieved by introducing mechanisms that impose an order based on external sources or through consensus among validators. This approach enhances fairness, transparency, and decentralization in the transaction ordering process, minimizing the potential for manipulation or biases. The transaction order is collectively determined, either by relying on trusted external sources (like Arweave mining hash) or through a consensus mechanism among validators. Further discussions are required to finalize the details of this step.
5. The final step involves gradually opening up the network, which was previously controlled by the Warp team. This phase occurs once the decentralization measures have been successfully implemented and thoroughly tested. Opening up the network fosters inclusivity, community involvement, and innovation, allowing external stakeholders to contribute, propose improvements, and participate in consensus and decision-making processes.

Through these steps, the Warp protocol aims to establish a decentralized sequencer network that not only ensures the reliable ordering and processing of transactions but also encourages community involvement and trust among participants.

By embracing decentralization, the Warp sequencer will pave the way for a more secure, scalable, and resilient future for the Warp contracts protocol and its ecosystem.

Explore the research, which paved the way to decentralization! 🌌