Can we scale bitcoin... with other blockchains?
Investors love blockchain-based L2s, but there's some bottlenecks in every design...
Last week, Botanix Labs launched mainnet for a bitcoin-denominated, federated sidechain. In the announcement posts, and dozens of media posts covering it, the network was touted as “decentralized” and “built on bitcoin”.
Before we cover the semantics, I will add that I’ve used Botanix. Bridging over wasn’t the worst experience and it was nice to finally use an EVM-style blockchain that was bitcoin denominated. The fact that they publicly announced their federation before launch was refreshing. All-in-all, Botanix handled their launch better than most “bitcoin season 2” projects to date, and for that, they deserve some praise. They also have the most distributed, publicly-known federation for a bitcoin-denominated system (at least to my knowledge).
Botanix, while launching as a federation, claims that the network will one day have 10,000 validators who act as sequencers and signers securing the funds backing its pegged bitcoin asset.
This claim made me wonder how difficult it might be to build bitcoin-native proof-of-stake systems, bridges, and other blockchain-based constructions. This post outlines some of the design challenges these teams face.
The two main sidesystem designs “bringing the EVM to bitcoin”
In the “bitcoin-evm-aligned” design space, there are teams building rollups and there are teams building monolithic sidechains (like Botanix). Most sidechains see rollups as their main competition.
Monolithic sidechains are networks where its full node & operator set handle all facets of the network — transaction execution, finalization, data availability, and consensus.
Rollups, however, use bitcoin for data availability and consensus. This means that rollup full nodes execute transactions and update the state based on data that was posted to, and made available, by bitcoin full nodes.
Can we scale with Proof-of-Stake systems?
Let’s generally look at some challenges Proof-of-Stake sidechains might face while doing this.
Most proof-of-stake systems use CometBFT for their consensus client. CometBFT has known scaling limitations due to all-to-all communication between its consensus nodes. In practice, CometBFT has never scaled past 200 consensus nodes as it would severely impact latency and performance. To reach 10,000 validators, while maintaining sub-5 second block times, any project would need to design a completely new consensus architecture from scratch, test it, and scale it gradually.
While somewhat randomized, the right to win a block in proof-of-stake is heavily weighted against the amount of stake a validator puts up. More stake, more blocks, more rewards. If institutions, holding large swathes of bitcoin, want to take advantage of bitcoin staking’s yield generation properties (they do), they may stake large amounts into any given network. This weights the stake heavily towards a few parties who can effectively gain control of the block production pipeline. So let’s limit stake then? E.g. Cap the amount that each entity can stake? Well, institutions will just run more validators. In practice, the weight of stake, correlated with the legal entities/persons running all the validators, will be the same.
Ethereum is the best attempt at making a proof-of-stake system distributed. But as we’ve seen with LSTs, most users don’t actually want to run their own validator and stake. It’s more attractive to simply give your money to someone else, have them stake it for you, get a liquid token in return to play DeFi games, and then pay a percentage of the staking rewards to the LST issuer in return. This set up centralizes stake massively to a federation of stakers and/or alternative governance mechanisms. Through LSTs, distributed proof-of-stake systems look a lot more like delegated proof-of-stake networks where the majority of users simply delegate their stake to a permissioned set of validators.
But even if you can distribute the validator set within the system, you still need to figure out how to secure the two-way peg. Stake-weighted, rotating multisigs have worked in practice, as we’ve seen with Threshold tBTC, but making the system is permissionless is difficult. You don’t want just anyone buying up a bunch of stake and gaining control of the two-way peg wallet(s). Threshold tBTC is the most distributed two-way peg that bitcoin has seen to date, but it is still permissioned to 35 signers. All signers must be approved by the Threshold DAO before entering the set. Another option is using one multisig and updating the signing thresholds based on stake weights. Nomic does this today where its top 20 validators by stake weight secure the nBTC two-way peg. But, since their token isn’t transferable, no one can go acquire NOM on the open market and become a signer. It’s permissioned in-practice. Additionally, both of the systems mentioned here rely on another token.
The fact is, know one has ever built a two-way peg exclusively secured by permissionless staking.
Proof-of-stake is hard. Bitcoin staking? Even harder. There’s only two examples of bitcoin staking in the wild. One relies on a multisig to enforce slashing (since we don’t have covenants) and the other doesn’t have slashing at all. It’s easy to counter arguments against Proof-of-Stake with “well, we’re going to use bitcoin as the staking asset and this solves all the problems”. But we’ve never seen this play out in practice.
So even in a world where stake doesn’t centralize, it’s unclear how these systems stay distributed, fully censorship resistant, and not reliant on some federated multisig somewhere down the line. Some smart teams are working on this and there might be new solutions coming to market that approach the design space differently.
Some of the tradeoffs related to rollups
You might chalk this off as a win for the rollups, but not so fast. Rollups equally have their challenges. Those challenges are a result of… you guessed it!
Tradeoffs.
Rollups must use bitcoin as a data availability layer. The ability to trustlessly reconstruct the rollup’s state, from bitcoin, and build fully trust-minimized sidesystem bridges is the result of using bitcoin as a data availability layer. Do not let the rollup teams tell you otherwise! An alternative DA layer significantly introduces more trust assumptions in the system. You either trust a federation, or another network secured by an altcoin, to make the data available — a prerequisite for advancing the state of the system. I talk about this here:
Bitcoin only makes 4MB of blockspace available every ten minutes. This is very limited in throughput. Other rollup data availability layers offer significantly more throughput. This means that posting data to bitcoin will be more expensive and that cost is incurred to the user. This chart outlines how expensive it might get.
Also, building proving systems, on any blockchain, is really f*cking hard. Ethereum (sigh, he mentioned it again) has a significantly more expressive scripting language. And for all rollups with general purpose smart contract environments on Ethereum, there is no system in production that does not have, at most, a 9/12 multisig that can immediately upgrade the systems relevant contracts and steal all money locked in the rollup bridge. Ethereum has been building towards trust-minimized rollups for nearly 5 years.
On bitcoin, we can’t construct native proof verification (within the block size limit) and state-carrying covenants without additional opcodes. This simply means that:
Proving systems on bitcoin are going to be complicated
They’re still going to rely on some subset of operators to process withdrawals
And they’ll probably be reliant on governance multisigs like their counterparts in Ethereum for some period time
Additionally, rollups rely on single sequencers to build their blocks. Running a full node in most rollup set ups is permissionless, so anyone can participate in verifying and advancing the state, but building blocks is usually confined to one entity. If this entity censored users, they theoretically could produce and build their own blocks, as they have access to the data and can run a full node, but we’ve never seen examples of forced inclusion and self-proposing in bitcoin. It’s likely another aspect in rollups’ decentralization roadmaps that needs to be built.
In my opinion, rollups are building towards the most trust-minimized sidesystem. Because they rely on bitcoin for consensus, they’re the only sidesystem that has the potential to be considered a true L2 (we’d need a softfork for this, though). And while complex, every problem that a rollup might face, there is ample research on how to potentially solve it.
But in the interim, sidechains, even as a federation, might be more trust-minimized.
A long road is ahead
Proof-of-stake sidechains and rollups both have their benefits and limitations. Equally, a lot of research and engineering work needs to be done to make these systems fully trust-minimized on bitcoin.
You can point out flaws in every construction. You can say “impossible” to anything. Most of the time you will be right. But let’s not waste our time. Tell users the tradeoffs, build towards more trust-minimized systems, and ship sick apps. Let a thousand flowers bloom, even if they rely on a centralized multisig in the interim.
–Janusz