Cross-Chain vs Multi-Chain Revisited
Vitalik’s idea of “Zones of Sovereignty” is a fundamental concept that refers to the ability of each individual blockchain ecosystem to have control over its own governance, economics, and security. For example, a blockchain may have high security and trust assumptions, while another blockchain may have lower security and trust assumptions as a tradeoff for faster and cheaper transactions.
Cross-chain and multi-chain protocols lie at the heart of the zones of sovereignty concept. A cross-chain dApp is deployed across multiple different blockchains in one instance using interoperability protocols, while a multi-chain dApp is deployed in multiple individual versions across distinct networks. Thus, a cross-chain dApp may cross multiple zones of sovereignty while a multi-chain dApp has each version existing within a zone of sovereignty.
As cross-chain infrastructure develops, the idea of a cross-chain future strengthens. Blockchains will have to define their own zone of sovereignty, while users and assets will have to cross the security boundary of a blockchain often. Developers will have to consider the various security assumptions for both the network and assets in a cross-chain vs multi-chain world. With the increased concerns of a cross-chain future, there are innovative methods that we can use to tackle the issues of crossing security boundaries and operating across multiple zones of sovereignty.
Ethereum itself can be thought of as a global computing engine currently secured by over 17 million ETH (roughly $30 billion). Users of dApps built on top of Ethereum implicitly trust the security pool underwritten by the blockchain’s validation mechanism. In return, users pay fees to Ethereum. L2s that rollup to Ethereum also benefit from leaning on the same pool to offer guarantees of varying degrees of trust; i.e. that a transaction is both valid and its ordering relative to other transactions is final.
To look at how this concept is applied in the wild: Polkadot secures its parachains through a shared security model, where all parachains share the same set of validators. This helps to increase the security of the overall network, as any attack on one parachain would require a corresponding attack on all other parachains in order to be successful. Additionally, Polkadot’s on-chain governance system allows for the community to vote on changes to the network, ensuring that the security model remains effective over time.
One concept missing from Vitalik’s post is the idea that different applications may require different levels of decentralization and security, depending on their specific use cases and needs. This is a feature, not a bug. Not every application being built requires it to be secured by over 17 million ETH; on the contrary, a majority of applications built and deployed to Ethereum mainnet are “overpaying” for security.
More on this and the case for a cross-chain future later, but first a tangent on security.
What Does “Security” Mean?
Security for a blockchain network refers to the crypto-economic guarantees for both the safety and liveness of a chain. Safety refers to the ability for a protocol to guarantee transaction validity, in that no malicious transactions such as double spending become finalized. Liveness refers to the ability for a blockchain network to eventually process the correct transactions and come to consensus.
One example of the security for a Proof-of-Stake chain is its susceptibility to long-range attacks. A long-range attack is where a malicious actor creates a branch on the blockchain starting from the genesis block and overtakes the main chain.
For Proof-of-Stake blockchains, new nodes and nodes that have been offline for a significant amount of time are affected by weak subjectivity. This means that upon going online, a node will be presented with all of the published branches of that blockchain. This is referred to as weak subjectivity. In addition, for Proof-of-Stake chains, the cost of validators to create up-to-date branches is zero as securing the network is done through a staking mechanism, and no actual “work” has to be done. Malicious actors will attempt to build a branch that is longer than the current main chain through various attack methods, and thus overtake the main chain with a completely or partially different history.
The security boundary of a chain refers to the total set of blockchain networks/protocols/tokens that depend on the security of one blockchain network’s security assumptions. For example, when an individual bridges assets from Ethereum mainnet to an Ethereum L2 (like Optimism), those assets still sit within the security boundary of Ethereum as Optimism relies on Ethereum for security.
Importantly, in a multi-chain world, it is unlikely users will ever be able to stay within one security boundary. For example, Avalanche, Ethereum, Polygon, Solana, and Cosmos all have different security boundaries that likely overlap each other. These security boundaries have dependencies and need the ability to communicate with each other given those dependencies. It is up to the blockchain network or protocols to minimize these dependencies or strengthen the security of the “lowest common denominator” within a security boundary, as ultimately, all a user cares about is the ability to transfer their favorite tokens and use them on their favorite protocols. The security of any bridged asset between chain A and chain B will always be based on the less secure chain, termed the “lowest common denominator”. A similar comparison can be made for dApps, rollups, and protocols as the security of it all is as strong as the weakest link.
What’s Not Being Talked About
Whereas steps can be taken to minimize the trust required when operating in cross-chain environments, there are still inherent risks present worth considering. Before proceeding further, it’s important to note what’s not being talked about, i.e. what should be out-of-scope when diving into Vitalik’s post…
Implementation Risk in Bridge Design
Even the most trust-minimized bridge is susceptible to bugs present in its implementation. This means that users who leverage a bridge to cross a Zone of Sovereignty’s security boundary may be affected by a future exploit at the smart contract or protocol layer. This can happen due to human error, such as when developers fail to properly audit their code or do not consider all possible attack vectors.
Smart Contract Hacks
Whereas smart contracts that underlie bridges may be simple in their implementation, dApp logic may be far more complex. Vulnerabilities in code that lives on one blockchain will lead to downstream contagion on other blockchains if they are exploited, allowing the hacker to steal or manipulate funds or data regardless of where the user thinks their assets are. When a smart contract is hacked, it can have wide-ranging consequences for all cross-chain ecosystems which it touches, as other contracts or applications may rely on its functionality or integrity.
Upgradability of Bridge Mechanisms (and Smart Contracts Generally)
Bridges and dApps often have upgradable smart contracts that can introduce new attack vectors. Despite extensive security audits, new protocol mechanisms can, and often have vulnerabilities. One great example of this is the Nomad bridge, which during an upgrade initialized the trusted roots to the wrong value, enabling exploiters to replay existing transactions with alternate receiving addresses. Upgradable bridge mechanisms are a necessity as bridges continue to develop, but over time, as contracts become immutable through being battle tested, this attack vector should be minimized.
That said, let’s get back to the topic at hand.
The Multi-Chain Thesis
Different users and developers with distinct use cases will evidently have different preference levels between security, permissionlessness, speed, community interest, and access to liquidity. For example:
- DAOs may want to live on blockchains with high-security guarantees in addition to adequate tooling available, but may not necessarily value speed of execution for transactions.
- Developers may want to build on blockchains with a high number of active users where they can find product-market fit.
- DeFi enthusiasts may want to use the latest DeFi protocols available on blockchains, and may exhibit a higher risk tolerance towards their underlying trust model.
- Institutional actors may value high-security blockchains with deep access to liquidity, without a thought to the other communities present on the platform.
This behavior isn’t theoretical, it’s what we observe happening today. Builders and users gravitate toward the platforms that best suit their needs. If the app-chain thesis is correct, then it’s a given that emerging pockets of communities will continue to build on specialized blockchains that best suit their needs. As blockchain specialization takes hold and the number of fragmented ecosystems continues to increase, it is easy to predict that so too will the number of striated communities.
Despite the growth of DeFi and cross-chain technology, the majority of DeFi protocols still exist in a multi-chain state, with individual deployments on each blockchain network. For example, Curve, Uniswap, and GMX deploy on individual blockchains while a select few other protocols are just barely beginning to explore cross-chain infrastructure for simpler cases such as governance participation and omni-chain tokens.
Vitalik’s post argues that the world will become more multi-chain over time and that as more blockchain use cases emerge and mature, each of them will thrive within independent and self-contained ecosystems. However, this is not the status quo.
In today’s paradigm, the average user traverses the security boundary across Zones of Sovereignty on a daily basis. The majority do this without a thought given to the machinations of either the underlying source or destination blockchains. It’s unlikely that there will be a future point at which users will coalesce towards a single ecosystem exclusively, nor should they be forced to.
With new entrants in the alt-L1 space in recent years, Ethereum has ceded a non-trivial relative share of overall asset TVL and user activity. Active communities thrive outside of Ethereum’s ecosystem and will continue to as new innovations at all layers of the blockchain stack come to fruition. This is a good thing. While Ethereum’s scaling woes are sure to be solved in due time, this is not the only bottleneck users encounter when choosing where to house their assets. Maybe more importantly, it is not the key factor in where developers choose to build their products.
The question shouldn’t be “How do we keep users safe within Ethereum’s Zone of Sovereignty?” but rather “How do we keep users safe regardless of what applications they choose to use?”
This brings us to the idea of sovereignty.
Why Sovereignty is Important
Comparing blockchain networks to nation-states, both seek sovereignty as a form of economic independence. Much like how a country does not want to have an over-reliance on foreign goods, talent, or security, a blockchain network seeks the same properties. A sovereign blockchain network allows for ecosystem participants to have economic independence, whether that is not needing to depend on the security of other blockchain networks or not needing to depend on the economic value of other blockchain network assets. As a result, a sovereign blockchain is able to capture a maximum amount of economic value with the least amount of dependency on external resources, while being able to direct the economic value to various internal stakeholders within the ecosystem.
In a world of infinite blockspace, developers care less about optimizations and consensus and more about connections to both builders and users alike. Users don’t care about composability just because it’s possible — they care that their assets and data can be used in other interfaces and contexts.
— adeets.eth, Apps as Sovereign Communities
More concretely, if a meaningful subset of the community decides to disagree with the changes being pushed to a protocol that holds their canonically-wrapped assets, identities, data, etc. — they should be able to fork.
That does not come with its own problems though. Different blockchains must decide on their own fork choice rule, an algorithm that nodes use to correctly identify and follow the canonical chain. This becomes tricky when a rollup wants to fork. Most rollups today do not have the ability to define their fork choice rule as they settle to an L1. Thus, it is unlikely for a rollup to fork without the L1 nodes initiating the fork.
The Cross-Chain Thesis
Within Cosmos, each blockchain is considered a separate sovereign entity that has the power to determine its own rules, policies, and protocols. This level of sovereignty is made possible through the use of the Cosmos SDK, which allows for the creation of customizable and independent blockchains that can communicate and interact with each other.
Through the use of inter-blockchain communication (IBC), the Cosmos ecosystem enables secure and efficient data transfer between sovereign blockchains. This means that each blockchain can maintain its independence and autonomy, while still being able to exchange value and data with other blockchains within the network. Overall, the concept of sovereignty is a key aspect of the Cosmos ecosystem, as it allows for the creation of a decentralized and interoperable network of blockchains that can work together to achieve common goals.
While this addresses aforementioned sovereignty concerns, Vitalik’s cautionary warning applies here: How are users of these independent Zones of Sovereignty kept safe when crossing the security boundary?
Luckily, there are a number of ways to tackle this.
Shared Security
Cosmos makes a shared security mechanism available. The Cosmos Hub secures networks by allowing validators to validate transactions on other chains that are part of the Cosmos ecosystem. This provides a higher level of security for the entire ecosystem, as the security of each chain is intertwined with that of the Cosmos Hub.
Mesh Security
Mesh security is a security model where blockchains provide security to each other while still maintaining independent sovereignty. For example, the Cosmos Hub will provide security to Cosmos-based chains while Cosmos-based chains will simultaneously provide security back to the Cosmos Hub. This enables blockchain networks to have their own sovereign validators while still having the security of a more secure blockchain network. In practice, a validator could validate transactions on separate blockchain networks that are economically intertwined, and thus be incentivized more for cross-chain staking.
Checkpointing
Checkpointing is a technique where only the latest X number of blocks of the chain can be reorganized. The underlying client of the network will accept all transactions up to the checkpoint as valid and irreversible. Thus, if any malicious actor attempts to fork the blockchain from a block before the checkpoint block, the client will not accept the fork. This creates an immutable blockchain up to the checkpoint.
There are some scenarios where checkpointing is used to implement weak subjectivity. For example, weak subjectivity on Ethereum is implemented by using “weak subjectivity checkpoints”. These checkpoints are state roots that all nodes on the network agree belong in the canonical chain, where the fork choice algorithm then trusts that the blockchain state defined in that checkpoint is correct, and verifies the chain from that point onwards. And thus, in some cases, weak subjectivity is checkpointing.
One great implementation of this is Babylon chain’s checkpointing. Checkpointing is able to replace the weak subjectivity of blockchains, but Babylon brings that benefit to all Cosmos chains via IBC. As direct checkpointing from consumer zones to Bitcoin is not scalable, Babylon presents itself as a checkpoint aggregation service. Babylon first receives IBC packets as checkpoints for individual consumer chains, and then sends those checkpoints to Bitcoin. From there, the consumer chains can read the checkpoints from Bitcoin.
Restaking
Ethereum is still king security-wise. Where the gold standard of trust is required for a new Zone of Sovereignty, this can be bootstrapped via mechanisms like restaking. First pioneered by EigenLayer, the concept describes a mechanism by which a set of Ethereum validators can choose to validate a Cosmos chain’s consensus in return for gaining additional revenue derived from the consumer chain. The consumer Cosmos chain in this instance effectively chooses to pay “rent” to the aforementioned set of Ethereum validators in return for taking on the risk of being slashed due to misbehavior. In this way, the prospect of attacking the nascent chain becomes the daunting task of carrying out an attack on Ethereum itself (with some out-of-scope caveats).
Closing Thoughts
Regardless of a multi-chain or cross-chain future, it is imperative for chains, protocols, and dApps to account for the security assumptions of all stakeholders and participants in their ecosystem. We remain optimistic about the ability for new core infrastructure to strengthen the security guarantees between different zones of sovereignty, and to improve upon existing dependencies of various security models.
About Evmos
Evmos is an EVM-compatible, IBC-enabled blockchain in the Cosmos ecosystem designed for cross-chain dApp development.
The Evmos Core Development Team is on a mission to create and ship the foundational tools necessary for building the cross-chain applications of the future. With groundbreaking features like EVM Extensions, the Evmos SDK, and the Evmos dApp Store, Evmos gives developers the freedom to take advantage of the IBC and connect their smart contracts to the Cosmos Ecosystem.
This revolutionary technology frees developers from the confines of today’s siloed blockchains.
The future is cross-chain.
Helpful Resources:
💻 Developer Documentation: https://evmos.dev/
👾 Official Discord: https://discord.gg/evmos
🐙 GitHub: https://github.com/tharsis/evmos
🕊 Twitter: https://twitter.com/EvmosOrg
📯 Telegram: @EvmosOrg
📄 Medium: https://evmos.blog/
🖥 Evmos Website: https://evmos.org
🌋 Evmos Jobs Board: https://boards.eu.greenhouse.io/evmos
Evmos is the EVM stack for building natively cross-chain decentralized applications. We encourage you to read the Evmos Manifesto and learn more about our plans to build a cross-chain future.
DISCLAIMER: None of this is financial advice. This content is strictly for educational purposes. It’s not investment advice or a solicitation to buy or sell any assets.
