Secure The Bridge: Cross-Chain Communication Done Right, Part I
On August 10, yet another hack happened on a cross-chain interoperability protocol.
It was a little different this time because it was the largest hack in crypto history and made it into mainstream media. The entire saga was also spiced up by banter between the hacker and the Ethereum community, including a community member receiving 13.37 ETH for advising the hacker on how to dodge the law enforcement and a Q&A with the hacker, who disclosed that he planned to return the stolen funds all along.
Behind all the fluff is what the Poly Network hack, along with the other four bridge hacks, revealed of the current state of cross-chain interoperability solutions:
Many interoperability solutions today are not safe to use or even usable. Right now we see many makeshift bridges that were thrown together to meet projects’ immediate needs. But eventually, they will either be replaced, or evolve into decentralized solutions or trusted third parties.
To understand why this is the case, we need to understand how cross-chain interaction is made possible, and some major design choices that could lead to critical security and user experience flaws.
Let’s begin with the Poly Network hack.
So… What Happened?
Effectively, Poly Network’s exploit was partly due to its trusted relayer (in their words, “keeper”) set-up, and partly due to its failure to appropriately verify transactions when sending information across chains.
Cross-chain transactions on Poly Network are facilitated by a group of trusted keepers, who sign blocks on the source blockchains. Their signatures are then verified on the destination chain by gatekeeper smart contract, which then execute transactions. The same smart contract also controls a directory of keepers and can change them when signatures are verified.
The hacker first called an (invalid) function on Ontology that produced a function signature collision with the signature hash that the change keeper function would produce when signed properly. The function was approved by the gatekeeper smart contract since it was a valid transaction on Ontology (although the colliding function itself didn’t exist). The hacker then called the function to change keepers in the directory on Ethereum through the gatekeeper smart contract’s arbitrary transaction execution service. The contract was tricked into believing that a corresponding transaction was indeed called and signed off on Ontology, since the colliding function the hacker called earlier produced the same function signature. The contract then executed the change keeper function, which enabled the hacker to change all keepers to an address he controlled and subsequently drained the network.
Although the immediate flaw of Poly Network’s cross-chain design seems to be that it shouldn’t have set gatekeeper contract to also be the controller for the keeper directory, the more fundamental problem with this bridge design is that users’ assets are completely entrusted to keepers with no additional check on transaction validity.
Note here that the gatekeeper contract does not verify transactions on chain but blindly trust a keeper’s signatures as proof that the transactions have happened on the source chain. This means that anyone successfully impersonates keeper can trick the contract into executing whatever functions they want. Adding to this risk is the small number of keepers, whose access to the network is recorded in the directory that was ultimately compromised.
Putting the above two points together, we can see that Poly Network’s security entirely relies on two assumptions: 1) keepers will behave honestly; 2) nobody can impersonate the keepers.
And it’s in the second assumption that the hacker found a loophole.
So how decentralized should a bridge be in order for it to be secured, and what are the assumptions bridge developers make in their design that can result in these differences? Let’s start from the basics of how a cross chain bridge is usually built.
For more in-depth analysis on the hack, refer to Mudit Gupta and the BlockSec Team.
Five Questions A Bridge Should Ask Itself
The most widely adopted bridge design is the tried and true lock-mint-burn method.
It basically works like this: a bridge designates an address on Chain A for users to deposit their assets. The bridge then mints wrapped versions of the tokens on Chain B and issues them to the users’ accounts of choice. To withdraw, users send the wrapped tokens back to an address on Chain B for the bridge to collect and burn. The bridge then releases the locked tokens on Chain A back to users.
Under this architecture, asset-mapping bridges can further be classified by the security assumptions they make and fit onto a spectrum of degrees of centralization.
- Who custodies the deposited assets?
- How is information relayed from Chain A to Chain B?
- How does the bridge verify that the relayed information is true?
- How are people incentivized to relay information?
- Who can trigger minting and burning?
Centralized Bridges
Centralized bridges can be seen as the least secure variant, but they may be acceptable if the bridge operator has a good reputation at stake.
A good example here is the Binance Bridge, where Binance the company functions as a broker between BSC, Binance Chain, and other blockchains, receiving user funds on one chain and releasing wrapped tokens on BSC or Binance Chain. Users can also directly withdraw assets to BSC or Binance Chain via their Binance exchange accounts.
It’s difficult to believe that Binance will intentionally scam their users. After all, they stand to lose their reputation and even users on the exchange if they were to commit such a scheme. However, this is not to say that the bridge is clear of solvency concerns.
Usually, it’s trivial to verify that a bridge is fully solvent by checking that the total balance of the bridge’s address on the source chain equals the total number of circulating wrapped tokens on the destination chain. In Binance’s case, though, performing an audit is difficult because there’s no way to confirm how many tokens users actually purchase and withdraw within Binance’s exchange.
In other words, Binance can issue more wrapped tokens than it’s currently holding in the reserve and the community could not verify it. To address this issue, Binance locks some assets on Ethereum as a “proof of reserves.”
Decentralized Bridges
Bridges typically cede centralized control by introducing a group of validators. At a high level, broadening the validator set answers the five questions above as following:
- Validators jointly custody deposited assets
- Validators jointly monitor activity on on Chains A and B and relay information between the two
- Validators come to consensus on the final states of Chains A and B
- Validators stake tokens to participate in relaying and their stakes are slashed when information is relayed incorrectly
- Validators jointly control minting and burning
Zooming in, we see that the biggest differentiators between decentralized bridges lie in how validators are incentivized and how information accuracy is ensured. In other words, the differences lie in whether the relay network is permissionless and how relayers achieve consensus.
A somewhat centralized bridge would have a group of whitelisted relayers, which together control the minting and burning of wrapped tokens via multisig. Since these validators are usually KYCed or know each other in real life, they are mutually trusted. Accordingly, any one of them can relay information from Chain A to Chain B. So far, only a few projects like Terra Shuttle (Terra), Chainswap (Solana), and Chainsafe (Avalanche) have adopted this design, and most have plans to further decentralize their bridges.
Other bridges are built on a Proof of Stake network that allows anyone to be a validator. These PoS networks can be existing ones or new ones formed specifically for the purpose of cross-chain communication.
For example, the Matic PoS bridge, deBridge, and Anyswap all leverage existing PoS blockchains — namely Matic, Chainlink, and Fusion respectively. On the other side of the spectrum, Axelar is building such a relay network from scratch.
In the PoS consensus environment, validators are incentivized to run nodes in exchange for transaction fees. They must relay correct information or their stake will be slashed.
Lastly, while most PoS based bridges rely on some consensus mechanism to accurately relay information, there are also a few bridges that feature completely trustless relayers. In this scenario, relayers are still needed to pass information from one chain to another, but bridges do not rely on them for information accuracy.
Instead, these bridges create on-chain light clients that verify relayed information and accordingly call mint/burn/unlock functions. For example, NEAR’s rainbow bridge implements a Ethereum light client in Rust as a NEAR contract, and similarly a NEAR light client in Solidity as an Ethereum contract. This is the most expensive form of cross-chain bridging, since it requires full SPV verification. But because of that, it’s also the most trustless. More on this in the next section.
A Tokenomics Problem
Although bridge-building sounds like a technical problem at first glance, it’s also to a large extent an economics problem.
It’s usually impossible to retrofit an asset into a multichain structure without disrupting its tokenomics, and most assets’ tokenomics weren’t originally designed for a multichain universe. A project with a token on a single chain needs to decide whether they want to inflate their total token supply, or do some sort of asset mapping when they expand to another chain.
For example, if Uniswap issues UNI on Ethereum, having UNI also on Polygon would require the Uniswap community to agree to mint more UNI on the Polygon network. The newly minted Polygon UNI can then be factored into the Uniswap tokenomics in two ways: either an equal amount of Ethereum UNI can be locked to maintain the fixed supply, or the community can decide to actually inflate the total supply to account for the newly minted Polygon UNI to be granted to Polygon Uniswap users.
In practice, most projects, for example SUSHI and 1INCH, tend to adopt the first approach. The most prominent exception is USDT, which has adopted the second approach: while USDT originally launched on Omni, it’s currently minted by its issuer, Tether, on multiple chains including Ethereum, Tron, and Solana, with no single chain operating as the clearing house. Economic considerations also influence how bridges work with these assets.
More Questions, and Some Attentive Answers
Although there’s a glut of bridges on the market, it’s safe to say that we still don’t have a satisfactory bridge solution. For one, most bridges are still not generalized solutions — each chain has built its own bespoke bridge, with inconsistent stability and APIs. Moreover, because most bridges use the lock-mint-burn model, liquidity is very fragmented, and confusing naming schemas can lead to a muddled understanding of what each token actually represents. Lastly, and perhaps most importantly, a few of these bridges are simply not safe enough for users to entrust their funds with, as the recent hacks indicate.
From a user’s standpoint, there’s still no all-encompassing cross-chain protocol. The closest solution is Anyswap, which currently supports Binance Smart Chain, Ethereum, Matic, xDAI, Avalanche, and a few others. Even so, users still run into issues like long wait times, minimum transfer amounts, and sometimes withdrawal limits.
Liquidity fragmentation is also still a severe issue in cross chain transfer. At the end of the day, a bridge can only be as successful as it is liquid. In BTC’s case, WBTC has built up a massive advantage over the others and has become the de facto wrapped BTC on Ethereum. The token, which relies on a centralized bridge, dominates the market, with over 70% of the total market cap. It’s likely that the same evolution happens for other assets — those who move fast and be the first to deliver a working wrapped token will have an advantage in wining the market, even if latecomers may have better designs.
The winning formula here seems to be amassing as much liquidity on as many mainstream chains as possible. In comparison, whether the bridge has the most technologically sound design appears secondary, as most layman users care less about the underlying architecture than simply moving their assets quickly and cheaply getting things done.
This being said, the more technical implications of differences in bridge design are currently underexplored, and the most prominent one is security.
2020 saw the rise of non-Ethereum L1s and side-chains, along with a suddenly intensified demand for cross chain asset transfer. For example, the Matic PoS Bridge alone was able to amass over $3B assets locked at its all time high. This is not to mention the 20+ other bridges currently available on the market.
To a large extent, this surge in cross-chain traffic has caught many projects off guard. As a result, many have had to build their own makeshift bridges to meet the demand for now. But are these bridges secure?
Some existing bridges that “parasite” on existing blockchains, or built on a network of trusted relayers, are more or less makeshift solutions that may fail to address long term user demand. Users of these bridges are usually restricted by the fact that there are no other bridges that connect to the specific chain they want to move their assets to (such as in the case of Poly Network). Therefore they are forced into trusting that the “keepers” or relayers behind these bridges will act honestly, without knowing much about the group.
A completely centralized bridge could potentially solve this concern if the company that runs the bridge is known and well reputed. However, the opacity of such operations creates new concerns around solvency, as discussed above.
Our last hope seems to rest upon decentralized, permissionless bridges. Will they be the winner of the interoperability race? It’s difficult to say, for the simple reason that they’re difficult to build. There’s a nonzero chance that a mediocre cross-chain protocol that generally works and has the most liquidity could end up being the standard in our ecosystem. Regardless of the outcome, though, the pursuit of a more secure bridge should always be our goal, as the entire ecosystem stands to benefit from security and good design.
We will discuss in more detail some bridges’ designs and the technical challenges that they face when connecting blockchains of different consensus mechanisms in Part II of this article.
Thanks to Rahul Bishnoi, Haseeb Qureshi, Xin Yan, and Karim Helmy for their insights and feedback.
