Add GraphQL query for accounts + merkle paths in snarked ledgers

[nholland94]

We need to support querying accounts and merkle paths from within snarked ledgers. This work is necessary to support cross chain bridges, as well as to provide trustless access to ledger data to web 3 applications integrating with Mina. It would be ideal if we can query any snarked ledger within the frontier, but the minimum requirement for this is the ability to query the snarked ledger of the best tip. We should take care with the design choices we make when providing this data from the frontier, as this can have ramifications on memory usage, masking complexity, and node performance.

[carterbrett]

Update on the ask from Nil here: Just exposing the snarked ledger of the best tip probably won't be sufficient for their needs since proof generation likely won't be in sync with the best tip.

March 8th Slack message from Haresh at Nil:

Since proof generation will not likely be in sync with latest tip of the chain, we need a way to access some historical ledger-states (at the moment no idea how far would we need to go back). Thus we would like the API which returns account merkle path to be changed to either

• account('pubkey','snarkLederHash') or
• account('pubkey','snarkLederHash', 'block_num')

[psteckler]

historical ledger-states

In the berkeley archive db, there's sufficient data to construct the staged ledger at a given block height, fairly easily. The time for that is linear in the block height. To generate the snarked ledger at a given height would be much more difficult, and would involve replaying txns until we found the snarked ledger hash.

But if it's an old block along the canonical chain, where there's an eventual snarked ledger that has evolved from an older staged ledger, should the Merkle path in the older staged ledger be enough?

[hgedia]

Adding the same comment from slack

AFAIK, this would work only for a few cases with an unknown probability, i.e staged ledger evolving to the snarked ledger. Take the below example.

Where batch size =3 would mean, the staged ledger evolves to the snarked ledger, but batch size =2 would mean they might match at block 7 (block 6 is when they could possibly align?). The issue is compounded as we never really know how many transactions are in a block and the snark batch size is also dynamic IIRC

I also think this API should be easy to use for zkApp developers, so probably needs to be exposed via a client, alas this is a product decision.

[mrmr1993]

To add some flavour to the original issue: the goal here is to support looking up an account that we know has been proven in a certain block (by using the ledger hash) and then allow a membership proof by also providing the merkle path.

Concretely, something like

query MyQuery {
    snarkedLedgerAccountMembership(
        ledger_hash: !$ledger_hash,
        public_key: !$public_key,
        token_id: $token_id)
    {
        merklePath,
        account: {
            balance,
            timing,
            nonce,
        }
    }
}
}

It's much more efficient to query the ledger database in 'batches' too, so I could also imagine a version of the above that supports a list of (public_key, token_id) tuples to resolve, if that doesn't result in a GraphQL interface that's too horrible.

[MartinMinkov]

Closing since https://github.com/MinaProtocol/mina/pull/16000 has been merged into compatible