亚太娱乐平台报道干货 | 再议有效性证明 vs. 失误性证明_亚太娱乐平台官网资讯

来自:EthFans 2020-01-05

-图源来自 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),而不需要在每一份交易后面都附一份证明。更优秀的是,在尊宝国际娱乐11大平台 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 ,? John Adler 以及 Vitalik Buterin 对本文的反馈。

? BLS 通常被认为是一种高效的聚合签名机制。我们相信 BLS 不会只应用在这个用例中,因为它是整合多个签名到一则消息中的最佳方式。在 OR 的用例中,许多消息都需要由交易收/发方签名;而 BLS 签名的验证耗时 10ms/签名 (每条消息进行一对操作),这不但是验证人(链下)的负担,主链在判别欺骗时也需要处置这种消耗。

(完)

原文链接: https://medium.com/starkware/validity-proofs-vs-fraud-proofs-strike-back-4d0bf90eed15

作者:Avihu Levy & Uri Kolodny

翻译&校对:安仔 C1int & 阿剑

本文由原作者授权 EthFans 翻译及再出版。