-
Notifications
You must be signed in to change notification settings - Fork 8
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
doc: ETCM-8682 Migration strategy for generic versioned Plutus data #198
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Nikolaos Dymitriadis <[email protected]>
Signed-off-by: Nikolaos Dymitriadis <[email protected]>
Signed-off-by: Nikolaos Dymitriadis <[email protected]>
data: | ||
- D-Parameter | ||
- Permissioned candidates list | ||
- Cardano SPO registrations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This guide will be for v1.4, when in v1.3 we introduce observability of token release from reserve to illiquid supply. Will this script be changed as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, native tokens is a completely new mechanism so no migration needed. There will be no legacy version, but the initial implementation can support versioning from the start.
|
||
Introducing versioned Plutus data is a breaking change in the smart contracts, which means | ||
new versions of the smart contracts will need to be used. The governance authority should use the | ||
new version of Partner Chains Smart Contracts to set up a new D-Parameter and permissioned |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This operations should happen when SPOs register with the new smart contracts.
operate using the old smart contract data. During this period: | ||
|
||
- all SPOs wishing to continue participating in the chain will need to register themselves | ||
again using the new smart contracts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do SPOs observe their new registrations when their nodes are still configured for the old addresses?
In my opinion it is not detailed enough to pass this to users. For me there should be detailed steps like:
I think the only sensible way is to prepare locally at least two directories (one for governance auth, one for SPO) and record each step required to perform the procedure. |
Description
Initial draft of the migration strategy.
Checklist
changelog.md
for affected crateNote on CI
If your PR is from a fork, the necessary CI jobs won't trigger automatically for security reasons.
You will need to get someone with write privileges. Please contact IOG Partner Chains developers to do this
for you.