On March 13, Trust Machines hosted a Twitter Spaces session that delved into the possibilities that could come with rollups on Bitcoin.
Part one of the Q&A – captured in this blog post – focused on the highly technical nature of enabling rollups on the Bitcoin blockchain. It also laid out the functionalities of optimistic rollups, zero-knowledge rollups, sovereign rollups, and how they could use Bitcoin layer 1 as a settlement layer.
The discussion in the second half of the session centered on the potential use cases – and potential tradeoffs – of Bitcoin rollups.
The session was moderated by Dan Held. He was joined by Trust Machines CEO and co-founder Muneeb Ali, Celestia Labs CEO and co-founder Mustafa Al-Bassam, Celestia Labs head of marketing and communications Ekram Ahmed, Freehold founder and CEO Patrick Stanley, and researcher John Light (who also does product work for Sovryn).
Here are highlights from their discussion.
The Excitement About Bitcoin Rollups and What They Can Give Bitcoin
Dan: Patrick, what are you kind of most excited about application wise?
Patrick: We basically cast off the yoke of this old notion of not being able to build on Bitcoin. I’ve spoken to a lot of people in the Ethereum community who love Bitcoin, they just use Ethereum every day. They had completely written off Bitcoin and now they're like, “Oh, now I see why you've been in the space for six years.”
Muneeb: At a high level, the message to take away might be that there's broad consensus in the Ethereum community that they just scale in L2s. It could be different types of L2s, but rollups are likely going to play a huge role there and Bitcoin is basically a couple of opcodes away from giving you the exact same functionality on [the Bitcoin network]. There will be some differences given that Ethereum is proof of stake at the L1 level. But ignoring that part, you would be able to benefit from 100% Bitcoin security and, much more importantly, you can deploy that $500 billion of VC capital into applications.
I think if you're a developer this is a huge opportunity to come in and try and be early in a space that actually doesn't have that much competition. Bitcoin rollups are actually sort of like a blue ocean right now; there's so much you can come and build. Frankly, I think Bitcoin is the most pristine collateral in this space, and I think it will likely remain so. Any applications you can come and build on Bitcoin would be extremely valuable.
What Would Rollups on Bitcoin Look Like as Scaling Solutions?
Dan: So does [a rollup] have the same peg in and peg out function as a sidechain, for example, where you peg into a certain address and that then mints you coins over on the other side?
Muneeb: Let's assume Bitcoin has the opcodes. I think the initial experience is going to be similar to L-BTC on Liquid or RBTC on RSK, so you are sort of converting BTC to something else, but it’s trustless. So you get that BTC-derived asset in your wallet as well. It's programmable.
The part that's not possible today without the awkward changes is this step where now you're saying, “I have the Bitcoin-backed asset or the Bitcoin-derived asset, and I want to go back to BTC right now.” Bitcoin L1 can't validate [your withdrawal request] and Bitcoin can’t enforce that at the L1 level. But with the opcodes, you would be able to do that.
John: I would also add that depending on what part of the Bitcoin community you're from, you might also be familiar with this kind of user experience when interacting with Lightning wallets. It's just that with rollups, you get a lot more functionality depending on the specific rollup that you're using.
You could potentially have a lot more functionality doing different types of smart contracts, maybe different types of self-custody protocols, using smart wallets or [engaging in DeFi functions] like peer-to-peer lending or trading different types of privacy protocols.
Really, the possibilities are endless. It just depends on what kind of rollups people build.
Muneeb: It's like Lightning on steroids.
Mustafa: Yeah, in order to move Bitcoin in a completely trust-minimized way and to really make rollups a scalability method for Bitcoin, we need to validate the rollups. One interesting thought that I had as a kind of stopgap until then is – and I know that the Bitcoin core developer community likes to move slowly and often for good reason to make sure nothing breaks – that we can actually create a forward rollup in Bitcoin that has the Bitcoin virtual machine on top of it, that adds these ZK CPU opcodes. You can basically create a sovereign rollup with another version of Bitcoin to test future Bitcoin upgrades before they actually happen.
The Potential Tradeoffs of Bitcoin Rollups
Dan: Can you guys touch on tradeoffs a little bit here? What could go wrong?
John: In the case of sovereign rollups, there are two catches. One, it doesn't have that trustless bridge. You need some sort of trusted bridge in order to be able to move Bitcoin into this other chain and then back to the Bitcoin blockchain. For both sovereign rollups and layer 2 rollups, there is the throughput limitation of the rollup that is constrained by the data availability capacity or, really fundamentally, the block size limit or block weight limit of Bitcoin layer 1 blocks, which is currently around four megabytes of data per Bitcoin block.
When I ran the numbers for the report that I wrote it looked like for layer 2 validity rollups built on Bitcoin, depending on the type of rollup that you did, you could fit maybe at most around two to 300 thousand transactions per layer 1 Bitcoin block. For more complex kinds of smart contract interactions, it's probably much less than that. So there's definitely like a scaling improvement, but it's not unlimited. That's kind of the main limitation.
[Some of the more theoretical tradeoffs] need more time to play out. There could potentially be issues with things like minor extractable value. If people are building trading systems and other kinds of advanced financial protocols on top of Bitcoin, that gives miners that kind of privilege. And so it's possible that if those kinds of protocols are built on top of rollups that are then built on top of Bitcoin, that could lead to some asymmetric advantage for Bitcoin miners.
Mustafa: It's a very difficult problem. The Ethereum community has been grappling with MEV. I think the Bitcoin community is going to have to look at what the Ethereum community has done to manage this problem. And it is a huge problem because if you don't manage it carefully, then you'll end up with extreme centralization among Bitcoin miners.
Before Ethereum had this new, kind of like, PBS, [which proposed a] block separation scheme, it was basically the case that most blocks were built by the same node, it's called a Flashbot RPC, which auctions blocks. So ultimately, the community may potentially have to think about that in the future and try to create some kind of infrastructure that tries to prevent that, or at least designed for public good.
The Final Word on Bitcoin Rollups
Dan: What are your final thoughts?
Muneeb: I do think that practically, [the downsides are] a little farther away than we think most because of how long it takes for Bitcoin to implement any changes. But also, I think a lot of the ZK rollup work is still maturing, especially when it comes to how quickly you can actually produce proofs. [I think there are also some] UX challenges as well, [but those] are also getting better.
[On that point] about Bitcoin fundamental L1 capacity, I do think I would love to see all sorts of different experiments. Stacks addresses those two issues. Instead of publishing all data to Bitcoin L1 actually publishes only hashes. Yes, you get reorg resistance, but you don't get data availability. So it's a different sort of tradeoff. You're not putting that much data in Bitcoin L1 and that's a good thing. But now, you're losing something: data availability is not coming 100% from the chain.
For MEV, there's a block number that Stacks' upcoming release will use where for the first one hundred blocks or more, you'll actually have a slightly different security budget. So you're attracting MEV attacks to a different layer and then saying that we only use Bitcoin finality later on because doing 100 plus reorg on the coin will be fairly catastrophic if someone can pull that off.
John: I think the work that needs to be done – both at the research and development level – for making this production-ready could be built either with sovereign rollups or layer 2 rollups. But this is an exciting space. Bitcoin is the OG cryptocurrency, the best money ever invented. I think it makes a lot of sense to continue building out this infrastructure on top of Bitcoin.
On the research side, I think the problem we talked about with MEV is a really interesting area of research. It would be worth looking at the layer 2 rollup space, particularly on Ethereum, and seeing empirically does MEV on roll a layer two rollups? Have any sort of negative effects on layer 1? Or does it remain isolated to layer 2 and the block producers or sequences on layer 2?
So yeah, for the intellectually curious, developers, researchers, and product people out there, I think there are a lot of interesting challenges to tackle and I'm excited to see it happen.
Mustafa: A kind of fundamental reason why I personally care about rollups is because it enables people across different teams to kind of contribute to a stack that's moderate instead of maximalist, necessarily, because the innovations in Ethereum can go back into Bitcoin. As we've seen with Rolllkit, you can employ Ethereum Virtual Machines (EVM) into Bitcoin and vice versa.
Dan: This is a big step in Bitcoin scaling. I can't emphasize how big this is because Ethereum-side, this is like the biggest way that scaling is going to happen. Rollups coming over to Bitcoin is a milestone.