Skip to content

Commit e4c8ddc

Browse files
Improve sv network reset docs (#2485)
Signed-off-by: Robert Autenrieth <robert.autenrieth@digitalasset.com>
1 parent 18e545f commit e4c8ddc

File tree

1 file changed

+91
-23
lines changed

1 file changed

+91
-23
lines changed

docs/src/sv_operator/sv_network_resets.rst

Lines changed: 91 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -21,26 +21,94 @@ redeploy your node.
2121

2222
To complete the reset, go through the following steps:
2323

24-
1. Take a backup of the DSO configuration (replace YOUR_SCAN_URL with your own scan e.g. |gsf_scan_url|)::
25-
26-
curl -sSL --fail-with-body https://YOUR_SCAN_URL/api/scan/v0/dso > backup.json
27-
28-
The backup allows you to verify that the SV weights and package versions do not change as part of the reset.
29-
2. Check your desired coin price in the SV UI.
30-
3. Uninstall all helm charts.
31-
4. Delete all PVCs, docker volumes and databases (including databases
32-
in Amazon AWS, GCP CloudSQL or similar).
33-
5. Find the new ``chainIdSuffix`` for cometbft. Usually this will just increase by 1 on a network
34-
reset but double check with the other SV operators on what has been agreed upon.
35-
6. Redeploy your node with migration id 0, the new ``chainIdSuffix``, and ``initialAmuletPrice``
36-
in the SV helm values. Note that this requires changes in the helm values of all charts.
37-
7. Take a backup of your node identities as they change as part of the
38-
reset.
39-
8. Verify that the SV weights (after all SVs rejoined after the reset) and package versions did not change by querying scan again after the reset.
40-
9. Verify that your coin price vote has been set as desired.
41-
42-
.. code-block:: bash
43-
44-
curl -sSL --fail-with-body https://YOUR_SCAN_URL/api/scan/v0/dso > current_state.json
45-
diff -C2 <(jq '.dso_rules.contract.payload.svs.[] | [.[1].name, .[1].svRewardWeight]' < backup.json) <(jq '.dso_rules.contract.payload.svs.[] | [.[1].name, .[1].svRewardWeight]' < current_state.json)
46-
diff <(jq '.amulet_rules.contract.payload.configSchedule.initialValue.packageConfig' < backup.json) <(jq '.amulet_rules.contract.payload.configSchedule.initialValue.packageConfig' < current_state.json)
24+
1. Backup information to be preserved across the reset
25+
26+
a. Take a backup of the DSO configuration (replace YOUR_SCAN_URL with your own scan e.g. |gsf_scan_url|)::
27+
28+
curl -sSL --fail-with-body https://YOUR_SCAN_URL/api/scan/v0/dso > backup.json
29+
30+
The backup allows you to verify that the SV weights and package versions do not change as part of the reset.
31+
b. Make a note of your desired amulet price in the SV UI.
32+
c. Make a note of all ongoing votes in the SV UI.
33+
Ongoing votes will be lost as part of the reset and need to be recreated manually after the reset.
34+
d. Make a note of all featured apps:
35+
36+
curl -sSL --fail-with-body https://YOUR_SCAN_URL/api/scan/v0/featured-apps > featured.json
37+
38+
Featured app rights will be lost as part of the reset and need to be recreated manually after the reset.
39+
40+
e. Make a note of the current round in the Scan UI.
41+
The current round number affects the reward distribution.
42+
43+
2. Decommission your old node
44+
45+
a. Uninstall all helm charts.
46+
b. Delete all PVCs, docker volumes and databases (including databases
47+
in Amazon AWS, GCP CloudSQL or similar).
48+
49+
4. Deploy your new node
50+
51+
a. Set the migration id to 0 in helm chart values. The migration id appears in all helm charts,
52+
both as its own value, e.g.::
53+
54+
migration:
55+
id: "MIGRATION_ID"
56+
57+
and as part of various values, e.g.::
58+
59+
sequencerPublicUrl: "https://sequencer-MIGRATION_ID.sv.YOUR_HOSTNAME"
60+
61+
b. Set ``initialAmuletPrice`` to your desired price in ``sv-values.yaml`` (see step 1.b).
62+
c. Set ``chainIdSuffix`` to the new value in ``cometbft-values.yaml`` and ``info-values.yaml``.
63+
Usually this will just increase by 1 on a network reset but double check with
64+
the other SV operators on what has been agreed upon.
65+
d. Founding node only: Set all helm chart values that affect network parameters,
66+
such that the verification steps listed below pass.
67+
e. Install all helm charts.
68+
f. Wait until your SV node is sending status reports.
69+
70+
5. Verify that network parameters were preserved
71+
72+
a. Confirm that the reset did not change the dso rules
73+
by repeating step 1.a and comparing the result:
74+
75+
.. code-block:: bash
76+
77+
curl -sSL --fail-with-body https://YOUR_SCAN_URL/api/scan/v0/dso > current_state.json
78+
79+
The reset should preserve SV reward weights, i.e., the following diff should be empty:
80+
81+
.. code-block:: bash
82+
83+
jq '.dso_rules.contract.payload.svs.[] | [.[1].name, .[1].svRewardWeight]' backup.json > weights_backup.json
84+
jq '.dso_rules.contract.payload.svs.[] | [.[1].name, .[1].svRewardWeight]' current_state.json > weights_current.json
85+
diff -C2 weights_backup.json weights_current.json
86+
87+
The reset should also preserve the amulet rules modulo cryptographic keys, i.e., the following diff should
88+
only show changes to the dso and synchronizer namespaces:
89+
90+
.. code-block:: bash
91+
92+
jq '.amulet_rules.contract.payload' backup.json > amulet_backup.json
93+
jq '.amulet_rules.contract.payload' current_state.json > amulet_current.json
94+
diff amulet_backup.json amulet_current.json
95+
96+
b. Check your desired coin price in the SV UI, and verify that it matches
97+
the value from before the reset (see step 1.b.)
98+
c. Check the current round in the Scan UI, and verify that it matches the expected value.
99+
This can either be roughly the same value as before the reset (see step 1.e.), or
100+
a different value if the SV operators agreed on that, e.g., to match the minting curve
101+
to a different network.
102+
103+
6. Take a backup of your node identities as they change as part of the
104+
reset.
105+
106+
7. Other post-reset actions
107+
108+
a. Recreate votes that were ongoing at the time of the reset, see step 1.c.
109+
b. Re-issue onboarding secrets to validators you are sponsoring.
110+
c. Recreate votes for featured apps when requested by validators.
111+
The expectation is that validators reach out to their sponsor and the sponsor initiates the vote.
112+
If necessary, consult the list of featured apps you backed up in step 1.d.
113+
d. Update your auto-sweeping configuration, as party ids change as part
114+
of the reset.

0 commit comments

Comments
 (0)