Zcash Orchard Shielded Protocol
1. 引言
在Zcash Orchard shielded protocol中，定义了新的shielded pool，其spending key和paymentaddress 可满足未来的扩展性改进。
2. 背景介绍
Zcash目前有2个active shielded protocols和相应的shielded pools：
- Sprout shielded protocol (在Zerocash 论文基础上做了相应的性能和安全改进)。自2021年2月起，Sprout shielded pool将进入closing状态，不再有新的ZEC注入。
- Sapling shielded portocol，其中做了大量功能和性能的大幅改进，自2021年2月起，仍为active shielded pool。
Sprout shielded protocol和Sapling shielded protocol存在以下两方面的问题：
- Sprout和Sapling 都无法与现有的efficient scalability技术兼容。
Recursive zero-knowledge proofs （其中 a proof verifies an earlier instance of itself along with new state） 若想用在Zcash上，需要a cycle of elliptic curves。
而Sprout protocol中没有使用elliptic curves，因此本质上来说其若在circuit中实现效率将很低；
Sapling protocol中使用了elliptic curve，但是目前无法基于该curve来构建an efficient curve cycle。 - Sprout和Sapling中的circuit使用的Groth16 proving system，需要 trusted setup：即circuit参数为 Structured Reference String (SRS) with hidden structure，若该hidden信息被泄露，则可伪造proof从而伪造资金。这些circuit参数是基于MPC来生成的——只要参与方中有一方是honest且未拖鞋，则该hidden structure是不可恢复的。MPC协议近年来一直在改进（如在Sprout MPC中只有6个参与方，而在2年后的Sapling MPC中每轮有90个参与方）。但是基于MPC方案trusted setup SRS就协议本身来说是一个风险点。如，在Sprout circuit (BCTV14)中的proving system中存在一个bug，使得Sprout shielded protocol容易被伪造，这就需要对该proving system进行改进，从而需要run a new MPC。
基于以上问题，需设计a new shileded protocol around a curve cycle，使得该proving system 既可满足recursion的需求，又不再需要SRS——Orchard Shielded protocol。
Orchard protocol需根据 Zcash Protocol Specification 中的设计来实现。
3. Orchard protocol的特别说明
Orchard protocol最大程度遵循了Sapling protocol的设计，以下仅关注相关差异。
3.1 curves
在Orchard protocol中使用了 Pallas / Vesta curve cycle，来替代Sapling中的BLS12-381和embedded curve Jubjub：【详细的安装证明见 Pallas/Vesta supporting evidence】
- Pallas：为application curve，来替代Jubjub。
- Vesta：为circuit curve，其scalar field为Pallas的base field。替代BLS12-381，其scalar field为“word” type。
Orchard中采用“simplified SWU”算法来定义infallible GroupHash，来替代Sapling中的 fallible BLAKE2s-based mechanism。“simplified SWU”算法 遵循 IETF hash-to-curve Internet Draft (Version 10) 规范。（但在任何不一致的情况下，协议规范优先）
采用curve cycle是一个明确的设计选择。在Orchard中，仅使用了half of the cycle (Pallas为an embedded curve of Vesta)，full cyle期待与在未来协议更新时能用上。
3.2 Proving system
Orchard采用：
- Halo2 proving system来替代Groth16；
- UltraPLONK arithmetization (UPA) 来替代 R1CS。
在Orchard proposal中并未使用Halo2来支持recursive proof，但是期待在未来协议更新时会用上。
3.3 Circuit
Orchard对于spend和output采用的相同的circuit，与Sprout类似。
在“action”中包含：
- a single (possibly dummy) note being spent
- a single (possibly dummy) note being created
在一个Orchard交易中，包含了一堆actions，且仅需一个Halo2 proof就可证明该一堆actions。
- action transfer及action description
- circuit statement
- action 设计原理
3.4 Commitments
Orchard protocol中采用了与Sapling中等价的commitment scheme。对于Sapling中的non-homomorphic commitment——Bowe-Hopwood Pedersen hashes，Orchard采用了UPA-efficient Sinsemilla替代。
- Sinsemilla hash函数
- Sinsemilla commitments
- commitment 设计原理
3.5 Commitment tree
Orchard采用了与Sapling相同的commitment tree structure，只是实例化时用Sinsemilla替代了Bowe-Hopwood Pedersen hash。
- commitment tree 设计原理 及其它替代方案
3.6 Keys and addresses
Orchard的keys和payment addresses结构与Sapling类似，主要做了以下调整：
- 移除了proof authorizing key，且 n k nk nk是a field element。
- i v k ivk ivk 由BLAKE2s计算改为由Sinsemilla commitment 计算。
- o v k ovk ovk 派生自 f v k fvk fvk， o v k ovk ovk不再是spending key的一部分。
- 所有的diversifiers都可产生有效的payment addresses。
Orchard的keys和payment addresses 采用Bech32来encode。在Zcash主网中：
- Orchard地址以“zo”为前缀；
- Sapling地址以“zs”为前缀；
- Sprout地址以“zc”为前缀。
Orchard keys以hierchical deterministic (HD)的方式派生，不再适配Sapling ZIP 32的HD机制，相反，Orchard中定义了一种类似Sprout的hardened-only derivation mechanism：
- Sapling中的key components：
- HD key派生说明
- Orchard keys和addresses 设计原理
3.7 Notes
Orchard notes的结构为 ( a d d r , v , ρ , ψ , r c m ) (addr, v,\rho,\psi,rcm) (addr,v,ρ,ψ,rcm)，其中：
- ρ \rho ρ 为the nullifier of the spent note in the same action，其具有唯一性。
- ψ \psi ψ和 r c m rcm rcm 派生自a random seed。【该seed与Sapling ZIP 212 类似】
3.8 Nullifiers
Orchard notes的Nullifiers的计算方式为：
n f = [ F n k ( ρ ) + ψ ( m o d p ) ] G + c m nf=[F_{nk}(\rho)+\psi (\mod p)]\mathcal{G}+cm nf=[Fnk(ρ)+ψ(modp)]G+cm
其中：
- F F F以Poseidon hash 函数 的方式实现。
- G \mathcal{G} G 为a fixed independent base。
3.9 Signatures
Orchard采用的RedPallas签名机制（RedDSA instantiated with the Pallas curve）来替代Sapling中的RedJubjub签名机制（RedDSA instantiated with the Jubjub curve）。
4. Orchard中的其它基本原理
提出新shielded protocol and pool的主要动力在于：
- 需可将spend authority迁移至a recursion-friendly curve。
Sapling中的Spend authority是基于Jubjub curve的，但是目前没法基于Jubjub或BLS12-381构建an efficient curve cycle。
不过在当前的设计目标中，除了具备recurision-friendliness之外，并未实现recursive protocol。因为在单次升级中部署整个scaling方案的风险 远远要大于 逐步分阶段部署实现。
Orchard当前主要关注curve cyle和proving system。
5. 安全和隐私考量
Orchard protocol中定义了新的shielded pool。
与Sapling类似，Orchard protocol中仅支持花费Orchard notes，通过valueBalanceOrchard transaction field来讲ZEC 移进或移出 the Orchard pool。
主要基于以下考虑：
- Orchard pool形成了与Sprout pool和Sapling pool 不同的anonymity set 。该新的Orchard pool初始为0 notes（Sapling部署时也是初始化为0），但是，由于Orchard actions中的arity-hiding属性，Orchard交易将increase the size of the anonymity set more rapidly than Sapling。
- 通过 由
valueBalanceOrchardfield创建的“transparent turnstile” 与 the consensus checks that each pool’s balance cannot be negative 结合，将有效防范Orchard protocol中潜在的造假漏洞，以及现有shielded pools中的潜在造假漏洞也不会影响Orchard pool。 - 将Orchard pool中的金额花费至非Orchard address，将会揭露交易的金额，这是transparent turnstile的necessary side-effect，但是，可通过将大部分shileded活动迁移至Orchard pool并尽可能减少这类交易来环境。这些情况下，钱包在传输其交易中创建的UX时，需揭露相应的金额。
【钱包应补助迁移其user bases来store funds uniformly within the Orchard pool。钱包支持多个pools的相关实操内容见 Best Practices for Wallet Handling of Multiple Pools】
6. 相关代码实现
相关代码实现有：
- https://github.com/zcash-hackworks/zcash-test-vectors/pull/14
- https://github.com/zcash/halo2
- https://github.com/zcash/orchard
参考资料
[1] ZIP-224 Orchard Shielded Protocol
[2] [ZIP 224] Orchard (provisional name) Shielded Protocol