Cross-chain validation: current design overview & directions

[cwgoes]

Executive summary

The basic idea of "cross-chain validation" is to split the functionality of the proof-of-stake state machine, such as picking validator sets, tracking validators, tracking delegations, locking collateral, disbursing rewards, punishing misbehaviour, etc. across separate chains, where one (or many) chains run part (or all) of the proof-of-stake logic and one (or many) other chains accept & relay proof-of-stake relevant information (e.g. validator set updates, proofs-of-misbehaviour, etc.) cross-chain using IBC (sometimes via IBC packets and sometimes directly via the light client algorith, such as to submit misbehaviour).

Cross-chain validation has potential advantages in separating concerns (such that chains can specialise in running parts of the proof of stake machine) and providing additional guarantees to multi-chain security models in certain cases. At present, many chains in the Cosmos ecosystem share a number of validators (by real-world identity), but the chains do not have any in-protocol knowledge of this identity, so they cannot use it to reason about additional security properties, and the validators cannot use their singular identity to simplify accounting, share collateral safely, etc.

On top of the basic set of cross-chain validation protocols, a marketplace could be established to match sellers of validation services (validators), sellers of locked-collateral (validators, delegators), and buyers of validation services & locked collateral (chains/zones). Such a marketplace could reduce the overhead of recruiting a validator set for new or temporary chains which support the cross-chain validation protocols, and could reduce the complex accounting and cost-benefit calculations required of validators running many chains, since security costs could be to some degree standardised and inflation/fee payments can be automatically managed (e.g. converted into a common token of the validators choice through a decentralised exchange).

Cross-chain validation comes at a cost of protocol complexity, which needs to be reasoned about very carefully, especially to avoid accidentally inducing complex "fractional reserve collateral" systems by clumsy incentive design, which could put the security of a complex interoperating set of chains at risk (some optimism is to be found in the inherent transparency of the security models, modulo off-chain contracts, but this still needs to be properly analysed). Cross-chain validation should not be construed as "shared security" or as a replacement for sovereign security, but rather as a complement to it - cross-chain validation should be designed to allow many points on the continuum between "fully sovereign" and "fully shared", so that particular chains & applications can customise a particular configuration to their unique needs.

Basic protocol set

The basic set of cross-chain validation protocols is intended to allow a "leader" chain to completely manage the validator set, delegations, fee payments, and proof-of-stake security (misbehaviour handling) for a "follower chain". Note that "leader chain" and "follower chain" are merely roles, defined ex post by what role chains choose to play (although a follower chain's state machine may choose not to implement the proof-of-stake module at all, in which case it would be dependent on the existence of some leader chain). In principle, nothing prevents chain A from playing the role of follower chain for its own validator set, with chain B leading, and also playing the role of leader chain for chain C, which is then a follower chain for chain A (although this may not make economic sense in practice). Furthermore, these protocols are designed as a modular set, so that chains could pick and choose between components - for example, a chain could delegate control over its validator set to another chain, but still elect to handle inflation rewards & fee payments itself (although this may reduce some of the benefits of cross-chain validation).

As currently conceptualised, the basic protocol set will include the following subprotocols:

• Sending validator set updates over IBC
  • Validator set (or subset thereof) managed by leader chain (somehow, the packet encoding need not be specific about how)
  • Validator set updates accepted by follower chain, used to update its own validator set (or some fraction of it)
  • Packet types
    • Delta (change some validators power, possibly create or delete if nonexistent / zero-power)
    • Reset (set to provided new set)
  • Packet information
    • Validator identifier
    • Validator voting public key
    • Validator voting power
• Slashing over IBC
  • Collateral managed by leader chain
  • Faults occur on follower chain
  • Don't really want IBC "packets" for misbehaviour though, instead light client verification
  • Some IBC packets for misc.
    • Follower chain can instruct leader chain to jail, slash for being offline
• Paying rewards over IBC
  • Validator set (or subset thereof) managed by leader chain
  • Managed validator set receives rewards on leader chain as IBC vouchers
  • Vouchers can be redeemed back to follower chain
  • Packet types
    • Pay rewards
      • For one block
      • Includes map from validator identity to rewards
      • Maybe could combine multiple blocks with no validator set changes (epoch)
    • Implicit voucher minting & supply tracking assumed
• Control protocol
  • Follower chain can request leader chain start a new validator set, manage it
    • Specify options, e.g. token, fractional collateral allowed/disallowed, etc.
  • Follower chain will be subscribed to updates
  • Follower chain can send rewards back, tracked on leader chain
  • Follower chain can shut down leader chain's managed set
  • Do we want a way to share collateral?

Market negotation for rewards/collateral/validation can come later on & build on top of these basic protocols.

Directions of analysis

It may be necessary to define the core protocols at an abstract level, at minimum, before further formalisation, but before design finalisation or implementation we should carefully analyze the cryptoeconomic properties of cross-chain validation, especially as they relate to consensus security & proof-of-stake security.

Validator set intersections

Useful properties may be provided by certain thresholds of "validator set intersection" between chains, as alluded to in the summary above. Consider a case where a leader chain & a follower chain have a validator set intersecting by over 2/3 (by stake) - this then provides the guarantee that every block of either chain is processed & signed by at least one honest intersecting validator, an additional guarantee that can be used to reason about e.g. data availability - any data (perhaps outgoing IBC packets) in the block must be available to that validator, so they could be slashed for failing to make that data available to the other chain within some time bound.

Sharing collateral

At present, most of the collateral staked in Cosmos SDK chains is not "fully utilised", since the slashing rate is far less than 100% - so the same collateral could safely be used to secure additional chains, as long as appropriate accounting is performed to prevent fractional reserve collateral (or reason about it very, very carefully). Analysis should take place in conjunction with formalisation of the Cosmos proof-of-stake security model to determine what the cross-chain validation case looks like with many leader & follower chains, and collateral potentially shared across them. Ideally, it would be possible to precisely state the security of a particular transaction (in terms of who would have to collude, and what cost would be incurred, in order to finalise a conflicting block & double-spend the transaction), subject of course to assumptions about the non-existence of off-chain contracts etc.

[ethanfrey]

Very nice writeup

[Chjango]

Cross-chain validation should not be construed as "shared security" or as a replacement for sovereign security, but rather as a complement to it - cross-chain validation should be designed to allow many points on the continuum between "fully sovereign" and "fully shared"

The phrase "variable security" comes to mind because I anticipate that once cross-chain validation is implemented, presumably as a Cosmos SDK module, there would be precedent to use ATOMs as part of the collateral set securing any chain (assuming multiple tokens being used as underlying, slashable collateral).

[Hyung-bharvest]

https://forum.cosmos.network/t/brainstorming-cross-chain-validation-and-reformation-of-cosmos-sdk/3244

this is a brainstorming of cross-chain validation feature expansion. there are various expanded design for cross-chain validation to be considered. I would like it to be reviewed for more general design discussion.

[robert-zaremba]

This sounds like a generalization of the Flow blockchain design, where they split the operators in 4 groups:

• Collector Nodes - collect transactions in a block.
• Execution Nodes - execute blocks and propose state change. Enable speed and scale
• Verifier Nodes - randomly verify some state changes / transactions proposed by Execution Nodes. They guarantee correctness
• Consensus Nodes - ensure decentralization

[robert-zaremba]

the same collateral could safely be used to secure additional chains

This is only true if the other chains are using the same staking tokens. How often this is true?

[cwgoes]

the same collateral could safely be used to secure additional chains

This is only true if the other chains are using the same staking tokens. How often this is true?

Chain can elect to map particular staking tokens to voting power in consensus however they prefer to.

[ebuchman]

Note there is some ongoing work on protocol design happening here: https://github.com/informalsystems/cross-chain-validation. Should be moved into this repo soon.

[cwgoes]

Closing in favour of Informal's more recent work.