Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Phased acyclic asynchronous upgrades over IBC #107

Closed
cwgoes opened this issue May 28, 2019 · 1 comment
Closed

Phased acyclic asynchronous upgrades over IBC #107

cwgoes opened this issue May 28, 2019 · 1 comment
Labels
app Application layer. brainstorming Open-ended brainstorming.

Comments

@cwgoes
Copy link
Contributor

cwgoes commented May 28, 2019

Desiderata

  1. Single staking token (which can be present on multiple chains)
  2. Single main chain designated at any one point in time
    1. Main chain only can mint tokens.
    2. Main chain is (socially) canonical source-of-truth.
  3. Individual stakeholder choice as to which version to stake on
  4. Asynchrony in stakeholder choice of when / where to migrate tokens & stake
  5. Acyclic version graph (need not be a chain or tree)
  6. Progressive upgrades, where security and risk can change continuously (instead of the binary choice provided by pass/fail on governance proposal-based upgrades)
  7. Atomic switch-overs & intentional halts when necessary to retain sufficient security
  8. No necessary internal state compatibility between versions (but requisite IBC-layer compatibility)

Requirements

  1. Interchain collateralization protocol - ICS 16: Interchain collaterization protocol #27
  2. Mutual comprehensibility between staking modules such that inflation can be minted for interchain-collateralized-security

Possible requirements

(would prefer to eliminate if possible)

  1. Approval voting of possible upgrades for interchain-collateralization-protocol-compliance

Basic concept

Assume some set of state machine versions in simultaneous operation.

  • Stakeholders maintain ranked-choice vote of preference.
  • All stakeholders must always validate current main chain.
  • All stakeholders must always validate all chains for which they are voting above the main chain.
  • Any single stakeholder can start voting-for and validating a new version.
  • Slashing conditions for validating other than as voted.
  • Threshold-contingent switch of main chain as soon as enough votes switch to another.
    This switch will in fact switch state in a "transfer mode" of IBC (e.g. port all balances).
    This way the two versions need only maintain compatibility at the IBC interface layer.
    During transfer mode, no further upgrades can occur, both chains must be validated by all validators.
    Once transfer mode is done, state resets, voting / upgrades can occur again.
  • Users can choose to risk funds on new version prior to main-chain-threshold-switch (over IBC).

Needs more concrete protocol details.

@cwgoes cwgoes added app Application layer. brainstorming Open-ended brainstorming. post-mvp labels May 28, 2019
@cwgoes cwgoes self-assigned this Aug 24, 2019
@cwgoes cwgoes removed their assignment Dec 8, 2019
@cwgoes cwgoes self-assigned this Jan 4, 2020
@cwgoes cwgoes removed their assignment May 14, 2020
@cwgoes
Copy link
Contributor Author

cwgoes commented Feb 23, 2021

Out of scope for the time being.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
app Application layer. brainstorming Open-ended brainstorming.
Projects
Status: Backlog
Development

No branches or pull requests

1 participant