Ideal properties of an Opaque Delegated Aggregate Transaction (ODAT) scheme.
We're exploring various ways proof aggregations can improve scalability, and this is an attempt to distill one coherent set of ideal properties for a particular design approach. These aren't "perfect ideals" because I'm assuming certain trade-offs, which I try to identify, but there're likely to be other implicit assumptions to uncover.
I have no idea how feasible the entire set is as a whole, or how feasible it is to attain some properties but not others.
Properties
- ODAT transactions allow the functionality of existing (ex: Sapling, Orchard) shielded transfers or the aggregation of some number of subtransactions.
- Opaque: The two cases of aggregating versus nonaggregating transactions are indistinguishable. Implication: onchain data cannot reveal the existence of an aggregator, in turn ensuring aggregation is a permissionless market.
- Delegated: The aggregated subtransactions may be issued by different parties from each other and from the aggregator.
- Subtransactions may spend outputs of other subtransactions within the same aggregation unit. An aggregating transaction is associated one-to-one with an aggregation unit.
- An aggregating transaction can be created at any time to aggregate any set of transactions which aren't already finalized by consensus. Bug: Is this consistent with
- Aggregation ensures validators of the aggregating transaction need not learn any internal transaction details, and therefore this ideal scheme has strong pruning / compression properties. Assertion: this is implied by aggregation-vs-non indistinguishability.
- Because an aggregating transaction can be validated by base layer validators cheaply without internal state, subtransaction issuers which can validate base layer consensus can achieve the same validation guarantees without tracking all internal aggregation state.
- An aggregator is prevented (somehow?) from denying availability to subtransaction funds by withholding an aggregating transaction indefinitely. A total guess at a workable approach to implement this might be some kind of timeout for an aggregating transaction, after which the original deposits into the aggregation scheme
Are there ideal properties missing here?
Use Case
The intuition is that these properties would easily allow very high capacity centralized aggregation with strong privacy and safety guarantees. Decentralization of aggregators could be potentially developed as a subsequent improvement. Both improvements would not disrupt a standard base layer operation or transaction capacity.
From Ideals to Real Life
Assuming we cannot achieve all ideal properties, which trade-offs or sacrifices give the best outcome?
Very speculative intuition: sacrificing ideal property 5 is my guess as to a fruitful exploration; introduce some boundary for aggregation units that requires some kind of deposit/transition mechanics. Timeouts or other conditionals help achieve 8. The aggregation must "settle" by finalizing the aggregating transaction within the timeout deadline. The bounded nature of this scheme might allow correctly pruning "sub-nullifiers" from base layer nullifier sets to achieve property 6. Intermediate aggregation "checkpoints" can achieve property 7. Of course this is super hand-wavy and the devil's in the details.
Related
This exploration is largely inspired by imagining what zkrollup-like extensions of https://github.com/zcash/zcash/issues/4946 might be.
Opaque: The two cases of aggregating versus nonaggregating transactions are indistinguishable. Implication: onchain data cannot reveal the existence of an aggregator, in turn ensuring aggregation is a permissionless market.
This would require that aggregates support all of the functionality of unaggregated transactions, rather than a simplified subset. I think that is both too hard, and unnecessary.
An aggregating transaction can be created at any time to aggregate any set of transactions which aren't already finalized by consensus. Bug: Is this consistent with
There seems to be an incomplete sentence that I can't infer here.