Portico Testnet
Last updated
Last updated
The Portico Testnet introduces two essential rollup functionalities: Sequencing Liveness and Multi-Rollup Sequencing. This guide helps developers understand how Radius ensures these functionalities while preserving the fundamental values of rollups.
Explore the integration of the shared sequencing layer with rollups on (closed).
Sequencing liveness involves the continuous processing of transactions and block production within rollups, guaranteeing uninterrupted sequencing of transactions even in the face of potential rollup disruptions or failures. This is crucial for a seamless user experience and fostering trust in rollups while preventing any transaction delays.
Before delving into how Radius ensures sequencing liveness, let's examine two key approaches it employs:
: Radius adopts a leader-based sequencing approach enabled by the encrypted mempool. A designated sequencer node (known as the leader) takes the lead in block sequencing. Other sequencer nodes (followers) receive the sequenced block from the leader. This design choice significantly enhances block production efficiency without exposing the network to censorship or sandwich attacks.
: The leader provides order commitment (pre-confirmations) of ordered transactions to the users before decrypting the transactions. This step prevents manipulative behavior and mitigates centralization risks.
Two potential scenarios of sequencing liveness failures can disrupt rollup operation:
: Delays in the sequencer providing the block to the rollup operator may occur due to potential attacks by malicious users. Practical Verifiable Delay Encryption (PVDE) enables users to generate proofs for the decryption key, helping the sequencer in identifying transactions that might lead to decryption failures. (Refer to )
Leader Failure: Leader failure can result in interruptions during the block sequencing process
To ensure sequencing liveness during leader failure, Radius employs the RAFT algorithm for leader recovery where a new leader is elected from among the followers. This algorithm is effective for leader-based sequencing, ensuring high availability, consistency, and fault tolerance in leader election, log replication, and security.
The shared sequencing layer involves a designated leader determining the order and broadcasting transactions to the followers. The RAFT algorithm, based on the Crash Fault Tolerance (CFT) consensus algorithm, enhances broadcasting efficiency and minimizes communication overhead compared to the Byzantine Fault Tolerance (BFT) algorithm.
A modification to the RAFT algorithm ensures data consistency among followers during leader election. In the original RAFT model, followers lacked an identical view of the data. However, in our modified version, the candidate requesting votes to become a new leader must have data identical to the majority of followers. This modification ensures the block inclusion of pre-confirmations determined by a failed leader.
Initial: All nodes begin as followers.
Timeout: If a follower doesn’t receive a message from a leader or candidate during the election timeout, it transitions to a candidate state, initiating a new round.
Voting Request: The candidate sends a vote request to all nodes, including a vote for itself and its data.
(Modified) Voting Process: Nodes vote for the candidate only if their data matches the candidate's data.
Leader Election: The candidate with the majority of votes becomes the leader.
Explore a demonstration of Sequencing Liveness on the Portico Testnet (closed).
Please note that the speed of interactions in the testnet has been adjusted for demonstration purposes and does not reflect the actual speed of sequencing events
The transaction ordering process within the shared sequencing layer involves four components: User, Leader (Sequencer), Follower (Sequencer), and Rollup.
For sequencing liveness, the leader ensures that the majority of followers receive the order commitment (pre-confirmation) before it is sent to the user. For example, with a total of 10 followers, the leader ensures at least 6 followers receive the order commitment before sending it to the user.
The following scenarios illustrate the diverse interactions within the shared sequencer network.
User submits encrypted transactions to the leader.
Leader orders transactions in an encrypted state.
Leader provides order commitment (pre-confirmation) to followers before sending it to the user.
Rollup operator receives the transaction list (block) from the leader.
Scenario 2: Majority of Followers Receive Order Commitment Before User
User submits encrypted transactions to an initial follower.
Initial follower forwards encrypted transactions to the leader.
Leader orders transactions in an encrypted state.
Leader provides order commitment to the majority of followers before sending it to the initial follower. Example: In a set of 5 sequencers, the leader ensures order commitment to at least 3 followers before reaching the user (including itself, initial follower, and another follower).
Initial follower forwards the order commitment to the user.
Rollup operator receives the block from the leader.
In case of leader failure, a new leader is elected among follower nodes.
Rollup receives the transaction list (block) from the newly elected leader.
Nodes cast votes for a candidate only if the candidate's data matches theirs. This ensures the newly elected leader possesses identical order commitment data with the majority of followers to guarantee sequencing liveness for the rollup in the event of leader failure.
Now that we've explored how Radius ensures sequencing liveness for rollups, let's delve into multi-rollup sequencing.
Shared sequencing involves multiple rollups sharing the same sequencer. This sequencer sequences blocks and submits them to respective rollup operators.
To manage multiple rollups, the shared sequencer must distinguish data associated with each rollup. Using rollup identification, it selectively provides relevant transactions when a rollup operator requests the transaction list (block) for execution.
Rollup identification is facilitated through a unique Rollup ID assigned to each rollup, issued by the rollup itself. The rollup operator registers its address (Operator Address) with the shared sequencing layer, allowing it to associate each operator with the correct rollup.
Each rollup is assigned a unique identifier known as the Rollup ID, issued by the rollup itself. The rollup operator registers its address (referred to as the Operator Address) with the shared sequencing layer. The mapping of the Rollup ID and the Operator Address allows the shared sequencing layer to associate each operator with the correct rollup.
Rollup ID: Unique identifier assigned to each rollup
Operator Address: Address of the rollup node operator
Operator Public Key: Public key of the rollup node operator
To identify transactions for each rollup, the leader manages the following information and provides it to the followers:
Transaction Hash
Rollup ID
Block Height
Order
Sequencer Signature
Transaction Identification: Leader pre-determines execution order and assigns and stores the rollup identification data, including Rollup ID, Block Height, Transaction Order, and Sequencer's Signature.
Block Request: Rollup node operator requests a block (a list of transactions to be executed) from the shared sequencing layer, including Rollup ID, Operator Address, and Operator Signature.
Operator Verification: Leader verifies the node operator based on the requested data, validating the operator's signature using the rollup’s Operator Address list.
Block Height Update: After verification, the leader provides the next block height (current block height +1) as a pre-confirmation for subsequent user transactions, closing the current block height.
Transaction Decryption: Leader checks the decryption status of all transactions in the requested block. If any transactions remain undecrypted, the operator is informed that the block is still being generated. Once all transactions are decrypted, the leader provides the complete transaction list to the operator."
To view all sequencing events in real-time, refer to the , which is synchronized with the visualization on the testnet
In the event of a leader's failure, candidates receive votes based on their latest status (). The eligible candidate securing the majority of votes becomes the newly elected leader. Once elected, the new leader synchronizes data with all followers, ensuring identical order commitment data across the network.
Explore a demonstration of Multi-Rollup Sequencing on Portico Testnet (closed). The shared sequencer submits blocks to two rollup operators in Rollup A and B, both deployed with the rollup framework.
