replace Root with Root_(hash, common) in persistent database

[glyh]

This is a follow up for #16624

This PR only contains patch to be merged into compatible. It's compatible because we try to replace Root with (Root_hash, Root_common) when:

1. initializing a new DB;
2. trying to moving the root;
3. trying to query root or root_hash

That means attempting to perform transactions on old persistence database, the bottleneck will occur once and not after.

Here's the PR for the testcase.

[svv232]

I made some grammatical suggestions, but overall looks good! How was this tested dynamically against loading a pre-hard fork db?

[svv232]

trying to move the root.

[svv232]

initializing a new DB.

[svv232]

Trying to query root or root_hash.

[svv232]

Capitalize we and use a semi colon instead of a comma.

[svv232]

!ci-nightly-me

[glyh]

Hello @svv232 The plan for testing is to have a persistent database that only has Root in it. Try to access it once, confirming the 90s time. And then access it again, confirming it takes less than a second.

George told me to implement something similar to src/app/cli/src/init/transaction_snark_profiler.ml and hand it over to @dkijania to integrate it on CI.

[svv232]

Hello @svv232 The plan for testing is to have a persistent database that only has Root in it. Try to access it once, confirming the 90s time. And then access it again, confirming it takes less than a second.

George told me to implement something similar to src/app/cli/src/init/transaction_snark_profiler.ml and hand it over to @dkijania to integrate it on CI.

ok sure! I was just looking for confirmation that this is indeed backwards compatible. It seems okay to me, but having evidence from dynamic testing is pretty nice. How were you testing this by hand against your local db? I will be convinced to approve if this is indeed the case.

I will also be convinced if you show the tool output if you already have it with an old db with just root.

[svv232]

!ci-nightly-me

[glyh]

@svv232 I'm testing this in https://github.com/glyh/mina/tree/persistent_frontier_test_destructive And Using the data from https://storage.googleapis.com/o1labs-ci-test-data/dump_2025_02-13-07-54-53.tar.gz

So What I do is:

1. Unzip the zip file to some folder, say /abc/def, we'll have a folder /abc/def/2025_02-13-07-54-53
2. Under branch persistent_frontier_test_destructive, in nix develop mina, run dune build on root directory for mina's repo
3. cd into _build/default/src/lib/transition_frontier/persistent_frontier/tests/
4. run TEST_DUMP_PERSISTENT_FRONTIER_SYNC=/abc/def ./test_persistent_frontier.exe test "Deserialization perf test". This should fail, and taking ~90s, which is our bottleneck
5. run the above command again. This should succeed in ~1s.

EDIT:
It turns out the bottleneck is no longer 90s, but 60s in the branch persistent_frontier_test_destructive. I guess I accidentally optimized something else as well.

[svv232]

!ci-build-me

[glyh]

fatal: couldn't find remote ref corvo/persistent-frontier-split-key-root
🚨 Error: The command exited with status 128
user command error: exit status 128

I assume I should relocated this PR in MinaProtocol/mina instead of glyh/mina?

[glyh]

Reopen as requested by @dkijania

[dkijania]

!ci-build-me