Was Vitalik Right About His Cross-Chain Comments?

Last week, Vitalik Buterin posted a rather lengthy comment on reddit stating some points of concern on the future of cross chain and bridging infrastructure.

This post comes at a very interesting time where dozens of cross chain and bridging projects are rolling out, all attacking the problem from different angles. To many pundits in the space, his comments have been controversial to those exploring the expanding L1 ecosystems and hoping for new ways to interact with many ecosystems at once.

Vitalik’s comments are a great starting point to discuss approaching the bridging problem. It is refreshing to see that some of the greatest technical experts in the space are coming to consensus about this topic.

We’ve been developing our own cross chain solution for the better part of 18 months now, so after having thought about this problem for a long time ourselves, we figured it would be a good opportunity to analyse bridges and explain how Chainflip has been designed specifically to evade the common pitfalls. Let’s get stuck in.

First, How Do These Bridges Work?

A ‘Bridge’ is a very generic term that has led to many sub-products and variations in the past year. Nevertheless, most of them work in a similar fashion, so let’s briefly discuss what Vitalik identifies as a potential issue.

Bridges are a bidirectional communication service that enables 1:1 asset interactions across several chains. This means in theory you can move ETH from the Ethereum chain to an ETH-like token on the Avalanche chain, for example.

The service looks at the ETH being deposited in a smart contract on Ethereum, after which the same number of ETH-like tokens are minted and issued on the receiving blockchain with its own standard. Every bridge must create its own version of the underlying asset. This means that if there are 5 ETH bridging services between Ethereum and Avalanche, there will also be 5 versions of ‘wrapped’ ETH on Avalanche, each of which are non-fungible with each other.

When a user has to bridge back their ETH-like token to the Ethereum chain, the smart contract burns the ETH-like token while releasing from the contract the corresponding amount of ETH. This way making sure that the circulating token supply doesn’t de-correlate from reality.

This is quite problematic, but there really is no way around this. L1 Blockchains are designed to be sovereign. They do not have shared execution states, nor do they have shared security models. Without some representation of assets from other blockchains, interaction is impossible, or at least very limited. The representation of these assets is also problematic because they require the trust of a third party service or protocol to remain valuable and useful. These are tradeoffs many have been willing to make in the short-term, but is the vision of the cross-chain future well understood?

Vitalik’s tweet on this subject highlighted the core issue here. The value of L1s comes from their sovereignty. They are specifically designed to be independent and immutable. Some projects have their own L1 framework to create shared state and security to allow for some native interoperability, as is the case in the Polkadot and Cosmos ecosystems, but generic cross-chain interoperability is not a reality. Attempts to get around this core quality of L1 chains introduces widespread fragmentation in liquidity, friction and complexity in the user experience, risks for application developers, and undermines the value of self-custody. Vitalik added to this in his post:

"This is why I think zones of interdependency are likely to align closely to zones of sovereignty (so, lots of Ethereum-universe applications interfacing closely with each other, lots of Avax-universe applications interfacing with each other, etc etc, but NOT Ethereum-universe and Avax-universe applications interfacing closely with each other)"

So What Else Did Vitalik Say?

Vitalik’s other major concern mainly revolves around the possibility of the bridge becoming undercollateralized or depegged through a majority attack on either of the bridged chains.

Interestingly, Vitalik pointed out that an independent chain can survive a majority attack quite easily, especially with Proof of Stake. However, where products force users and developers to be interdependent across multiple chains, problems on either one can be catastrophic.

Coming back to our initial example, if the Ethereum mainnet is being majority attacked, some of the transactions can be censored or reverted, at least temporarily. This means that the attackers could wait for the ETH-like token to be minted on the receiving blockchain, and then revert the initial ETH deposit back to their mainnet Ethereum address, having then both ETH on the Ethereum blockchain and the ETH-like token on the Solana blockchain, completely dismantling the very mechanism of the bridge, and through on-chain markets extracting a large percentage of the value stored in the bridge.

This also works in reverse. If the Solana blockchain gets majority attacked, the ETH-like token sent to the smart contract to get burnt can be reverted and ‘’not burnt’’ once the ETH on the Ethereum mainnet has been released.

Normally, these kinds of attacks don't matter if the asset remains on the same chain, as the state can easily be rolled back to the pre-attack state. A bridge, however, even a fully decentralised one, can not revert its accounting.

Vitalik also points out a very interesting counterintuitive design flaw, which is that the security is inversely proportional to the size of the bridge (assets being stored). As a bridge becomes bigger, the motive to majority attack one of the chains also increases, because the amount of funds that can be reverted and ‘’depegged’’ become larger.

True, but not the biggest problem

51% attacks and other majority attacks on chains are quite unlikely. While Vitalik’s point is certainly true, the more likely catastrophic event which would completely undermine bridging is the bridges themselves.

Bridges are services operated by one or more participants. The participants have responsibility over witnessing deposits on a certain blockchain, and/or executing the minting/burning in another chain, or they are the ones that have to make sure liquidity is guaranteed to the receiving blockchain by another actor or smart contract.

These actors can be called in many ways depending on the type of project and what tasks they undertake, they usually go by "Bonders", "Relayers", "Guardians", "Routers", "Network operators" or even "Validators".

These operators are by far the most security critical part of any cross-chain or bridging protocol, as they are the ones that can have transactions reverted, funds stolen, or erroneous amounts of tokens burnt or minted for example.

In this early multi-chain phase that we are in, where we have a large amount of projects trying to find ways to secure their bridging processes, it is clear that hacks or collusion between operators within the bridge are far more likely to happen than an attack on blockchains like Ethereum or Solana.

The community in general should be focused on how these bridging services are operated and how they function.

Is the network permissionless? Are operators whitelisted? How many of them control the bridging process? What are the consensus rules around it? How can collusion or theft be avoided? What happens when a part of the network doesn’t follow the rules? How many operators need to collude to take control of the network? What do they have at stake to incentivise good behaviour?

Although there are certainly grey areas here, can we trust all projects claiming to be decentralised? It is one thing to not offer a decentralised service. It is another thing to lie about it.

These fundamental questions that make the very fabric of every open blockchain are by far the most critical attack vector on bridges and cross chain protocols.

Even 5 months after a bridging process was perfectly executed, whichever user is still holding the wrapped assets, Damocles sword hangs over their head.

The ongoing security overhead is something that users and other apps must be aware of when connecting to these bridges. Even if users can be lulled into using these bridges, it is actually the application developers who are most likely to be unwilling to accept uncontrolled risks into their tech stack by utilising one or more bridging protocols.

What is Chainflip doing ?

Chainflip needs to be treated for what it is: an exchange. The Chainflip multi-chain AMM design leverages a network of 150 validators that control and manage the funds and the swapping process, but at the end of the day it can be broadly categorised as an exchange.

The fact that only native assets are handled through Chainflip without the need of synthetic or wrapped assets means that users do not carry security risks after using Chainflip, nor are they left with a token with limited liquidity and non-fungibility with other wrapped assets.

Because users always deposit and receive the native token on its native chain, once the funds have been swapped and are in the users wallet, Chainflip does not control or risk any of those funds.

Chainflip is just like any other exchange in terms of overhead risk. If you swap your Bitcoins to Ethereum on Coinbase, once the Ethereum tokens have been confirmed in your wallet, Coinbase can very well be off-line, exploited or even disappear; this wouldn’t affect at all your funds or tokens swapped in the past or that are already in your wallet, which is way better for users. Once you’re done, you can stop thinking about it.

Just like normal exchanges, the people that are exposed to long term risk are the LPs or market makers, who have to keep their liquidity on the service. LPs get paid in part to carry this risk. Users, the end customers, shouldn't have to accept that risk if they want self-custody, and so on both Coinbase and Chainflip, they don’t.

Exchanges have been the most widely used method of cross-chain interoperability to date. Although really obvious when said out loud, this model has proven to be very successful in allowing users to transfer value across chains. At Chainflip, we’re extending this model to remove many of the disadvantages of the traditional exchange model, and are introducing a range of new technical features for developers which significantly reduce friction for end users. It is permissionless, decentralised, highly liquid, and is composable without violating the zones of sovereignty of each integrated blockchain.

It is worth mentioning that Chainflip is not the only protocol offering native swaps. For one, there are centralised exchanges, but there is also THORChain that offers credibly decentralised native swaps which shares a similar basic design to Chainflip, but there's a big market to play for, and Chainflip's design should allow the protocol to create its own market.

By simply swapping into the native token of the desired ecosystem, users can play freely and risk free between multiple ecosystems, and application developers can plug into the Chainflip API to help users onboard into their dApp from any chain with only a day or two of work.

So, How Should Chainflip Be Viewed?

While assets swapped through Chainflip have native finality once they are confirmed on their respective blockchain, Chainflip relies on a validator network with consensus rules and active game theory to store and manage funds used in the AMM. The ⅔ majority of the validator network controls the funds stored in every vault, the incoming and outgoing transactions from these vaults and the addresses that can interact with the protocol.

With 150 permissionless validators from day one, we can be proud that we have spent this much time developing a credibly decentralised solution that fixes problems without creating new ones, and prouder still when we release it this year.

It’s always very hard to predict the future of the crypto world, but we don’t think generic cross-chain interoperability is ever going to happen. Cross-chain 'messaging' also appears to be a fairly inconsequential primitive. Maybe someone will prove us wrong in time. However, we do think that protocols like Chainflip offer the next best thing, and are built on the most tried and true business model in the industry: the exchange. By offering a product which offers the best qualities of exchanges without a lot of their downsides, one that is composable, decentralised, permissionless, highly liquid, extensible, and easy to integrate, we hope that we can help the multi-chain reality of crypto today and tomorrow break down barriers to user adoption, increase the prevalence of self custody, and ultimately help other projects who are developing new primitives in the crypto space.

Subscribe to our newsletter for updates, and join the Discord to get in on the action. All of our links can be found at https://chainflip.io