diff --git a/zip-0224.html b/zip-0224.html index bf56913b..cacd8329 100644 --- a/zip-0224.html +++ b/zip-0224.html @@ -61,30 +61,30 @@ Discussions-To: <https://g

Proving system

-

Orchard uses the Halo 2 proving system 23 with the PLONKish arithmetization [#halo2-arithmetization], instead of Groth16 and R1CS.

+

Orchard uses the Halo 2 proving system 23 with the PLONKish arithmetization 22, instead of Groth16 and R1CS.

This proposal does not make use of Halo 2's support for recursive proofs, but this is expected to be leveraged by future protocol updates.

Circuit

Orchard uses a single circuit for both spends and outputs, similar to Sprout. An "action" contains both a single (possibly dummy) note being spent, and a single (possibly dummy) note being created.

An Orchard transaction contains a "bundle" of actions, and a single Halo 2 proof that covers all of the actions in the bundle.

Commitments

The Orchard protocol has equivalent commitment schemes to Sapling. For non-homomorphic commitments, Orchard uses the PLONKish-efficient Sinsemilla in place of Bowe–Hopwood Pedersen hashes.

Commitment tree

Orchard uses an identical commitment tree structure to Sapling, except that we instantiate it with Sinsemilla instead of a Bowe–Hopwood Pedersen hash.

Keys and addresses

@@ -105,14 +105,14 @@ Discussions-To: <https://g , instead of being a component of the spending key.
  • All diversifiers now result in valid payment addresses.
    • -

    There is no Bech32 encoding defined for an individual Orchard shielded payment address, incoming viewing key, or full viewing key. Instead we define unified payment addresses and viewing keys in 32. Orchard spending keys are encoded using Bech32m as specified in 20.

    +

    There is no Bech32 encoding defined for an individual Orchard shielded payment address, incoming viewing key, or full viewing key. Instead we define unified payment addresses and viewing keys in 32. Orchard spending keys are encoded using Bech32m as specified in 20.

    Orchard keys may be derived in a hierarchical deterministic (HD) manner. We do not adapt the Sapling HD mechanism from ZIP 32 to Orchard; instead, we define a hardened-only derivation mechanism (similar to Sprout).

    Notes

    @@ -123,9 +123,9 @@ Discussions-To: <https://g \(\psi\) and \(\mathsf{rcm}\) - are derived from a random seed (as with Sapling after ZIP 212 30).

    + are derived from a random seed (as with Sapling after ZIP 212 30).

    Nullifiers

    @@ -139,14 +139,14 @@ Discussions-To: <https://g \(\mathcal{G}\) is a fixed independent base.

    Signatures

    Orchard uses RedPallas (RedDSA instantiated with the Pallas curve) as its signature scheme in place of Sapling's RedJubjub (RedDSA instantiated with the Jubjub curve).

    @@ -166,7 +166,7 @@ Discussions-To: <https://g field, combined with the consensus checks that each pool's balance cannot be negative, together enforce that any potential counterfeiting bugs in the Orchard protocol or implementation are contained within the Orchard pool, and similarly any potential counterfeiting bugs in existing shielded pools cannot cause inflation of the Orchard pool.
  • Spending funds residing in the Orchard pool to a non-Orchard address will reveal the value of the transaction. This is a necessary side-effect of the transparent turnstile, but can be mitigated by migrating the majority of shielded activity to the Orchard pool and making these transactions a minority. Wallets should convey within their transaction creation UX that amounts are revealed in these situations.
    • diff --git a/zip-0224.rst b/zip-0224.rst index ba8927ac..13885530 100644 --- a/zip-0224.rst +++ b/zip-0224.rst @@ -108,7 +108,7 @@ Proving system -------------- Orchard uses the Halo 2 proving system [#halo2-proving-system]_ with the PLONKish -arithmetization [#halo2-arithmetization], instead of Groth16 and R1CS. +arithmetization [#halo2-arithmetization]_, instead of Groth16 and R1CS. This proposal does not make use of Halo 2's support for recursive proofs, but this is expected to be leveraged by future protocol updates.