Interchain Timestamping for Mesh Security
Introduction
The Cosmos blockchain network has become widely recognized for its well-designed architecture, which enables sovereign blockchains to interact safely and efficiently with one another using the Inter-Blockchain Communication (IBC) protocol. However, a key limitation of this approach is that each individual blockchain, especially those that are new, may be relatively small and therefore have potential security limitations. This contrasts with for example Ethereum where there is only one single large blockchain providing security to all the projects built within it. Because of the interconnected nature of the Cosmos chains, insecurity of one chain will propagate to other chains, thus weakening the overall security of the ecosystem.
An analogy for this would be considering Ethereum as a 19th-century empire that provides protection to its inhabitants, in exchange for taxation (gas fees) and the forbiddance of sovereignty. Under this analogy, Cosmos would in turn be a network of present-day countries that may rule as they wish and collect their own taxes, but do not have the same level of security as that of a grand empire.
The formation of NATO has been one solution to this, whereby independent countries have formed a mutual defense alliance in the event of an attack on any individual member. Similarly, the idea of Mesh Security has been recently introduced, whereby different Cosmos chains share security with one another.
What is the mechanism by which security can be shared across blockchains? One method currently proposed is cross-staking: validators validate across multiple blockchains using the same stake. By sharing validators, honest behavior is incentivized which in turn increases security. This is because poor performance as a validator on any given blockchain would result in slashing not only on that blockchain but on others as well.
In this article, we will present an alternative and yet complementary approach to Mesh Security: interchain timestamping. This method shares security between blockchains with their entire validator sets, rather than between subsets of validators, thus further realizing the analogy of entire countries securing each other. This entails timestamping blocks on any given blockchain by posting their headers on another blockchain. This increases security significantly as the reordering of transactions on one blockchain now requires not only forking of that blockchain but also reordering the timestamps present on another blockchain.
In this paper, we will show that interchain timestamping is an effective method for sharing security while still maintaining the sovereignty of smaller blockchains. We will also show that it is readily available to be implemented, as IBC already provides such timestamps which can be utilized. Interchain timestamping is therefore a practical approach that supports the vision of Mesh Security. Outside of the Cosmos network, it can support other Proof-of-Stake blockchains that are IBC-compatible.
Let’s dive in!
An Example of a Double-Spend Attack
Consider that a malicious party (who we’ll call John) wishes to send 1M tokens from the fictional “Rugpull Chain” to Osmosis. John uses IBC, which works by locking up the 1M RUG tokens on the Rugpull Chain and minting the equivalent amount of RUG tokens on Osmosis. John then swaps the 1M RUG tokens on Osmosis for 10,000 OSMO tokens.
John sends 1M RUG tokens to Osmosis using IBC and swaps them for OSMO tokens.
Unfortunately, John is the Founder of Rugpull Chain and therefore has a very large amount of tokens staked. He creates an alternative past blockchain history (“fork”) of Rugpull Chain that states that he had never actually sent the 1M RUG tokens to Osmosis. Since he has a large number of tokens staked, he’ll likely be able to be chosen as a validator and in turn have this malicious fork approved. He’s now gotten the OSMO tokens without paying anything at all!
A fork is created, stating that he had never sent the RUG tokens to Osmosis.
The result is that John has signed both the original block as well as the new block that states he never sent the RUG tokens to Osmosis. This will be noticed by the network and he will be subject to a slashing penalty.
John is subject to a slashing penalty for double signing.
However, Rugpull’s total amount staked may be relatively low if it is a smaller blockchain, meaning that the slashing penalty may be outweighed by the amount of OSMO tokens gained. That means that additional security is required in order to increase the cost of corruption for blockchain systems.
Interchain Timestamping Explained
It turns out that it’s actually possible to prove that John had sent the 1M RUG tokens from Rugpull Chain to Osmosis, through what’s referred to as interchain timestamping. Rugpull Chain could timestamp their blocks by putting the block headers onto another larger chain, such as Osmosis itself. Therefore, when John creates a new fork that says he had never actually sent the RUG tokens to Osmosis, it would be disproven as the original transaction was timestamped
When John creates a new fork on Rugpull Chain to reverse the original transaction, it’s unsuccessful because a timestamp already proves that he had sent RUG tokens to Osmosis.
John originally was able to use his stake on Rugpull Chain to say that he hadn’t sent the RUG tokens. However, to reverse the timestamp that’s posted on Osmosis, he would need a large enough stake on Osmosis in order to reverse the timestamp there as well. Due to Osmosis (or whichever specific chain is chosen) being a much larger blockchain, the cost to fork it will be significantly higher than the cost to fork Rugpull Chain.
John now needs to stake tokens on Osmosis as well in order to reverse the previously posted timestamp. This significantly increases the potential slashing penalty.
How Cross Staking Protects Against this Attack
We explained earlier that a proposed mechanism for Mesh Security is cross-staking, whereby validators validate across multiple blockchains using the same stake denominated in a native chain’s token. This results in slashing not only on the native chain, but on others as well. In the example above, a validator stakes their OSMO tokens on the native Osmosis chain, but can simultaneously cross-stake them on Rugpull. This increases the cost of attack for John, because he now has to acquire OSMO tokens in order to attack Rugpull, which would result in these tokens being slashed as well.
Drawbacks of Cross-Staking
However, cross-chain staking has several potential drawbacks.
- Larger blockchains may have validators that become prominent validators across multiple blockchains, thereby increasing validator centralization and reducing the sovereignty of smaller blockchains. This should be avoided, as decentralization and sovereignty are core to the Cosmos ecosystem. One potential method of mitigation is the limitation of validator voting power on any given blockchain (e.g. a cap of 10%). This, however, significantly reduces the benefits of shared security (See Replicated Security vs. Mesh Security by Informal Systems for an analysis).
- Even if a validator acts honestly on the native chain, it is possible that they can act maliciously on another chain that they are cross-staking on. Slashing on each of the chains provides some protection against this, but not all attacks are slashable, such as stalling attacks.
- Cross-staking takes advantage of existing shared validator infrastructure where a validator company already stakes on multiple Cosmos chains (using the chains’ respective native tokens). Certain blockchains may not in fact share many common validators, rendering this approach less effective.
Interchain Timestamping vs. Cross-Staking
Let us compare interchain timestamping with cross-staking with regard to the above drawbacks of cross-staking:
- In the interchain timestamping solution, the interchain timestamps are only used to resolve forks on Rugpull in case the Rugpull validators attack the Rugpull chain. If the Rugpull chain does not fork, then Osmosis validators cannot attack Rugpull. Thus, the sovereignty of Rugpull is preserved.
- Osmosis validators can collude with Rugpull validators to attack the Rugpull chain under interchain timestamping. However, to do that, the Osmosis validators have to fork the Osmosis chain as well. Thus, Osmosis validators cannot act honestly on Osmosis while participating in an attack on Rugpull. Thus, interchain timestamping provides a stronger level of security via “fate coupling”.
- Since the interchain timestamps are as secure as any other transactions on the Osmosis ledger, interchain timestamping automatically borrows the security of the entire Osmosis validator set, and not just a subset of the validators who choose to cross-stake.
Cross-staking leverages existing Cosmos infrastructure in terms of shared validators across multiple Cosmos chains. It turns out that interchain timestamping can also leverage an existing infrastructure: IBC!
Interchain Timestamping is already here
IBC works by relying on light clients between blockchains. Light clients only store relevant parts of a blockchain, in contrast to a full Node which runs the entirety of the blockchain. Parties known as relayers pass on the IBC transactions from one blockchain to another, and rely on block headers and transaction proof in order to ensure authenticity.
What’s interesting to note is that this IBC process already automatically creates a timestamp that’s included in the block header, and this works for both intrachain and interchain transactions.
The bottom line is that interchain timestamps already exist between any two chains which are connected through IBC. Using these timestamps to provide mesh security is a matter of adding the capability to the clients to utilize these timestamps.
Cross-staking is done by validators and they are incentivized to cross-stake across chains because they earn yields on both chains. Interchain timestamping is done effectively by IBC relayers so they should be appropriately incentivized. In fact, proper incentivization of IBC relayers, in general, is an important problem under active investigation in the Cosmos ecosystem. This additional role of IBC providing security via timestamping can provide additional incentives to maintain this important piece of infrastructure in Cosmos.
BTC Timestamping: Protecting Against Unslashable Attacks
In this article, we described slashable attacks and how to increase their costs via interchain timestamping on another Cosmos chain.. This is effective for short-range attacks whereby a small number of blocks of recency are targeted.
Long-range attacks on PoS blockchain systems should also be of concern. These can be done via a few different techniques, but the general principle is that a malicious party has removed their stake already (“unbonded”), making the attack unslashable.
It turns out that this can also be solved through timestamping, albeit a different type. PoS network transactions can in fact be bundled together and timestamped to Bitcoin in intervals, preventing non-slashable long-range attacks. PoS blockchains are in effect inheriting Bitcoin’s Proof-of-Work security as any malicious party would now need to change the timestamp that was sent to the Bitcoin network by creating a new Bitcoin fork (hint: very hard to do).
Unslashable attacks (where the stake is unbonded) can be prevented by sending timestamps to Bitcoin. To alter this timestamp, one would have to create a longer BTC fork.
Bitcoin timestamping could also theoretically be used for increasing the economic security of short-range slashable attacks by requiring a Bitcoin timestamp before confirming all transactions. However, because of Bitcoin’s slow confirmation, this will add significant confirmation latency, as compared to interchain timestamping on another Cosmos chain. So a good combination is to use Bitcoin security to protect against long-range unslashable attacks, and use interchain timestamping on other Cosmos chains to increase the economic costs of short-range slashable attacks.
If you’d like to learn more about Bitcoin timestamping for PoS blockchains, please check out our blog post titled Checkpointing Babylon to BTC.
Conclusion
In this article, we showed that interchain staking is a complementary alternative to Mesh Security that enables the sharing of security between blockchains while maintaining their sovereignty.
By timestamping transactions from any given blockchain to a larger chain, any potential attack would not only need to reorder transactions on the smaller chain, but would also need to reorder the timestamps on both blockchains. This significantly increases the cost of the attack and complements Mesh Security, as security is not solely shared between validators, but between the entire blockchains as well. Smaller blockchains in particular benefit from this.
It turns out that IBC already automatically creates timestamps, meaning that interchain timestamping is therefore readily available. It may also be used to support other Proof-of-Stake blockchains outside of the Cosmos network, assuming that they are IBC-compatible.
Proof-of-Stake blockchains must take utmost care in securing their networks and we recommend reviewing the above solutions and considering how they could support one’s own blockchain projects.
If you are interested in learning more about how Babylon security could be of help to your network, please feel free to contact us at any time and we’d be happy to talk.
Follow us on:
