Persisted db hashes may not match persisted data

[batconjurer]

The app root hash field is stored along with all data to disk. On restart, the hash field is read but not checked against the data that has been reloaded. It is possible that flushing to disk can be interrupted and thus the correct hash is persisted but not all the data is written. Thus on start up, the ledger starts to make progress (since it has the correct app hash), but will result in state divergence one block later.

To fix

• Try to make db flushed more atomic (likely not a foolproof solution)
• Recompute the hash of the backing data and check it against the persisted hash on startup.

[bengtlofgren]

Can you provide the relevant lines and files in the code where it reads the hash?

[batconjurer]

namada/apps/src/lib/node/ledger/shell/mod.rs

Line 573 in 4bc441e

let result = self.wl_storage.storage.get_state();

[batconjurer]

If you chase that function down, it leads here:

namada/core/src/ledger/storage/merkle_tree.rs

Line 395 in 4bc441e

pub fn root(&self) -> MerkleRoot {

[cwgoes]

@batconjurer Is this issue still applicable?

[batconjurer]

Oh wow, haven't thought about this in a while. I'll need to dig back into it

[batconjurer]

Yes, this is still relevant @cwgoes