The bridge race is on. Godspeed my friends
What’s up layer 2 enjoyooors.
I’m back from Nashville with a slight case of whatever has been going around. I feel like shit, still smell like cigarettes, but man, I’m feeling quite optimistic.
The previous Bitcoin conference felt very gloomy. All of the new “Layer 2” projects were front and center, I had to explain to everyone why they weren’t Layer 2s, and why no one has solved the “trust-minimized bridge issue” yet.
Fast forward a few months and Nashville felt different. Maybe it was who I hung out with, but I felt most people started to see through the Bitcoin L2 charade. And when you’ve got people like Peter Todd calling everything out for what it is, maybe the message moves across quicker.
The general consensus was that most people knew that L2s parading in the expo area are stretching the truth regarding their designs.
Nevertheless, I do want to touch on upcoming designs for a number of bridges (or two-way pegs) for Bitcoin sidechain and L2 protocols.
Let’s “crunch” the numbers. Of the 13 mainnet sidechain projects on our site, only 3 operate a “consensus-level bridge” for Bitcoin assets. Only one of those has slashing in place, but the slashable token is non-transferrable and has no value. Thus, only a small amount of bitcoin is being locked in that bridge likely due to safety reasons.
Live projects that say they’re going to be launching with a BitVM-style, fraud proof-type thing, are just launching with MPC protocols managed by custodians. See BitLayer, Merlin and Bsquared Network.
This means that, in practice, all two-way pegs are federated (ahem, custodial) systems to some degree. Federations aren’t inherently insecure, but we’re setting the bar high and are asking for (demanding!) solutions that are not only secure, but also sovereign. Users shouldn't need to forgo the custody of their assets to use these systems.
In our testnet section, a few more projects are claiming to use BitVM, or a BitVM variant, for their upcoming two-way peg. Research on this is accelerating, but most projects will launch with a federated operator set and a federated verifier set. We don’t want Tony DDoS-ing the bridge by yeeting a fraud proof every chance he gets.
The path to decentralization while providing users full sovereignty over their assets isn’t an easy one. Systems can get hacked, code can have bugs, etc. It’s really hard to design a fully permissionless and trust-minimized L2.
So reliance on federations isn’t necessarily a knock on teams in this design space. Go-to-market obligations exist. Hell, Ethereum L2s are mostly still managed by glorified multi-sigs.
The difference is that Ethereum has a clear path to building trust-minimized, general purpose L2s. The bridging mechanism is a massive part of that, if not the biggest. It’s been our stance to not have an opinion on future bridge designs; namely BitVM, projects inspired by it, and designs leveraging new opcodes such as OP_CAT.
But, the current state of Bitcoin sidechains sees nearly all projects depend on federations and custodians. And in the best case, we have bridges that rely on secondary consensus networks and alternative tokens to function. This isn’t bad, but it isn’t Bitcoin.
Thus, I’m at least concluding that, based on our research of sidechains and L2s, Bitcoin benefits from conversations related to improved bridging mechanisms. I believe that the most successful Bitcoin L2s, long-term, will either be supported by a variation of BitVM2, proposed opcode changes, or a combination of both. A takeaway I had from Nashville is that these systems may even be complimentary.
The development is unprecedented. BitVMX and BitcoinOS announced that they both optimistically verified a validity proof on Mainnet. Citrea and Alpen aren't too far behind. And, L2 Iterative hacked a STARK verifier directly in Script, leveraging OP_CAT on Signet.
The race to build the bridging infra is on.
Godspeed to all those involved.
