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
previously signed rounds of 4407836must not be signed again - this is why we restore our validator state before starting up the node
compile digd v2.6.0 using go 1.19.3 and move binary to correct folder (~/.dig/cosmovisor/upgrades/v2/bin/ for cosmovisor users)
start nodes at a coordinated date with enough time to prepare. as soon we reach the latest round and have >2/3 VP agreeing the chain will resume. Tests using digd v2.6.0 on the above provided snapshot have shown good results.
Backup plan
Plan alpha could fail in case of the following situations:
digd v2.6.0 is unable to produce a deterministic result in block 4407836 due to unforseen reasons
the chain is able resume but one or more validators are hardslashed because they didn't preserve and restore their validator state and doublesign by accident
In the case plan alpha fails we have two options:
a) if the chain resumes we could revert any possible hardslashes in an upgrade, like secret network and chihuahua did recently
b) last resort would be to use a state-export of block 4407835 to create a new genesis and relauch dig-1 from this state while accepting the archive problem. CryptoCrew have exported that state and are providing it here: https://quicksync.ccvalidators.com/SNAPSHOTS/dig-export-4407835.json
The text was updated successfully, but these errors were encountered:
In times of differentiating apphashes recent chain-halts have shown one factor to be crucial:
CryptoCrew is proposing to take the following path for relaunching Dig:
Plan alpha
4407835
and hash9992D8150EEF051E0385F31389CA56A01DA30634DEDC033726262492E311B2B9
by performing:4407835
- need to preserve and restore priv_validator_state when taking this path!4407836
must not be signed again - this is why we restore our validator state before starting up the nodecompile digd
v2.6.0
usinggo 1.19.3
and move binary to correct folder (~/.dig/cosmovisor/upgrades/v2/bin/
for cosmovisor users)start nodes at a coordinated date with enough time to prepare. as soon we reach the latest round and have >2/3 VP agreeing the chain will resume. Tests using digd
v2.6.0
on the above provided snapshot have shown good results.Backup plan
Plan alpha could fail in case of the following situations:
v2.6.0
is unable to produce a deterministic result in block4407836
due to unforseen reasonsIn the case plan alpha fails we have two options:
a) if the chain resumes we could revert any possible hardslashes in an upgrade, like secret network and chihuahua did recently
b) last resort would be to use a state-export of block
4407835
to create a new genesis and relauchdig-1
from this state while accepting the archive problem. CryptoCrew have exported that state and are providing it here: https://quicksync.ccvalidators.com/SNAPSHOTS/dig-export-4407835.jsonThe text was updated successfully, but these errors were encountered: