If you need a primer on blockchain bridges, go here to understand important concepts. Today, we dive deep into underlying bridge security and cover the following: 

  1. What happens when users bridge

  2. What we mean by security

  3. Which categories of bridges we see

  4. Bridge security comparisons

  5. Extensibility—where you can bridge to

We will use Alice as an example throughout this guide: 

Alice has 0.5 ETH on Arbitrum and wants to use those tokens on Polygon PoS. To do so, Alice has to use a bridge. For her, most bridges look the same. She connects her MetaMask to the bridge UI. Then she selects Arbitrum as the source, Polygon PoS as the destination chain and the tokens she wants to bridge. After setting the desired amount, she can submit a transaction and wait until she receives her tokens in her wallet on Polygon PoS. Alice wants a somewhat fast and secure transfer of her tokens. For sure, Alice does not want to lose her tokens during this transfer.

1. What users should know when they bridge tokens

In the background, blockchain bridges are protocols—a set of rules and the implementation thereof. The rules define the responsibilities for protecting and releasing the users’ assets held in the bridge. Some protocols are more secure than others. 

Bridges tie scaling solutions to Ethereum layer-1 and connect different blockchains. A bridge is responsible for holding the assets on a (layer-1) blockchain while similar assets are released on another (and external) service. It defines who has custody of the funds and the conditions that must be satisfied before the assets can be unlocked. In a nutshell, whenever a layer-1 blockchain like Ethereum connects to any other system, there is a bridge involved. In that sense, a bridge is fundamental for any scaling solution. Furthermore, the security of a bridge defines the security of the usage of the off-chain system. Imagine connecting two secure systems via a highly fragile bridge. 

In any case, from the perspective of the source blockchain (Arbitrum for Alice), a bridge is a smart contract, in some cases a multi-sig wallet, that holds users' funds and defines the conditions of how those funds can be withdrawn. The other side of the bridge (Polygon PoSfor Alice), on the target system or blockchain, is another smart contract that creates or unlocks the same amount of funds for the user. That way the user can use those funds on the other system. 

A blockchain bridge cannot really move tokens between blockchains. In fact, a blockchain bridge consists of two smart contracts holding tokens and a set of rules that define who has access to those tokens. Between those two smart contracts on different blockchains, there is a flow of messages with cryptographic signatures. Those messages are instructions for smart contracts on the destination chain to create or release new tokens, triggering a payout for the recipient of the transaction. So bridges must ensure the validity of those messages. 

In every case, bridges need external parties that relay the messages. Those parties watch the smart contracts on every chain, create or pick up messages and relay those to the other chain. 

The technical challenge of bridges lies in the very nature of blockchains. Blockchains are designed to be consistent and validatable. So in fact, a blockchain can only know and trust information that the blockchain itself produces. Any external information - and therefore the concept of bridged tokens - is hard to independently validate since a blockchain has no way of knowing the outside world or the other blockchain. Most bridges use clever tricks to ensure that the relayed message is valid and if so Alice can receive her tokens.

Importantly, if bridges introduce new and unsafe tokens to the destination chain by minting, these assets are dependent on the security of the bridge and not only on the security of the chain itself. This can compromise the security of the chain.

2. What do we mean by security?

Security is the absence of risk. In our case, we understand risk as to the risk of a bridge relaying an invalid message. This includes not relaying a valid message like a valid withdrawal request. To put this into economic terms, a bridge is secure if it is not subject to economic attacks where the amount of funds required to compromise the bridge is less than the one required to compromise the underlying blockchains it connects.

In other words and from Alice’s perspective, the security of a bridge is defined as the likelihood of a happy case— receiving the tokens that she was promised on the destination chain. The more likely it is, the more secure we call the bridge. That is the same as saying how unlikely the unhappy case is - in a secure bridge it is unlikely that something bad will happen for Alice. 

We compare the different bridge designs on how they can prevent such a bad outcome. Here’s what could happen to Alice when she tries to bridge her tokens: 

  1. Alice could be censored - her valid message could be censored.  Her transaction could be rejected because the bridge operators have her account on a ban list. In that case, she could not bridge and in the worst case not be able to withdraw her tokens.

  2. Alice could receive fewer or no tokens on the destination chain than agreed upon - her valid message could be tampered with. So in our example, Alice could be promised 0.495 wETH on Polygon PoS but she only gets 0.1 or none at all. In that case, the bridge didn’t relay the valid message but changed the message in the process.

To be fair, there are many more factors that need to be considered when it comes to the security of a bridge that goes beyond this blog post, see here.

When building a bridge one needs to take risks on every layer into account:

  • The security and finality of the blockchains and consensus layers that a bridge connects. 

  • A bridge should be able to deal with chain reorgs and different forms of finality.

  • Smart contracts bear a very specific risk on their own—we can think of upgradability or simply bugs that a hacker could exploit. 

  • The off-chain infrastructure needs to be maintained and designed in a state-of-the-art web security design. 

But as said, those considerations go beyond the protocol design analysis in this blog post.

So for now we can break down the question of the security of bridges on how different bridge designs prevent those two bad outcomes for Alice. Because there are over 100 bridges out there, we can look at categories of bridges which differ by their protocol design.

3. Which categories of bridges do we see?


https://twitter.com/bkiepuszewski/status/1526652823026401280?s=20&t=VCLsg2TYMV8JirkaOc80Xw


1. Rollups can be seen as highly secure bridges. The validity of messages and resulting states can be proven on layer-1. They implement a light client on layer-1 that checks the validity of the state root from layer-2. That way, rollups have the fewest trust assumptions of all bridges. The bridge will only release the funds if there is a mathematical or cryptoeconomic proof of correctness. This proof happens on layer-1 and that way those bridges inherit the security of the layer-1 blockchain. 
Examples: StarkGate, Arbitrum Bridge, Optimism Bridge

2. Then we have Optimistic Bridges. Those bridges optimistically assume that a relayed message or a bundle of relayed messages is correct until proven otherwise. However, the destination chain cannot check the actual validity of a message, but they trust that there is at least one honest watcher - who can check the validity and prove fraud on the source chain. A proposer proposes messages and a watcher can check the validity and step in if there is fraud. Because there is always the possibility that an honest watcher is secretly watching the bridge to prevent any fraud, an attacker can never be secure of succeeding, making any attack anti-economical. However, the security of Optimistic Bridges relies on the fact that there is a permissionless watcher set. If the watcher set is permissioned, in theory, all watchers could be bribed to collude.
Examples: Nomad, Connext (Optimistic modular architecture), Across, NEAR Rainbow Bridge

The next two categories trust a set of validators—if the validators state validity the bridge has to trust them. The set can be as big as all validators of the source chain or as small as whatever the project team were able to spin up themselves.

3. The next category consists of bridges implementing a "consensus" light client. Consensus-checking light clients are less secure than Rollups as they can not validate if a block is correct - they trust the Miners/Validators of the source blockchain have agreed on a certain state. Basically, they check if a block is signed correctly and in the case of PoW they check the difficulty. That means a light client bridge assumes that the validator set of the source chain is not colluding. If the Miners/Validators are compromised, the bridge can accept an invalid block. However, if a block is accepted by the bridge, merkle proofs can be used to show that something happened on the source chain. 
Examples: Cosmos IBC

4. Finally, we have bridges that rely on an external set of validators attesting to the validity of messages. It could be MultiSig, dynamic validator set with PoS consensus, MPC scheme, Intel SGX security box, Oracles, whatever. It is ultimately all the same category. The security of these systems relies on economic incentives. Most of them require validators to stake a certain amount of tokens that can be slashed if they commit any fraud. By design, there is no way to guarantee that they will act honestly once the amount of money a validator can steal from bridging becomes larger than the amount staked. Some bridges only use two parties - a relayer and an oracle - that are in charge of relaying and validating the message. In this case, if the system is permissionless, there is no way to guarantee these two actors will not collude together.
Examples: Multichain, Celer cBridge v2 (can be Optimistic by user choice), Layer0, Axelar, Wormhole, Polygon PoS

4. How bridges are secured (comparatively):

We can now compare how different bridge designs would prevent bad outcomes for Alice.

5. Extensibility: where can you bridge to?

So why would Alice not only use Rollups to bridge her tokens? 

While native bridges and light client bridges are the most secure for the specific domains they were built for (ex: the Arbitrum bridge is the most secure one between Arbitrum and Ethereum, IBC is the most secure communication protocol for Cosmos), they have—by design—a big limitation: they only work for that specific connection they were custom-built for.

IBC only works within the Cosmos ecosystem, Arbitrum for Ethereum, XCM for Polkadot, etc.

On the contrary, validator bridges and optimistic bridges have the flexibility to connect any smart contract chain.

If Alice wanted to bridge between Arbitrum and Polygon she would need to go through either of the two systems.

Final Thoughts

Hopefully, this helps you understand why your crypto needs a secure route.

As a reminder:

  • Blockchain bridges lock tokens on one side and release tokens on the other side

  • The security question is always how can the other side be convinced in a secure way to release the correct token amount to the correct person?

  • Rollups can validate every transaction

  • Optimistic bridges can prove fraud at least on the source chain

  • Light client bridges and validators depend on a bigger or smaller set of trusted validators.

You're on your way to understanding bridge security even more in your self-sovereign Web3 journey now. Happy bridging!