Hailed by some as a crucial piece of infrastructure for our multi-chain future, cross-chain bridges are seeing their fair share of controversy. It all started with Ethereum’s own Vitalik Buterin warning about their potential for
That said, even though today’s bridging solutions are not without their shortcomings, cross-chain bridging is a mandatory feature for ensuring multiple blockchains can co-exist in one larger ecosystem. It transforms the zero-sum game of networks competing for nodes, developers, and users into a more collaborative spirit of a diverse economy. Empowering users to move their assets between networks brings them more versatility and value, while also offering every up-and-coming protocol a wider audience and breaking up innovation silos. Bridging is crucial for the Internet’s future as a decentralized, user-owned Web3, we just need to build our bridges differently—and all of the pieces are already in place.
Protecting the Bridge
In the simplest terms, a typical cross-chain bridge incorporates smart contracts on two blockchains, Chain A and Chain B, with a middleman — an Oracle — passing data from one chain to the other and allowing users to exchange different cryptocurrencies directly between the two chains.
When transferring tokens from Chain A to Chain B, the bridge locks the token on Chain A, minting a new token on Chain B. In so doing, the total number of tokens in circulation remains constant, divided across the two chains. This allows the owner of the newly minted tokens to burn them, and redeem the originally locked tokens, at any time.
This means that when we engage in cross-chain transactions, the bridges built between the specific blockchain often hold collateral of millions locked in them; and are therefore a constant and lucrative target for hackers and other malicious actors.
Since bridges often hold millions locked into them, they do make for a lucrative target for hackers and other malicious actors. Their developers usually realize that and use various security solutions to keep criminals at bay. The most popular and cryptographically advanced option is using multi-party computation (MPC) based walletsto receive, protect, burn, and mint tokens as part of the bridge’s operations.
An MPC-based wallet breaks the key down into multiple pieces—key shares—stored on different machines. To sign off a transaction from an MPC wallet, the user needs access to a threshold number of key shares (two out of three, for example). From a hacker’s perspective, this means having to compromise multiple machines instead of just one to be able to tamper with the system. It is indeed a solid and reliable technology.
Still, though, the bridge connecting Axie Infinity’s Ronin sidechain with the Ethereum main net was MPC-based, requiring the signatures of five out of nine validator nodes. But when a malicious actor managed to
Interoperability by Design
The sad tale of the Axie hack is a case study of everything that is wrong with today’s prevalent cross-chain bridge design. While having only nine validators is hardly the pinnacle of decentralization, the fact that one and the same entity controlled
The same flaw plagues most other bridge solutions where a single entity is in control of most of the MPC nodes and works as the Oracle enabling cross-chain communication between smart contracts. The core premise behind MPC—forcing the hacker to go after multiple high-security targets—never really comes into play here. By the same account, the system is no longer decentralized, as anyone using it has to trust that the centralized entity will indeed hold their tokens in custody instead of running off with them.
At the same time, though, MPC is one of the only viable options for securing the cross-chain wallets, as putting those in the hands of a centralized entity once again creates a centralized point of failure. Security takes scale, and for cross-chain bridges to be secure, they must be as decentralized and trustless as the blockchains they bring together.
New-generation blockchains must rethink the basic design of bridging both to avoid the accumulation of technical and financial risk and to aim for the largest security model in a blockchain i.e. the threshold built into the consensus model as the core components of their design philosophy.
The blockchain space must embrace decentralized Oracles operating in what is effectively the industry’s rendition of double-entry bookkeeping, the venerable and time-honored system of accounting where every transaction appears on at least two accounts as debit or credit. Such Oracles would be enabling data exchange between different blockchain networks, making sure that cross-chain transactions are correctly recorded in both decentralized ledgers and are open for anyone to audit.
To take part in facilitating the cross-chain communications, nodes would have to assign, not only stake, tokens as collateral for guaranteeing their integrity, much as they do in a Proof-of-Stake protocol. The process would work on a rotational basis, with new nodes selected and signed with the highest security threshold for every epoch from a larger pool of bridging nodes to widen the scope of participation and make the system more decentralized. This is where tailored large-scale MPC protocols come into play. Orchestrated the right way, this enhances the scale of the network and reduces the risk in a way that hardly impacts processing time, as it grows through scalable parallelization.
Moving forward, true decentralization is the only way to keep cross-chain bridges secure—and true decentralization demands replicating a lot of blockchain’s design principles when building them. So all the pieces are indeed there, as we’ve now had more than a decade to experiment with blockchain and MPC, and now it’s time to marry them.