**Blogpost about bridge security**

**Our goal:**
To educate users and the broader crypto community about bridge security, and some of the existing solutions on the market, as well as ongoing research.

**Our target audience:**
Retail users wanting to bridge tokens - Alice.

**Our timeline:**
Finalisation 15th of June

**What do users want when they bridge?**

So 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 - or any other wallet - to the bridge UI. Then she selects the source and 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 on the destination chain.

In the background, blockchain bridges are complex protocols. Some 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 and integrity of a bridge define 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, 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, on the target system or blockchain, 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 - only messages with cryptographic signatures. Those messages trigger a payout on the destination chain. So bridges must ensure the validity of those messages.

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 it itself produces. Any external information - and therefore 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 into the destination chain injected message is valid and if so Alice can receive her tokens.

If a bridge can ensure most of the time that it relays valid messages and blocks invalid ones, we call it secure.

**What do we mean by security?**

Security is the absence of risk. In our case, we understand risk as the risk of a bridge relaying an invalid message. This includes not relaying a valid message, for example, a valid withdrawal request.

In other words and from Alice’s perspective, the security of a bridge is defined as the likelihood of a happy case, so to receive the tokens that she was promised on the destination chain. The more likely it is, the more secure we call the bridge.

To assess the security of a bridge, we will try to list all the bad outcomes for Alice and compare the different bridge designs on how they can prevent such a case. So what could happen to Alice when she tries to bridge her tokens.

1. **Alice could be censored.** So her transaction could be rejected because the bridge operators have her account on a black list. In that case she could not bridge and maybe not withdrawal her tokens. In this case the bridge would have blocked a valid message.
2. **Alice could receive fewer or no tokens on the destination chain than agreed upon.** 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 the case the bridge would have relayed a wrong message.
3. **Alice could receive the wrong tokens** or tokens with less value. So Alice could send wETH on the source chain but receive something else on the target chain. Some bridges mint their own tokens instead of unlocking the canonical tokens immediately. That way, there is a risk for Alice.
4. Alice could get an IOU for her tokens on the destination chain, but then the **Bridge could get hacked** and Alice loses the value of her IOU.
5. …

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

**Which categories of bridges do we see?**

We put all bridges into four different categories. We follow the work of L2beat and their great educational efforts to …

**Rollups and other Layer2s** can be seen as highly secure bridges. The validity of messages and resulting states can be challenged and 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 those bridges inherit the security of the layer-1 blockchain. We call these "native" bridges.
Examples: StarkGate, Arbitrum Bridge, Optimism Bridge

The next category is bridges implementing a "consensus" light client. **Consensus-checking light clients** are less secure than Rollups as they do not validate the state explicitly - they trust the Miners/Validators of the source domain. Basically, they check if a block is signed correctly and in the case of PoW they check the difficulty. In the block there is the message, which validity needs to be ensured. If the Miners/Validators are compromised, they can mine an invalid block.
Examples: NEAR, Cosmos IBC

Then we have **Optimistic Bridges**. They are secure as long as there is at least one honest validator that manages to raise an alarm within the fraud-proof window (the longer the better). A proposer proposes a set of new valid messages and a watcher can check the validity and step in if there is fraud.
Examples: Nomad/Connext, Across

Finally, we have bridges that rely on some **validators attesting to the validity of messages**. It could be MultiSig, dynamic validator set with PoS consensus, MPC scheme, Intel SGX security box, whatever. It is ultimately all the same category.
Examples: Multichain, Celer cBridge v2

Show a comparison table on how bridges are secured:

Here we can now compare how the different bridge designs would prevent the bad outcomes for Alice.

| | Native Bridges | Light Client Bridges | Optimistic Bridges | Validator Bridges |
| --------------- | ----------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- |
| Censoring | As long as the blockchain and the open source smart contract are censorship resistant, this is not possible | As long as the blockchain and the open source smart contract are censorship resistant, this is not possible | If the proposer and all the watchers collude, they could censor a user. If the watcher set is unknown, a collusion is unlikely | As long as > 1/3 of the validators do not collude, the bridge cannot censor |
| Invalid Message | Alice (or someone else) can challenge this on the source chain and she will most likely win her case | Alice (or someone else) can challenge this on the source chain and she will most likely win her case | Alice (or someone else) can challenge this on the source chain and she will most likely win her case | As long as > 1/3 of the validators do not collude, the bridge realy an invalid message |
| Wrong Tokens | Bridge only use canonical tokens backed 1:1 on the source chain | Bridge should use only canonical tokens backed 1:1 on the source chain | Bridge should use only canonical tokens backed 1:1 on the source chain | Bridge should use only canonical tokens backed 1:1 on the source chain |
| Bridge hack | There is always the possibility of hacks. Risk increases the more different chains and VMs are connected | There is always the possibility of hacks. Risk increases the more different chains and VMs are connected | There is always the possibility of hacks. Risk increases the more different chains and VMs are connected | There is always the possibility of hacks. Risk increases the more different chains and VMs are connected |