Shielded airdrop complexity evaluation

[cwgoes]

Suppose that we want to enact an instantaneous evaluation as described here, and hook this up to the pre-genesis process, such that:

1. We would copy the Zcash Sapling commitment tree root from a specific Zcash block height.
2. This root would be embedded in the genesis tooling.
3. Users would generate a convert circuit proof converting this note into a note of shielded NAM.
4. These notes of shielded NAM would be included in the genesis block proposal.

How difficult would this be to implement? A few possible concerns that I see:

• we've added asset types, does this change note/commitment formats in significant ways (would this make just "copying the Sapling state" difficult)?
• users will need to make ZKPs during the genesis process, similar ones to spending their ZEC notes - does this introduce security risks, and what does the zcash key/wallet ecosystem look like?

[joebebel]

From a purely technical perspective, combining sapling state with the other circuits is easy to do, there would just need to be a flag in the prover/verifier for each statement/proof which indicates the "type" and ultimately the correct crate is called for each statement. The convert circuit is agnostic to where the value commitment comes from (although the out of circuit code might need some minor work to get the sapling value commitment into it). for the most part, it doesn't seem like there's much (if any) additional cryptographic complexity. For the concerns, each note type and each commitment type must be kept separate, as in one type of note commitment cannot be treated as a different type (both that the code should prevent wrong behavior, and also that there is domain separation of different data hashes). The Convert circuit itself doesn't know anything about differences between types, so it can take value commitments of arbitrary type. The nullifiers would be revealed as part of each spend statement.

[cwgoes]

Work moved to a separate discussion & repository.