Trusted Bridges are Decel

Do not index

Why do we have bridges?

Bridges are fundamentally crucial to the success of the crypto industry due to two reasons: information exchange and freedom to transact.

Drawing parallels with nation states, crypto economies have many similarities. The global economy is defined by trade between nations. No nation state can be completely independent because it's impossible for any single economy to fulfil all its needs. No economy can produce all goods and resolve all issues. Even if hypothetically possible, it would be challenging to cater to the ever-changing desires of its citizens effectively. As a result, it becomes necessary to outsource some things, hence trade routes and agreements. An economy without free trade risks shrinking and eventually dying out.

In the context of blockchains, bridges serve as the channels for information exchange between distinct consensus systems. These are crucial for generating the network effects that enable these crypto economies to thrive and continuously grow. Without an information exchange highway, similar to nation states, they risk contraction and dissolution. It's important to note that a bridge's security isn't something that can be simply added in an update. The bridging protocol must be built on secure primitives. Just like the design of the blockchains being bridged, security must always be the starting point.

You can see now that without bridges, the crypto you know and love will be lost in time like tears in the rain.

How do cross chain bridges work?

Cross-chain bridges typically utilize an off-chain component, known as a relayer, to transport messages between connected chains. A series of contracts or modules on the connected chains confirm the validity of these messages. The means through which validity is established in the protocol is the defining factor of the bridge. There are two broad models for validating cross chain messages. These models reflect two kinds of ideals, revealing who upholds the cypherpunk values that originated this industry and who disregards them. It differentiates between the accelerationists and decelerationists.

Multi-Sig / Oracle (Trusted Bridge)

In this model, a trusted group of participants attest to the state of events on the connected chains using their digital signatures. However, this "trusted group" is often just a multisig controlled by a single entity on the same machine. As we continue, we'll explore the problems that can arise from this setup.

Consensus Client Bridge (Trustless Bridge)

In this model, we have on-chain light clients that verify consensus proofs from the connected chains. These proofs provide a concise commitment to the global state of these chains. Additionally, we use state proofs to verify claims about the state of the connected chains. Since this model is built on cryptographic proofs of consensus and state, it's inherently an open and permissionless system.

No matter what security model a bridge purports to use, if consensus and state proofs aren't part of its design, it's no safer than a traditional bank server. This implies it inherits all known drawbacks of such systems.

Speed vs Security

A bridge's primary purpose is to enable secure cross-chain interactions and provide distinct state machines with a verifiable view of each other's state. If a bridge allows for potential false claims about state, it fails its primary purpose and should not exist. While fast message passing is desirable, bridging speed is fundamentally limited by the maximum speed of the consensus protocols of the interoperating chains. Thus, a bridge should not aim to surpass the speed of these consensus layers. In fact we can assert that a bridge's security level is correlated with message-passing speed. The more the message-passing speed exceeds the speed of consensus layers, the less secure the bridge becomes.

If the goal is to increase the speed of message passing, innovation that reduces the time to finality must occur at the consensus layer. However, this is a challenging issue to address, particularly in networks with large validator sets, like Ethereum. As a result, many teams resort to designing trusted bridges.

Should bridge security be a spectrum?

Unlike decentralization, bridge security isn't a spectrum; it's either secure or it isn't. Good engineering design includes preparing for all possibilities. A well-designed system should handle all invariants, but this basic engineering requirement is impossible to meet with trusted bridges. This is due to the main invariant being part of the protocol's design, making it impossible to pre-program the protocol to respond to a malicious takeover of its trusted authority set.

On the other hand, trustless bridges can be pre-programmed to respond to malicious behavior. With the help of fishermen, the on-chain light client can respond to malicious consensus proofs and halt operations permissionlessly. When it comes to defenses, compromising a trusted bridge only requires stealing the private keys of the majority of the multi-sig/oracle, a one-step process that is nearly impossible to detect until the protocol has been compromised. The recent discovery of an ssh backdoor and a vulnerability in Apple M1 chips underscores the notion that multi-sig and oracle-based bridges are not future-proof. If the ssh vulnerability had spread into production releases of Linux unnoticed, what could have prevented a malicious actor from targeting trusted bridge operators, stealing the private keys from the majority of the trusted set, and compromising the protocol? Instances like these emphasize the need to enhance trustless bridging systems, as they offer the best protection against such threats.

Ideally, a secure system should have multiple defenses against malicious behavior. A multistep defence process is only possible with light client-based bridges.

You don’t want to be this guy when you lose your funds in a bridge hack

Acceleration vs Deceleration

Recently, the concepts of acceleration and deceleration have been hot topics in tech circles. Accelerationists believe in pushing technological boundaries, proceeding as long as no laws of physics are broken. On the other hand, the term 'decel' has been used for those who advocate slowing technological progress due to fears of self-destruction.

However, I want to co-opt the term 'decel' to describe cross-chain bridges. Trusted bridges can be considered 'decel' bridges as they rely on inferior and flawed designs, which have proven multiple times to be insecure and unsafe for users and the industry. To build such technology for millions of people requires a kind of cynical hypercapitalism that strives to extract value from the system at all costs irrespective of the consequences, this contradicts the cypherpunk manifesto, the foundation of this industry.

This industry exists because we collectively believe in freedom, decentralization, censorship resistance, and hard cryptographic guarantees. Therefore, every sector of this industry, cross-chain bridging especially, should accelerate towards these values. The only bridge model that upholds this is a trustless model backed by the hard cryptographic guarantees of consensus and state proofs. Let's make bridging cypherpunk and accelerate towards trustlessness (t/acc).