Tooling to allow users verify HF package

[georgeee]

Come up with a set of tools that allow users to easily verify HF package.

1. Mina command to export ledger(s) (without need to start a node)
2. A simple utility (~30 lines of code) in Ocaml/Go that verifies two RocksDB databases are equal
3. Shell script (using two commands above and jq tool) to compare mainnet export json to a set of ledgers formed by the Mina node

Shell script from the third step should do the following:

1. Execute the script (from #14793) to convert exported mainnet config to runtime config and .tar.gz representations of ledgers
2. Use mina command from 1. to export ledgers (genesis, staking, next) out of runtime config
3. Compare ledgers from previous step to those contained in runtime config (using jq utility)
4. Rewrite runtime config to contain ledger accounts instead of references
5. Run mina executable to initialize .tar.gz representation of ledgers from runtime config
6. Using Rocksdb comparison tool, compare .tar.gz from previous step to .tar.gz from the first step

Related issue: #14836

[georgeee]

1. Ensure it is not possible to export fork config from a mainnet node that is not synced
2. Ensure correct messages are being printed from the script a. Is script is not able to verify the ledger equality, print a message suggesting checking inputs to the script and contacting community/MF on Discord if they're not able to identify the trouble on their own

[emberian]

Only parties that are online at the time of the network halt / hardfork are able to export the protocol state required to perform the verification. As a possible addition or alternative to this (maybe a community member can take it up?), a zkapp could be written which will

1. verify the final blockchain proof of v1 mina
2. performs a zkappified version of the data migration to v2 (this will be some work!)
3. asserts that the migrated data is equal to the new chain's start configuration.

This provides a proof that HF data was not tampered with. It does not solve the problem of network partition/any short forks during the transition (ie, that the correct chain was chosen of all the alternatives available during that slot). That would be its own challenge but is conceivably possible to build a new snark that folds up chain selection within a slot. At that point, the fork regains succinct verifiability back to chain boot in 2021, modulo the assertion that whoever performed the proof+fork had all available blocks gathered.

[Sventimir]

The most recent updates to the ledger export mechanism add (among others) an option to choose a block to export a ledger from. Choosing some block in the past further narrows down the time window in which ledger state can be exported by a verifier. If transactions are halted already, the ledgers should still remain the same even if the state is exported on a different (later) block, but one needs to take into account block rewards which may accumulate during operations after transaction stop (unless they're disabled). Other parameters of the fork (most importantly current global slot) will certainly differ and so cannot be reasonably verified in this scenario.

[georgeee]

Mina command to export ledger(s) (without need to start a node)

It's possible to export genesis ledger, as well as epoch ledgers from genesis config.

Export of staged ledger as well as staking/next staking ledgers is impossible without synchronization to the network (i.e. running a Mina node)