Beyond Confirmations: Using Espresso for DA
How Espresso’s versatile infrastructure provides fast confirmations and scalable data availability
Espresso is a decentralized network that provides fast, reliable confirmations to chains, dapps, and other infrastructure, acting as a single, credibly neutral source of truth for cross-chain composability. Espresso is building upon Ethereum’s rollup-centric roadmap, on a mission to support the scale that rollups provide while solving the current issues of fragmentation among chains and ecosystems.
Espresso is also building for a more modular developer experience: we think that developers should have flexibility in what their stack looks like and the ability to customize for their specific needs. As such, we developed the Espresso Network to be versatile. In addition to providing confirmations, developers can also use it as a decentralized sequencing layer, a data availability layer, or both.
Briefly, Espresso can be used in the following ways:
- Confirmations: All chains that leverage Espresso benefit from fast, reliable confirmations backed by BFT consensus — replacing the need for users, bridges, and beyond to depend on preconfirmations from centralized sequencers.
- Data availability: All chains using Espresso for confirmations also benefit from its highly efficient data availability layer. However, chains integrated with Espresso are free to leverage alternative DA solutions, such as EigenDA, Celestia, Avail or Ethereum itself. We have designed Espresso to be flexible and additively compatible with these choices.
- Decentralized sequencing: Chains integrating Espresso may also use it as a decentralized sequencing layer, leveraging the network to determine the order of transactions on the chain. However, this is not required: Chains can use their own sovereign sequencers to determine transaction ordering and still benefit from Espresso’s confirmations and/or low-cost data availability.
EspressoDA Design
We designed EspressoDA with the aims of supporting Ethereum-level security (including scalability to tens of thousands of nodes), bribery resistance, and high performance (low latency and high throughput). To maximize along all these vectors, Espresso employs a three-layer approach that can be maximally efficient under favorable conditions, while offering robust fallback mechanisms that disincentivize and mitigate adversarial attacks. To go deeper, check out our full technical deep dive on how we designed EspressoDA.
We made some different design choices to data availability offerings like Celestia, EigenDA, and Avail.
Espresso forgoes Data Availability Sampling (unlike Celestia, which prioritizes this) in favor of Verifiable Information Dispersal. For more on our reasoning, you can check out our recent research forum post on the topic.
More of our differentiations are summed up as follows:
EspressoDA will charge only a nominal fee to reduce spam.
Roadmap
We recently launched our Mainnet 0 release, which can be used today for data availability — and we expect the first chains to be doing so in the upcoming weeks.
As the name suggests, this is a very early release that leaves much to be built, optimized, and refined.
The following are the areas for which we have upgrades planned over the coming months:
PoS and slashing
The Espresso Network today relies on a fixed validator set, with plans to upgrade to permissionless proof-of-stake in early 2025. Since we don’t have PoS live yet, validators who misbehave will not suffer any financial loss. However, all our validators are publicly known, and misbehavior is still detectable. If they misbehave in the Espresso Network, our validators risk damaging their reputation within the wider ecosystem. Reputation-based security is difficult to quantify, however.
Today, if ⅔ of Espresso validators, including the entire DA committee and the CDN, refuse to give a user the data HotShot finalized, the user cannot access the data any other way. For example, if a rollup needed to retrieve its data from Espresso in order to generate a proof for settlement, and many nodes in HotShot refused to give the rollup access to the data, the rollup would be prevented from settling on Ethereum.
The PoS system we are implementing economically incentivizes validators to produce the data and failure to do so would result in penalties such as slashing.
Permissionless light client contract
Our light client contract is what settles HotShot’s state on Ethereum. To do that, a relayer generates a proof and submits it to the light client contract. Currently, the light client contract only accepts cryptographic SNARK proofs from an Espresso relayer. Whilst the contract is permissioned, if Espresso’s relayer goes down or acts maliciously, HotShot’s state will no longer be updated on the L1. However, L1 state updates can continue if the permissioned relayer is modified or permissioned mode is turned off.
Rollups also do not need to rely on the light client contract if they don’t want to. If a rollup is using this light client contract as input to its own settlement contract, then the rollup wouldn’t be able to settle while the HotShot updates have stalled. In practice, L2s can use escape hatches for both themselves and Espresso, which reduces the severity of such an event. However, it’s a priority to upgrade to support permissionless proof generation and submission.
Create a security council for upgrades
Currently, Espresso alone gets to upgrade our light client contract on Ethereum. If we are malicious, then we could post a bad upgrade that claims a rollup’s data is available when it was never finalized on Espresso. This would break the safety of rollups that use this light client contract.
We plan to create a security council comprised of publicly known people, many of whom are not associated with Espresso, that would be required to vote on any upgrade to Espresso, preventing Espresso ourselves from deploying malicious code. Our plan is to steward creation of this security council to coincide with our proof-of-stake upgrade, slated for early 2025.
No time delay on upgrades
Upgrades on the light client contract currently can be performed immediately. This is a problem because depending on the upgrade, some rollups may want to exit Espresso if they disagree with the upgrade or want time to verify the upgrade themselves. If there is no delay on upgrades, rollups don’t have a chance to exit Espresso or give feedback on the upgrade before it goes live. To address this, we are implementing a time-lock upgrade mechanism which would ensure that any upgrade proposal will have a mandatory delay period before it’s live. This would give rollups and apps an opportunity to act based on the proposed changes.
In addition to the above planned upgrades, we will also continue to optimize the Espresso Network to ensure we are supporting the highest throughput, lowest latency, and lowest costs possible.
We anticipate having new benchmarks to share in early 2025.
Fueled by Espresso
To learn more about EspressoDA and how your chain can leverage the Espresso Network for confirmations, sequencing, data availability and beyond, check out our docs.
Cross-chain composability is coming soon, courtesy of Espresso’s global confirmation layer.
About Espresso Systems
Espresso Systems builds the infrastructure and incentive mechanisms to ensure that all chains can work together as one. The Espresso Network provides chains with fast, reliable confirmations of their own state, as well as the states of other chains. Its versatility also means chains can use the Network for decentralized sequencing and data availability. Espresso Research explores the design space of cross-chain composability, defines the role of the Espresso Network within it, and collaborates with design partners to develop and test innovative proposals. Founded in 2022, the company has raised $60 million from partners including a16z Crypto, Greylock Partners, and Electric Capital.
Website | Docs | GitHub | Medium | HackMD | X | LinkedIn | Warpcast | Discord | Research Forum