译者：李荣强，公众号『确定性投资之路』作者。
译者按：当前 Zcash 有三个版本代号，一个是 Sprout， Sapling ，以及即将部署的 Halo 2。每个版本都有对应的代码和响应的匿名矿池地址，因此后续翻译时将直接使用这些代号。
我们很自豪地介绍 ZIP224 这个版本的功能，它提供了将 Halo 2 引入到 Zcash 网络的一个途径。
Halo 2 零知识证明系统，由 ECC 公司发明并开发，移除了初始信任设置，减少了 Zcash 协议攻击面，提高 ZEC 供应总量完整性的保证。
作为 Halo 2 零知识平台的第一个发布， 这将使得未来的环形升级不需要信任设定的仪式成为可能， 使得 Zcash 匿名协议能更加敏捷的适应未来的升级，比如发行其他的资产。
除此之外，当前版本打开了聚合证明和区块链简洁之路， 这两项扩展性的提升，使得 Zcash 协议能够与时俱进。
1、一个 Zcash 协议功能提案
Zcash 中的 Halo 2 部署的第一阶段引入了一个新的匿名交易协议， 这使得创建第一个匿名的转账能力不需要依赖与信任设定。
这个协议提供的功能，将会非常类似于来自 Sapling 版本提供的那样，然而，凭证系统将使用 Halo 2 技术栈。
这个发布包含了新的椭圆曲线周期，Pallas 和 Vesta 周期， 他们一起被称之为 Pasta 曲线。
Pasta 曲线， 一个新的加密结构，这是ECC持续努力的结果，以确保 Zcash 能够从突破性的密码学发明中尽可能地多收益，这些创新同时提高了安全性和性能。
Mir 协议 和 Mina 项目采用（之前的 Coda）已经采用了 Pasta曲线, 并且 Mina 已经为 Pasta 曲线在 Ledger 中集成，该集成已经被提交给 Zondax，以用于将来的 Zcash Ledger 集成。
开始在账本整合中派上用场，这已经被提交到 Zondax 中，供未来 Zcash 账本整合用。他们也被包含在 Arkworks Rust 库中。
这个 ZIP 发布包引入一个一个新的匿名地址格式，使用 Pasta曲线，和一个新的匿名池。
这个协议设计的特性和匿名特性是故意和 Sapling 版本保持同一，目的是为了限制技术上的风险，并且简化用户体验和易用性。
在新协议和实施准备就绪之前，将委托第三方进行审核，以增强对新协议和实施安全性的信心。
2、匿名池
如果这个协议被激活， 这个 ZIP发布将会为 Zcash 创建第三个匿名池，为了表示我们 Zk-SNARK 技术栈的连贯性，第一个匿名池被称为 Sprout， 第二个匿名池被称为 Sapling。
新的匿名池将会被一个匿名池十字旋转门保护着，正如这个旋转门的之前是为了在Sprout 和 Sapling 池之间过渡的那样。
我们将逐步淘汰旧的匿名池，这样的设计就使得我们可以部署新的匿名技术时，将秘密学和工程上的风险降到最低。
这鼓励我们迁移到一个无信任的证明系统当中，增强了人们对于Zcash 供应量合理性完整性的信任，同时降低了实现的复杂性以及 Zcash 的攻击面。
在 Canopy 网络升级过程中， 我们部署了 Zip 211，禁用往旧的 Sprout 匿名池中增加新币的功能。
类似的，在 Zip224 被激活之后，未来有新的网络要升级，我们的意图是部署 ZIP219，也会类似的禁用往旧的 Sapling 匿名池中添加新币功能。
当前这个 Sprout 匿名池往 -To-Sapling 匿名池迁移的工具将会被升级，从激活之后起将支持从 Sprout 匿名池到 Halo 匿名池的迁移，也支持从 Sapling 匿名池到 Halo 匿名池的迁移。
3、减少元数据泄露
考虑到 Sprout 和 Sapling 升级的过程中的一些经验， 当前这个zip包含了一些改变，目的是为了减少一部分未加密交易过程中元信息的泄露。
这一功能通过将输出和花费合并到一个互相无法区分的动作中，是通过对一个交易中的所有动作使用一个单一的锚来实现的。
4、Zcash 未来凭证
在 Sapling 版本中，当前激活的协议是 Grouth16， 最小但却是最高效的可验证的零知识证明构造。当前 Zcashd 中，这些证明容量小于 200 byte，单独验证一笔交易大约需要 7-10 毫秒。
对于我们当前使用的网络规模来说已经足够了，这个验证时间在网络延迟噪声容限内。
然而，即使在某种程度上，这还是不够的，尤其考虑到 Zcash 扩展性的一些使用场景当中，比如 UDA 用户自定义资产这个情景中。
当我们讨论，Zcash 中可接受的验证时间和交易容量大小时，数量级并不是成败的关键，然而我们需要的凭证是即能支持技术上的扩展性和可编程性，比如在凭证中承载数据。
这些技术允许凭证汇总在一起处理，并摊销凭证验证时间。从而使得每个交易的验证成本和交易容量大小以指数级减少。除了非常有限的情况之外，我们现有的凭证无法支持上述所有这些技术。
而我们在 Halo2 上实现的东西，不仅仅支持上面的这些技术操作，而这些操作是实现扩展性必不可少的工具，但是甚至是没有这些工具的情况下，我们现行凭证的大小和单一凭证的验证时间依然足以应对 Zcash 在短期内的使用。
通过移除对于初始信任设置的需要，当前 Zip 包即缓解了人们对于初始设定流程安全的担忧，也确保了在将来任何新的变动都不再需要这个 MPC 的信任设定仪式，比如引入 UDA （用户自定义资产，即发行新的 Token）特性。
这一特性使得这些更新将很容易在 Zcash 网络中实现， 同时还会降低未来升级的成本和风险以及时间。与当前的 Groth16ping 凭证相比，Halo依赖于更弱复杂性更低的密码学假设，后者依赖于基于配对的密码学。
即使没有紧急的原因使得我们对于 Zcash 网络当前使用的 BLS12-318 配对协议产生担忧，但是能够使用更低安全性的假设是欢迎的。
Zcash 的扩展性的实现，需要对 Zcash 当前彼此相关的协议进行大规模的重新设计，而不仅仅是在 Zcash 上实现 Halo 2那么简单。
Halo 2 将成为设计这些协议的核心组件。在不久的将来，我们将会利用 Halo 2 的特性通过交易聚合的方式去，减少链上带宽和验证时间。
最终，这些特性还可以使我们实现一个完全简洁的区块链，实现近乎实时的同步，对于轻量级客户端提供全节点级别的安全保证。
5、性能
从开发 Halo2 的那一刻起，我们就一直在努力的做着，以确保我们可以解决扩展性上的挑战以及移除信任设置，同时不会以任何有意义的方式降低性能。
从计算方面讲，我们相信 Halo 2 和Sapling比也有竞争力，甚至可能优于Sapling，即使交易量会更大。
此外，Halo 2 的积聚以及聚合功能，将使得我们在未来的可扩展版本中大大降低交易体积。
Halo 2 在匿名交易的构建相比于使用Groth 16凭证系统构而言会看起来有一点不同。Halo 2 无需像Groth 16 那样对每一个花费和输出描述创建几个单一的凭证，而是并行的创建所有的凭证，因此他们可以分摊交易体积和花费的时间。
只有单一凭证的交易粗略的计算有几 kb 大小，但是额外的凭证材料的边际大小要小的多，边际验证时间微不足道。
上述的这种匿名交易中可以包含数 kb 的备注数据，这并不意味对交易大小有显著的增加。单个线程验证一个单独的交易需要30毫秒的时间，对于单个凭证验证而言，比 Groth16 差一些。
但是与需要大量串行操作的 Groth16 凭证不同，我们的凭证完全可以并行的验证，并且可以根据可用线程数进行扩展。
Halo 2 中 只要 3-4 个线程并行处理，这个时候的性能接近 Groth16 的水平了，如果有更多线程，那 Halo 2 在 Zcash 网络中的表现会更加的优异。
6、具体实现
我们将针对不同类别用户加以说明，通常来说， 对于所有类型的使用者来说， 这个特性的升级增加了新的错误或者未预料到的设计上的瑕疵的风险， 这对于任何网络升级功能都是如此。
此外，由于 Sapling 仍将是活动池，因此在激活包含 ZIP 224 的网络升级时，不需要任何特定的操作项目即可继续使用 Sapling 地址或与 Sapling 匿名地址集成，而不是升级到 Zcashd 的支持版本或我们的移动钱包 SDK 。
那些直接依赖 Zcashd 或我们的钱包 SDK 的用户，以及对最终用户体验没有复杂需求的用户，应该有一个相对简单的实现。
（1）对于矿池运营人员
为了使用 新的 Zip224 的地址作为新的匿名地址， 运营人员仅仅需要在生成地址的时候响应的添加 -mineraddress 这个参数就行。
对于那些使用新的 Zip224 匿名地址作为收款人时，矿池运营人员不需要做任何改变即可发送。
（2）钱包供应商
那些使用我们 SDK 的钱包供应商，比如 NightHawk 和 Unstoppable 版本的人来说，只需要升级一下对应支持的版本就好，将会自动获得 Zip224 新发布的特性。用户界面代码中需要进行其他工作以容纳ZIP 224地址。
（3）交易平台和硬件钱包用户
交易所比如 Gemini 这样支持 Sapling 版本匿名提现地址的，将需要添加对 Zip224 格式地址的支持。Zondax 方面也需要对于 Ledger 整合的支持，然而 Mina 方面已经为使用 Pasta 曲线的项目做了支持，这将有助于 Zondax 的工作。
（4）开发者方面
ZIP 224 的实施得益于 ECC 的密码学工程专业知识，这是通过多个部署级别的 ZKP 技术产生的。
结合 ECC 在匿名地址钱包的 SDK 所作的努力， 我们相信这个更新的技术将会比当前 Zcash Sapling 版本的部署和整合上更加容易。
（5）当前 Zec 持币用户
对当前 Zec 持有人可以使用上文中提到的迁移工具或者现在在用的那个标准的转账机制将它们的资金迁移到新的匿名池中。
（6）区块链浏览器
区块浏览器必须更改他们处理 Zcash 总供应量计算的方式，并相对应的解析和显示有关 ZIP224 转账的详细信息。
原文链接：
https://electriccoin.co/blog/technical-explainer-halo-on-zcash/
作者：白话区块链；来自链得得内容开放平台“得得号”，本文仅代表作者观点，不代表链得得官方立场
凡“得得号”文章，原创性和内容的真实性由投稿人保证，如果稿件因抄袭、作假等行为导致的法律后果，由投稿人本人负责
得得号平台发布文章，如有侵权、违规及其他不当言论内容，请广大读者监督，一经证实，平台会立即下线。如遇文章内容问题，请发送至邮箱：linggeqi@chaindd.com
