Input: list of leaves
Output: all siblings necessary to prove the inclusion of all requested leaves, and one UC
Return the list of unknown leaves with the otherwise valid response? (wrong shard, not yet certified); or fail the batch?
Sharding: either
- keep shards separate, not sharing uc / seal
- best effort sync - uc is different, unicity seal (and signature check effort) is shared, if lucky
- put a specific future BFT Core round number in request so that response is certified by this (or later) seal
- some extra memory in Aggregator so that specific BFT Core round in past can be used to synchronize
Motivation: optimize storage and token verification effort.
- one Unicity Token, re-fetch all inclusion proofs, save only one UC; then validate only one UC
- Batch of Unicity Tokens. Amortize UC verification across entire batch and all txs in tokens
(signature check is expensive to prove in ZK)
Note that this technique has to set limits on which predicates are supported. Like, no predicates with time-dependent evaluation.
This multi-request is more efficient than requesting inclusion proofs one-by-one; also it is guaranteed that all share the same UC.
Input: list of leaves
Output: all siblings necessary to prove the inclusion of all requested leaves, and one UC
Return the list of unknown leaves with the otherwise valid response? (wrong shard, not yet certified); or fail the batch?
Sharding: either
Motivation: optimize storage and token verification effort.
(signature check is expensive to prove in ZK)
Note that this technique has to set limits on which predicates are supported. Like, no predicates with time-dependent evaluation.
This multi-request is more efficient than requesting inclusion proofs one-by-one; also it is guaranteed that all share the same UC.