Zcash Orchard Shielded Protocol

最新推荐文章于 2023-11-27 14:41:00 发布

mutourend

最新推荐文章于 2023-11-27 14:41:00 发布

阅读量466

点赞数

分类专栏： Zcash

本文链接：https://blog.csdn.net/mutourend/article/details/116043419

版权

Zcash 专栏收录该内容

17 篇文章 3 订阅

订阅专栏

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。

3.4 Commitments

Orchard protocol中采用了与Sapling中等价的commitment scheme。对于Sapling中的non-homomorphic commitment——Bowe-Hopwood Pedersen hashes，Orchard采用了UPA-efficient Sinsemilla替代。

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$ 是a field element。
$i v k$ 由BLAKE2s计算改为由Sinsemilla commitment 计算。
$o v k$ 派生自 $f v k$ ， $o v k$ 不再是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：

3.7 Notes

Orchard notes的结构为 $v,\rho,\psi,rcm)$ ，其中：

$\rho$ 为the nullifier of the spent note in the same action，其具有唯一性。
$\psi$ 和 $r c m$ 派生自a random seed。【该seed与Sapling ZIP 212 类似】

在这里插入图片描述

3.8 Nullifiers

Orchard notes的Nullifiers的计算方式为：
$nf=[F_{nk}(\rho)+\psi (\mod p)]\mathcal{G}+cm$

其中：

$F$ 以Poseidon hash 函数的方式实现。
$\mathcal{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。
通过由valueBalanceOrchard field创建的“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】