Sovereign rollups on bitcoin

This thread is based on two Twitter threads I published about sovereign rollups on bitcoin here and here.

A few weeks ago Eric Wall gave a talk at StarkWare Sessions where he left the audience with an intriguing idea: what if we used the same technique that inscriptions use to embed data in bitcoin to build a sovereign rollup on bitcoin?

This idea of using bitcoin as a data availability layer for sovereign rollups was also hinted at last month by Sovereign Labs in their Sovereign SDK announcement.

What is a sovereign rollup? Referencing Celestia’s conception of the modular blockchain stack, a sovereign rollup is a settlement (and maybe also execution) layer blockchain that uses another blockchain as its consensus and data availability layer.

A sovereign rollup built on bitcoin can have its own execution environment supporting custom logic, while obtaining bitcoin-grade data availability and double-spend resistance. Note however that like a sidechain, and unlike a validity rollup, there is no trustless BTC bridge.

The cost of obtaining bitcoin-grade data availability and double-spend resistance is an upper limit on throughput: a sovereign rollup can only support as many txs per block as it is able to fit into the available space in a bitcoin block (max 4 MB of data).

Validity proofs could still have a role to play in sovereign rollups, but for scaling rather than bridge security: a sovereign rollup could still include validity proofs in its block data, allowing many more transactions to fit into a block than would otherwise be possible.

The idea here is that rollup block producers can still use the same data compression techniques that are possible with validity rollups, such as referring to accounts instead of addresses and only posting state diffs with validity proofs, saving a lot of space onchain. Rollup full nodes would then scan bitcoin blocks looking for transactions that contain block data relevant to them, and if the attached proof validates, then they will add that block to their chain, apply the state diff to the state, and proceed to the next block.

Regardless of whether validity proofs are used or not, the only way to re-org a sovereign rollup block is to re-org the bitcoin block that the sovereign rollup block was confirmed in. That gives sovereign rollups their bitcoin-grade data availability and double-spend resistance.

“But,” you might wonder, “there’s no trustless bridge! What is this sovereign rollup thing good for?” Yep, if you want to use BTC, you still need a trusted bridge to the rollup. The benefit is, once you have that, then the rollup has bitcoin-grade data availability and double-spend security.

With a sovereign rollup built on bitcoin, one rollup confirmation = one bitcoin confirmation. That is a real security improvement over the sidechains of today, which, due to their lower security budget, are much easier than bitcoin to re-org. Also, building a sovereign rollup on bitcoin can provide a nice testing ground for devs and users to get a feel for what a validity rollup on bitcoin would be like. Yeah, there’s no trustless BTC bridge, but everything else (data availability capacity, block time, etc) is ~the same.

At my local BitDevs meetup, someone asked: how is this sovereign rollup technique different than blockchains like Stacks that put a hash of their blocks into bitcoin transactions?

The first difference is that unlike a sovereign rollup, Stacks is able to re-org independently of bitcoin. Worth noting that, unlike bitcoin re-orgs, attempts to re-org Stacks have to be made public from the start. This is described in SIP-001:

Like all single-leader blockchains, the Stacks blockchain allows the existence of multiple blockchain forks. These can arise whenever a leader is selected but does not produce a block, or produces a block that is concurrent with another block. The design of the Stacks blockchain leverages the fact that all attempts to produce a block are known to all leaders in advance in order to detect and mitigate block-withholding attacks, including selfish mining. It does not prevent these attacks, but it makes them easier to detect and offers peers more tools to deal with them than are available in existing systems.

The second difference is data availability. Because Stacks only stores a hash of its blocks in bitcoin transactions, not the full block data, Stacks has different data availability guarantees than bitcoin. We’ll come back to data availability and why it matters later.

There are other protocols that only put a hash of a blockchain into bitcoin transactions and yet do fully inherit bitcoin double-spend security. Commerce Block’s Mainstay is one such protocol:

Mainstay is a protocol that enables the creation of a cryptographic proof that a given system with changing state is unique and that the full history of that state is unique. This proof is generated from a linked sequence of irreversible and provably unique cryptographic commitments made to the Bitcoin blockchain which in turn derives its immutability and global objective state from the Proof-of-Work consensus algorithm. In this way, any independent system with state (and a unique history of state changes) can be proven to be as immutable as the Proof-of-Work blockchain it is secured by. The proof of immutable state (PoIS) generated by the Mainstay protocol is trustless and independently verifiable.

Mainstay differs from sovereign rollups in two key ways. The first difference is Mainstay’s reliance on third parties to maintain forward progress. If the third party fails, then the Mainstay chain will need to hard fork to restart.

An important property of the Mainstay protocol is that it does not require trust in any party, including the entity holding the staychain base private key (xpriv) to confirm that a given sidechain state is immutable. However trust is required in this entity to ensure that the mainstay is persistent, and that the system continues to operate (i.e. commitments continue to be generated). If the key was stolen then an attacker could steal the Bitcoin in the staychain tip output and prevent further confirmations. To remedy this, the sidechain would need to be hard-forked to reset the mainstay (i.e. to commit a new base transaction into the sidechain).

The second difference between Mainstay and sovereign rollups is, as with Stacks, data availability. Like Stacks, a Mainstay chain only puts a hash of its blocks into bitcoin transactions, not the full block data, so Mainstay chains have different DA guarantees.

Bitcoin-grade data availability is perhaps most important for rollups built on top of sovereign rollups. These rollups rely on the data availability guarantees of their parent chain (in this case, the sovereign rollup) so bitcoin-grade data availability is especially valuable.

I am looking forward to seeing any and all experiments that take advantage of this newfound use for bitcoin block space!