来源|?dankradfeist.de
作者|?DankradFeist
原标题：《数据可用性检查》
数据可用性检查须知
本文旨在解释数据可用性检查，以及为什么区块链的扩容方案，例如以太坊2.0，需要它们。本文预设了读者具有区块链(例如比特币和以太坊)的基本背景知识、最好对现在使用的共识算法(工作量证明和权益证明)也有所了解。为了简单起见，解释内容将建基于权益证明链——由所有具有相同权重的全节点运行共识协议，具有2/3诚实假设；但这些分析同样适用于工作量证明和其他协议。
入门知识
想想看，区块链有全节点和轻客户端，还有一个点对点网络，它可能对数据是有损的，但不会自适应地审查数据。相对于全节点来说，轻客户端是一个更便宜的选择。在传统的区块链协议里，我们假设所有客户端都运行全节点，验证在状态转换中的每一笔交易。运行一个全节点要求计算机有大量的内存、算力和带宽。对于移动客户端和许多资源受限的环境来说，这个成本可能太高了。
轻客户端是只需下载每个区块的区块头的节点，它们信任全节点对状态转换的检查是正确的——并假设共识算法不会产生违背这点的区块链。轻客户端依赖全节点为任何相关交易提供区块内的信息。这很可能只占链上所有数据很小的百分比。
为了解释地更清楚，我介绍这里的三类角色：
全节点通过对每个区块的共识生成一条区块链，并始终下载所有数据和验证所有状态。每当它们看到区块里有不一致的状态(例如，区块的最终状态与区块内的交易不一致)，它们会生成一个欺诈证明，以警告轻客户端。轻客户端只下载区块头(非交易数据和状态)，除了它们想知道的交易和部分状态。它们与全节点连接，以请求所需要的数据。点对点网络传播区块头，并允许随机访问上传到它的数据块。一个全节点具有下列安全保证：
与其他全节点形成的共识(绝对)多数可以构建另一条区块链，从而进行双花攻击；更广泛来说，它们可以任意对交易进行重新排序，创建另一个版本的交易历史。由于要检查状态，即使是其他全节点形成超级多数对不一致的状态达成共识，也不可能让一个诚实全节点同意这条链。因此，一个全节点的安全假设是2/3的诚实全节点可以保证交易不会被重新排序，但正确的状态执行是不需要任何的诚实假设来确保的(一个全节点根本不可能被接受一个不正确的状态转换)。
对于轻客户端来说，情况略有不同，因为它们不下载和验证状态。因此，在没有欺诈证明(详见下文)的情况下，“天真”的轻客户端会被，相信由绝对多数(2/3)的全节点达成共识的区块链是没有问题的，即使它实际上有一个不正确的状态转换。
欺诈证明
欺诈证明能是给轻客户端一个更好的安全模型，使其安全性接近于全节点。其目的是，只要至少有一个诚实的全节点(比2/3多数假设弱得多)，轻客户端也可以被保护，免受无效链的影响。
欺诈证明是如何实现这点的？假设区块链执行区块B内的交易t1,…,tn，且区块头为H。如果我们增加一个执行跟踪，用来存储每笔交易前和后的状态的默克尔根，我们把它叫做s0,…,sn，如果有任何交易被错误执行(即其结果没有正确应用于状态)就可以构建一个虚假证明：如果说交易ti?是有问题的交易，给出三元组(si?1,ti,si)，再加上在区块头H里显示已被打包的默克尔证明，这将构成一个欺诈证明。事实上，我们仅需要打包ti?需要和影响到的si-1和si。这个欺诈证明的大小比原来的区块B要小得多，因此容易在网络里广播，警告轻客户端不要跟随这条链。
所以，现在轻客户端的安全假设就比之前的要强很多了：
2/3的不诚实全节点可以构建另一条链，从而改变交易历史或给交易重新排序(例如，发起双花攻击)。但是为了防止出现不正确的状态转换，现在的假设是至少有一个诚实全节点(它可以创建欺诈证明)，且网络是同步的(这样你就能即使接受到欺诈证明)。
数据可用性问题
用欺诈证明保护轻客户端不受错误状态转换影响这个方法其实有一个缺口。如果绝对多数的全节点都已经对一个区块头签名了，但不发布部分数据(特别是，这可能是欺诈性交易，它们将晚点发布，以过别人接受印出来的或偷来的钱)？显然，诚实全节点将不会跟随这条链，因为它们不会下载该数据。但轻客户端不会知道数据是否可用，因为它们只下载区块头，不下载数据。因此，现在的情况是诚实全节点知道有猫腻，但它们无法警告轻客户端，因为它们缺少可能需要用来创建欺诈证明的数据。
难道它们就不能用其他信息警告轻客户端，告诉它们：“嘿，小心，这个区块的数据不可用。”吗？是的，但问题在于它们无法证明——不存在数据不可用的证明，所以上述的简单欺诈证明机制是不起作用的。
更糟糕的是，这不是可归责的问题。有些数据可能因为网络条件不好而丢失了，而这些数据可能在以后再次出现。因此，如果你是一个诚实节点，看到数据不可用的警报，然后检查发现数据实际上在那里，你不能确定是谁出错了：可能是出块者没有在开始时上传数据，而是在警报产生后才上传(出块者的错)，或者这是一个错误的警报。
由于这不是可归责的问题，我们不能因为警报的结果惩罚出块者或挑战者。这很烦人，因为这基本上意味着增加这个功能会增加一个DOS向量(Vitalik的这篇文章对这个问题进行了非常好的说明。)
解决方案：用纠删码进行数据可用性检查
要解决这个难题，就要确保轻客户端可以知道数据是否真的可用。因为如果它们知道这个数据是可用的，它们也就知道很可能有一个诚实全节点看到并检查了该数据——如果该数据是不正确的或是欺诈性的，诚实全节点就会广播一个欺诈证明。
当然我们不想要轻客户端必须下载整条区块链和状态来实现这点——因为这样它们就不再是轻客户端了。因此，我们将让它们下载随机的数据块，并检查它们是否可用。如果你尝试下载100个不同的数据块，并全部都获取了，你就可以很确定大部分的数据都是可用的(例如，如果少于50%的数据是可用的，你能成功下载100个数据块的概率是2-100≈10-3，这是一个非常小的数字)。
然而，这只能证明大多数的数据是可用的——比方说，10兆字节的数据块中仅有100字节丢失了，在这种情况下，你对那一点数据发出请求的可能性非常低。而100字节足以为作恶交易作掩护，躲过诚实的欺诈证明者。
因此，我们需要对这些数据做一些处理，以确保那些检查切实保证所有的数据都将是可用的。我们可以用纠删码(erasurecode)实现这点。一个纠删码以更大量的数据E取代区块数据B，其特性是某固定百分比q<1将总足以重构整个数据。因此，即使有些数据丢失了，只要轻客户端确保足够大部分数据是可用的，它们就知道区块数据B是可被重构的。
现在，我们准备定义轻客户端在数据可用性检查中的行为。对于每个它们下载的区块头，它们将尝试下载数据E中k个随机数据块，以评估数据是否实际可用。如果它们可以下载全部的数据块，那么，在网络里有实际上足够的数据重构整个区块的概率是1-qk。
使用这个机制就无须全节点警告轻客户端数据是否可用了。只需要下载少量数据，轻客户端就可以自行测试并知道答案了。
纠删码实例:RS码
我们实际上是如何构建纠删码的呢？一个简单且为人熟知的实例是Reed-Solomoncodes(缩写为RS码)。它们是基于这样一个简单的事实：在一个域里，任何次数是d的多项式都仅由其在d+1点的估值确定。例如，多项式的次数为1(即一条线)，然后只需要知道多项式两个点的值就足以知道整个多项式了(只有一条线穿过两个不同的点)。
我们必须在一个有限阈里解多项式，否则系数和估值都会变得任意大。幸运的是，有大小为2m的域可用(即所谓的二进制域或伽罗瓦域F2)，这样我们就不需要研究素域Fp(尽管我们可能在一定方案里因为其他原因需要)。
因此，假设我们有n个数据块d0,…,dn?1，我们想对其进行纠删编码。为了用一个RS码来实现，我们将插值一个多项式
次数为d=n-1，估值d0在0，即f(0)=d0、f(1)=d1，这样下去。我们知道有这样的多项式存在，事实上拉格朗日插值多项式(Lagrangeinterpolationpolynomials)给了我们建构它的明确方法(尽管还有更高效的方法)。
现在，我们通过对多项式在更多的点上估值来拓展数据——比方是n多个点，如果我们想把比率设为q=0.5。那么就会有dn=f(n),dn+1=f(n+1)...,d2n?1=f(2n?1)。由此我们得出它的一个特性，即任何n个点将足以重构这个多项式——如果我们有多项式f(x)，我们也可以轻易对它在0,...,n-1进行估值，得到我们的原始数据。
就这些内容了！RS码不过是一些多项式插值。这实际上就解决了数据可用性问题了，因为它们在编码效率上是最优的，除了一个小问题——欺诈事件可以以另一种方式发生，即产生错误的编码。而对于RS码，为了证明编码是错误的，你必须提供n个数据块，并足以用一个多项式对其中的n-1插值，并显示最后一个不在这个多项式上。这就是为什么我们现在做大量的研究，旨在找出避免必须做这些不正确编码证明或使它们尽可能小的方法。
在分片上的应用
数据可用性检查对于许多不同区块链扩容方案是很重要的，因为即使节点不能检查所有或甚至下载所有数据，它也能给这些节点提供安全。由于这是区块链的一个根本性瓶颈(共识节点必须下载所有数据)，这是一个重要的扩容要求。
例如，在以太坊2.0里，验证者只需对信标链上的数据进行完全验证，分片上的验证工作由委员会负责。这个结构旨在减轻验证者必须验证所有数据的负担。但是，这意味着验证者在多数分片上实际上是轻客户端(除了活跃验证者)。因此，数据可用性检查是需要的。在这种情况下，以太坊2.0的验证者实际上同时是“全节点”和轻客户端。那些下载并检查所有分片数据的节点是“超级节点(supernodes)"——这些节点可能只会由组织或做了大量质押的人来运行，他们会验证所有分片。我们当然不会想要只是信任这一小部分人是诚实的来运行以太坊2.0。
因此，有数据可用性检查和欺诈证明是绝对必要的，这样一般人都可以运行验证者节点。
扩展阅读
1.VitalikButerin的这篇文章解释了欺诈证明和纠删码
它介绍了多维RS码如何形成更小的不正确编码证明这是论文版本2.多为代码替代方案的最新想法：
使用STARKs使用FRIs使用Kate’spolynomialcommitment方案原文链接：https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。