Arbitrum Nitro integration

For the Gibraltar release Espresso Systems has built a proof-of-concept integration to run the Arbitrum Nitro optimistic rollup stack on top of the Espresso Sequencer.

Transactions are forwarded from the Nitro RPC node to the Espresso Sequencer and processed as they are sequenced and made available on the Espresso Query Service (EQS).
The Nitro nodes fetch the commitments to Sequencer blocks from the HotShot contract and validate that the transactions in the Nitro block are the ones sequenced by the Espresso Sequencer.

Mapping HotShot Blocks to Nitro Blocks

The most important design decision for rollup integrations with Espresso is how to derive the stream of rollup blocks from the stream of HotShot blocks. We have written a more general post on this topic: The Derivation Pipeline. Espresso currently uses a namespaced Merkle tree (NMT), where each namespace corresponds to one rollup.

For this integration we chose to do a 1-to-1 mapping of HotShot blocks to Nitro blocks. This means that the rollup will produce exactly one rollup block for each Espresso Sequencer block.
To justify how the Nitro block is built from HotShot, the block producer creates an instance of the following type and posts it to the L1.
```
type EspressoBlockJustification struct {
	Header espressoTypes.Header // The espresso block header
	Proof  espressoTypes.NmtProof  
}
```
The Header contains the root of the NMT. With the proof and the rollup ID (this is akin to chain ID within the EVM ecosystem, except specific to rollups in the shared sequencer), validators can verify that the ordered list of transactions in a rollup block corresponds exactly to the one sequenced by the Espresso Sequencer.

Arbitrum uses L1 Messages as a container for communication through the L1 (see for example here). For this integration, a new message type was defined for a batch of transactions sequenced through Espresso. The message also includes the Espresso block justification.

Transactions contained in this type of L1 Message are handled a bit differently than in the original Nitro node. In the original Nitro node, the sequencer is expected to filter out invalid transactions and will be punished by having its entire block discarded by validators if it fails to do so. When using a shared or decentralized sequencer unaware of the state of the rollups, it’s not possible to prevent invalid transactions from being sequenced. Instead, invalid transactions, either malformed or otherwise invalid (e.g., bad signature, double spend, nonce error) are included in L2 blocks but cannot cause state changes. The invalid transactions are kept such that:

validators can verify that these transactions are invalid
validators can recompute the HotShot commitment and equate it to the one in the HotShot contract for which the HotShot consensus has been verified on L1. This serves to ensure that the block producer included the correct transactions in the L2 block.

We envision that, in a production setting with proposer builder separation (PBS), incentivized builders would aim to produce blocks with valid transactions, which would make invalid transactions rare, but not impossible. Furthermore, Espresso prevents free DA of invalid transactions, and can further implement mechanisms to avoid rollup nodes bearing the cost of invalid transaction spam.

Validation

Arbitrum Nitro uses WASM for validation and a modified WASM called WAVM for proving. For more background please refer to the official docs. In order to make validation work with our changes there were two main requirements:

All the transactions need to be available in the WASM VM.
The HotShot commitment needs to be available in the WASM VM.

The first requirement is taken care of by the new type of L1 Message described above. For the second requirement, we modified the interaction of the WASM VM with the host to allow the host to provide the HotShot commitment as an input.

We have not yet implemented fault proofs for this integration. It would require supporting our changes in WAVM VM and the One Step Proof on L1.

Data availability

For this release, the Arbitrum Nitro rollup uses the Ethereum L1 for data availability (DA). Since the Espresso Sequencer has its own DA called Tiramisu, we could use it for the integration or as a AnyTrust DA provider in future work.

Preconfirmations

Our integration supports preconfirmations. Clients can get an updated view of the state by interacting with the rollup RPC as soon as new rollup blocks have been built. They don't need to wait for rollup blocks to be posted on L1 by the batch poster.

Clients can also query a validation node, which derives its state from validated L1 batches. Because validation nodes need to perform more work, this path is slower, but may be appropriate for clients with weaker trust assumptions.

PreviousInteracting with Gibraltar NextDeploying a rollup on Gibraltar

Last updated 16 days ago