Espresso on Bitcoin

# Espresso on Bitcoin *Disclaimer(s): This blog is purely conceptual. There are currently no “trust-minimized” validating bridges for rollups on Bitcoin. Everything is currently a multi-sig. There are no Bitcoin rollups in production. There are some cool rollup designs happening around BitVM (e.g. Citrea).* --- Espresso offers a shared sequencing marketplace for rollups (and other offchain scaling protocols). It enables proposers to bid on slots for individual rollups, or multiple rollups at once. These proposers can be proposers for the Ethereum EVM mainnet, or proposers only participating in HotShot. A new wave of scaling protocols on top of Bitcoin are currently being developed. A number of these proposed protocols are sovereign rollups, or BitVM rollups, that will use Bitcoin for data availability. Bitcoin sidechains are also being developed to act as a settlement layer for rollup-style blockchains. Rollups on top of Bitcoin (or Bitcoin sidechains) can use Espresso to decentralize their sequencer set. Rollup stacks can also opt-in to using Tiramisu DA to offer high throughput and low cost data availability to support validium-like appchains. In this blog post I will cover what it takes for Bitcoin rollups to integrate with Espresso. Espresso is made of two components: a) HotShot finality gadget and b) a combinatorial auction to assign proposers. You can read more on these components [here](https://hackmd.io/@EspressoSystems/BasedEspresso#Construction-details). ## Transaction lifecycle In many proposed Bitcoin rollup implementations, [transactions](https://www.blog.citrea.xyz/life-cycle-of-a-citrea-transaction/) are sent to a sequencer node for transaction inclusion and ordering. After transactions are included in blocks, and are ordered, blocks are sent to a prover that executes the transactions in the block and submits a valid proof of execution (a.k.a validity proof) to the Bitcoin L1 as an inscription. A [BitVM](https://bitvm.org/bitvm2) bridge program, or group of sovereign rollup nodes, will read this proof and verify that the rollup state transition is valid. For rollups settling on sidechains, the transaction life is practically the same as a rollup on Ethereum. This is because proposed Bitcoin sidechains have more expressive execution environments and can (maybe) verify zk-SNARKs containing rollup state transitions. We wrote about that lifecycle [here](https://hackmd.io/@EspressoSystems/EspressoSequencer#A-Rollups-Overview). In either of these designs, integrating with Espresso would see the sequencer node be replaced by a marketplace of participating proposers. These proposers can be HotShot proposers or Ethereum L1 proposers who have opted into participation in HotShot consensus. The process is as follows: - Proposers purchase “lottery tickets” to bid on specific rollup slots. Proposers can bid on a single namespace (one rollup) or multiple namespaces (multiple rollups) at once. - Upon winning the rights to build a HotShot block, proposers construct the HotShot block in its given slot. - The block is constructed and broadcasted to a quorum of HotShot nodes who attest to the block commitment and finalize it on HotShot. - This gives rollup users a preconfirmation that their transaction is included in a HotShot block, and will be finalized on its respective L1. After the block is constructed, the block will be sent to a prover who will execute the transactions in the given order and then generate the aforementioned proof of correct execution. It’s worth noting that Espresso’s finality gadget, HotShot, is optimistically responsive and has no fixed block time or size. This means that it can process pretty big blocks in mere seconds under optimistic network conditions. ## Data availability bridge Espresso’s data availability layer, Tiramisu, satisfies the data availability requirement for HotShot. To track the current state of HotShot, and ensure that previously proposed blocks match the proof of execution generated by the prover, a Bitcoin rollup would need to be able to read the current state of Espresso. Due to limitations in Bitcoin script, it is not possible to create a data availability bridge between Tiramisu and an on-chain Bitcoin L1 contract. However, BitVM enables us to run a sidechain bridge program off the Bitcoin mainchain to execute an Espresso light client optimistically, with a 1-N trust assumption. Bridge operators could be challenged by any of the online verifiers in the event that they are withholding data or are offline. Thus, we can have a subset of Bitcoin full [nodes](https://github.com/BitVM/bitvm-js/blob/main/docs/sidechain_bridges.md) participate in the DA bridge between Espresso and BitVM. In this design, the BitVM bridge program would run an Espresso light client and verify Espresso signatures to read Espresso headers directly. Once the Bridge is able to read Espresso headers, or the rollup state root, they can implement a dehashing oracle to read whatever they like from Espresso, including reading blobs from Tiramisu DA. This would enable the bridge program to read data blobs directly from Tiramisu and verify them against rollups’ proofs of execution that are inscribed into the Bitcoin L1. This design is suitable for Bitcoin as the bridge program would also be responsible for [verifying zk-SNARKs](https://bitvm.org/snark) containing the rollup’s state transitions. Bitcoin sidechains can be more permissive than the Bitcoin L1. A sidechain with more permissive smart contracting capabilities could simply have a bridge program on-chain run an Espresso light client to verify HotShot state. This would enable it to read Espresso headers, and verify rollups’ proof of execution stored against data blobs from Tiramisu. For example, [SIDE Chain](https://docs.side.one/) is going to use Espresso to decentralize its sequencer operators for rollups using it as a settlement layer, and could implement this type of bridge program to integrate with Espresso. ## Potential use cases Not only does the Espresso marketplace enable rollups to sell their slots to a network of participating proposers, improving decentralization and credible neutrality, but it also allows for transaction bundles between rollups using Espresso. For example, a rollup using Bitcoin for data availability, and an Ethereum rollup, could sell their slots to a shared proposer, enabling atomic inclusion for rollup transactions between the two rollups (see open questions). This would improve interoperability between Bitcoin rollups and rollups from other ecosystems. Another interesting use case for rollup-like blockchains, on Bitcoin, is using Espresso’s Tiramisu as a data availability layer. This could make these Bitcoin chains pseudo-validiums. This gets especially interesting when chains do not want to enshrine a specific data availability layer, and want to have bridges with multiple blockchains. For example, a validium could have a native bridge contract with Ethereum, and run a BitVM bridge program to secure its Bitcoin assets, and use Espresso for DA. For a modular settlement layer, like Side Protocol, a shared sequencing marketplace will enable its rollups to have improved interoperability and atomicity with each other, and likewise with rollups in other ecosystems. ## MEV Mitigation Espresso enables rollups to enact their own block builder policy for MEV mitigation purposes. For example, rollups could create a builder protocol that leverages an encrypted mempool that doesn’t let block builders see the contents of rollup transactions. Then, proposers who won the right to the rollup’s slot will take the produced block from the builder network, propose its contents to HotShot attesters, and see the block be finalized on HotShot (see open questions). For more on MEV mitigation and Espresso, please see this post on [Timeboost](https://medium.com/offchainlabs/time-boost-a-new-transaction-ordering-policy-for-arbitrum-5b3066382d62) and this blog [post](https://blog.shutter.network/shutter-for-espresso/) from Shutter Network. ## Open questions When writing this blog, some team members and I chatted through some open questions we have on such an integration: - In the future could Espresso add a Bitcoin signature into Espresso state? If so, then presumably the Bitcoin L1 could actually verify Tiramisu. Is this possible given current constraints on Bitcoin L1? If not, what would be needed to make it possible? - Can a rollup on Bitcoin synchronize its slots with the Ethereum L1 to ensure stronger atomicity guarantees with Ethereum rollups? - For what it’s worth, some of us think so! - Is it possible to split the "Bitcoin L1 state" into smaller parts? This is desirable because, instead of being conditional on a Bitcoin block, rollup finality is conditional on an individual UTXO. So long as that UTXO doesn't change due to a reorg, then x-rollup atomicity is unaffected, even if Bitcoin reorgs as a whole. - What would be needed for Bitcoin miners to participate as HotShot proposers? - What is the relationship with rollup block builders, HotShot proposers and Bitcoin miners in the context of Bitcoin? For example, what are the consequences of a rollup that implements a specific builder policy (e.g. Timeboost) in a world where Bitcoin miners can also act as HotShot proposers? ## To Finish While Espresso is primarily focused on supporting Ethereum’s rollup-centric roadmap, the introduction of more expressive bridge programs creates an opportunity for potential integrations between Bitcoin rollups and Espresso. Espresso will likely be in production before Bitcoin rollups, so this also gives them an interesting opportunity to launch with decentralized sequencers and have improved composability with all rollups integrated with Espresso. If you are interested in exploring integrations between Bitcoin and Espresso, please contact me on [Twitter](https://twitter.com/januszg_) at @januszg_. ### References 1. [BitVM Sidechain Bridges](https://github.com/BitVM/bitvm-js/blob/main/docs/sidechain_bridges.md) 2. [Chainway Clementine Blog](https://www.blog.citrea.xyz/unveiling-clementine/)