zips icon indicating copy to clipboard operation
zips copied to clipboard

Ideal properties of an Opaque Delegated Aggregate Transaction (ODAT) scheme.

Open nathan-at-least opened this issue 4 years ago • 2 comments

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

  1. ODAT transactions allow the functionality of existing (ex: Sapling, Orchard) shielded transfers or the aggregation of some number of subtransactions.
  2. 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.
  3. Delegated: The aggregated subtransactions may be issued by different parties from each other and from the aggregator.
  4. Subtransactions may spend outputs of other subtransactions within the same aggregation unit. An aggregating transaction is associated one-to-one with an aggregation unit.
  5. 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
  6. 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.
  7. 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.
  8. 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.

nathan-at-least avatar Mar 11 '21 00:03 nathan-at-least

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.

daira avatar Mar 17 '21 02:03 daira

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.

daira avatar Mar 17 '21 02:03 daira