Orchard-ZSA reference implementation

[PaulLaux]

This PR implements draft ZIP 226 (Transfer and Burn of Zcash Shielded Assets) and draft ZIP 227 (Issuance of Zcash Shielded Assets).

• Burning mechanism: the ability to publicly burn ZSA notes. This is done by adding a burn field inside the Orchard bundle and the ability to utilize it. In addition the changes to bvk and bsk to support this change. See ZSA burn functionality QED-it/orchard#35 for a full list of changes.

/// A bundle of actions to be applied to the ledger.
#[derive(Clone)]
pub struct Bundle<T: Authorization, V, D:  OrchardDomainCommon> {
    /// The list of actions that make up this bundle.
    actions: NonEmpty<Action<T::SpendAuth>, D>,
    /// Orchard-specific transaction-level flags for this bundle.
    flags: Flags,
    /// The net value moved out of the Orchard shielded pool.
    /// This is the sum of Orchard spends minus the sum of Orchard outputs.
    value_balance: V,
    /// Assets intended for burning
    burn: Vec<(AssetId, V)>,
    /// The root of the Orchard commitment tree that this bundle commits to.
    anchor: Anchor,
    /// The authorization for this bundle.
    authorization: T,
}

• Note Encryption: We extended the Domain trait in the zcash_note_encryption crate to support various lengths for COMPACT_NOTE_SIZE by converting the relevant constants into trait-specific types. Later, implemented OrchardDomainV3 to support the new note structure.
• Updated the Python implementation to support the changes. See Testing encryption v3 QED-it/zcash-test-vectors#6 and the zsa1 branch for details.

Also included:

• To avoid the ambiguity of the word "type", note_type was renamed to asset of type assetID.
• Test vectors for AssetID derivation AssetID test vectors QED-it/orchard#34
• Split note mechanism.
• Circuit changes to support AssetID, split notes, and all other new functionality.
• Backward compatibility for Orchard Bundles

The proposed changes should be considered a draft, not a final version.

[nuttycom]

@str4d and I had an extensive discussion about this type in a pairing. Our conclusion is that parameterizing the Bundle type via the D parameter causes the downstream code that consumes Orchard bundles to be exposed to details about note encryption that are too low-level for the consumer. Also, the fact that we are parameterizing with D but are not fully concretizing the contents of the bundle relative to that parameter enables the representation of mixed states (e.g. D = OrchardVanilla but with burn nonempty) that we do not want to exist.

Instead, there should be separate Bundle and BundleZsa types; this then means that:

• the OrchardDomainCommon type may not need to exist, and we can use separate implementations of zcash_note_encryption::Domain.
• the new fields, expiry_height and burn will only exist in the BundleZsa type.

The Action type then doesn't need to be parameterized by the domain type; it can just be parameterized by the type of the enc_ciphertext, and each Bundle type can concretely set this to a ciphertext type that directly matches what is used in the domain. This will facilitate the memo changes from ZIP 231 (for which the concrete length will be different than at present, and for which zcash_note_encryption::Domain::Memo will be set to the type of the memo key.)

At the top level, what we will do is route scanning of V6 transaction outputs into one batch decryptor, and scanning of V5 outputs into a separate batch decryption.

[PaulLaux]

Actually, having the parameter D does not expose much detail to the downstream consumer (unless explicitly requested).
The consumer have either

let bundle: Bundle<_, _, Orcahrd> = ...

Or

let bundle: Bundle<_, _, OrcahrdZSA> = ...

and can proceed with the Bundle<_> operations. But this almost never happens since most of the handling is unified. (We have it mostly in tests.)

The major consideration for this type of parametrization is clean code reuse: in most cases Bundle<_,_,Orchard> and Bundle<_,_,OrchardZSA> are treated the same and we can have nice abstraction in the form of

    let bundle: Bundle<_, i64, D> = builder.build(rng);
    bundle
        .create_proof(&pk, rng)
        .unwrap()
        .apply_signatures(rng, [0; 32], &[])
        .unwrap()

In critical places like

pub fn build<V: TryFrom<i64>, D: OrchardFlavor>(
        self,
        rng: impl RngCore,
    ) -> Result<Bundle<InProgress<Unproven, Unauthorized>, V, D>, BundleMetadata), BuildError> {

or

 pub fn prepare<R: RngCore + CryptoRng>(
        self,
        mut rng: R,
        sighash: [u8; 32],
) -> Bundle<InProgress<P, PartiallyAuthorized>, V, D> {

or

pub fn apply_signatures<R: RngCore + CryptoRng>(
        self,
        mut rng: R,
        sighash: [u8; 32],
        signing_keys: &[SpendAuthorizingKey],
) -> Result<Bundle<Authorized, V, D>, BuildError> {

among many others.

Later it is propogated Action:

fn build<D: OrchardDomainCommon>(
        self,
        mut rng: impl RngCore,
) -> (Action<SigningMetadata, D>, Witnesses) {

Where also most of the logic is shared between an Orchard action and an OrchardZSA action.

All while the difference between the Bundles or the Actions is encapsulated inside OrchardFlavor and called transparently by the consumers.

All while fully supporting backward compatibility.

Removing the parameter D and creating two different types will obliterate all these nice properties, and the code will be harder to maintain and harder to reason about, as most of the logic for both is the same.

That being said, we can change the handling for the note encryption part to align with ZIP 231 once it is done and we can have it (or we can do it on top).

Also, the burn handling can be changed to have a dedicated empty type for Orchard and non-empty type for OrchardZSA as we did for Zebra's ShieldedData:

pub struct ShieldedData<FL: Flavor> {
   ...
    /// Assets intended for burning
    /// Denoted as `vAssetBurn` in the spec (ZIP 230).
    pub burn: FL::BurnType,
}

Forcing the burn to be empty for Orchard.

Other solutions for Burn and note encryption are also possible.

However, we strongly recommend keeping the D parameter for Bundle for the reasons mentioned above.