You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Single staking token (which can be present on multiple chains)
Single main chain designated at any one point in time
Main chain only can mint tokens.
Main chain is (socially) canonical source-of-truth.
Individual stakeholder choice as to which version to stake on
Asynchrony in stakeholder choice of when / where to migrate tokens & stake
Acyclic version graph (need not be a chain or tree)
Progressive upgrades, where security and risk can change continuously (instead of the binary choice provided by pass/fail on governance proposal-based upgrades)
Atomic switch-overs & intentional halts when necessary to retain sufficient security
No necessary internal state compatibility between versions (but requisite IBC-layer compatibility)
Mutual comprehensibility between staking modules such that inflation can be minted for interchain-collateralized-security
Possible requirements
(would prefer to eliminate if possible)
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.
The text was updated successfully, but these errors were encountered:
Desiderata
Requirements
Possible requirements
(would prefer to eliminate if possible)
Basic concept
Assume some set of state machine versions in simultaneous operation.
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.
Needs more concrete protocol details.
The text was updated successfully, but these errors were encountered: