Decentralising the Warp Sequencer - A Deep Dive
They have been talking about it for a while, and now the Warp Contracts team is making an impressive push in its mission to evolve the world of Arweave smart contracts, as they are on the verge of decentralising their Sequencer.
The Sequencer's job is to receive, organise, and send transactions for further processing. So, what will decentralising it look like?
Let's break it down section by section.
Decentralising the Warp Sequencer
Firstly it's important to understand what the team is doing here. They are on the road to fully decentralise their protocol. A lot of projects boast decentralisation, with many not having that trait. Some projects do not even have roadmaps or plans to become decentralised. Thankfully Warp did, and now they are following through on the promise!
Setting the Criteria
In its blog post were it goes into full detail, Warp explains it is laying out the groundwork for its new Sequencer based on four primary standards:
Decentralisation: The new model will foster transparency and accountability. Instead of a single entity ordering transactions, the process will be spread across several nodes, eliminating a single point of control and increasing system resilience.
Security: In a decentralised Sequencer, the risk of a single point of failure is substantially reduced. Robust security measures will ensure the protection of the system against potential attacks.
Performance: The swift and efficient processing of transactions is vital. While the Sequencer already simplifies performance requirements, a prompt confirmation process remains crucial to provide a seamless user experience.
Simplicity: Warp states that despite the complexity introduced by decentralisation, the final solution should remain simple, as a streamlined approach mitigates technical risks, enhances stability, and facilitates system maintenance.
Functionality
Here's a simple rundown of what the entire process will look like after the decentralisation switch has been fully flipped on:
Using the Warp Contracts SDK, users create and sign transactions that are sent to the Sequencer network.
Network nodes validate and distribute these transactions, initiating a consensus process to agree on a block of transactions in a certain order.
The validated transactions are forwarded to Bundlr, which guarantees their finality by sending them to Arweave. Block metadata undergoes a similar process.
Generated blocks are fetched and retrieved for further processing, including contract state evaluations.
Transactions sent directly to Arweave (L1) are retrieved and merged with L2 transactions that have undergone sequencing.
Roles
For all this to work, the decentralisdenised process requires the following distinct roles, as identified by Warp:
Validator: Validators secure the Sequencer network and ensure the system's integrity. They validate incoming transactions and broadcast them to other nodes. Validators also participate in the consensus process to agree on blocks. Warp has also integrated a token slashing mechanism to incentivise good behaviour.
Proposer: Selected from the pool of active validators, the proposer is responsible for constructing a block of transactions and proposing it to other validators. If a 2/3 consensus is reached, the proposed block is committed to the blockchain.
Relayer: Transactions pass through the sequencer for order establishment, facilitated by the relayer using Bundlr for reliable data delivery to Arweave.
Syncer: Warp Contracts support L2 and L1 transactions. L2 transactions are processed immediately in the sequencer chain, while L1 transactions may experience a delay. The syncer merges and saves transactions in the Warp database, served by the Warp Gateway and downloaded by DRE nodes.
Implementation Plan
The Warp team are decentralising the Sequencer one step at a time, making sure all flows nicely:
The first step is to build a new Sequencer network using the Tendermint BFT consensus engine. However, the relayer and syncer components will remain centralised for coordinated testing and evaluation.
Next, the relayer component will be made decentralised, with Sequencer nodes taking over the responsibility of transmitting data to Bundlr.
Transaction encryption will then be introduced to safeguard against content-based attacks.
Subsequently, measures will be put in place to limit the proposer's ability to select and sequence transactions freely. This will enhance fairness, transparency, and decentralisation in the transaction ordering process.
Finally, the network will be opened up after testing.
