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
We need the ability to export and import state to and from a genesis file (collection of TOML files). This may be useful in case Namada needs to perform an irregular state-modifying upgrade where specific data structures kept in state must be manually modified or where the keyspace layout needs to change. This requires:
each validity predicate can export its state to and import its state from part of the genesis file (e.g. MASP - commitments, nullifiers, notes, etc.; governance - proposals, delegates, etc.)
the ledger can export its state to and import its state from part of the genesis file (e.g. replay protection, other system-level key/value state pairs)
The export and import functions should be inverses; i.e., when we export state and reimport it on a different node, we get exactly the same state. This can be tested by hashing the entire storage, exporting it, importing it, re-hashing the storage on the new node, and checking that the hash matches the original. It's important that we're able to take the state export and start up a new chain (with the export as genesis), we should test this flow as well.
We should be able to use Serde for JSON serialization & deserialization, so this shouldn't require too much more than paired import / export functions for all VPs and other parts of state, where:
the import function takes a bunch of structs (deserialized from JSON) and writes them to the appropriate DB keys
the export function reads all relevant DB keys into structs and serializes them to JSON (which can be imported)
We'll also need a namada export <filename> command (no special import command should be required, just the usual genesis start).
This work may have conflicts with ongoing genesis flow refactors by @batconjurer; we should communicate with him.
The text was updated successfully, but these errors were encountered:
We should be able to test this on a testnet quite easily.
Run a chain with 4 validators and 2 nodes. Let the chain run for 1000 blocks. Stop 1 validator and 1 node. The chain continues. Export the state on 1 validator and 1 node. Clean the data directories of the 1 validator and 1 node. Import the state into the validator and node. Both should continue where they had exported it.
Agreed with @sug0 to start with a simpler version that does not serialize/deserialize everything to JSON, but just add an import DB command to mirror the dump DB command, and write a simple demo of exporting & importing state, including performing some simple modification.
We need the ability to export and import state to and from a genesis file (collection of TOML files). This may be useful in case Namada needs to perform an irregular state-modifying upgrade where specific data structures kept in state must be manually modified or where the keyspace layout needs to change. This requires:
The export and import functions should be inverses; i.e., when we export state and reimport it on a different node, we get exactly the same state. This can be tested by hashing the entire storage, exporting it, importing it, re-hashing the storage on the new node, and checking that the hash matches the original. It's important that we're able to take the state export and start up a new chain (with the export as genesis), we should test this flow as well.
We should be able to use Serde for JSON serialization & deserialization, so this shouldn't require too much more than paired import / export functions for all VPs and other parts of state, where:
We'll also need a
namada export <filename>
command (no special import command should be required, just the usual genesis start).This work may have conflicts with ongoing genesis flow refactors by @batconjurer; we should communicate with him.
The text was updated successfully, but these errors were encountered: