Integrating OP Stack Rollups
Introduction:
In this section, we will explore the architecture of an optimistic rollup and how it can be integrated with the shared sequencer and relayer. To make it easier for you to understand, we simplify the complexity of an optimistic rollup and focus mainly on its interactions with the shared sequencer.
How Rollups work:
Rollups break transactions down into two parts: data and execution. For instance, when a transaction is posted on the blockchain, rollups execute the transaction on L2 and post the transaction data on L1. This process reduces congestion on the L1, stabilizing network fees and transaction speeds.
Key Components that are needed to integrate with OP Stack Rollups are:
- Shared Sequencer: Shared Sequencing separates the sequencing and execution of transactions. This allows different execution layers to all use the same shared sequencer and allows rollups to focus on their execution layer. The shared sequencer sequences the transactions and orders all of them into a singular block which can contain transactions from multiple rollups.
- Relayer: Communicates with the DA Layer and Rollup
- SEQ: Each block which contains 1 or more transactions is signed using Avalanche Warp Messaging(AWM) which gives us a signature we can easily verify in a zkSNARK before it gets submitted to the contract on Ethereum.
- Orchestrator: Ensures that the data is sent to the L1 Sequencer Contract after it has been posted to a DA Layer and this also generates the ZK Proof to be sent to the L1.
Transaction Flow
We will follow a transaction through the system and take you along the way with the steps below.
Submit transaction(TX) to the rollups(the proposer)
Rollups send TX using chainID’s to SEQ
Single block for multiple rollups is created by SEQ
The relayer listens to the SEQ for blocks and posts them along with the AWM signature to DA layers. The Proposer can connect to this relayer to reach soft finality by getting the block and verifying the AWM signature over block root.
Orchestrator sends data to sequencer contract after DA layer header has been received in order to confirm the data exists on the DA layer. The Orchestrator is doing the ZK Proving in this scenario which is required so we can easily verify the block came from the sequencer when the commitment and proof are sent to the L1.
The rollup(proposer) then executes the transactions relevant to them from the block and produces a new state root.
Last updated
