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,且nknknk是a field element。
  • ivkivkivk 由BLAKE2s计算改为由Sinsemilla commitment 计算。
  • ovkovkovk 派生自fvkfvkfvkovkovkovk不再是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的结构为(addr,v,ρ,ψ,rcm)(addr, v,\rho,\psi,rcm)(addr,v,ρ,ψ,rcm),其中:

  • ρ\rhoρ 为the nullifier of the spent note in the same action,其具有唯一性。
  • ψ\psiψrcmrcmrcm 派生自a random seed。【该seed与Sapling ZIP 212 类似】


3.8 Nullifiers

Orchard notes的Nullifiers的计算方式为:
nf=[Fnk(ρ)+ψ(modp)]G+cmnf=[F_{nk}(\rho)+\psi (\mod p)]\mathcal{G}+cmnf=[Fnk(ρ)+ψ(modp)]G+cm

其中:

  • FFF以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。
  • 通过 由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】

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

Zcash Orchard Shielded Protocol相关推荐

  1. Zcash中的Notes

    1. 引言 本文主要关注Sapling note. Zcash中Sapling note以n\mathbf{n}n表示,其代表a value vvv is spendable by the recip ...

  2. Zcash halo2 背后技术衍化介绍

    1. 引言 自2019年起,ECC团队就在为2021年Zcash的扩展性进行了相关预研,最主要的研究成果就是Halo,作为一种新型的zk-SNARK方案,其解决了Zcash中的2个主要问题: 在保证了 ...

  3. Rollup项目的SNARK景观

    1. 引言 前序博客有: SNARK Design 主要参考Justin Thaler 2022年8月在a16z crypto专题研讨会上的系列讲座: SNARK Design, Part II, w ...

  4. POSEIDON: A New Hash Function for Zero-Knowledge Proof Systems 学习笔记

    1. 引言 Grassi等人2019年论文<POSEIDON: A New Hash Function for Zero-Knowledge Proof Systems>. 前序博客有: ...

  5. 零知识证明学习笔记:背景与起源

    副标题:斯坦福学霸的零知识证明学习笔记(一) 本文作者东泽,来自安比技术社区的小伙伴,目前就读于斯坦福大学,研究方向密码学,本系列文章来源于作者在斯坦福著名的课程<CS 251: Cryptoc ...

  6. ZLiTE Lightweight Clients for Shielded Zcash Transactions using Trusted Execution

    ZLiTE: Lightweight Clients for Shielded Zcash Transactions using Trusted Execution 论文:Cryptology ePr ...

  7. Zcash中的signatures

    1. 引言 在 Zcash Protocol Specification 中,约定对signature是"validate",对zk-SNARK proof是"verif ...

  8. Zcash中的加解密机制

    1. 引言 接前序博客 Zcash中的Notes. Sapling note的组成为tuple n=(d,pkd,v,rcm)\mathbf{n}=(d, pk_d, v, rcm)n=(d,pkd​ ...

  9. Zcash中的description

    1. 引言 Zcash 中支持的description类型有: JoinSplit description Spend description Output description JoinSplit ...

最新文章

  1. .Net中如何操作IIS(源代码)
  2. MediaCodeC解码视频指定帧,迅捷、精确
  3. webpack+react多页面开发架构
  4. 两个人投票的c语言程序,设计网页投票器(二)《精通Unix下C语言编程与项目实践》之十...
  5. 浅谈网络游戏的设计——服务器端编程 (2)
  6. 广州市出租车GPS数据(20210127)
  7. 企业供应链管理架构图
  8. 删除360UDiskGuardXX.dll
  9. DELL戴尔开启/关闭触摸板方法
  10. 如何得到信号的幅度谱和相位谱
  11. Crosses and Crosses POJ - 3537 (博弈)
  12. 对待新知识、新领域的心态——好奇、批判、独孤求败
  13. 用友U8供应链期初数据录入案例教程2
  14. Python Web 开发中 Excel 转 PDF 文件
  15. Python报错:local variable referenced before assignment
  16. 问题 D: 零起点学算法89——程序设计竞赛
  17. 【台大郭彦甫】Matlab入门教程超详细学习笔记四:数据类型与文件读写(附PPT链接)
  18. c# Thumbnail 生成缩略图,生成压缩图,最大宽高比例缩放,最大边按比例缩放
  19. 剑网三服务器一直未响应,《剑网3》大师赛第二个比赛日赛后采访回顾
  20. 实现海康监控视频播放(录像回放)(抓拍,录像等功能)

热门文章

  1. 驻足回首,二十载已沧海桑田;登高望远,路漫漫亦求索不息
  2. LWN:关于readahead的讨论!
  3. EntityWrapper的in用法
  4. A*- not a star in the space, it's on you hands
  5. Ubuntu12.04启动时显示“超出频率范围”的解决方法
  6. PHP基础之基本语法大全
  7. OpenGL基础图形编程(八)变换
  8. MongoDBC++开发(四)bsoncxx::builder::stream::document的增删改查操作
  9. 实现上一篇,下一篇的效果
  10. Consul安装使用