Does Shared Security improve Interoperability?

Tech Talk
1

I wanted to start a thread which puts into words an advantage of Polkadot which is not covered that often (that I can see). Hopefully I get everything right below, but I am also writing this as an opportunity to bring further clarity to the actual features that exist, allow others to call out any mistakes, allow others to further the story, and ultimately spread the knowledge to our community.

So the topic at hand is how Polkadot’s cross-chain messaging protocol (XCMP) is advantaged over other protocols, for example IBC or any non-protocol-native messaging system, primarily due to the implications of Shared Security across the interacting chains.

So what is the problem normally?

Any two blockchains can communicate to each other over a bridge. There are many kinds of bridges, ranging from fully trustless to fully trusted, but in the end of the day, messages are passed over the bridge, and transition the state of these chains.

The issue is that these two interacting chains have completely independent security guarantees.

The concern is that two chains both change their state due to some cross-chain interaction, but a weak chain is attacked / reorged, and that would leave the two chains in a conflicting state, with no definitive path toward resolution, especially if there are different parties and incentives at play.

This means the security around interactions between two or more chains is as weak as the weakest chain. Compared to Polkadot, where all parachains, and their interactions are secured by the full security of the Polkadot relay chain.

That being said, all chains (even those in Polkadot) are potentially susceptible to some kind of attack where the logic of the chain has a backdoor which manipulates the state of the chain after a cross-chain interaction. This means that even today, there is some level of trust needed between two chains which want to interact with one another, that they will not act maliciously within the sovereignty of their own state transition function.

How would we solve this?

Another seldomly talked about topic which can help solve this is SPREE.

At a high level, this is where interactions between two chains is managed by logic which is stored on the relay chain, and also the state is maintained on the relay chain. This would mean that even the two chains interacting with one another would not have control over the specific data and logic around their interaction, but instead follow the rules defined by their common security provider.

This too highlights the need for a shared security layer for a future of truly trustless interoperability.

  • Is this all right?
  • Does this make sense to others?
  • Is there a future of interoperability without shared security?
    • What assumptions and guarantees can be made from that future?
    • Are there places where interactions would not benefit from shared security?
  • Are there other benefits that shared security provides to interoperability that I have not mentioned?
  • Are there any real world examples of these points?
    • Where the Polkadot advantage can be seen?
    • Where the competitive disadvantage was abused?
2 Likes
2

Honestly, I think the advantages over independent Tendermint chains are overstated.

Compared to optimistic rollups, though, they’re significant. It’s like if you had messaging between hybrid PoS chains that each didn’t finalize for a week. I was curious how Optimism handled bridging for the Superchain and from looking it up now the answer is disappointing: Superchain Explainer | OP Stack Docs. Tl;dr if you want high security and low latency, you need zk proofs.

SPREE, though, should be a game changer for bridges and cross-chain DeFi and I’m not aware of other systems that could possibly implement something similar. Trying to do something like SPREE for ORUs looks like this: Cross-ORU Contingent Blocks - by James Prestwich.

3 Likes
3

While finalization time is certainly a consideration, I think independent security guarantees are also important here. For example, finalized blocks can generally still be reverted if enough tokens are slashed, and these kinds of scenarios certainly can happen under a coordinated / intentional attack.

I believe I am accurate to say that even chains with “instant finality”, for example in Tendermint, are vulnerable to this kind of attack.

For example, if an independent Tendermint chains rolls back, it can lead to inconsistencies in the global state of the Cosmos ecosystem. As opposed to Polkadot, where rolling back a block on one parachain implies rolling back the state of all parachains. (Perhaps this is a downside in itself compared to sovereign chains?)

This can means without shared security, there are avenues to attack a very secure chain, by instead attacking a weak chain that interacts with that secure chain. On Polkadot, even the interaction between chains are all equally secured by the relay chain.

Perhaps this advantage is indeed overstated, certainly it is hard to empirically measure, but that is exactly the conversation I hope to have here.

4

I should clarify. I don’t think that comparison is overstated because of deterministic finality, but rather because I think economic attacks on proof of stake systems are overstated and ignore factors like slippage.

I consider the economic advantages of sharing security, either through restaking or validator sharding, to be that it’s cheaper for the client chains than funding a separate validator set through inflation, while simultaneously accruing more value to the validators.

Practically, it’s been quite easy for new L1s to spin up decently decentralized validator sets and the problems we’ve seen in bridging have been technical rather than economic.

1 Like
5

As a metaphor, I think of Shared Security as akin to protected trade routes, whereas SPREE is enforced trade agreements.

3 Likes
6

Pretty good tweet potential :stuck_out_tongue: