Access the full report here.
Bridge Type Based on Security
At the most basic level, a “secure” bridge needs to do three things well:
- Ensure the integrity of state changes (verify the validity of transactions)
- Make those state changes publicly available for anyone to “check the work”
- Ensure censorship resistance
This last point around censorship resistance within a bridge simply comes down to ‘who's in charge of verification?’ We also must consider the relationship of the two chains:
- Natively Verified - Light clients and relays
- Locally Verified - Liquidity networks
- Externally Verified - External validators
- Optimistically Verified - Optimistic assumptions and challenge periods
Natively Verified
This approach has the same trust assumptions as the underlying chain, i.e., the safest option of the bunch, as light clients are used to enabling secure communication.
As we know, blockchains use a network of full nodes that build blocks and check every single transaction for accuracy in a decentralized manner. This is incredibly resource-intensive and inefficient (compared to a central database). Because of the high cost to run and maintain a full node, light clients, a less resource-intensive way of still interacting with a blockchain, was created. Rather than execute all transactions like a full node, a light client simply verifies block headers making it far less resource-intensive to run.
With light clients, a bridging technology can run a light client of chain A on chain B's virtual machine and vice versa, letting them communicate with one another. Bridges with this design (Near/Aurora-Ethereum, and Cosmos IBC) are considered “natively verified.” While providing nearly the best security design, native bridges are scarce as they require the chains to use the same consensus mechanism and are more burdensome to implement.
Light clients that cross-check consensus on both chains are less secure than rollups as they don't explicitly validate the state. Instead, they trust what the validators declare, adding one layer of trust.
Locally Verified
Locally-verified bridges are slightly easier to implement because they don't need a light client on both chains to verify every transaction. Instead, only the entities involved in the bridging mechanism verify the transaction. This means the bridge is only as secure as the weaker chain but still provides adequate security assumptions as the sender is presumably already comfortable with the chain security since they intend to use it (or have been using it).
The tradeoff with local verification is that it's only suitable for sending tokens between two chains. Anything beyond this, like designing a dapp that interoperates with the two networks, is better suited for alternative methods.
Examples include Hop and Connext.
If you want more cryptocurrency analysis, including full-length research reports, trading signals, and social media sentiment analysis, use the code "Publish0x" when subscribing to CryptoEQ.io to make your first month of CryptoEQ just $10! Or simply click the button above!
Externally Verified bridges
External verification relies on external validators to pass messages from the source chain to the destination chain, introducing trust beyond the two chains. An ad-hoc “decentralized” validator (relayer) network secures the bridge and delivers the transactions. After the set of validators has reached a consensus on the initial bridging request transactions, the message passes to the destination chain. Both chains approving the transaction finalize the bridging transaction.
This method is the most popular bridging design due to its simple implementation. However, it's also the least secure, often sacrificing decentralization, safety, and censorship resistance with the introduction of intermediaries. Rather than relying on the security of either blockchain, you're trusting a small number of validators not to collude or screw up.
To combat this, the bridge will oftentimes decide which group of whitelisted, KYC’ed validators get to control the minting and burning of wrapped tokens. This due diligence on the new validators allows the bridge to determine their trustworthiness and create a crisis management plan should anything go wrong to protect the bridge’s reputation.
The validator set may use a basic multisig, PoS consensus algorithm, or another mechanism to reach a quorum. Regardless, the validator set controls the funds.
To maintain economic security, validators often stake or bond economic value that can be slashed. However, the value staked by the external validators must be greater than the TVL of the bridge. Otherwise, the bridge is economically insecure, and hackers can spend $X to attack the chain and gain $X + $Y.
Practically speaking, the staked value would hopefully be many times greater than the TVL. If the two values get close enough together, the hacker could also assume his actions would cause the token price of the two chains to decrease and short those L1 tokens. In this scenario, even if the bridge were “technically” economically secure, the hacker would be able to make enough on the short positions to justify the attack.
Important considerations for externally verified (most) bridges:
- Who can access the locked assets?
- How does information get relayed from A to B?
- How does the bridge verify the relayed information is true?
- What are the incentives for relayers?
- Who can trigger minting and burning?
Examples of externally verified bridges include Stargate, Multichain, Axelar, and Synapse.
Optimistically Verified
As far as security, optimistically verified bridges fall between native and external implementations. They work much like Optimistic rollups in that they assume transactions are valid by default and then open a challenge period whereby monitors can contest the transactions if they believe fraud has occurred or it's invalid. If the challenge is successful, the transaction is reverted. They are secure as long as at least one honest validator manages to raise the alarm within the fraud-proof window.
One area in which optimistically verified bridges shine is in the event of a hack. In externally verified hacks, where the private keys of a majority of validators are compromised (ex: Ronin bridge hack), the attacker can remove all of the funds from the bridge and abscond. However, in an optimistically verified system, even if the attacker manages to get the private keys of all the validators, they still can't be guaranteed to get away with all funds as long as one honest watcher in the system identifies the fraud. If that happens, they can revoke the attacker's access to the funds. The tradeoff to this approach is the long challenge period, i.e., slow time to finality. An example of such a bridge is Nomad.
