The Bridges of Blockchain County

Any test engineer worth her (or his) salt, and who has a bit of blockchain knowledge, will tell you that cross-chain bridges are going to be the most vulnerable to attacks, exploits, and hacks.

Those of you who are not test engineers with blockchain knowledge may wonder, "Why would that be?"

The answer is simply this: attack surfaces. But before I dig into what attack surfaces are, here is a whirlwind tour of what blockchain bridges are all about.

A bridge is something that allows users to transfer assets from one blockchain to another.

Except that you can't actually do what the previous sentence says. Digital assets aren't like Van Gogh paintings - you can't wrap them up carefully and ship them from the Kr?ller-Müller museum to the Louvre for a display, and then ship them back again a few months later.

A digital asset lives on the blockchain that it was created on, and can never move onto another system in any real sense.

But what you can do is lock up assets on one chain, and then create secondary assets on another chain, which represent the assets on the first chain, with a guarantee that if and only if the secondary assets are destroyed, the primary assets will be released again.

Except that you can't actually guarantee what the previous sentence says. Because as any test engineer worth her (or his) salt knows, software contains bugs.

And a bridge needs a lot of software on a lot of different platforms to work. The more lines of code, and the more "operating systems" that those lines of code have to run on, the more likely it is that there will be bugs.

And a bridge has three operating systems:

• the blockchain for the primary asset,
• the blockchain for the secondary derived asset, and
• the wibbly-wobbly operating system outside of the other two blockchains, in which programs that monitor those two blockchains operate.

Here's an analogy: if your vault only has one door, then there is only one way for a burglar to get into it. But if your vault has two doors and a window ... well, you do the math.

And that's what attack surfaces are. They are the doors and windows to the room containing the treasure that we are trying to protect. The more doors and windows there are, the more opportunities there are for hackers to subvert the system.

And in the blockchain world, bridges have the most doors and windows. They can't avoid it.

I guess that's why Gavin Wood has taken so long to roll out features for the Polkadot ecosystem, which is all about cross-chain communication. Perhaps he's still smarting from the Parity wallet hack (150 000 ETH lost) and has become a lot more careful because of it. And that's a good thing.

It's also why I'm not impressed by Vitalik Buterin finally announcing in 2022 that bridges are risky. We knew that well before the Wormhole hack, from empirical evidence. Just look at the Poly Network hack in August last year, which saw over 600M US$ stolen. A bug in a bridge resulted in the biggest blockchain heist ever.

At this point I image some of of you are thinking, "That's a lot of criticisms, Keir, but what can we do about it?"

I am, at heart, a test engineer. Have been one since 1999. And in my experience, everything contains bugs, no matter how much effort you put into eliminating them. Software is like living in a kitchen full of aging fruit, with more bananas and mangoes arriving every day - you're going to have fruit flies, no matter how much time and effort you put into fumigating the place.

So I'll be honest: I don't know what the solution is.

There are no silver bullets that can provide 100% guaranteed bug-free secure bridging protocols, because there are no silver bullets that can provide 100% guaranteed bug-free anything.

Sorry about that.