I’ve seen a lot of chatter recently concerning two distinct topics that in reality couldn’t be more related.

1. Why is bridging between L2s so slow in some cases? And why does it take so long to deposit from L2s to centralized exchanges (CEXs)? And;

2. What exactly is Espresso? Is it a beverage? A hit song by Sabrina Carpenter? The solution to slow bridge and deposit times? (Spoiler: it’s all of those!)

To understand the answer to these questions we need to go back to a time before pump.fun shitters and trench warriors, before CryptoKitties and DAO hacks.

We need to go back to the beginning of cryptocurrency, and really even before that. It concerns the double-spend problem.

The Cypherpunks

A good place to start this exploration is where arguably the modern cryptocurrency movement began: the cypherpunk mailing list. Back in the early 90s, a group of three legendary computer scientists started this group under the belief that we would soon need to defend some of our most important rights online: sovereignty, privacy, and freedom.

The names of the three are: John Gilmore (one of the founders of the Electronic Frontier Foundation, or EFF), Eric Hughes (author of A Cypherpunk’s Manifesto) and Timothy C. May (author of The Crypto Anarchist Manifesto)

They took seriously the possibility that much of human interaction would move into the digital world, and foresaw the potential threats to personal freedom this new reality would create. To avoid serfdom, they knew people would need to remain in control of their own destiny, both offline and online.

Given the state of the internet in the early 90s, this must have taken incredible foresight. Need I remind you that in 1998 the Nobel Laureate in economics, Paul Krugman, wrote: “By 2005 or so, it will become clear that the Internet’s impact on the economy has been no greater than the fax machine’s.”

Perhaps it was our cypherpunk friends who deserved the Nobel Prize all along!

One of the cypherpunks’ key insights was that we needed a digital alternative to cash. Private ownership and free enterprise (under the constraints of sensible legislation and social security) had proven to be among the largest forces for progress the world had ever seen.

Yet the cypherpunks realized that we stood to lose much of what had been gained in this area if all activity on the internet were to be controlled by authoritarian governments and monopolists.

If they could determine which individuals could trade online, and with which counterparties, and up to what amounts they could spend, then in effect the internet would be owned by those powerful entities, leaving little old us in the position of digital serfs.

Thus it was paramount to build a system for transferring value online that wasn’t reliant on third parties. This new system had to empower individuals to take actions they deemed appropriate, without requiring permission from big brother.

Hal Finney, receiver of the first Bitcoin transaction ever (and possibly the mastermind behind Bitcoin), was another legendary member of the cypherpunk mailing list. He had a keen interest in digital cash and published at length about potential problems with creating a functional version of it.

Possibly the largest issue he identified was the double-spend problem. In the words of Finney: “The big issue in digital cash is double-spending. Someone could send the same piece of cash to more than one seller.”

In other words, double-spending allows a person to infinitely inflate the money supply by spending the same money as many times as they’d like.

In the centralized setting it is rather trivial to solve this problem. We simply rely on a trusted authority to keep a ledger that tracks what money has been spent, as well as which parties were involved in a specific transaction.

But Hal Finney and the other cypherpunks were dreaming of escaping the grasps of authorities and helping individuals take charge of their own destiny. This meant that a truly functional version of digital cash needed to have certain properties, most importantly:

1. Decentralization, to avoid single points of failure and protect against attempts to shut the project down.

2. Privacy, so that people can choose what to spend their money on without fear of repercussions.

3. Censorship resistance, to ensure that people’s background and social class would bear no influence on their ability to access the system.

4. Prevent double-spending, so that people could trust the money they received was legitimate.

Many attempts were made to implement these features over the years. And much innovation took place alongside those attempts.

In 1989, David Chaum founded DigiCash, which allowed people to withdraw ‘cash’ from their bank accounts directly to their PCs hard drive. It could then be spent anonymously, much like withdrawing cash from an ATM and using it in the physical world! A centralized mint authority would ensure that money couldn’t be double spent by keeping track of all transactions.

In 1994, they successfully completed the first electronic cash payment over computer networks, decades before modern stablecoins became a thing. However, just a few years later, in 1998, DigiCash would go bankrupt.

This proved why decentralization was such an important property to strive for in a future version of digital money. If a company going bankrupt could cause the system to fail, then that system could never survive in the face of powerful adversaries.

The introduction of Bitcoin

Following Digicash, a number of important innovations would culminate in the pseudonymous Satoshi Nakamoto posting their Bitcoin Whitepaper to the Cryptography mailing list (this was slightly different from the cypherpunk mailing list, though it did have some overlap between participants).

With the introduction of Bitcoin, there was for the first time a decentralized system for payments that was secure against double-spending. A system that was accessible to all and was free from overreaching authorities. The cypherpunks' dream had at last been realized… *cough* If we ignore the lack of privacy at least *cough*.

Bitcoin solves the double-spending problem in a novel way. First it introduces its own currency, simply named Bitcoin:

1. Each coin is represented as a chain of digital signatures.

2. A coin can be transferred by signing the hash of the previous transaction and the public key of the recipient, and adding these to the end of the coin.

While this allows recipients to verify that whomever sent them their coins actually owned them, it doesn’t prevent double-spending on its own. For that, the recipient additionally needs to verify whether this was the first time the coins were spent.

In other words, anyone receiving a Bitcoin transaction needs to be aware of the entire history of Bitcoin transactions in order to check if a coin was spent prior to them receiving it. And because Bitcoin is decentralized, we need a way to agree on what the correct history of transactions is without relying on a trusted authority.

The solution that Satoshi proposed was a distributed timestamp server, or what is now better known as a Proof-of-Work blockchain. Anyone can participate in this network by sending transactions or running a node. It works as follows:

1. Users broadcast their transactions publicly to all nodes.

2. These transactions are bundled into a block by the block proposer.

   1. Blocks contain the block size, a list of transactions and a transaction counter, and a block header.

      1. The block header consists of the blockchain software version, the previous block's hash, the Merkle Root, a timestamp, the difficulty target, and the nonce.

   2. Anyone can become the block proposer by incrementing a nonce until they find a hash that starts with sufficiently many 0s as determined by the difficulty target. This activity is called Proof-of-Work, or PoW.

      1. The amount of 0s required is adjusted frequently, so that the time to find the correct hash remains close to 10 minutes, regardless of the overall hashrate.

3. The block proposer will broadcast their block to all other nodes once they’ve found the correct nonce.

4. The other nodes will only accept the block if all the transactions are valid and not double-spent.

5. Nodes will express their acceptance of this block by using its hash as the previous block hash in the next block they propose.

In this manner, we ensure that everyone can agree on the history of the Bitcoin blockchain, as each block refers to the previous block. Because we agree on the history, we can also verify that no transaction included in the chain has been spent before.

There is however one remaining issue. Imagine wanting to accept a Bitcoin transaction, tx1, in order to sell a pizza. We verify that tx1 has been included in block N. We now know for a fact that tx1 can’t have been double spent. It's however still not safe to immediately accept this transaction.

Recall that the Bitcoin chain is built by subsequent blocks all referring to the previous block. And a block can only be added through PoW. Nothing here guarantees that block N will remain part of the future Bitcoin blockchain.

For example, an attacker can create block N’ in parallel to block N and not include tx1 in block N’. If the subsequent blocks are then built on top of block N’ instead of block N, i.e block N’+1, block N’+2, etc, the Bitcoin blockchain will end up in a state that excludes block N, and thereby tx1 as well. This act of removing a block from the chain and inserting another is known as a reorganization, or reorg.

This means that if we accepted tx1 immediately upon seeing it in block N, the attacker would have effectively double spent tx1 against us, and we’d have sold them a pizza for free! Just imagine the alternate universe where the headline reads “Laszlo Hanyecz scammed me out of 10.000 Bitcoin by reorging the Bitcoin blockchain!”

So at what point should we then consider it safe to accept a transaction? According to math™, and assuming the attacker controls less than 51% of the network’s hashrate, we know that every time a block is built on top of the chain that includes block N, it becomes exponentially harder to reorg the chain to exclude block N.

Just waiting a few blocks therefore makes it probabilistically very difficult for an attacker to cause a double-spend via a reorg. Another way of thinking about this is in terms of finality guarantees: the guarantee that a transaction wont revert.

In Bitcoin, the finality guarantee is that if an attacker controls less than 51% of the network’s hashrate, then the odds of successfully reverting a transaction drop exponentially each block.

In other words, Bitcoin’s finality guarantee grows stronger with each passing block, assuming no one controls 51% of the hashrate. Though because there always remains a tiny chance a block could reorg, we say that Bitcoin only has ‘probabilistic finality’.

For example, if the attacker controls 10% of the network’s hashrate, then at block N+1 they’d have a ~20% chance to replace it with block N’ and N’+1. But if we waited to accept the transaction till block N+6 the attackers odds drop all the way to 0.02%.

So to answer the question of how long we should wait to accept a Bitcoin transfer, that depends on two factors. First, how valuable was the transfer? And second, how much risk are you willing to take? Depending on the answer we can determine how many blocks to wait.

At this point you may be asking “Gets, this is all pretty interesting, but you promised to explain why bridging and CEX deposits can be so slow! Not to mention, you’re supposed to explain what Espresso is!”. This is a fair point, so let’s begin with CEXs and bridges. And I promise I’ll cover Espresso after that!

CEXs are by default very risk averse (or at least, they should be!). If they fall victim to a double-spend attack owing to a transaction reverting then they stand to lose customer funds. In the past, multiple exchanges have fallen victim to double-spending. Most famous were the repeated attacks against Bitcoin Gold and Ethereum Classic, which led to millions of dollars worth of double-spending.

For this reason, CEXs often take a conservative approach to accepting deposits. For a Bitcoin deposit most CEXs tend to wait ~6 blocks to honor a deposit. With blocks being published once every ~10 minutes, it can take close to an hour to deposit Bitcoin to a CEX. Though a more sensible approach may be to wait fewer blocks for smaller deposits.

The ghosts in Ethereum

Most people reading this have likely deposited to a CEX from Ethereum or one of its rollup chains. This can generally take up to ~13-15 minutes. The Ethereum block time however is only 12 seconds. And the block times of rollups can be as low as 0.2 seconds! (And soon even faster, s/o to MegaEth)

So then why do exchanges wait such a long time to accept these deposits? To understand this we’ll need to understand the finality guarantees of Ethereum and, by extension, rollups. These differ quite a bit from Bitcoin’s.

First of all, Ethereum, and many rollup chains, do not track coins as a series of transaction outputs. Instead, individual accounts directly own balances of assets. A transaction simply subtracts the balance from the sender account, and adds the balance to the receiving account. Each account also includes a nonce that increments with every transaction, this ensures that the same transaction can’t be sent twice.

Reaching consensus also works differently in Ethereum. Rather than relying on Proof of Work, nodes can participate in the network by staking 32 ETH tokens. This process is referred to as ‘Proof-of-Stake’, or PoS, and we refer to the staked nodes as validators.

The validators run a consensus protocol called Gasper, which is really a combination of two other protocols: LMD GHOST and Casper FFG. Taken together, these allow Ethereum validators to progress the chain and finalize blocks.

It’s worth noting that in Ethereum finality is not probabilistic. Instead Ethereum guarantees that as long as ⅔ of the validators are honest, a finalized block can never reorg. One exception is if the community decides to manually fork the chain, in what is known as a hard fork. Additionally, an attacker would have to burn ⅓ of the total stake to finalize a conflicting block. In this event, a hard fork may be used as a last resort to decide which finalized block is correct.

What follows is an overview of how blocks get added to the blockchain and finalized in Ethereum:

1. ‘Slots’ happen every 12 seconds.

2. ‘Epochs’ happen every 32 slots. (~6.4 minutes)

3. Every epoch, the validator set is split into committees.

4. At least one committee is assigned to each slot within an epoch.

5. From the committee assigned to a slot, a single validator is assigned to propose a block of transactions to the network.

   1. An honest validator will propose their block to build on top of the chain with the most accumulated attestations.

6. The other validators in that committee will broadcast an attestation to the network. An attestation can be seen as a vote consisting of:

   1. A vote for the current head of the chain. The head is the latest block that has been observed by the validator. Ideally this is the block that was just proposed in their slot.

      1. If there are multiple forks observed, the validator will vote for the head of the chain that has the most votes attached to it, as weighted by stake.

      2. This allows us to assume that whichever fork we observe with the most votes by stake attached to it is the correct one.

   2. A vote for the most recent checkpoint that has been justified. (A checkpoint is justified if it has previously received votes from over ⅔ of the stake)

   3. A vote for the next checkpoint to be justified. This is typically the first block in the current epoch as observed by the validator. If the first block of the epoch is missing, then the most recent prior block is chosen.

   4. If validators submit multiple conflicting votes, they can be slashed.

7. Once 32 slots have completed (one epoch), we can justify the next checkpoint if it has received attestations from over ⅔ of the stake.

8. Once the new checkpoint has been justified, we can finalize the justified checkpoint it was built on top of.

9. Finalizing a block thus requires ⅔ of stake to come to an agreement, making it impossible for an attacker to revert a finalized block without:

   1. Owning or manipulating two-thirds of the total staked ETH.

   2. Destroying at least one-third of the total staked ETH (because they will be slashed for having voted on two conflicting finalized checkpoints).

It therefore takes at least 64 blocks, or ~12.8 minutes, to achieve Ethereum’s strongest finality guarantee. Namely, an attacker needs to burn ⅓ of the total staked Ethereum to finalize a conflicting block. This means it currently costs around $18B to attempt to double-spend a finalized transaction on Ethereum!

But Ethereum also provides a weaker finality guarantee. As we just learnt, every slot, a subset of validators gets to vote on what they believe to be the latest head of the Ethereum chain. If they see multiple conflicting forks, then they will vote on the block that is part of the chain with the most votes attached to it.

In this manner, observing a block that is part of a chain with a lot of votes attached to it all but guarantees that future blocks will also be built on top of it. This means that in a similar fashion to Bitcoin, it becomes harder to revert a transaction the deeper its block is buried in the chain.

So a CEX once again has options for when to accept a deposit. They can wait for a block to be finalized, knowing that an attacker needs to burn billions of dollars to double-spend against them. Or they can choose to wait for the deposit transaction to be buried sufficiently deep in the Ethereum blockchain based on their own risk framework. In practice however, many CEXs wait for the block to be finalized, as they prefer the certainty it provides.

Do rollups practice safe CEX?

As mentioned previously, Ethereum rollups in part share the finality guarantees of Ethereum. To understand this, let's briefly explore what an Ethereum rollup is. For our purposes, we will consider the following definition:

1. A rollup is a standalone blockchain.

2. Transactions for this blockchain are sent to a centralized server called a sequencer.

3. The sequencer determines an ordering for these transactions and turns them into blocks.

4. The sequencer publishes the blocks for consumption and promises not to change their ordering after publication.

5. The sequencer will forward their blocks in batches to Ethereum.

6. Ethereum will include the rollup’s batches in an Ethereum block.

7. Ethereum will eventually finalize the block that included the rollup’s transaction batch.

8. The canonical rollup blockchain is determined by the batches that were finalized on Ethereum.

In summary, the sequencer can make short-term promises about what the rollup chain looks like, but what is finalized on Ethereum will overrule the sequencer’s promise in the event of any discrepancies. The fact that the sequencer can give these short-term promises means rollup transactions have one additional finality guarantee as opposed to standard Ethereum transactions.

This new finality guarantee is often referred to as a ‘pre-confirmation’, or preconf. By this we simply mean that the sequencer promises that a transaction will end up in the eventual rollup chain, prior to the transaction being included in a batch that is finalized on Ethereum. We can observe that this preconf is entirely based on the reputation of the sequencer. There is no direct cryptographic or economic guarantee that the preconf will hold.

Relying on the sequencer for a preconf introduces a single point of failure. All it takes is for a single party to be compromised in order to break the finality guarantee. This could happen in many ways, whether by a rogue employee, or by a hacker with strong sympathies for their great leader.

This is exacerbated by the fact that many rollups today rely on the same party to run their sequencer, e.g. a Rollup as a Service provider (RaaS). If a single RaaS were to be compromised, the attacker could break the preconfs of all the rollups operated by that RaaS.

If a CEX were to accept a deposit from a rollup based on the sequencer’s preconf, they would take on two risks:

1. The sequencer’s operator could lie and post a different batch to Ethereum that doesn’t include the deposit transaction.

2. A malicious actor could compromise the sequencer and post a different batch to Ethereum that doesn’t include the deposit transaction.

To avoid the risk of being double-spent against by such attacks, CEXs typically wait for deposits from a rollup to be included in a batch that has been finalized on Ethereum. This is why it often takes a similar amount of time to deposit from a rollup to a CEX as it takes to deposit from Ethereum itself (~13-15 minutes).

The logic for why it can take a long time to bridge between Ethereum and its rollups is largely the same. To build this intuition, let's consider an attack on a very simple burn-and-mint bridge that allows us to move USDC between Arbitrum One and Base:

1. Alice sends 100 USDC to a burn smart contract on Arbitrum One in block N.

2. The smart contract burns the 100 USDC tokens.

3. Alice presents the transaction that burnt her USDC to a mint smart contract on Base in block M.

   • We assume that the smart contract on Base can verify this transaction was executed on the Arbitrum One blockchain in block N.

4. The mint smart contract on Base mints 100 USDC tokens and sends these to Alice in block M+1.

5. Alice causes Arbitrum One to reorg, ending up in block N’. In this new fork she witholds her original burn transaction.

6. Result: Alice now has 100 USDC on Base while retaining her original 100 USDC on Arbitrum, thereby inflating the USDC supply, and supposedly pissing off Circle and other holders of USDC in the process.

To prevent this from happening, bridges therefore may wait to honor a transaction until they are more confident a reorg can be avoided. Though certain bridge designs in use today do tend to trust centralized sequencers, they take on substantial risk. This was recently highlighted when Degen Chain experienced a reorg, causing issues for the Relay bridge.

The so-called ‘canonical bridges’ between rollups and Ethereum take their security to the most extreme level. Not only do they wait for Ethereum finality to avoid reorgs, they also ensure that no trusted party is required to verify that a transaction that withdraws assets from the rollup executed correctly.

This does mean that bridging with the canonical chain takes as long as it takes to perform the trust-minimized verification. For rollups that rely on fraud proofs this can take up to 7 days. Using zk-proofs and TEEs instead can greatly speed things up, but may increase costs.

Adding a shot of Espresso

Now that we know the basics of how rollups prevent reorgs that could lead to double-spending and how this may affect the time it may take to deposit to a CEX or bridge between rollups, it is finally time to explain what Espresso does. I promised we’d get to this!

At its core, Espresso is also a blockchain. Similar to Ethereum, nodes can participate in Espresso via PoS. Likewise, the staked nodes are referred to as validators. The validators run a consensus protocol called HotShot. (Espresso’s validators are currently whitelisted, with permissionless PoS in testnet and planned for release later in 2025)

And like Gasper in Ethereum, HotShot allows validators to vote in order to finalize Espresso blocks. The way this works in HotShot is as follows:

1. HotShot proceeds in a series of ‘views’.

   1. Views don’t have a fixed time frame. Instead, they can proceed as fast as the network allows.

2. Each view, one validator is randomly chosen to be the leader and propose a block during that view. The leaders for each view are chosen ahead of time.

3. The leader either:

   1. Forms a quorum certificate, or QC, from the highest view they’ve observed, ideally this is from the previous view.

      1. A QC can be formed when ⅔ of the stake-weighted validators vote that a valid block was proposed in a given view.

   2. If they can't form a QC from the highest observed view, they will form a timeout certificate, or TC, for that view instead. Additionally, they will include a QC for the highest view in which they could successfully form a QC.

      1. A TC can be formed when ⅔ of the stake-weighted validators vote that no valid block was proposed within a specific timeframe for a given view.

4. The leader bundles transactions into a block and broadcasts it to the network. For efficiency, the block is erasure coded into shares, and validators receive shares proportional to their stake, as opposed to the full block. The shares are divided in such a manner that ⅔ of the stake-weighted validators can always reconstruct the block. Additionally, as part of their proposal, the leader will:

   1. attach the QC for the highest view they’ve observed. Or;

   2. Attach the TC for the highest view they’ve observed, and additionally attach the QC from the highest view they’ve been able to obtain one from.

5. If a block is proposed during a view with a valid QC then it is certified. In this manner, the proposed block always extends the highest certified block as observed by the leader.

6. The validators will vote to accept the proposal if in their view the proposed block also builds on top of the highest certified block they have observed. To accomplish this, each validator keeps track of all votes for all blocks they have observed.

   1. Votes to form the QC are sent directly to the leader of the next view.

      1. Validators can be slashed for submitting conflicting votes on the same view.

   2. If the validator does not receive a valid proposal within a specified time following the last view, they will instead send a vote to form a TC to the next leader.

7. Once the leader collects ⅔ of the votes they can immediately form a new QC or TC and propose a new block.

8. In this manner we create a chain of certified blocks, where each block must refer to the previous certified block.

9. Once a chain of 2 certified blocks is formed, we can finalize the first certified block of the 2-chain as soon as we receive a subsequent QC.

   1. For example: Proposal(view = 10, QC(view = 7), TC(view = 9) ) <- Proposal(view = 11, QC(view = 10) ) <- Proposal(view = 12, QC(view = 11) ). Following this, we know that at least ⅔ of stake agrees the block proposed in view 10 is correct and becomes finalized.

In practical terms, this process enables Espresso to finalize blocks in just a few seconds. Additionally, because finalized blocks include a QC that proves that ⅔ of stake voted on it, we can slash up to ⅓ of the stake in the event that a second, conflicting block is finalized, as they’ll have voted on both blocks. This means Espresso gives the same type of strong finality guarantee that Ethereum gives at much lower latency.

Now that we know how Espresso finalizes blocks, we can slightly tweak our earlier rollup definition to create a new type of rollup that works as follows (additions in italics):

1. A rollup is a standalone blockchain.

2. Transactions for this blockchain are sent to a centralized server called a sequencer.

3. The sequencer determines an ordering for these transactions and turns them into blocks.

4. The sequencer publishes the blocks for consumption and promises not to change their ordering after publication.

5. The sequencer forwards their blocks to Espresso.

6. Espresso will include these blocks in a block.

7. Espresso will quickly finalize the block that included the rollup’s block.

8. The blocks finalized by Espresso will be batched and forwarded to Ethereum.

9. Ethereum includes these batches in a block.

10. Ethereum eventually finalizes the block that includes the rollup’s transaction batch.

11. The canonical rollup blockchain is determined by the batches that were finalized on Espresso and Ethereum.

Thanks to integrating Espresso, the rollup can now offer a new type of finality guarantee for its transactions. All we need to do is alter the rollup’s settlement contract to only accept blocks that have been finalized by Espresso. This ensures that if a rollup block was finalized by Espresso, it will end up in the canonical rollup blockchain, unless an attacker controls ⅓ of Espresso’s stake and is willing to burn it.

This is practically the same guarantee that Ethereum provides, albeit with fewer validators and less economic security. Though there is no reason this has to remain the case, assuming that Espresso becomes a successful protocol, combined with the ability to restake ETH tokens to Espresso.

The important difference is that Espresso finalizes blocks in just a few seconds, as opposed to the ~12.8 minutes it takes Ethereum.

And this finally ties everything together. Traditionally, depositing to CEXs from rollups, and bridging between rollups, was slow, due to the fact CEXs are conservative entities that want strong finality guarantees. Thanks to Espresso, rollups can now achieve these strong finality guarantees at very low latency!

This means CEXs can safely process deposits from rollups integrated with Espresso within seconds. Likewise, bridges can safely process crosschain transactions from Espresso-integrated rollups within seconds, as well.

The answer!

So, to answer the original questions that prompted this post:

1. Why is bridging between L2s so slow in some cases? And why does it take so long to deposit to centralized exchanges (CEXs) from L2s? Because they want to avoid double-spending!

2. What exactly is Espresso? A blockchain that provides rollups with strong protection against double-spending at very low latency!

Appendix

Novel bridge designs

It's worth noting that novel bridge designs have been implemented that try to isolate the risk of double-spending to affect only certain participants of their protocol. This enables these bridges to settle crosschain transfers quicker, so long as they can find participants willing to take on the added risk. For these bridges, it is arguable whether Espresso would provide much benefit in terms of latency. However, it is undeniable that they stand to gain much from the additional security benefits provided by Espresso.

I will include a brief overview of two of the most popular designs, which will make it apparent that Espresso greatly increases their security, while retaining their ability to provide end users with low latency crosschain transactions.

The first category revolves around ‘solvers’. These are entities that fill orders on the end user’s behalf. A popular example is Across. I will next describe the bridging flow in Across, where Alice wants to move 1 ETH from Arbitrum to Base, with the help of solver Bob:

1. Alice signs an intent to bridge 1 ETH from Arbitrum to Base.

2. Alice’s 1 ETH is deposited into an Across escrow contract on Arbitrum.

3. Bob waits till they are confident Alice’s 1 ETH deposit won't reorg.

4. Bob claims Alice’s intent to bridge.

5. Bob sends Alice 1 Eth from his personal funds on Base.

6. Bob submits proof they have paid Alice to the Across protocol

7. After a challenge period, Across will repay Bob 1 Eth.

In this design, Bob is competing with many other solvers, and whichever solver claims Alice’s intent to bridge first gets to complete the order and earn a fee. This means that typically the winning solver will act based on the pre-confirmation given by a rollup’s centralized sequencer, as opposed to waiting for Ethereum. If a transaction is large enough however, there may not be any solvers willing to take on that risk, and Alice may end up waiting ~15 minutes for Ethereum finality.

Espresso may be especially useful to speed up these larger transactions, but also makes it far safer for solvers to fill smaller transactions with low latency. Additionally, as new rollups continuously pop up, Espresso removes the need for solvers to worry about the trustworthiness of any new sequencer, which may reduce the friction faced when trying to onboard solvers to new rollups.

The second category of bridges are based around liquidity pools. In this design, users can deposit tokens into a pool that others can access for crosschain transactions.

Some trusted party is then relied upon to sign messages that attest to something like the following: ‘We have confirmed that Alice has deposited 1 ETH on Arbitrum, she can now withdraw 1 ETH from the liquidity pool on Base’. Once this message has been received on Base, Alice will be able to withdraw 1 ETH.

In the example mentioned above, the party that signs the crosschain message is responsible for verifying that the deposit on Arbitrum was successful and won’t revert. This means that if these types of bridges want to provide low latency for bridging between rollups, they have to rely on preconfs from the sequencer.

Now the risk becomes less isolated, as a double-spend can impact all the liquidity providers in the pool, as opposed to just a single solver. Not to mention, the trusted party can also steal all the funds from the liquidity pool by forging messages. But because liquidity is pooled, these systems may have an easier time with supporting larger swaps than solver based bridges.

Stargate, which is the most used bridge in this category, improves on this design even further with ‘Hydra’. Here they allow tokens locked in the liquidity pools to be minted 1:1 as ‘Bridged Assets’ that can be burned and minted on chains that support Hydra. This greatly increases their capital efficiency and effectively allows chains to share liquidity using the Bridged Assets.

The downside here is that risk is no longer isolated any type of hack will have far reaching effects, as it can impact both LPs and typical end users holding the Bridged Assets on other chains that support them.

This is somewhat akin to the consequences faced following the Multichain bridge hack. This resulted in over $100m in losses for LPs, and bridged assets losing most of their value, causing great harm to anyone holding them.

Incidents like these once again highlight why security is so important. Integrating Espresso into applications like Stargate can mitigate many of these risks, both by avoiding reliance on centralized sequencers for preconfs to support fast bridging, and by replacing the trusted parties in charge of signing messages with TEEs and/or ZKPs.

Espresso as a shared sequencer & DA layer

People who have been following Espresso for a while may have some questions after reading this post. Espresso has spent a lot of effort on trying to get rollup chains to use the same decentralized sequencer. Yet this is a somewhat distinct problem from that of providing rollups with protection against double-spending. So can we still use Espresso as a shared/decentralized sequencer and DA layer?

The answer is a resounding yes! The main difference between using Espresso as a sequencer and purely using it for double-spend protection is that rollup users send their transactions directly to Espresso, as opposed to sending them to a centralized sequencer first.

The benefits of Espresso become even more pronounced when used as a shared sequencer. It grants rollups stronger censorship resistance, removes central points of failure, and makes it much easier to achieve the holy grail of interoperability: synchronous composability. Distinct rollups that share the same block builder in combination with Espresso can act as if they are a single blockchain.

Realistically however, most rollups prefer to maintain their own centralized sequencer for many reasons I won’t get into here (I think you’ll agree this post is long enough as is). I do however believe that we will reach a point where this is no longer the case, and at that time a natural evolution for rollups that are already integrated with Espresso for confirmations may be to use Espresso as a sequencer as well.

Espresso’s design still makes it as easy as ever to use for sequencing, while maintaining revenue, and regardless of the rollups internal design and application specific needs.

As for DA, Espresso is once again flexible. Any integration with Espresso automatically makes use of EspressoDA, but rollups are free to use additional DA layers if they so desire. For example, we assume that most Ethereum rollups will continue to use Ethereum for DA in addition to EspressoDA. What we do ensure however is that Espresso can offer extremely high throughput DA to whomever needs it.

And for anyone who wishes to accuse us of pivoting, I dare you to find one other project who has managed to produce blog posts that are way too long with such consistency over the years! (Jon Charbonneau doesn’t count)