Shielded aidrop discussion space

Protocol Design
1

Intro and context

Context:

In brief, the first iteration of the protocol (which is worth reading to have a good understanding of the problem space) constructed a transaction the linked together an input zcash note and an output MASP note on a 1:1 ratio using the convert circuit.
To do so, we where creating a spend circuit on zcash, which was never going to be posted on the zcash chain, and would have acted as a proof of holding shielded assets. After a conversation with ZCash cryptographers, we realized that this approach was publishing the nullifier of a zcash note before said note had been spent: a likability issue between note commitment and its nullifier will arise when the note will be spent.

To come around this problem, a claim circuit is introduced. The claim circuit, seen on the github page, acts as a spend circuit, but without ever revealing the nullifier of the zcash note used for the claim. It works with a non-membership proof, that proves that a private witness nullifier is not among the public set of relieved nullifiers.

A transaction is then made of:

  • Claim description
  • Covnert description
  • Output description

Similarly on how a transaction with using the convert circuit happens.

Challenges

  • Protocol Implementation: the implementation of the protocol would be complex, as it involves writing novel circuits, transaction structures and signatures which have to be written from scratch. On the other hand there are libraries that can be used as blueprint model (zcash sapling, MSAP).
  • Protocol integration: once the protocol is implemented and a working API has been set in place, a pipeline that involves zcash wallets, namada validity predicates (which could be on-chain or off-chain) would need to put in place. It would define where the airdrop transaction is created and how it gets validated.
  • Orchard: a lot of shielded assets are kept in the Orchard pool, which is written in halo2. I am currently researching the feasibility of having a convert circuit that can bundle together in a transaction an Orchard note with a MASP note. In my current understanding it would involve writing circuits for JubJub curve (the sapling curve) operations in halo2.The challenge lies mostly in the value balance check, as the pederson commitments for the value commitment are not homomorphic when they are computed on different curves. On the other hand, we could have a validity predicate that host verifiers in both groth-16 (masp) and halo2 (orchard).
  • MASP transparent balance: talking to Marco we realized that the shielded airdrop increases the value of the MASP pool without increasing its transparent balance, which can cause funds to get stuck in the MASP. A naive solution to this problem would be to increase the MASP transparent balance by the total amount of the balance of the zcash pool. Different solutions should be researched, keeping in mind the the value of the claim airdrop can not be leaked.

First to-dos (2-3 weeks)

  • Research Orchard-MASP compatibility and evaluate complexity of the problem. I think this should be the first to do, because it can have an impact on how we abstract the protocol specification and modularization of the problem, vs a monolithic spec that is Groth16 through and through.
  • Write a fully descriptive specs of the protocol.

Other usage outside airdrop

It would be interesting to see if this protocol can open up to further applications other than a shielded airdrop that can increase the utility of the MASP and Namada chain in general for zcash holders.

1 Like
2

A roadmap for compatibility with Orchard shielded pool

We can think of another circuit that can allow holders of shielded zcash assets in the Orchard pool to claim a shielded airdrop reward.

It would be an Equivalence Statement that can prove that the same value is being used in two different value commitments: a \mathsf{HomomorphicPedersenCommit_{rcv}^{Sapling}(D,v)} in Sapling and a \mathsf{HomomorphicPedersenCommit_{rcv}^{Orchard}(D,v)} in Orchard. The equvalence statement could be either an Halo2 or Groth16 circuit, but we can think about writing it in Halo2.

Statement outline

We can think of an halo2 arithmetic circuit that has as public input:

  • A rappresentation of the Sapling Value Commitment as point in the Pallas curves
  • A Orchard Value Commitment

as private input:

  • the value that is used for both commitments

The would claim that both commitments were constructed using the same value.

Usage in the transaction

The transaction would then be made of:

  • Claim description (in Orchard/Halo2)
  • Output description (for MASP/Groth16)
  • Convert description (as the other shielded transactions)
  • Equivalence description (which would have inside the Equivalence Statement)

The transaction would be work as the other airdrop transactions, using the Sapling value commitment that has been proved to be equivalent to the Orchard value commtiment in the Covert Description and most importantly in the Balance and Binding signature scheme.

In practice, an actor would compute locally and out of circuit the equivalent Sapling Value commitment to the Orchard value commitment present in the Orchard Note which they are using in the Claim Description and prove that these commitments have to the same value inside.

Cuircuit functioning

The circuit would:

  • Perform a Perdesen commitment as it is done Sapling using the private input value
  • Perform a Pedersen commitment as it is done in Orchard using the private input value
  • Check that the Pedersen commitments match the public inputs.

Implementation challenges

The Equivalence circuit would be small, so there are no issues with long proving times. However, its implementation requires some preparation work. The challenge here is that we would be implementing a circuit that does non-native field arithmetic, namely simulates the filed arithmetics and curve operations that are done using JubJub and BLS12-381 curve into an Halo2 circuit, which uses the Pasta curves. Before starting to implement the circuit we would have to:

  • Find a way to rapresent JubJub points in Pasta curves
  • Write an Halo2 gadget that perform the needed non-native field operations in Pasta
  • Write an Halo2 gadget that perform the JubJub curve operations

This background work has the perk of being self-contained and independent from airdrop protocol itself. With these things in place, the circuit for the Equivalence Statement should not be a complicated halo2 circuti to write.

Thanks @xuyang for the useful (as always :slight_smile: ) discussion.

2 Likes
3

From today’s conversation @camofu @cwgoes:

Carlo’s original plan:

  • Write down a document that describes the architectural changes and the non-native arithmetic involved.
  • Write gadgets of elliptic curves operations in Halo2.
  • Write “equivalence circuit”.

Feedback:

  • Avoid implementing anything until getting feedback from the Zcash team
  • Communicate plan roughly for Zcash cryptographers (e.g. in a Zcash forum) for them to evaluate the proposal.
  • Low priority for testnet (airdrop will take place somewhere in 2025).
  • We are not trying to share specs with the Zcash team, but an architectural sketch.

Goal:

  • Share a sketch of the protocol that is more precise and more descriptive than the current draft.
  • Generalise a transaction

Estimate:

  • End of next week

@camofu Can you share what it means to generalise a transaction in this case?

1 Like