Brainstorming "cross-chain validation" and reformation of Cosmos-SDK

Archived Cosmos-SDK
1

I am trying to imagine the most generalized concept of cross-chain validation.

Below are the generalization of cross-chain validation I’ve got so far.

On the table of possible cross-chain validation combination, range of possible targets will define the direction of reformation of Cosmos-SDK for the hub or zones to apply these cases via IBC.

This brainstorming is important because, we need to design “validator set projection” IBC protocol to fully comply with generalized cross-chain validation application on IBC.

These are some questions we have to answer.

  • Do we want to allow multi-token staking feature on Cosmos-SDK?
    • if yes, do we want to allow a staking token not validating its own but only validating other blockchain?
  • Do we want to allow a token to validate more than 2 blockchains?
  • Do we want to allow a blockchain to be validated by more than 2 tokens?
  • Do we want to allow a “pegged token” to be used as a staking token?

  • Generalization for token ledger

    • Multi-denom feature basically serve this objective
    • Target chain’s native token minted on source chain implies that the source chain is securing the original ledger of the tokens
    • IBC fungible token transfer protocol allows each token to be moved to the target chain

  • Generalization for token staking and validation

    • Notes

      • Cosmos-SDK allows any staking whitelisted tokens to perform every functionality related to staking
      • It does not mean all of these staking whitelisted tokens can participate on the consensus process of the chain itself.
      • Unique chain for any “stakable token” to be staked
        • A chain can have several stakable tokens
        • But, a stakable token has only one chain where to stake → the unique hometown of the stakable token
        • hometown chain is also the original ledger of the stakable token
          • original ledger means controlling the supply and bank of the token

    • Every possible cross-chain validation categorization to be considered

      Untitled
      Untitled1019×214 4.94 KB

      • case 1
        • token A, B : native
          • chain A and chain B is completely independent each other
      • case 2
        • tokan A : native + cross-chain validating
          • token A staked on chain A, validating chain A and cross-chain-validating chain B
        • token B : native
          • token B staked on chain B, validating its own chain B
      • case 3
        • token A : native
          • token A staked on chain A, validating its own chain A
        • token B : cross-chain validating
          • token B staked on chain A, cross-chain-validating chain B
      • case 4
        • token A : native + cross-chain validating
          • token A staked on chain A, validating chain A and cross-chain-validating chain B
        • token B : cross-chain validating
          • token B staked on chain A, cross-chain-validating chain B
      • case 5
        • token A : native + cross-chain validating
          • token A staked on chain A, validating chain A and cross-chain-validating chain B
        • token B : native + cross-chain validating
          • token B staked on chain B, validating chain B and cross-chain-validating chain A
4 Likes
2

@xhipster I know you had some basic ideas, mind sharing?

1 Like
3

Fantastic work to get the conversation started. I’ll think on this and try to respond in more depth.

2 Likes