-
Notifications
You must be signed in to change notification settings - Fork 515
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add GraphQL query for accounts + merkle paths in snarked ledgers #12706
Comments
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:
|
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? |
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. |
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 |
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.
The text was updated successfully, but these errors were encountered: