Bridges as Clients
Bridges Got Hacked Because of Bad Code, not Bad Ideas
While we like to focus on the “formal” security model of bridge designs, exploits rarely happen on the design layer. It happens at the implementation layer. People cannot write bug-free code. If we look at the last 10 major bridge hacks, eight of them happened at the implementation level - faulty upgrades, front end, signature checks, and outdated libraries….
New designs, most of the time, are more complex and do not help on making bridge implementation safer. If we look at Bitcoin, most, if not all, of the hacks/incidents happened also at the implementation level. Someone once created 184 billion bitcoin through a value overflow bug. While all of these hacks were “fixed” through soft and hard forks, bridges do not have this luxury.
Therefore, we should start looking at bridges or bridging as a concept, from a new lens. How can you combat implementation vulnerabilities while the software/code is rapidly evolving? One answer is through client diversity. By having different implementations of the same idea, we can have more resilience on the software/client level.
Intro
While contributing to the multi-message aggregation (MMA) design for Uniswap cross-chain governance, I came to a new mental model to think about bridges - bridges as protocol clients. Protocol, in this sense, is similar to HTTP, TCP/IP, and even SHA256 - a set of agreed-upon instructions/specifications to achieve some goal (communication, compression, verification …). A client is an implementation of the protocol. The same protocol could be implemented differently. For example, you can have a SHA256 implementation in C, Typescript, or Julia. In the Ethereum world, we have the Ethereum protocol spec and numerous clients.
Each protocol also differs in depth and scope. For example, the Ethereum protocol spec covers a networking protocol, a consensus protocol, and many interface-level protocols. However, HTTP only covers the networking part. The scope of the protocol will be important as we will see in later parts relating to bridges.
In summary:
The protocol is the specification of how to achieve something - a goal. It mostly lives in the form of words and is not directly used by consumer-facing developers.
The client is an implementation of the protocol. It lives in the form of code and is used directly by consumer-facing developers.
What do I mean by a bridge?
In this article, I define a bridge as an interoperable solution for cross-blockchain communication. Bridges relayed the reality of one blockchain to another.
Bridging as a Protocol
The goal of a bridge is to carry some information from one blockchain to another. It functions similarly to HTTP. The bridge protocol can be viewed as a networking protocol. It also functions differently from HTTP. Instead of connecting a server and a client (browser) in the HTTP setting, the bridge protocol connects blockchains. These blockchains cannot natively communicate with one another and require external parties to push information to them.
Regardless of these differences, viewing bridge protocols as networking protocols is immensely beneficial. First, on a foundational level, the goal of bridges is information transfer, which is the same as most networking protocols. Second, to the cross-chain dApp developers, bridges function extremely similarly to networking protocol in the server world. Lastly, viewing bridges as networking protocols emphasizes the importance of standardization - developers do not need to relearn API interfaces when switching between the underlying bridge providers.
Unfortunately, the current bridging space does not have an agreed-upon protocol. Other than a few ERCs and ethresearch forum posts, no one is really talking about it. Shout out to ERC-6170, ERC-5164, Martin Köppelmann, and Auryn Macmillan for pushing the conversation forward.
You might see where I am going with this.
Bridge Providers as Clients
Now, hypothetically, if we have a standard bridging protocol, meaning APIs for cross-chain messaging are standardized, we can view bridge providers (Hyperlane, Axelar, Wormhole…) as different clients of the underlying protocol. Each bridge provider writes their own bridge client. These implementations could have different programming languages, trust assumptions, mechanism designs, and security/liveness guarantees. Because these clients live under the same bridging protocol, these differences could be leveraged to be a value-add instead overhead for developers and users.
The benefit of a diverse client set, client diversity as it is normally called, is well-documented and discussed in the blockchain world (sources). However, it is rarely discussed in the bridging world. As I have mentioned in the beginning, 8 out of the 10 major bridge hacks are due to software bugs. If we can add redundancy to the system to make it more resilient, we definitely should.
Multi-Message Aggregation
Currently (Mar 2023), I am implementing this idea into practice with Multi-Message Aggregation (MMA). MMA is a design for Uniswap cross-chain governance message passing. It is designed to pass Ethereum mainnet commands to Uniswap deployments on other non-L2 EVM chains. MMA uses N bridges to pass the same message from Ethereum to another chain. On the receiving chain, if k of the N bridges passed the same message, the message is executed.
MMA is completely open-source and spearheaded by Uniswap delegates. Moreover, MMA can be used not only for Uniswap but also for any DAO that wishes to pass governance messages from Ethereum to other EVMs chains. Lastly, MMA has been supported by most bridge providers such as Celer, Wormhole, Axelar, Hyperlane, and many others.
MMA is looking for contributors! Please take a look at our repo and submit any PR if you see anything that can be optimized. If you don’t have time, a quick retweet would be greatly appreciated!
Conclusion
I believe that bridges are critical for enabling cross-blockchain communication, but their implementation can be vulnerable to hacks due to software bugs. To address this issue, I suggest viewing bridges as protocol clients, implementing a standard bridging protocol, and promoting client diversity to improve security. Through the Multi-Message Aggregation (MMA) design for Uniswap cross-chain governance message passing, I am putting this approach into practice, and I invite interested parties to contribute to this open-source project. Ultimately, by prioritizing security in bridging, we can create a more resilient and trustworthy ecosystem for cross-blockchain communication.
Interesting idea!