Discussion Thread for "cross chain validation"

Conversation Hub Relations
1

This thread is to discuss definition and functionality of “cross chain validation”, aka, shared security.

Below is our version of definition.
We can start discussion from this definition.

 

  1. naming of the protocol
    • shared security, delegated security
      • security is too broad wording
      • does not explain the characteristic of interchain protocol
      • does not represent the fact that it is an application on IBC
    • interchain collaterization
      • interchain seems adaquate wording to explain that it is a protocol between different chains, and also it implies it is an application on IBC
      • collaterization seems too broad concept compared to what it really serves because many defi applications also use the word collaterization in different range
    • cross-chain validation
      • cross-chain and interchain seems very similar description
      • the word validation seems correctly describe the role of the protocol
    • conclusion
      • we will use the word “cross-chain validation” as now
          
  2. naming of each blockchain
    • leader/follower chain
      • the roles are not related to front and behind so it is not adaquate
    • control/controlled(?) chain
      • the role is to validate but not control(it is too much wording than its role)
    • mother(parent)/child chain
      • looks like very intuitive definition, which is also widely used in capital market
      • it might gives wrong impression of too strong belonging
    • conclusion
      • we will use mother/child chain as now
          
  3. must roles
     
    • validator set projection via IBC
      • reasoning
        • each mother/child chain should be informed about other chain’s validator set
        • mother chain and child chain both needs to know recent entire validator set on both chains to correctly process consensus procedure
      • process of validator set projection
        • the mother chain transfers its validator set information to the child chain via IBC
        • the child chain commits the state of entire validator set including validators on both chains
        • the child chain transfers the committed entire validator set to the mother chain via IBC
      • periodic heartbeat
        • validator set should be shared on both chains like a heartbeat to inform most recent validator set information
        • what if relayer cannot relay mother chain validator set into child chain for significantly long time?
          • is it okay for child chain to continue producing blocks even though the mother chain validator set has not been updated for long time?
          • the child chain should safety-stop when mother chain validator set has not been updated for certain number of blocks
             
    • mother chain validators operate full-validator setup on child chain
      • mother chain validators participate on all child chain validation process
        • to fully participate on child chain validation, mother chain validators should operate full setup child chain validator node
           
    • consensus fault punishment on mother chain
      • mother chain validators will be slashed or jailed if they do consensus fault behavior on child chain consensus process
      • this feature needs an IBC protocol called “evidence relay”
         
    • evidence relay
      • relayer should relay consensus fault evidence on child chain to the mother chain to allow mother chain validators to punish the mother chain validator who did consensus fault behavior on child chain consensus process
      • manual evidence reporting on mother chain is additional feature
         
    • hybrid cross-chain validation
      • hybrid validation means mother chain validators and child chain validators having proportional consensus voting power so that they participate on consensus with given power
      • for example
        • mother chain proportional power = 50%
        • child chain proportional power =50%
        • if a mother chain validator has 10% of total mother chain validators who participate on the child chain, he/she will possess 50%*10%=5% of entire power on child chain
      • the parameter is defined in the state of child chain
         
    • cross-chain reward/fee distribution from child chain to mother chain
      • mother chain validators can choose which child chains to participate
      • process
        • rewards for mother chain delegators are accumulated in a module account in child chain
        • a mother chain delegator request a “cross-chain reward withdrawal”
        • IBC distribution protocol transfer such request to the child chain
        • withdrawal amount is transferred from child chain to mother chain
        • distribute withdrawal amount to requestor on mother chain
           
    • optional participation of mother chain validators into each child chain
      • mother chain validators can choose which child chains to participate
      • methodology
        • on mother chain, mother chain validators create a new validator for participating on a specific child chain
        • there exists an activation flag on the validator which implies the validator’s intention to participate on the child chain consensus process
        • when the activation flag is on, the validator is subject to responsibility of consensus fault punishment, uptime, and beneficiary of rewards
        • delegators of the validator will automatically follow the setup of the validator
           
    • role of relayers for cross-chain validation
      • validator set projection heartbeat
      • evidence relay
      • IBC peg : for cross-chain reward distribution
      • IBC distribution : for transfer information about reward distribution of mother chain delegators and validators
          
  4. optional roles(future roadmaps)
     
    • governance voting power projection
      • to allow delegators on mother chain participate in governance on child chain
      • with predefined proportional governance voting power
      • we need additional IBC governance protocol to share governance power and votes
5 Likes
2

Let me describe some points to discuss

  1. which chain to confirm the entire validator set?
  • child chain : mother chain validator set info is relayed to child chain. Entire child chain commit the entire validator set on child chain.
  • mother chain : child chain validator set info is relayed to mother chain. Only mother chain validators commit the entire validator set on mother chain
  1. periodic heart beat
  • if the child chain cannot get mother chain validator set info for predefined number of blocks, entire validator set info in child chain can be recognized as old info, so we need a safety stop to prevent problems caused by significant power changes in mother chain
  1. mother chain validators operate full-validator of child chain to participate
  • they should operate full-validator binary to verify all txs and state changes, just same as the responsibility of child chain validators
  1. cross chain reward distribution
  • option1 : interchain reward transfer happens only when a delegator withdraw rewards
  • option2 : entire rewards periodically transferred to mother chain and withdrawal happens for each request on mother chain

  1. validators in mother chain can choose which child chains to participate, not delegators. Delegators can choose validators based on their child chain portfolio.

  2. there is a whitelist of child chains in mother chain which are allowed for mother chain validators to participate on each child chain’s consensus