# Layer2 中的有效性证明与欺诈证明

By [Starknet 中文](https://paragraph.com/@starknet-zh) · 2022-12-19

---

> 原文：[Validity Proofs vs. Fraud Proofs](https://medium.com/starkware/validity-proofs-vs-fraud-proofs-4ef8b4d3d87a)  
> 翻译：以太坊爱好者，阿剑

引言
--

在本文中，我们将从欺诈证明（Fraud Proof）与有效性证明（Validity Proof）的区别出发，分析和比较不同的 Layer-2 可扩展性方案。我们断言，相较之下，有效性证明在根本上具有优势，因为有效性证明方案保证了只有合形式的状态转换才会被接受。

背景
--

在最近几个月，基于证明的以太坊可扩展性方案——比如 [Truebit](https://truebit.io/)、[Gluon Plasma](https://leverj.io/GluonPlasma.pdf)、[dFusion](https://github.com/gnosis/dex-research/tree/master/dFusion)、[Roll-Up](https://github.com/barryWhiteHat/roll_up) 以及 [Ignis](https://github.com/matter-labs-archive/matter-network) 这样的项目——开始浮出水面，让人颇为激动。这些项目背后的理念很简单：与其给区块链写入很多交易，不如产生一个证明（例如一条哈希值），可以简洁地表示这些交易，进而表示出新的状态。

上面提到的所有项目都是 Layer-2 方案：它们定义了一种运行在 Layer-1 上的协议（和逻辑），并且基于这些协议来提供多种服务：存储资金/取出资金、一个根据链下状态时时更新的账本，并作为一种 “全局时钟” 而运作。重要的是，这些协议没有嵌入 Layer-1，因此 Layer-1 也无法强制执行任何 Layer-2 的逻辑。

在此，我们想展开一种框架来比较这些方案，尤其是关注 “欺诈证明” 与我们所谓的 “有效性证明” 之间的区别。欺诈证明和有效性证明不是 Layer-2 的专利，在 Layer-1 上也可以存在，但当前大家仅在 Layer-2 上做尝试，因此我们的分析也都基于 Layer-2 方案。

欺诈证明即表示某个状态转换不正确的证据。这种方案反映了一种乐观的态度：_假设_ 区块上表示的 Layer-2 状态都是正确的，除非有人能证明不是。实际上，提交到链上的区块也很有可能包含着一次不合逻辑的状态转换。

有效性证明即表示某个状态转换正确的证据。这种方案的态度更为消极：当且仅当某个状态是正确的，区块才应该包含代表相应 Layer-2 状态的值。

在继续推进分析之前，有必要强调的是：证明系统（例如 SNARK、STARK）既可以被用作欺诈证明，也可以用作有效性证明。我们不应该混淆证明的方式（例如，SNARK、STARK）和证明的目的（错误或是有效）。

深度分析
----

### 欺诈证明

欺诈证明的主要优点是无需为每一次状态转换都提供证明，只在系统需要中断的时候提供。因此，欺诈证明方案需要的计算资源更少、更适合可扩展性受限的环境。这种方案的主要缺点则来源于其非交互性：它定义了多方之间的 “会话”。一次会话要求各方——尤其是断言状态转换有误的一方——必须在线（系统要具备活性），并且允许其它方用多种方式打断会话。但问题的核心是：协议会将沉默（即挑战者的缺席）视为默示的同意。实际上，攻击者完全可以尝试用 DDoS 攻击制造出表面的沉默。

概念上，欺诈证明方案可以表述如下：因为区块有可能包含不正确的状态转换，欺诈证明协议设定了一个时间框架——纠纷时间窗口（DTF）——来处理不正确的状态。这一窗口的长度也是用区块数量来定义的。如果在纠纷时间窗口内无人提交欺诈证明，相应的 Layer-2 状态转换就会被认为是有效的。如果有人向智能合约提交了欺诈证明，而且经证明是正确的（即，在窗口期内提交，并且证明了某个状态转换是不合逻辑的），则（至少）智能合约会将 Layer-2 状态回滚到最后一个正确状态。除此之外还可能实施对作恶一方的惩罚，等等。

DTF 时间长度的选择很重要：DTF 时间越长，发现错误状态转换的几率就越高——听起来很棒。但同时，时间越长，用户需要等待的时间也越长（比如需要取款的时候），这就是一个副作用了。

### 有效性证明

有效性证明总体上说更为简单：向一个智能合约发送一些链下计算已然发生的证据。智能合约仅在一个新值被证明为正确之后才更新区块链。有效性证明的主要优点是区块链上总是能反映出一个正确的 Layer-2 状态，而且一个新状态可以即时使用。而主要缺点就是每个、每次状态转换都需要一个证明，不单单是状态转换受到质疑时才需要提交证明，这就影响到了其可扩展性。

### 51% 攻击

在多种可能的攻击方法中，我们主要关注 Layer-1 上的 51% 攻击。最近 51% 攻击[频发](https://www.coindesk.com/markets/2018/06/08/blockchains-once-feared-51-attack-is-now-becoming-regular/)，连[以太坊经典](https://www.coinbase.com/blog)也未能幸免。那么欺诈证明和有效性证明如何应付这种攻击呢？

欺诈证明：一场 51% 攻击会在区块链中引入一个欺诈性的状态，比如从交易所中 “偷取” 一些资金。细节如下：

*   攻击者用一个欺诈性的状态转换创建了区块 BlockFr。例如，区块中包含了一笔交易，将交易所中所有的资金转移到攻击者的账户。
    
*   在 BlockFr 之后，他们还会接上 DTF 区块，以一个包含取款交易的区块告终（取款交易会取出攻击者从 BlockFr 区块中得到的所有资金）。
    
*   然后他们在 DTF 区块后面继续生成区块，直到超过当前链成为更长的链。他们能这么做是因为他们掌握了 51% 的算力
    
*   难搞的是，发动这样一场攻击的运营成本跟 “奖金” 规模（即受攻击的交易所控制的金额）无关（在撰文此时似乎相当低：[在以太坊上发动攻击只需每小时 10 万美元](https://www.crypto51.app/)）。这就意味着，随着密码学货币交易所的体量上升，攻击交易所会越来越有吸引力。
    

![](https://storage.googleapis.com/papyrus_images/c47f7c90c32e54eff8de5db1e0b903feaf85e1ea373531e2214f4e5d020513f8.png)

总而言之，问题的根源在于 Layer-2 解决方案定义了自己的逻辑，而且允许一个区块包含欺诈性的的状态转换。这样一来，攻击者偷盗资金之后的账本状态也会被认为是一个合法的状态！甚至都没有什么双重花费，只是出现了一桩欺诈。

有效性证明：51% 攻击只能遮蔽已有的账本历史，可能可以提供另一种历史；但重要的是，这一新的历史也是完全合形式的（correct）。这里所说的攻击范围仅限于在 Layer-1 上可能发动的攻击。在币币交易所中（尤其是那些所有资产都记录在同一条链上的交易所），[覆写历史的勾当](https://en.wikipedia.org/wiki/Global_financial_crisis_in_September_2008)有时候是一本万利的：例如，一个卖家，可能会很乐于遮蔽掉一笔时候来看成交价位于谷底的交易，但是，在给定区块链上的交易所中，没有办法可以直接吞掉对方的钱。

我们提议的解决方案
---------

如果有这么明显的劣势，欺诈证明型系统（例如 Gluon Plasma 和 dFusion）还会作为一个选项？

主要原因就是提供有效性证明迄今为止都仍是非常昂贵而且繁琐的。

在使用证明系统以前，免许可系统中唯一一种 “有效性证明” 就是简单重复运算（replay），因此可扩展性大为受限；而且，这种重复计算直至今天仍在 Layer-1 上使用，虽然众所周知它是可扩展性的一个障碍。证明系统则提供了一种非常有吸引力的特性，叫做 _简洁性_（succinctness）：为了验证一个状态转换操作，你只需要验证一个证明，而且验证的开销是完全独立于状态转换的计算量大小的（更准确地说，它与状态转换操作的大小是多对数（polylogarithmic）关系）。

Ignis/Roll-up 都基于 SNARK（简洁的非交互式知识证明），需要一个受信任的初始设定，并且相较于 STARK，需要证明者使用更多的计算资源。StarkWare 正在努力部署 StarkDEX，为去中心化交易所提供可扩展性方案；他会使用 STARK 来实现有效性证明，我们预计会在 2019 年第一季度末部署到测试网上。

结论
--

本文比较了欺诈证明和有效性证明作为 Layer-2 可扩展性方案的工具价值。我们强调了有效性证明应对 51% 攻击的内在优势。而 STARK，因为证明时间更快，而且验证简单、无需受信任的初始设定，是一种生成有效性证明的有力工具。

感谢 Dan Robinson、Linda Xie、Alexey Akhunov 以及 Georgios Konstantopoulos 审读本文的初稿。

---

*Originally published on [Starknet 中文](https://paragraph.com/@starknet-zh/layer2)*
