Cross-chain validation: current design overview & directions #448
Comments
cwgoes
added
app
|
Very nice writeup |
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). |
|
this is a brainstorming of cross-chain validation feature expansion. |
|
This sounds like a generalization of the Flow blockchain design, where they split the operators in 4 groups:
|
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. |
|
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. |
|
Closing in favour of Informal's more recent work. |
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:
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.
The text was updated successfully, but these errors were encountered: