原文标题：《引介 | Zk Sync：以太坊大规模采用的必要环节》
原文来源：Unitimes
内容摘要
一个成功的公链扩展性解决方案不仅需要带来高交易吞吐量，它还需要具有这样的能力：系统能够在不牺牲去中心化的特性下满足百万用户的需求。加密货币大规模采用的先决条件包括：快速，低成本，流畅的用户体验以及隐私保护。
在没有技术突破的情况下，已有的扩容方案不得不对这些要求中的一个或多个作出重大妥协。幸运的是，零知识证明的最新进展为解决这个问题开辟了全新的可能性。
今天，我们在 Matter Labs 很兴奋地展示我们对 ZK Sync 的愿景：一个基于 ZK Rollup 的以太坊的无需信任的扩容及隐私解决方案，同时强调一流的用户及开发者体验。我们也很荣幸地宣布 ZK Sync 的 devnet 的发布。
ZK Sync 旨在为以太坊带来 Visa 级别的数千笔交易/秒（TPS）的吞吐量，并同时保证资金如同底层 Layer 1 账户般安全并维持高度的抗审计性。协议的另一个重要方面是它的超低延迟：ZK Sync 中的交易会提供即时经济终结性 (instant economic finality)。
我们认可一个简洁的设计哲学以及渐进式的协议演进，逐一引入新特性，每一步都为用户带来最实际的价值。这就是我们为什么从基石（安全性）开始，首先关注基本的可扩展性（代币转移），然后关注可编程性（智能合约），以及最后关注隐私的原因。
区块链扩容最棘手的问题
当前，实际上加密货币仍然主要用于投机。如果没有真正的大规模采用，这些神奇的互联网货币、DeFi、Web3.0 以及其他所有有前景的区块链创新的价值主张将会在很大程度上不能得到实现。
可扩展性不仅仅是关乎交易吞吐量，而且是关乎区块链系统是否为满足百万用户的需求做足了充分的准备。
让我们来考虑一下将区块链革命扩张至大众采用所面临的最困难的三个问题。
挑战 #1：保持去中心化
要实现现实世界的采用，区块链需要带来比当前最去中心化的区块链还要高出一个数量级的交易吞吐量。比特币能够达到 7 TPS，以太坊勉强达到 15 TPS，而仅 Visa 大体上可以处理惊人的 2000 TPS。
但是比特币和以太坊的慢是一个特性而不是一个 bug！通过减少验证者的数量来提高速度的可能性是微乎其微的。业界领先的区块链网络所夸口的众多全节点是这些网络最关键的资产。这提供了弹性，而这实际上使区块链从根本上不同于现有的金融机构。
另一种流行的扩容方法是要求每个验证者仅仅检查相关区块链的一部分而不是全部的流量。但这不可避免地引入了额外的信任假设以及将此类系统放置于一个非常不可靠的博弈论基础之上。
挑战 #2：实现隐私保护
大多数人都不愿意把他们的大部分财产转移至一个公开透明的玻璃盒里。如果收款人能够立即知道付款人有多少钱，那么高风险地区（如委内瑞拉）的居民是不可能会使用加密货币给当地商家付款的。如果付款记录能够链接到付款方在现实世界的身份，那么创建和消费色情内容的人将不太可能把加密货币作为 Paypal 的替代品。
此外，在缺乏链上保密的情况下，那诸如 GDPR (欧盟通用数据保护条例) 和 CCPA (加州消费者隐私法案) 这样的隐私法规将促使普通企业从公有区块链转向更加中心化的支付和金融中心，把我们日益无现金化的社会转变成一场监管噩梦。
隐私是大规模采用的绝对前提。
但由于以下几个因素，在公有区块链上实现隐私保护是极其困难的：
隐私保护必须作为一个完整协议特性被默认启用。引用 Vitalik Buterin 的话：「如果你的隐私模型拥有一个中等规模的匿名集合，那么你实际上有一个小规模的匿名集合。如果你的隐私模型拥有一个小规模的匿名集合，那么你仅仅拥有一个大小为 1 的匿名集合。只有全局性的匿名集合才是真正可靠安全的。」
为了默认启用隐私保护，尽管计算成本会明显地增大，但隐私交易的成本一定要十分低。
隐私模型必须支持可编程性，这是因为现实世界的用例需要的不仅仅是转账：这些隐私模型还需要账户恢复，多重签名，支付限度，等等。
挑战 #3：满足用户体验的期待
现实是残酷的：产品经理很清楚地知道，相对于竞品，用户通常更喜欢更易用，更轻量的，即可满足的用户体验，并常常忽略长尾风险。吸引用户从熟悉事物转向新事物需要一种非凡的力量。对于一些人来说，加密货币的价值主张（完全拥有所有权，抗审查，健全通货）已经足够了，而这些人很可能已经上船了。除了这部分已经进入这一领域的人以外，我们需要数百万，甚至数十亿，才能达到加密货币实现其承诺所需的规模。
为了吸引数百万的主流用户，我们需要为他们提供一种不仅仅符合这些期待，而且超越他们的用户体验。我们必须在保持用户习惯的传统互联网产品所有便利的特性的同时提供全新的可能性。一切都必须快速，简单，易懂以及容错。
ZK Sync 的承诺：无需信任，保密和飞速
在本篇技术评述上，我们将探讨所提出协议的高层架构、设计选择以及相关特性。
1) 安全性：扎根于 ZK Rollup
ZK Sync 是构建于 ZK Rollup 这个概念之上的。
简而言之，ZK Rollup 是一个 Layer 2 扩容方案，其中所有资金都由主链上的智能合约持有，而计算和存储则在链下进行处理。对于每个 Rollup 区块，状态转变的零知识证明（SNARK）被生成并由主链智能合约进行验证。这个 SNARK 包含了 Rollup 区块中每笔交易有效性的证明。此外，每个区块的公共数据的更新通过主链网络以低成本的 calldata 形式进行发布。
这种架构提供以下的保证：
Rollup 验证者永远不能损坏状态数据或者窃取资金（与侧链不同）。
即便验证者停止合作，用户总是可以从 Rollup 中取出资金，这是因为数据总是可用的（与 Plasma 不同）。
多亏了有效性证明 (validity proofs)，用户和单个可信第三方都不需要在线监控 Rollup 区块以防止欺诈行为 (不同于如支付通道或 optimistic rollup 这类型的欺诈证明系统)。这篇优秀的文章深入探讨了有效性证明相对于欺诈证明的压倒性优势。
换句话说，ZK Rollup 严格继承了底层 Layer 1 的安全性保证。基于这方面，同时基于以太坊社区和现有基础设施的丰富性，是使我们决定专注于 Layer 2 解决方案而不是试图建立自身 Layer 1 的一个决定性因素。
为了更好地理解这个概念，请参考我们在 ZCon1 和 Dappcon 会议期间的视频讲解，以及一个在 zeroknowledge.fm 上介绍 Matter Labs 的 播客，或者我们早期的技术讲解文章。好奇的读者可以在这篇文章中探讨 ZK Rollup 和 Optimistic Rollup 之间的差异。
在以太坊基金会的资助下，Matter Labs 在过去一年一直致力于 ZK Rollup 技术。自从第一个原型发布以来，我们已经完全重写了原始架构以及 ZK 电路。最新版本包含了我们从社区受到的反馈和实现了各种在可用性和性能上的改进。
2) 可用性：实时交易
我们期望零知识证明技术当前的发展能够达到这样的证明时间：让 ZK Rollup 区块能够在一分钟内生成。一旦区块证明被提交至主链并由 Rollup 智能合约所验证，则这个区块内的所有交易都被确认并处于 Layer 1 级别的抗重组保证之下。
然而，在零售及在线支付的场景中，即便是以太坊的 15s 区块延迟也很可能太长了。我们该怎么样进行改进呢？
方法如下：我们在 ZK Sync 中引入了即时交易收据 (instant tx receipts)。
被选中参与到 ZK Sync 区块生成的验证者将必须在主链上往 ZK Sync 合约发送一笔大金额安全保证金。验证者们会运行一次共识协议给用户提供交易的亚秒级确认 (subsecond confirmation)，即用户的交易将会被包含在下一个 ZK Sync 区块中并由绝对多数的 2/3 共识参与者所签名（按权益加权）。
如果一个新的 ZK Sync 区块生成并被提交至主链，那么它就不能回滚。然而，如果这个区块没有包含承诺的交易，那么原始收据签名者与新区块签名者交集部分的安全保证金会被 slash (罚没)。这个交集一定会持有超过 1/3 的权益 (质押金)。这保证了至少 1/3 的安全保证金可以被 slash 掉，且只有恶意用户会被惩罚。
被 slash 的一部分资金会被用于补偿交易接收者，而其余部分会被销毁。
slash 惩罚可以由用户自身或任何一个共识中给原始交易收据签名的诚实参与者所触发。后者将会有一个自然的动机去检举欺诈行为：因为如果他们参与了后续区块生成，那么他们也会被 slash。(笔者注：如果诚实参与者不检举并继续参与后续共识，那么在后期被举报的情况下，由于诚实参与者是基于有问题的区块继续共识的（即确认了有问题的区块），那么他也会被 slash）因此，共识中至少有一个诚实参与者就足以进行欺诈行为的检测。
让我们来总结一下这个协议的性质。我们将一笔零确认交易称为一笔带有 ZK Sync 区块的即时收据的交易，该 ZK Sync 区块尚未被发布至以太坊主网上。
在 ZK Sync 上对零确认交易的双花只有在区块证明被发布到主链前一个很短的几分钟的时间窗口内才是可行的。此外，恶意验证者需要哄骗用户去接受一个价值 1/6 安全保证金的零确认交易（笔者注：结合上下文，此处 1/6 为笔误，应该为 1/3）。
从买卖双方看，零确认交易是这样的：
1. 即时的
2. 交易可能是可逆的，但仅仅在几分钟以内
3. 只有同时对数以千计的商家发起攻击时才能回滚交易，而非挨个发起攻击。
这是一个相对于信用卡支付在用户体验和安全上重大的改进！让我们从不同参与者的角度来看看：
出售实体商品的线上商店会立即确认用户订单，但不会受到攻击，因为它们将会在发货前等待交易被完全确认。
实体店在处理量较小时实际上并不会受攻击的影响。即使你基于一张即时交易收据来出售一台 Macbook，要使你蒙受损失需要的是数千个分布在不同位置联合起来的物理攻击者以及绝大多数验证者的合谋。
但让我们继续深入探讨。为了量化风险，保证金提供的经济担保可以与工作量证明类型的区块链提供的结算担保作比较（见 Nic Carter 写的好文章）。例如，Coinbase 认为在以太坊上存款操作的终结需要 35 个交易确认。通过从 AWS 上租用 GPU 来进行为时 10 分钟的 51% 攻击来回滚交易的成本约为 60,000 美元。假设安全保证金上有数百万美元，那么回滚一个即时 ZK Sync 收据要明显贵得多。因此，即时收据一般来说有着类似于 ETH 或者甚至更好的经济最终性 (economic finality)。
需要注意的是，即时交易收据还可以防止 ETH 区块重组，这是因为它们的有效性独立于以太坊。此外，以太坊的结算担保与 ZK Sync 的结算担保有机地结合在一起。
3) 活性：抗审查与抗 DoS 攻击
任何一个扩容方案都有一个不可避免的特性：大多数用户不能参与全部交易量的验证。这导致了在 Layer 2 扩容方案中需要专业的角色（比如 Plasma 或者 Rollups 中的验证者，闪电网络中的 hubs 等等）。而这些角色在安全性和性能方面的需求带来了中心化和审查的风险。
ZK Sync 的设计通过长期引入了两个不同的角色来解决这个问题：验证者 (Validators) 和守卫者 (Guardians)。
验证者 (Validators)
验证者负责将交易打包进区块并为它们生成零知识证明。他们参与了共识过程，因此必须为了支持即时交易收据而提交一部分的安全保证金。他们的节点必须运行在一个拥有良好互联网带宽的安全环境中。或者，他们可以选择在不安全的按需云服务商生成零知识证明。
验证者会通过交易费得到奖励，收费形式可以是任何交易代币（为了达到终端用户最佳的舒适度）。
为了保证 ZK Sync 的快速共识，任何时候都只允许有限数量的验证者（在 30 至 100 之间，取决于具体分析）。然而，请记住，ZK Rollup 的验证者是彻底无需信任的。在 ZK Sync 中，恶意验证者既不能危害系统的安全性，也不能欺骗诚实验证者触犯 slash 条件。因此，不同于 Optimistic Rollup，一个小验证者集合可以频繁地被守卫频繁地切换。同时，只要超过 2/3 的被指派验证者是诚实且正常运转的，共识的活性就能得到保证。
守卫 (Guardians)
守卫是由大多数 ZK Sync 代币持有者组成，这些代币持有者通过抵押他们的代币份额来指派验证者。守卫的目的是监控点对点交易流量，检测审查行为等等。门卫的动机是通过保证 ZK Sync 一直具有抗 DoS 和抗审查的性质来保护他们权益 (也即抵押的代币) 的价值。
尽管守卫需要保持其投票秘钥一直在线，但 ZK Sync 中的守卫永远不会面临被 slash 或者被盗的风险（所有权秘钥可以保持冷存储）。他们也可以选择只监控一小部分流量。因此，他们的节点可以在普通笔记本或云服务器上运行，也就是说，不需要专门的验证者服务器。
守卫会收到来自被指派的验证者的交易费奖励，这些奖励以 ZK Sync 原生代币的形式发放给守卫。他们的收益和权益会被长期地锁定，以激励他们把 ZK Sync 代币的长期价值的重要性置于短期回报之上。
4) 可编程性与隐私保护：构建模块
实现高效的可编程性和隐私性是 ZK Sync 景愿中最困难的部分。它需要一个合适的零知识证明系统和一个智能合约编程框架的可靠设计和实现。
4.1. RedShift：透明通用的 SNARK
实现基于零知识证明的智能合约（无论是透明的还是隐私保护的）的最大障碍是缺乏高效通用的具有递归构成的零知识证明系统。Groth 16，作为当前最高效的 ZK SNARK，需要一个特定于应用程序的信任建立的过程，并且会在应用递归时损失大量效率。另一方面，基于 FRI 的 STARK 需要高度专业化的技巧去构建，且缺乏任意通用电路的高效递归组件。
这是我们研究 RedShift 的主要动机之一：RedShift 是一个全全新的源于基于 FRI 的多项式承诺方案的透明、高效和非常简洁的 SNARK。我们目前正在整合同行评审以及社区反馈，然后把 RedShift 作为 ZK Sync 的一个核心部分进行部署。
Redshift 是一种通用型 SNARK，它允许我们很方便地把任意程序转换成可证明的零知识电路。异构电路（例如，不同的智能合约）可以递归地整合至一个 SNARK 中。由于完全依赖于抗碰撞的哈希函数 (collision-resistant hash functions)，RedShift 很可能是后量子安全的。
4.2. Zinc：零知识证明智能合约框架
在 ZK Sync 的可编程模型的设计中，我们致力于结合以下几个目标：
高可扩展性
同时支持公有和私有的智能合约
最为重要的是：平坦的学习曲线且易于开发
很多优秀的项目有着某几个相同目标，但是没有一个项目同时承诺实现所有目标。例如，ZkVM 为通用保密智能合约提供一个虚拟机，但它是基于 bulletproofs 的，并不支持简洁的证明聚合。ZEXE 有一个一流的隐私保护设计，但其需要对零知识证明的细节和权衡有着深入的了解，这大大提高了更为广泛的程序员圈子的参与门槛。另外，更为简单的零知识编程框架缺乏安全智能合约开发的表达能力或者特性。
这使得我们决定去创建 Zinc：一个专门为基于零知识证明的智能合约而设计的安全、简单且高效的编程框架和基于虚拟机的运行时环境。
SyncVM 的关键设计优先是安全性和对开发者的友好程度。定义合约的编程语言严格遵循一种简化的 Rust 语法并拥有借鉴 Solidity 和 Libra 中 Move 的编程组件。它不要求开发者为了编写高效安全的程序而去深入理解零知识证明领域的细节。事实上，拥有 Rust，Solidity，C++或者更为简单的编程语言北京的开发者可以在一天内学会 Zinc。
考虑一下用 Rust 为 Bellman 框架编写的程序中的一部分（ZEXE 有着相似的 API）及用 Zinc 编写的相同部分：
Zin v0.1 将于 2020 年 1 月发布。
ZK Sync v0.1 开发网现已上线！
ZK Sync v0.1 开发网现已上线。此版本的范围限制在单个操作者设置下进行 ETH 和 ERC20 代币的转移。
查看 ZK Sync 的 SDK
在 github 上浏览代码
尝试一下 demo
v0.1 开发网的发布是把 ZK Sync 景愿带到现实这个漫长过程的第一步。这将需要大量的研究，实验和开发上的努力。虽然一些设计可能会随着我们的学习和吸收反馈意见而改变，但是我们承诺 ZK Sync 的景愿将保持不变：ZK Sync 将成为数百万用户进行加密货币领域的桥梁。我们为用户体验设置了一个高标准并将证明零知识技术能够在不牺牲区块链革命价值的情况下提供类似于 Web 的体验。
您可以在 Matter Lab 的 Twitter，公共的 Telegram 频道，或者订阅我们的简报（偶尔发布）来追踪我们的进展。
如果您想为 ZK Sync 开发做出贡献，请与我们联系。我们一直在寻找有才华的工程师和密码学家来加入我们的团队。
译者：双花
原文链接：https://medium.com/matter-labs/introducing-zk-sync-the-missing-link-to-mass-adoption-of-ethereum-14c9cea83f58
区块律动 BlockBeats 提醒，根据银保监会等五部门于 2018 年 8 月发布《关于防范以「虚拟货币」「区块链」名义进行非法集资的风险提示》的文件，请广大公众理性看待区块链，不要盲目相信天花乱坠的承诺，树立正确的货币观念和投资理念，切实提高风险意识；对发现的违法犯罪线索，可积极向有关部门举报反映。