# Bridging fast and safe with Espresso
*Author: [gets](https://twitter.com/getsqt)*

Espresso satisfies some of the most desirable criteria for bridges, both from a security and speed perspective. [HotShot](https://docs.espressosys.com/sequencer/espresso-architecture/hotshot-fast-finality-for-l2s), besides providing consensus for Espresso’s sequencing [marketplace](https://hackmd.io/@EspressoSystems/BasedEspresso), also acts as a shared finality layer for rollups, finalizing L2 transactions within seconds. Rollups use HotShot to provide a strong pre-confirmation that their transactions will eventually be finalized on the layer-1. HotShot can support all of Ethereum’s consensus participants through restaking, granting it a high level of decentralization and economic security. This means that the safety guarantees are expensive to break, and it helps mitigate regulatory and cybersecurity risks through decentralization. A safety guarantee refers to the conditions under which a determined state of a blockchain will not be changed. Today’s L2 bridging experiences demand a tradeoff between speed and security, but with HotShot speed and security go hand in hand.

Even in the event of a safety violation, the shared finality gadget can be used to roll back all participating chains in unison, providing protection against cross-chain double spends. In the case that only the source chain of a bridge transaction uses Espresso, it will still be possible to quickly bridge out, owing to strong safety guarantees. For example, [Circle’s CCTP](https://developers.circle.com/stablecoins/docs/required-block-confirmations) doesn’t trust the pre-confirmations provided by centralized sequencers. However, if a rollup utilized the HotShot finality gadget, they could enable fast, native USDC bridging from their L2 to other chains. Espresso therefore makes rollups not only more well connected with chains that share the same finality gadget, but also with the broader ecosystem. We showcased fast bridging between rollups in a recent [demo with Across](https://www.youtube.com/watch?app=desktop&v=gCAP8pw312A), with the bridge transaction settling in seconds!
## Exploring how bridges work
In order to unpack why exactly Espresso improves bridging for L2s, we will now explore bridges in a bit more detail. Bridges are primarily used to transfer and swap tokens between blockchains.

Imagine that Alice wants to bridge DAI tokens from chain A to chain B. There are two approaches commonly used by bridges to achieve this. One way is for bridges to lock and mint tokens. In this system, Alice will lock DAI on chain A, and once chain B has confirmed the lock, Chain B will mint (wrapped) DAI tokens to Alice.

The other model sees bridges relying on pre-existing liquidity on the destination chain. In this design, Alice will find a counterparty to send her DAI to on chain A, and have the counterparty send her DAI (or another token of her choice) on chain B. Certain “liquidity bridges” can be custodial, in which case Alice is relying on a trusted third party to send her tokens on chain B.

All types of bridges (besides fully custodial ones, where the custodian simply verifies they have received funds on chain A and sends the funds to a predefined account on chain B) rely on a message passing between chain A and chain B, and a way to verify the authenticity of that message. 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. For an overview of the methods used to verify these cross-chain messages, this [L2BEAT post](https://gov.l2beat.com/t/l2bridge-risk-framework/31) is a great reference point.

Bridges rely on these verification processes to protect different aspects of the cross-chain application. For lock and mint bridges, the verification process prevents Alice from minting DAI on chain B without first locking DAI on chain A. For liquidity bridges, the verification process protects liquidity providers and/or users involved in the bridge transfer.
## Safety guarantees
Besides verification, there is another important aspect of bridge security. We need a way to determine the safety guarantee of the blockchain state that is being verified. For example, Ethereum’s strongest safety guarantee is that as long as 2/3 of the stake is honest, the finality achieved after two epochs will not break. The cost to break this safety guarantee is 1/3 of Ethereum’s stake, as stake will be slashed in the event of a safety violation.

Consider the following bridge example. Alice locks DAI on chain A, and mints DAI on chain B after some verification process. Now, Alice has her DAI on chain B, but also causes chain A to revert to a state prior to her locking of DAI. The end result is that Alice has effectively doubled the amount of DAI she owns by bridging to chain B while also retaining her DAI on chain A, thereby inflating the total supply of DAI on the market.


Assuming that chain A was Ethereum and the bridge waited 15 minutes for Ethereum to finalize, this is unlikely to happen. This owes to the fact that the cost of this attack is 1/3 of Ethereum’s stake. However, if the bridge didn’t wait for Ethereum to finalize, this could happen through a simple reorg with no slashing punishment. Prior to finalizing, Ethereum’s safety guarantees are therefore not as strong.

The following criteria of blockchains need to be taken into consideration by bridges when determining how trustworthy the safety guarantees they are relying on are, and what happens in the case a safety guarantee is broken, along with some examples:
## Shared versus siloed consensus
Sharing consensus allows for shared safety guarantees. This means that bridges can easily reason about safety, because there’s only one relevant source of finality. More importantly they can avoid losing funds in the event of a reorg or safety violation by designing their bridge with the shared safety in mind.

This is because any reorg or safety violation can apply to all chains within the shared consensus equally, allowing them to roll their states back in unison. For example, canonical rollup bridges between rollups and the L1 share safety guarantees, because the rollup and the L1 eventually share consensus. Any reorg or safety violation on the L1 will impact the rollup equally. However, a rollup can still reorg independently from the L1 prior to the rollup’s transactions being included on the L1, because at that point the rollup follows the consensus of its sequencer.

Certain bridges make use of this shared security to improve UX for the end user when compared to the canonical rollup bridge. For example, [Bonders in the Hop bridge](https://docs.hop.exchange/basics/a-short-explainer#hop-is-powered-by-a-set-of-bonders) expedite bridge transactions from rollup A to rollup B by running a full node of rollup A and verifying that a bridging transaction originating from rollup A has been finalized in an L1 block. This allows an end user to bridge faster than waiting on the canonical rollup bridge, yet is just as secure owing to the shared safety guarantees.


Similarly, [Relayers in Across](https://docs.across.to/relayers/running-a-relayer) may choose their own criteria for when to honor a bridging transaction. For example, if Alice wants to send DAI from rollup A to rollup B:
* Send Alice DAI on rollup B when Alice’s bridge transaction is finalized on the L1. This prevents all parties involved from losing funds.
* Send Alice DAI on rollup B when Alice’s bridge transaction is included on the L1. If the L1 experiences a reorg which only affects rollup A, the relayer may not receive Alice’s DAI on rollup A and thereby lose capital.
* Send Alice DAI on rollup B when Alice’s bridge transaction is included on rollup A. If rollup A’s sequencer equivocates, the relayer can lose their capital.
## Economic security vs reputation
Economic security imposes a monetary cost on attacks, but requires capital to be secure. But this capital requirement makes safety guarantees easier to reason about. For example, breaking finality in Espresso will probably bear a large slashing cost due to restaking. This means that a rational actor would need to be able to profit a lot to consider breaking safety in Espresso.

Rollups typically don’t rely on economic security, and instead rely on the reputation of the entity running their sequencer to provide safety guarantees to users prior to settlement on the L1. Economic security and reputation can be combined, as is done in dPoS systems for example.

Bridges can also rely on known entities to honestly perform their role to secure the bridge. For instance, the [Wormhole Guardian](https://docs.wormhole.com/wormhole/explore-wormhole/guardian) network consists of 19 entities that would suffer severe reputational damage and legal consequences if they misbehave.
## Centralized vs decentralized systems
Centralized systems are typically faster than decentralized systems and easier to instantiate, but may have weaker safety & liveness guarantees. They also generally rely more on reputation instead of economic security, allowing them to be more capital efficient.

But, they have a number of key vulnerabilities. Some risks can be related to cybersecurity. The [Ronin bridge hack](https://cointelegraph.com/news/the-aftermath-of-axie-infinity-s-650m-ronin-bridge-hack), one of the largest cryptocurrency related hacks to date, happened because a single party was compromised. Regulatory pressure is another issue that may weigh heavier on centralized entities. For example, a centralized sequencer might be forced to censor transactions at the whim of any enforcement body that pressures them in the jurisdiction they are based within, causing funds to become stuck. Though this may be less of an issue if an escape hatch is implemented.

Centralized systems may have very low latency, which can lead to good UX. However, any bridge that relies on the safety guarantees of a centralized party is taking on additional risks. For example, if a bridge trusts the soft-confirmation of a centralized sequencer, all it takes is for a single party to equivocate for whatever reason, and the bridge will lose money. Even if the sequencer operator is honest, it could still fall victim to a cybersecurity incident causing them to equivocate on their soft confirmation.

Decentralized systems are typically slower than centralized systems, but can have stronger safety & liveness guarantees. Though recent advances in consensus protocols have brought down the latency to within reach of their centralized counterparts, as is reflected in HotShot. Decentralized systems tend to rely more on economic security instead of reputation, as this helps with keeping their operator set more permissionless. They may also be more secure against regulatory capture, especially if the nodes are geographically distributed. The fact that they are run by a large set of participants also makes them safer against cybersecurity threats, because more than one party needs to be compromised to break the security of the system.
# Conclusion
[Much](https://hackmd.io/@EspressoSystems/SharedSequencing#Atomic-cross-rollup-transactions) has been [said](https://www.youtube.com/watch?t=134&v=eg1vg6HzOJI&feature=youtu.be) about the atomicity guarantees provided by participants of the Espresso marketplace that acquire shared sequencing rights. For example, by relying on a crypto-economic bond or [real time proving](https://www.youtube.com/watch?t=134&v=eg1vg6HzOJI&feature=youtu.be), they can settle cross-chain transactions atomically in a single block. In the economically bonded case, the shared sequencer will attest to the validity of some cross-chain transaction, and the total volume of cross-chain transactions can be limited to equal the total security bond within some fraud proof window. With real time proving, the shared sequencer would provide validity proofs of state to go along with some cross-chain message to ensure correct execution.

Through this post we now also hope to have explained why Espresso, through HotShot, ensures that bridges can settle transactions originating from L2s with greater speed while maintaining strong security guarantees. Espresso helps unify the L2 landscape, not only by enabling synchronous composability through its marketplace for shared sequencing, but also by improving the asynchronous interoperability we all know and use today. If you are working on an application or a rollup that will benefit from bridging with Espresso - or if you are working on a bridging protocol and interested in partnering - get in touch with us [here](https://y3at7jy5knf.typeform.com/to/KgayxNsX?typeform-source=www.espressosys.com).