Arbitrum Nitro Integration Overview
Last updated
Last updated
TL;DR - Chains and Rollup-as-a-Service (”RaaS”) providers can leverage the Espresso Network to provide users with faster, more secure confirmations on their transactions. The Espresso Network also provides chain operators with information about the state of their own chain and the states of other chains, all of which is important for improved UX and ultimately, cross-chain composability. This document outlines the steps for chains/RaaS to integrate with the Espresso Network.CommentIntegration at a glance - Integrating with the Espresso Network requires minimal changes to Arbitrum Nitro's existing rollup design, and the key change is running the Arbitrum Nitro batch poster inside a Trusted Execution Environment (”TEE”). See here for an explanation of this design and see here for trust assumptions that partners should be aware of when integrating. Today, Espresso has developed software to run the batch poster using SGX in Microsoft Azure. We plan to release a version compatible with AWS Nitro (not to be confused with Arbitrum Nitro) by EOQ1’25.
*Assumes familiarity with TEEs. Teams may want to allocate up to 7 days to upskill and deploy this technology for the first time.
We will host a kick-off call to walk through your technical architecture, including what cloud providers you work with. In an effort to expedite the integration process, we ask that you please share with Espresso:
A config file that we can work from. Note: This is only needed if Espresso is running the batch poster.
Direct access to your RPC node (instead of through an intermediary). Note: This is only needed if Espresso is running the batch poster.
Confirmation that you are able to run the TEE within your existing infrastructure. Note: Espresso is able to run it on your behalf; however we prefer to support you to run it using your own infrastructure.
Confirmation of the integrating chain's current Arbitrum Nitro version.
Other pre-requisites include understanding how a TEE operates, if you aren't already familiar:
Docs specific to AWS Nitro Enclaves:
Docs specific to SGX:
Guide to enable a prover using SGX (note this links to Taiko’s docs, as Taiko currently uses SGX)
We require that teams run a testnet and mainnet deployment; however chains and RaaS providers have the opportunity to also run internal devnet deployments beforehand (this is recommended if it's our first time working together). This process will allow us time to fix any issues and bugs that may occur during testing and will ultimately ensure a more seamless transition to mainnet. An illustrative integration timeline may look like this (see diagram below):
An internal deployment (3-4 days) is optional but is recommended for new architecture or a RaaS provider that has not previously integrated with Espresso.
A devnet deployment (3-7 days) is optional but is recommended for new architecture or a RaaS provider that has not previously integrated with Espresso.
A testnet deployment (5-7 days) is required, and we look to run a testnet for 5-7 days with no incidents before we consider deploying to mainnet.
A mainnet deployment would follow a successful testnet deployment.
Run the batch poster inside the TEE (e.g. AWS Nitro or SGX)
Deploy the EspressoTEEVerifier contract
Stop the batch poster node and copy the batch poster’s databases files to the TEE
Perform the sequencer inbox migration
New batch poster starts catching up messages and building up state
Espresso engineers will support your chain and RaaS provider as you navigate the integration process through relevant devops services, async tech support, and calls to run through integration steps.
Espresso has a 24x7 support model and tracks the health and frequency of batch posting to ensure that there are no delays. If something isn't working, Espresso will automatically trigger an on-call procedure to investigate the incident. We recommend that our integrated chains also monitor these health metrics and have an incident management procedure.
How much does it cost a chain or RaaS provider to integrate with Espresso?
Fees are paid by the builder of each block. Initially, in Mainnet 0.0/Decaf 0.0, Espresso will run a simple builder and cover fees. Fees will not be collected from rollups using Espresso or their users. There will be no third party builders during Mainnet 0.0/Decaf 0.0.
What is Espresso’s latency for blocks? How long does it take blocks to reach finality?
Espresso confirmations are faster than waiting for Ethereum finality, which takes 12-15 minutes. Using Espresso, the current latency for blocks is 2-9s (1-3s with transactions, 8s with no transactions) with HotShot finality reached after 3 consecutive blocks, typically in 6-20s (slower when blocks are empty). There are future roadmap improvements to decrease latency and time to finality (including an adjustment to finalize after 2 consecutive blocks, rather than 3, which should result in a 20-30% reduction in latency).
What is Espresso’s throughput per second?
During some recent heavy load testing, we achieved ~100 TPS with small transactions (~200 bytes each). We currently have a 1MB limit on the block size, which performed well under the same load testing. We plan to use our Proof of Stake upgrade in March 2025 to significantly improve network throughput and latency with (i) an increase to the block limit, and (ii) adding erasure coding via Verifiable Information Dispersal.
