Solving Blockchain Interoperability Problems with Espresso Systems

Currently, there are over 30 layer 2 (L2) chains, with over $30B TVL locked across them and over 30 EVM bridges. That means that we can also say that there are 30+ sequencers 👀!

If you’d prefer to watch a video 📹 of this, please scroll down to the end to find the Youtube video.

But, what exactly is the role of the sequencer?

In Layer 2s (L2s), sequencers are responsible for selecting and ordering transactions from the mempool and submitting the batch of transactions to form a block on the L2.

They play a crucial role in maintaining the efficiency and security of the network.

How is it that we’ve never heard of the term sequencers until L2s became prevalent 🤔?! And, who is responsible for ordering transactions in L1?

To address this, let’s go through the lifecycle on L1/Ethereum.

The Lifecycle of a Transaction on Ethereum

The Lifecycle of a Transaction on Ethereum

1. User Submission: User submits transaction
2. Mempool: It enters a pool of other transactions, the mempool. The mempool holds all transactions. waiting to be included in a block.
3. Block Proposal: The selected validator who is able to propose the next block selects transactions from the mempool and orders them and place them in a block. Validators prioritize transactions based on factors like transaction fees, so as to maximize their rewards.

If you’re familiar with Proposer-Building Separation (PBS), you know that block builders get involved here to build the most profitable block. PBS is a concept aimed at optimizing block construction in blockchains. Block builders are specialized entities that focus on constructing the most profitable blocks by selecting and ordering transactions from the mempool. Validators (or proposers) are responsible for proposing the next block. Block builders submit their constructed blocks to validators through an auction-like mechanism. MEV refers to the additional profit miners (or validators) can extract by manipulating the order of transactions within a block.

4. Block Validation & Consensus: Once a validator proposes a block, other validators verify the block to ensure it follows the protocol rules and contains valid transactions. This is done through a consensus mechanism.
5. Finalization: After reaching consensus, the block is added to the blockchain. All validators update their copy of the blockchain to include the newly added block, maintaining a synchronized ledger.

On L1, validators perform the job of sequencing. 📝

In L1 blockchains like Ethereum, the network of validators order these transactions thus we get decentralized sequencing for free.

A summary of the batch is submitted to L1 (Ethereum in this case) and L1 validators verify the state commitment proof.

But what’s important to note is that the transactions on L2 are only confirmed once it’s finalized on L1.

L2 Transaction Lifecycle vs L1 Transaction Lifecycle

Instead of validators, sequencers select and order transactions from the mempool, batch them into a block on L2.

A summary of the batch is submitted to L1, and L1 validators verify the state commitment or proof.

L1 confirms the batch; L2 state is updated based on the confirmed batch

L2 finality depends on L1 finality. 😲

When can we say a transaction is final on L2? Is it when it’s on the L2 block? Well no, since L2 blockchains leverage the security of the L1 blockchain. A transaction is considered final on an L2 when it’s finalized on an L1.

So wait what?! I thought the whole point of an L2 is to have faster transactions, higher throughput and also lower gas fees.

Yes, L2 solutions provide faster, cheaper transactions by allowing users to trust the state of the L2 chain before it is fully finalized on L1.

Now let’s cover the concepts of finality vs pre-confirmations.

Finality vs Pre-confirmations

When we have finality on a blockchain, that means this block and all preceding blocks are considered immutable.

So you may have seen this indicated on etherscan, a transaction on an unfinalized block will say unfinalized until finality is achieved and its status changes to finalized.

When a block is finalized, all the validators in the network have a consistent view of the blockchain.

Having a synchronized view of the ledger of transactions also means that no transactions can be reversed.

This is really important because whether you use the blockchain for message passing of 0 value or 1000 ETH, it’s important not to mess the ledger and account balances up!

Finality is what all blockchains are striving for.

Transactions that are finalized are secure, irreversible and all nodes accept them as valid.

Pre Confirmations
Most people accept a transaction as “final” once they’ve seen it on etherscan. As a matter of fact, so do wallets like Metamask. Once the first confirmation for a block of transactions is received, Metamask will show that transaction as “confirmed” to the user.

So users and apps rely on pre-confirmations on both L1 and L2 blockchains.

On L1, we have a pre-confirmation once the block has been submitted by the selected validator other nodes see this block. On L2, we have a pre-confirmation once the sequencer submits the batch of transactions to the L2 chain.

The more confirmations the transaction receives before finality, the less likely it is for that transaction to be reversed.

Validators have strong economic incentive to not act maliciously but how about centralized sequencers?

Now that we know:

a) What a sequencer is
b) The transaction lifecycle on L1 vs L2 and
c) the concept of finality vs pre-confirmations

Let us focus on some of the drawbacks of using rollups to scale ETH

The drawbacks of using Layer 2s

I don’t know about you but I remember being so confused that I had to bridge assets onto layer2s to be able to benefit from faster transactions on Ethereum. I thought, “Isn’t this just another network with new rules? And why are the bridges so slow anyway? Ugh, but I’m a web3 native so GM layer2s!”

Let’s briefly talk about why bridging can be so slow.

Each L2 is its own network and receives its own set of transactions, to its isolated mempool to be selected and ordered by its own, isolated sequencer.

Let’s consider two L2 chains named Zipchain and Zapchain. In order for a transaction between Zipchain and Zapchain to complete, the transaction has to be first sent to Zipchain, and then finalized on L1 so that it can be finalized on Zipchain. Zapchain then reads information about the transaction on L1, performs the action required and then that transaction has to be finalized on L1 so that it can be finalized on Zapchain. After tehse steps, the user’s cross chain transaction has completed.

Because an individual chain doesn’t have a direct way of verifying the state of another chain, they rely on a number of verification processes to ensure the veracity of the cross-chain messages. ❕

This makes bridging slow and leads vendors to creating centralized bridging solutions to speed up some of the processes.

As you can tell this is also an issue for interoperability and leads to the inability to stack apps on top of each other like the DeFi legos we’re used to on L1.

Fundamentally, these L2s are different chains, one L2 is not going to be able verify all the things that happened in the other L2, especially while it’s happening.

Introducing shared sequencers

Just as an exercise, if multiple L2s shared a sequencer, at least there is this one party that is able to produce the next update in these L2s at the same time.

If you “trust” the sequencer, you can ask the sequencer to do things on your behalf. For example, if you want a transaction on one L2 to only be included if some transaction on the other L2 were to also succeed, you can ask the sequencer to do that.

If rollups shared a sequencer, the sequencer can then share preconfirmations for multiple L2 chains at once and thus a user can request that txn2 on rollup2 only succeeds if txn1 on rollup1 succeeds.

However, what has the Espresso Systems team learnt by speaking to over 40 L2s and L3s in the space? Some chains are not just going to agree to have a shared sequencer.

So, what is an efficient way to balance sovereignty and benefits that can come from having a shared sequencer to coordinate the construction of these to rollups at the same time?

Introducing the Espresso Marketplace

The Espresso Shared Sequencer Marketplace is the solution to balancing sovereignty whilst introducing the benefits of shared sequencing to L2s.

In the Espresso Marketplace, L2s can auction off their block space to shared, decentralized proposers/sequencers, including Ethereum mainnet proposers, which gives these third party sequencers, the right to sequence for 1 or many L2s simultaneously in a given time slot.

These shared proposers have the opportunity to win an auction and gain the right to sequence transactions for multiple rollups at the same time, facilitating cross-rollup activity and making cross-rollup transaction processing more efficient. This also opens up a potential for new revenue streams for the rollups, as they can receive the income generated from the bids⁠.

L2s can opt into and out of selling their sequencing rights on the marketplace at any time — including setting a “reserve price” or a minimum threshold that must be bid.

The Espresso Marketplace offers a credibly neutral shared sequencer network and will be implemented in upcoming releases.

Benefits of integrating with the Espresso Marketplace

• Value Generation — bids collected from sequencers goes to L2s.
• Sovereignty — Rollups get to set the reserve price and decide when they want their transactions to be sequenced.
• Interoperability — Atomic inclusion and execution guarantees can be provided by these sequencers which can enhance interoperability.
• Decentralization — The sequencers will be running on the Espresso decentralized network which is named HotShot.
• Fast Finality — fast pre-confirmations can be obtained from this decentralized network which can be used by bridges to offer faster bridging times. Bridges can use the decentralized principles and crypto economic guarantees to provide higher certainties that the transaction will be executed as proposed.

Fast Bridging with Fast Finality from Espresso Systems

At ETH Denver, Ben, the CEO of espresso demoed a proof of concept between Espresso and a bridging protocol, called Across Protocol, to show how Espresso can be used to speed up bridging to 7 seconds. In fact, it only took 2 seconds to get that fast finality from Espresso.

Using Espresso’s Shared, Decentralized Sequencer network, Hotshot, on its own can help fast bridging. The Liquidity bridge provider knows transaction/state is finalized once Hotshot accepts it.

Espresso’s recent testnet release, Cappuccino, is focused on HotShot — a fast finality layer that rollups can share for much quicker confirmations than the Ethereum L1 provides. As such, HotShot enables fast bridging and more seamless interoperability between rollups.

3 Things to know about the future of L2s (and L3s) with Espresso Systems

1. The Espresso marketplace helps rollups maximize value whilst enabling a more seamless user experience through atomic execution guarantees.

2. Enhanced Interoperability will be a non-negotiable, unlocked by Espresso’s Fast Finality Gadget which enables fast bridging.

3. Developers will want to build on Rollups that use the Espresso Marketplace so that they can take advantage of defragmented liquidity.

You can watch me talk about all of this at ETH Prague, 2024 in the video below.

The Future of Rollups on Espresso Sequencer Marketplace

Disclaimer: As of the time of writing, I am employed as a software engineer at Espresso Systems, but my thoughts and opinions are independent and not endorsed by the company.