- 图源来自 Unsplash 的 Artur Tumasjan -
导语
近几个月以来, 越来越多关注的目光放到了 Optimistic Rollup (OR) 这个基于错误性证明 (Fault Proof) 的拓展框架上. 我们 StarkWare 则采用 有效性证明(Validity Proofs ,VP), 因为它比错误性证明更安全 . 本文将在安全性讨论之外, 列举一些 VP 较 OR 的额外优势, 同时纠正大众对有效性证明的常见误解, 最后介绍 StarkEx -- StarkWare 开发, 基于 STARK 和有效性证明的拓展引擎.
在此特别说明, 和 OR 比较, VP 具有以下优势:
从根本上更安全
撤款时的资本效率高 1000 倍
可拓展性更强(链上)
在计算方面, 至少能达到相同的效率
安全性
在 上一篇分析 (编者注: 中译本见文末)中, 我们比较了 VP 和 OR , 前者只会在某状态转换被严格证明有效的情况下执行该状态转换, 而后者则允许任意的状态转换(因此是 Optimistic , 乐观的), 参与方可以针对无效的状态转换提交错误性证明. 我们的上一篇文章聚焦安全性分析, 明确指出了一种能在 OR 中实施, 且会导致 OR 中所有资金被盗的攻击手段( 其它可行的攻击手段 也在后续不断讨论). 区块链上的基础架构解决方案必须足够健壮, 要能支撑来自金融世界, 每天万亿级别的资金交互负载. VP 和 OR 分别怎样胜任? 由于在 OR 中窃取资金的成本和收益大小无关, 所以一旦系统承载了足够多的资本, 使得破坏系统变得有利可图, 那理性的参与者肯定会想方设法通过攻击牟利. 与 OR 相反, VP 不会转换到任何无效的状态, 使得无论承载多少资金都不会被盗. 对于大规模的金融系统, VP 更健壮, 而 OR 更脆弱.
也可以站在数据集一旦遗失的角度分析系统的安全性. 和 VP 相比, OR 中的数据更为敏感. 一旦数据遗失, OR 中的资金就可能被盗 -- 也正因如此, 目前的设计方案都集中在链上数据可用性挑战 (Data Availability) 上. 而对于 VP , 由于采用了链上数据(例如 ZK-Rollup), 资金就跟存在 Layer-1 中一样安全. 至于 VP 的链下数据部分, 资金最多被冻结, 而不会失窃.
资金效率
数字货币世界中流动性的一大痛点在于资金取款时的延迟. 在 OR 中, 标准取款窗口期 大约为 1 周 时间 -- 这是给提交错误性证明的有效窗口时间(一个安全性参数). 在 VP 中, 标准取款窗口大约为 10 分钟(利用额外的软件和硬件提升能变得更短)-- 这是针对上一次计算结果来生成有效性证明的时间. 因此 OR 的标准取款窗口时间要比 VP 长 1000 倍(1 周 / 10 分钟 ~ 1000). 使用 OR 就要承受这样 1000 倍的不便, 这不仅是时间上的延迟, 也是资金效率的降低.
我们先前描述过一个免信任的 快速 提款机制: 想要立刻提款的用户需要给流动性提供商打一份链下资产的欠条, 即签名了的条件支付交易, 然后流动性提供商从自己的 "存钱罐" 智能合约中垫付这笔资金, 在链上把欠条金额上的资金转给提款用户, 整套操作需要的时间和区块链网络的转账时间差不多. 流动性提供商会定期把累积的链下资产转移到链上的 "存钱罐" 中.
VP 和 OR 都能应用快速取款机制. 但在 OR 系统中, 流动性提供商需要在 "存钱罐" 中准备 1000 倍的资金, 因为他们收到链下资产等待的时间窗口要长 1000 倍. 这个 1000 倍的比例和 "存钱罐" 流动性算法中的各种假设都无关: 无论是基于取款金额期望值, 或 提款 - 存款差额, 再或者是峰值流动性需求, 平均撤款金额等等, OR 需要的储备金数量都是 VP 的 1000 倍.
然而, 有时根本无法使用快速撤款. 对于非同质化资产 (或者是一些非主流同质化资产) 就没法使用(或者应用的成本很高):
非同质 Token(NFT): 正如早先由 Vitalik 介绍那样, 如果一只名叫 Mitzi 的名贵 CryptoKitty 存在了链下, 他的所有者没法要求在链上再收到一只 Mitzi , 因为世界上有且只有这一只叫 Mitzi 的 CryptoKitty.
隐蔽交易: Zerocash 风格的承诺 (commitment) 在某种程度上也是非同质化的. 要想把隐蔽交易中的资金快速提到主链(主链上也应该保持隐蔽性), 用户必须要向流动性提供商揭露承诺中的数据, 破坏隐蔽性.
在这种快速撤款机制无法应用的场景下, 用户只能选择等待标准撤款窗口结束, VP 则要比 OR 快 1000 倍.
可拓展性(链上)
在这一部分我们将对比不同的 rollup 系统, 由于同类事物间的比较才有意义, 因此我们只比较提供链上数据可用性的 rollup 系统, 即: OR vs. STARK ZK-Rollup(StR). 虽然我们不想, 但是所有在链上存储数据的 rollup 系统都将随着 rollup 交易的增多而线性增大消耗的资源量. 链上数据包含一些 状态 (例如交易细节)以及 见证数据 (例如用来证明交易参与各方的数字签名).OR 和 StR 的区别在于随着交易量的增加, 前者的见证数据线性增长, 而后者把这些见证替换成了一个证明, 这个证明的大小只会多项式对数级别增长. 划重点, 对于足够大, 足够多的批量交易, StR 的链上数据指纹要比 OR 小很多...
从细节出发: 在 StR 中, 见证数据能核实 rollup 运营者所进行的查验, 因此一批计算只需要一则见证(例如一份 zk-proof), 而不需要在每一份交易后面都附一份证明. 更优秀的是, 在现代 zkp 系统中, 这个证明的大小是固定的(准确点来说, 正如我们前文所提到, 是多项式指数级别). 因此随着批量交易的增大, 分摊到每一条交易头上的资源消耗反而减少. 在 OR 中, 每一条交易都必须附上一则见证, 使验证人能核实交易的正确性. 因此对于大批量的交易, 并没有均摊减少的优势. 更重要的是. OR 中的见证要比交易本身大很多: 比方说 OR 见证需要包含所有用户的签名 1 , 而 VP 不需要(证明能核实它们已经在链下被验证过了). 在单纯的支付中, 见证要比支付的数据量大 3 到 5 倍; 而对于复杂的应用场景(比如说隐蔽交易), 见证通常会比状态的数据大 10 倍以上, 有时甚至更多.
总的来说, OR 明显要消耗更多的链上资源, 也因此比 StR 更快地顶到拓展性天花板.
通用计算开支(STARKs 越用越好用)
人们常常拿 VP 和 OR 的通用计算开支做对比: 即对于一个给定的链下计算任务, 两种不同的系统额外需要做哪些工作? 下文我们将围绕 StarkWare 的 STARK 展开, 因为这是我们目前应用的 VP 框架.
OR: 由于 100 个验证者互相监督基本上能够保证整个计算的正确性, 因此当提到 OR , 验证者的数量都数以百计. 到了验证阶段, 每一个验证人都需要进行一遍计算任务, 因此在 OR 中做通用计算的开支是原任务的 100 倍.
有必要说明, 验证人集合越小或者越多预先指派的情况, 验证人就越容易互相勾结, 或者受到外界的贿赂, 攻击.
STARK: 由于验证过程的计算开支微不足道, 它只需要一个实体 -- 证明者 -- 进行大量的计算. 验证的计算开支有多微不足道呢? 现在我们甚至可以用一台简单的智能手机对一大批计算结果做验证, 因此可以忽略验证的计算消耗. 人们常说证明者的计算开支是原有任务的 10000 倍, 因为证明需要消耗大量的计算来生成. 但实际上 StR 需要的计算开支仅仅是 100 倍, 因此额外的计算开支和 OR 大致相当. 之所以说 StR 的计算开支仅有 100 倍, 是基于以下理由:
对于算数 / 几何运算操作, 我们已经达到了少于 100 倍的计算开支. 目前应用的 Pedersen 哈希函数仅仅比原来的操作增加了 20 倍计算消耗: 即用 STARK 来证明一个 Pedersen 哈希值的正确性仅仅比直接计算 Pedersen 慢 20 倍.
对于那些像 SHA-256 那样众所周知计算开支很大的操作, 我们正试着把那些函数换成对 STARK 友好的操作. 我们目前受以太坊基金会的资助来进行这些研究, 而且在 2020 年第一季度, 许多密码学大牛会提交给我们他们的替代方案建议. 估计对 STARK 友好的哈希函数在证明时仅比某些高效的哈希算法 (例如 SHA-256) 的直接计算慢 100 倍.
最后, 很多人之所以称道 OR 是因为它能用到通用计算中, 并且将支持 EVM 代码, 而 VP 不具备这一特性. 对于将 STARK 用到通用计算中, 我们持乐观的态度.
感谢 Dan Robinson http://danrobinson/ , John Adler https://twitter.com/jadler0 以及 Vitalik Buterin https://twitter.com/VitalikButerin 对本文的反馈.
¹ BLS 通常被认为是一种高效的聚合签名机制. 我们相信 BLS 不会只应用在这个用例中, 因为它是整合多个签名到一则消息中的最佳方式. 在 OR 的用例中, 许多消息都需要由交易收 / 发方签名; 而 BLS 签名的验证耗时 10ms / 签名 (每条消息进行一对操作), 这不仅是验证人 (链下) 的负担, 主链在判别欺诈时也需要处理这种消耗.
(完)
来源: http://www.tuicool.com/articles/YjER3ii