Under the Bridge
Why secure Blockchain bridge architectures are important and Cosmos is leading when it comes to bridge security.
Blockchain bridges are a necessary evil these days. The web3 ecosystem has evolved into a heterogeneous landscape consisting of different layer 1 and layer 2 blockchain solutions, all with their advantages and disadvantages. A blockchain bridge works in a similar way to a real bridge. Let’s imagine two cities that both have their infrastructure. Both cities can exist independently of each other, but visitors would still like to travel to the other city, e.g. to take advantage of better leisure facilities. A real bridge allows a visitor to easily cross over to the other city while being able to return to his home city at any time. Unfortunately, it is not that simple in the crypto world and there are currently different approaches how to building a secure bridge. But not every blockchain bridge is equally secure as the recent Binance bridge exploit has just shown. Let’s put together a little overview!
Trusted Bridges
As the name suggests a trusted bridge depends upon a central entity. A very simple procedure for such a bridge application is, for example, if we make an ETH deposit from the Ethereum mainnet on a central crypto exchange and then withdraw that ETH back to Polygon. We are giving ownership of our cryptos to an external entity and how exactly our tokens are bridged is not clear to us.
There are other examples that fall into this category, even if they do not look like it at first glance; namely, simple smart contract bridges. And to be precise, we are talking about those that use a proxy smart contract. Proxy smart contracts are actually a great idea. In short, they allow to easily update a smart contract. But this is where the trust assumption lies in these smart contract bridges. Because that deployer, whether it is a single identity or a multi-sig wallet, standing from multiple identities, can change the actual logic of the bridge. However, this adds another risk to the bridge mechanism: Trusting the deployer not to simply add a malicious change to the smart contract and withdraw all user funds. Furthermore, this leads to the decentralization aspect of a blockchain smart contract bridge ad absurdum. The most dangerous aspect is that the average user often does not know what he or she is dealing with and such centralization problems have to be pointed out by external developers.
Here is a well-made overview of the different risks involved in crypto bridges:
Smart contract bug: Bug in a smart contract implementation that — presumably — was transparent and audited
Underlying blockchain implementation bug: Bug in an implementation of a chain full node, official libraries such as JSON-RPC, etc…
Offchain infrastructure bug: Bug in a critical off-chain infrastructure, typically non-transparent and non-audited
Crypto key exploit: For any system component that is managed by MultiSig (typically upgrade key or bridge external validator), some keys were compromised
Key security risk assumption failure: Any system has one or more security assumptions, for example, 51% honest validators, at least one honest validator in DAC, not a single honest validator for Optimistic Rollup, etc…
One major risk, being the trust assumption against a central authority, is already addressed on the second category of bridges:
Trustless Bridges
Completely trustless bridges are considered the holy grail among bridge implementations and are very difficult to implement because any bridge is only as secure as its weakest link.
The degree of trustlessness can be roughly divided into 3 subcategories:
1. Locally Verified (Atomic Swaps)
These bridge swaps are called “atomic” because they have only two possible outcomes. Either the trade is successfully completed and each trader receives the other’s funds. Or nothing happens and both traders keep the funds they started with. An example of this is Monero’s atomic swap bridge to Bitcoin.
2. Externally Verified
In this subcategory, bridge transactions are not verified by the actual blockchain domains, but by a third, external validator domain. One example is Thorchain. This third blockchain verifies, i.e., whether the transaction in blockchain A is valid and then executes the corresponding transaction on blockchain B. So the user has to trust another blockchain domain.
3. Natively Verified
Last but not least, there are the natively verified bridges. As the name suggests, unlike the externally verified bridges, no additional blockchain domain is required here. Simply put, this works by having one blockchain in its runtime environment verify the same transaction as it was executed in the other blockchain and vice versa. Examples include layer 2 entries & exists as well as Cosmos’ Inter-Blockchain Communication Protocol (IBC). You can find a deeper explanation of the different types here.
Basically, the same risk does apply to trustless bridges except for the trust assumptions against a central authority and most notably they can work completely aligned to the ethos of decentralization!
Cosmos IBC
To link independent blockchains together, the Inter-Blockchain Communication Protocol (IBC), an open-source module for message relaying between separate distributed ledgers, was developed. Cosmos blockchains do not need to directly communicate with one another, which is a critical aspect of IBC. Instead, they are able to communicate data packets through specific channels that employ smart contract modules and a light client for completely confirming the veracity of the state transmitted by the other blockchain. Any party can operate a relayer because of the trustless and permissionless nature of IBC, and the participating blockchains do not have to trust the parties transferring the information. This is a crucial element for achieving blockchain sovereignty without isolation, which is one of the Cosmos ecosystem’s main goals.
You might think that sounds great, but what about blockchains that are not based on the Cosmos code base? And you are right. Currently, only Cosmos-based blockchains support this kind of bridge communication. But even for this problem solutions have been found, namely the GravityBridge.
Gravity Bridge is a Cosmos-based, IBC-enabled blockchain with a current number of 166 validators in the network. It allows moving Ethereum assets to the Cosmos ecosystem with a mechanism based on the “Externally Verified” model as previously described. The smart contract itself does not rely on any proxy smart contracts, only a multi-sig approach is applied relying on the whole validator set of the network. This allows the network to operate in a trustless & permissionless manner.
If you want to have a deeper insight into how the contract works, check out their detailed explanation.
We, at Blockscape, believe in a decentralized & permissionless future, minimizing entry barriers for people from wherever they came and that is why we build our own front-end to interact with the Gravity Bridge and move your assets securely from Ethereum to Cosmos and vice versa! You can find our implementation here and start exploring the amazing Cosmos ecosystem as of today: https://bridge.blockscape.network/
Check out our beginner’s guide or join our Discord if you have any questions!
Conclusion
Here we are now at the current usable state of the art. We are still not quite there for “perfect” bridge solution. But as more research is done and more exploits are being discovered, the mechanism used are getting better and more secure. For example, just after the Binance bridge exploit happened, another security issue in IBC has been discovered & fixed as well. However, the great majority of cross-chain bridge attacks this year have taken place on blockchains powered by the Ethereum Virtual Machine compared to few security breaches in the IBC ecosystem of Cosmos.
But what about the future? Especially in the crypto space, the innovation phases are very fast and the next implementations for even more secure and even more trustless blockchain bridges are already being developed.
On the one hand, there are already ideas on how to build an even more secure bridge from an IBC blockchain to or from Ethereum using zkSnark proofs.
On the other hand, there are also concepts & first implementations (!), such as this one from Hyperledger, which shows that an IBC client can also be implemented directly in Solidity, in order to combine the native security functions of different blockchain domains even more.
L2beat just recently added a nice overview of the different bridges and their TVL. You can find it here!
The future of blockchain bridges is extremely exciting and we are following the latest developments closely to create accessible crypto solutions for all of us!
