# 翻译｜Polygon Avail By [泥巴街](https://paragraph.com/@0xb1961a3aaa359de2f096da26771ea205c6031f4e) · 2022-08-23 --- 来源 ｜ Github 作者 ｜ Polygon 翻译 ｜ Cxl 校对 ｜ Seaforest 原文：[https://github.com/maticnetwork/data-availability/blob/master/reference%20document/Data%20Availability%20-%20Reference%20Document.pdf](https://github.com/maticnetwork/data-availability/blob/master/reference%20document/Data%20Availability%20-%20Reference%20Document.pdf) 摘要 -- 在研究了现有区块链架构之后，我们提出了一种分离数据托管、执行和验证的架构。 我们讨论了几个合适的原语，用于建构一个保证数据可用性的数据托管层。我们概述了Polygon Avail的系统目标、设计、安全性和实现细节，这是我们聚焦可用性的区块链解决方案。 _【译者解释：原语是在操作系统中调用核心层子程序的指令。与一般广义指令的区别在于它是不可中断的，而且总是作为一个基本单位出现。】_ 1 目前dapp架构 ---------- 当今，在类似以太坊的生态系统中，主要有三类节点 — — 验证者节点、全节点和轻客户端。验证者节点把一个个区块附加到区块链，验证者节点从内存池（mempool）收集交易，执行这些交易，并且在向网络广播之前生成区块。这些区块包含一个小的区块头，区块头中包含对应区块内的交易相关的摘要和元数据。网络上的全节点接收到这个区块，并通过重新执行交易来验证其正确性。轻客户端只在需要的时候从邻近的全节点获取区块头和交易细节。区块头内的元数据使得轻客户端能够验证接收到的交易细节的真实性。 _【译者解释：内存池是一种加密货币节点的机制，用于存储有关未确认交易的信息。它充当尚未包含在区块中的交易的一种等候室。】_ 虽然这种架构十分安全，并被广泛采用，但它有一些严重的实际限制。因为每个交易都是由系统中所有的全节点执行的，这就形成了吞吐量有限的瓶颈。随着这类dapp的广泛采用，交易数量迅速增长，导致将一笔交易纳入一个区块的成本增加。面对这些问题，二层解决方案应运而生。 像Polygon这样的二层解决方案，通过创建一个锚定在以太坊这样的主链上的Plasma链来工作。在这样的架构中，dapps建构在Plasma链上，只有定期的检查点被记录在主链上。这样的系统的吞吐量取决于Plasma链的交易处理速度，而任何争议解决都可以在主链上执行。这样一个分离的执行和争议解决的好处是，它提供了更高的吞吐量，同时保留安全属性。在实践中，多个这样的Plasma链并行运行，从而提高系统的处理能力，同时保证了主链的安全性。 2 Plasma、Optimism rollup、zk rollup ---------------------------------- 二层解决⽅案的成功之处主要在于其执⾏和验证框架。基于 Plasma 的侧链⽅法，如 Polygon 所采⽤的⽅法，可以处理数千笔交易，并且只向主链提交⼀个哈希作为检查点。然⽽，它⾯临⼀个重要的问题。如果发⽣侧链纠纷，Plasma 缺乏有效的⽤⼾退出机制。此外，Plasma 缺乏处理任意指令的能⼒，尽管它们得到了像以太坊那样的准图灵完备的主链的⽀持。 像 Arbitrum 和 Optimism 这样的Optimism Rollup，使⽤Optimistic 执⾏范式，其中管理者/运营者执⾏侧链交易，并在主链上提交认定（assertion）。如果发⽣争议，其他参与者可以在固定的时间内，对链上的认定提出质疑，然后主链执⾏争议解决。虽然这提⾼了交易处理率，但它也有⼀些缺点，例如造成不可替代资产（Non fungible assests）的最终确定性（finality）的延迟。 Starkware 和 zkSync 等基于零知识的rollups，采⽤基于 ZK 的⽅法进⾏链下执⾏。运营者执⾏交易并向主链提交 ZK 证明。主链可以快速验证证明，并且可以向链上参与者确保只执⾏有效的状态转换。 另⼀类rollup是 Validium，它是介于 Plasma 和基于 ZK 的rollup的混合体。他们使⽤基于零知识的执⾏证明，同时将交易数据保持在链下。尽管这提⾼了系统的吞吐量，但它们遇到了与 Plasma 类似的问题。在这样的系统上，⽤⼾资⾦可能被冻结或扣押，也可能发⽣其他加密经济攻击。 虽然社区内部仍在争论哪种⽅法最好，但我们设想多个这样的rollup同时运⾏，共同形成我们设计的执⾏层。 3 数据可⽤性问题 --------- 虽然基于链下执⾏的架构提⾼了吞吐量，但它仍然受到以太坊等主链可以处理的数据量的限制。这是因为虽然执⾏是链下的，但验证或争议解决是严格在链上的。交易数据在以太坊上作为 calldata 提交，以确保数据可⽤于未来的重构。这极为重要。在optimistic rollup的情况下，运营商可能会提交⽆效交易，然后将向全世界隐瞒部分区块。这样，系统中的其他全节点将⽆法验证提交的认定是否正确。由于缺乏数据，他们将⽆法出⽰任何欺诈证明/质疑来证明认定确实⽆效。在基于零知识的rollup的情况下，ZKP 的稳定性确保接受的交易是有效的。然⽽，即使存在这样的保证，不透露⽀持交易的数据也会产⽣严重的副作⽤。这可能会导致其他验证者⽆法计算系统的当前状态。 我们认识到，要实现更⾼的吞吐量，我们不仅需要将执⾏置于链下，还需要有⼀个可扩展的数据托管层来保证数据的可⽤性。在后⾯的部分中，我们将讨论这种去中心化的数据可⽤性层的设计。 4 系统概述 ------ ### 4.1 分离组件 在⾼层次上来看，成功的区块链设计需要解决以下组件的问题： * **数据托管和排序**：该组件将接收交易数据并对其进⾏排序，⽽⽆需任何执⾏。然后它将以去中心化的⽅式存储数据并确保完整的数据可⽤性。我们称这个组件为DA层。 * **执⾏**：执⾏组件应该从DA层接受排好序的交易并执⾏它们。它应该创建⼀个检查点/认定/证明并将其提交给DR（Dispute Resolution）层，我们称之为执⾏层。 * **验证/争议解决**：该组件代表系统所锚定的主链。设计的安全性取决于该组件的稳定性和安全性。提交的检查点/断⾔/证明提交给执⾏层，执行层进行处理以保证系统只接受有效的状态转换（前提是数据可⽤）。我们将此组件称为DR层。 在这项⼯作中，我们提出了 Avail，它充当DA层。 我们设想多个roll-up计划或遗留执⾏层来形成执⾏层。 DR层可以是任何⽀持执⾏验证的安全区块链层。 ### 4.2 参与者和系统⽬标 **4.2.1 节点类型** 我们为 Avail 考虑以下类型的节点： * \*\*全节点：\*\*全节点下载区块并验证其正确性，不参与共识。他们存储区块链，但参与、保持诚实并没有激励。 * \*\*验证者节点：\*\*验证者节点参与区块⽣成，并且决定区块包含的交易和交易的排序。这些节点受到激励参与共识，并托管区块链。本质上，它们也是系统中利益相关的全节点。 * \*\*轻客⼾端：\*\*这些是具有资源限制的客⼾端，他们只保留区块头并根据需要从其他全节点查询交易数据。他们希望对区块可⽤有很⾼的信⼼，在查询数据时，他们还想要证明数据属于该区块的证据。 **4.2.2 系统⽬标** 我们的 Avail 设计应提供以下保证： (1) 去中⼼化的数据可⽤性区块链，即使有对⼿控制了少于三分之一的验证者节点的情况下，也会不断产⽣规范的区块。 (2) 即使存在⼀个⾮常强⼤的对⼿控制了系统中其他所有节点，但是可以访问区块头的规范链的诚实参与者也不会接受数据不可⽤的区块。 我们希望保证实现这两个系统⽬标。我们想强调的是，这两个⽬标都有不同的对抗假设。⽬标1只要绝⼤多数验证者节点保持诚实，就可以确保区块链系统继续以去中⼼化的⽅式运⾏。⽬标2确保有权访问区块头的规范链的外部参与者（例如运⾏轻节点的应⽤程序）⽆需信任任何全节点即可保证特定区块的基础数据可⽤。这是⼀个⾮常强的假设，它消除了检测数据、尝试隐藏的任何信任假设。在接下来的部分中，我们将讨论我们的构建理念，并认为它们实现了这些⽬标。 5 设计数据可⽤性层 ---------- ### 5.1 原语 **5.1.1 为什么冗余（redundancy）对于确保数据可⽤性很重要？** 假设我们有⼀个区块B划分为数据块 D_1_……,D_n_。区块⽣产者想要隐藏⼀个数据块。不失⼀般性，让我们假设第⼀个数据块被区块⽣产者隐藏。客⼾端可以随机查询⼀个数据块，以保证数据确实可⽤。它可以多次重复此过程，以获得对数据可访问性的⾜够信⼼。因此，对于每个查询，区块⽣产者需要⾜够幸运，D_1_不被查询。 然⽽，由于纠删码（erasure code）等⽅案包含冗余，假设n个数据块被编码为2n个数据块。纠删码确保了任何来自2n数据块的n个数据块⾜以重新创建数据。这使得区块⽣产者的隐藏任务变得更加困难。要隐藏⼀个特定的块，它⾄少需要使n+1个区块不可⽤。作为客⼾，查询恒定次数会⾮常有把握地表明数据确实可⽤。因此，冗余在数据可⽤性中起着⾄关重要的作⽤。 _【译者解释：纠删码是一种编码技术，它可以将n份原始数据，增加m份数据，并能通过n+m份中的任意n份数据，还原为原始数据。即如果有任意小于等于m份的数据失效，仍然能通过剩下的数据还原出来。 】_ **5.1.2 欺诈证明** 在上⼀节中，虽然我们讨论了数据冗余的优势，但我们忽略了纠删码数据块被区块⽣产者错误构造的情况。在这些情况下，即使⼤多数数据块确实可⽤，但可能⽆法访问整个区块数据。因此，欺诈证明由系统中的其他全节点构建并传播到轻节点。轻节点验证欺诈证明并确信收到的区块头属于错误的区块。欺诈证明的一个有趣特性是即使在少数诚实的假设下也能发挥作⽤。这是因为拥有⼀个诚实的完整节点作为邻居，就⾜以保证诚实的轻节点接收到欺诈证明。 设计时需要考虑的⼀个重要因素DA层是欺诈证明的⼤⼩。在简单的纠删码数据块中，为了证明编码不正确，需要将整个原始数据块传播到轻客⼾端。因此，欺诈证明⼤⼩为与区块的⼤⼩成最⼩线性关系。 **5.1.3 承诺（commitment）规模** 在基于⼀维纠删码的设计中，⼀旦区块⽣产者选择数据块 D_1_……,D_n_ ，它对数据块进⾏编码以⽣成 D_1_……,D_2n_ (假设编码率为0.5）。然后它在这些数据块上构建⼀个 Merkle 树，并将它的根保存在作为承诺的区块头中。⼀个获取D_i_的轻客⼾端获得Merkle成员资格证明以及数据块，以便它可以快速验证是否提供了合法数据块。承诺（Merkle 树的根）⼤⼩是任何设计中要考虑的重要因素。随着⼤量的承诺，区块头变得更⼤，从⽽导致⽹络流量增加。尽管基于更⾼维的纠删码的⽅案实现了更短的欺诈证明⼤⼩，但它是以更⼤的承诺为代价的。 ### 5.2 基于编码默克尔树的设计 我们在此简要讨论基于编码默克尔树 (CMT) 的⽅法。这种⽅法的新颖之处在于它提供了具有对数⼤⼩（logarithmic）的欺诈证明的恒定⼤⼩的承诺。 该设计在 Merkle 树的每⼀层都使⽤系统的纠删码。特别是基础层，它需要将k个数据块扩展到n个数据块的⽅式：即n个数据块中的k个数据块是原始数据块，其余的是奇偶校验符号（parity symbol）。树的下⼀层中的每个数据块都来自上⼀层的q个数据块的哈希。类似的系统纠删码也应⽤于该层，我们连续构建树的层级，直到我们有t个哈希作为承诺，保留在区块头中。 当轻节点对基础层数据块进⾏采样时，以不仅保证基础层的可⽤性，还保证了更⾼层的可⽤性的⽅式给出该数据块以及 Merkle 成员资格证明。采样_s 个基础层数据块的轻客⼾端， Merkle 成员资格证明还将⾼概率⾃动采样_s个中间层数据块。 对于全节点客⼾端（full client），解码树和⽣成欺诈证明也⾮常有效。通过访问区块头中的 CMT 的根层和之前层的⼀些编码数据块，哈希-感知剥离解码器对前⼀层进⾏解码，从⽽访问前⼀层的所有哈希。解码器继续进⾏，直到基础层中的所有数据块都被解码或发现编码不正确的证据。在前者的情况下，全节点可以访问整个数据，⽽在后者的情况下，它会⽣成欺诈证明并进⾏⼴播。 ### 5.3 基于 Kate 承诺的设计 在本节中，我们⾸先讨论 Kate 等人提出的多项式承诺等。然后我们继续讨论⼀个基于 Kate 承诺的DA层设计。 给定⼀个在⼀个双线性配对群上的多项式 𝜙 (𝑥) ∈ Z𝑝 \[𝑥\]，Kate等人提出了⼀种使⽤单个群元素对多项式做出承诺的⽅案。此外，该⽅案⽀持在某⼀点_i 开启承诺来得到𝜙 (𝑖) ，使⽤恒定⼤⼩见证⼈，允许验证者确认𝜙 (𝑥)确实在_i点被评估且得到了 𝜙 (𝑖)。承诺⽅案在计算上是隐藏和绑定的。承诺⽅案是加法同态的，并且⽀持单个⻅证⼈在同⼀多项式的多个点上进⾏⼀批开⼝。 给定这样的⽅案，区块⽣产者将区块数据分解成数据块，使得每个数据块都是该字段的⼀个元素。它将数据块排列成 n ⾏和 m 列，从⽽形成⼀个n×m 矩阵D . 它使⽤评估形式从每⼀⾏构造⼀个多项式以获得 𝜙1 (𝑥), . . . , 𝜙𝑛 (𝑥)。然后它提交每个多项式以分别获得𝐶1, . . . ,𝐶n 。为了冗余，它扩展 𝐶1, . . . ,𝐶𝑛 到 𝐶1, . . . ,𝐶2_n_。 它把 𝐶1, . . . ,𝐶2_n放_在区块头内部并⼴播它。表1显⽰数据排列和相应的承诺。 ![](https://storage.googleapis.com/papyrus_images/c7956a658dd564c61b9eef02823bb31f50608f2ccca8cce476950a036acf87b4.png) 查询数据区块的轻客⼾端将采样⼀些数据块 𝐷\[𝑖\] \[𝑗\]。除了得到数据，轻客⼾端获得⻅证人𝑤\[𝑖\] \[𝑗\]， 它可以⽴即使⽤上⾯讨论的 Kate承诺⽅案验证有效性。如果它查询同⼀⾏的多个数据块，批量承诺⽅案有助于为所有采样点提供⼀个⻅证人。因此，成员证明⾮常有效。 系统可以有两种全节点： 1. 具有整个区块的传统全节点， 2. 仅保留单列数据的列全节点。对于传统节点，它需要整个矩阵_D_, 将每列扩展到 2n个点并获得扩展矩阵_D ‘_。 然后它验证\*D ‘ \*的每⼀⾏，验证第𝑖行的承诺是不是 𝐶𝑖（满足 1 ≤ 𝑖 ≤ 2n）。 对于列全节点（column full node），它们只能获取并保留矩阵_D_的⼀列 . 他们将扩展每⼀列以检查它们是否属于扩展的承诺集。这是可能的，因为承诺和⻅证人是同态的。特别是，拥有𝐷\[1\] \[𝑗\], . . . , 𝐷\[𝑛\] \[𝑗\]和𝑤\[1\] \[𝑗\], . . . ,𝑤\[𝑛\] \[𝑗\]，节点可以同时扩展到 2 n个点并⽴即验证扩展开⼝是否有效。如果这样的列全节点的数量是𝑂(𝑚)，并且每个列全节点确保⾄少有⼀列可⽤，然后协同整个数据在列全节点内可⽤。 随着区块⼤⼩的增加，承诺的数量也会增加（保持列数固定，⾏数增加）。因此，承诺⼤⼩与区块⼤⼩成线性增⻓。但在这样的系统中，我们不需要任何欺诈证明。对于每个轻客⼾端，通信和计算开销是恒定的。对于每个全节点，计算开销为𝑂(𝑚∗𝑛𝑙𝑜𝑔(𝑛))，因为它需要执⾏ 𝑂(𝑚)FFTs，𝑂(1)对于每⼀列，以及⼀些⽤于验证的配对检查。但是，列节点只能执⾏ 𝑂(𝑛𝑙𝑜𝑔(𝑛)) 的⼯作，因为它只包含一列数据。 6 分析 ---- ### 6.1 攻击向量 任何DA层需要应对以下对数据可⽤性的攻击： 1. DA层中的绝⼤多数验证者想要更改已经完成的区块的顺序。 2. 绝⼤多数验证者创建了错误的区块头，即区块头中存在的数据的承诺是错误的。 3. 绝⼤多数验证者想要隐藏区块里的⾄少⼀个数据块。对于轻节点，这意味着⽆法以不可忽略的概率检测到数据的隐藏。对⼀个全节点来说，这意味着⽆法重建数据。 我们假定绝⼤多数验证者攻击DA层，因为我们希望最⼩化设计所需的诚实假设。 在达到最终性的假设下，重新排序攻击（攻击1) 很难发动。这是因为，为了成功发起这种攻击，攻击者需要打破底层共识的⾮模糊属性。特别是，最终确定层确保如果出现模棱两可的情况，可以识别出不诚实的各⽅并削减他们的利益。 在接下来的部分中，我们将展⽰如何在 CMT 和 Kate Commitments 这两种设计中应对攻击2和攻击 3。 ### 6.2 编码默克尔树 在基于 CMT 的⽅法中，区块提议者可能会尝试以两种⽅式构造错误的区块头： * ⼀层或多层中的纠删码是错误的。 * Merkle 树的构造是错误的。 在这两种情况下，欺诈证明都会收到攻击。可以访问数据的全节点可以构建错误编码证明并将其⼴播给轻客⼾端。 轻客⼾端从基础层随机采样也会采样更⾼层。由于每⼀层都是纠删码，因此对于⾜够多的采样，从 Merkle 树的任何层中隐藏任何数据块的概率⾮常低。⼀个完整客⼾端想要重建 Merkle 树，需要访问包含根哈希的区块头。除此之外，它需要每⼀层(1 − 𝛼)n 的样本，其中 n是一层中的所有的数据块，并且𝛼 是恶意块⽣产者需要使数据不可⽤以防⽌完全解码的编码符号的最⼩⽐例。有了这些信息，它就可以解码整个树。 因此，CMT ⽅法可以减轻攻击2和攻击3。 然⽽，我们注意到减轻攻击假设了⼀个诚实的全节点，它不如⽬标2中定义的那么强⼤。 ### 6.3 凯特承诺 在基于 Kate 承诺的⽅法中，攻击2相当于区块⽣产者的错误承诺。不失⼀般性，假设 𝐶1是错的。这意味着 从𝐷\[1\] \[1\]到 𝐷\[1\] \[𝑛\]⾄少有⼀个不属于𝐶1。再次，让我们假设 D\[1\] \[1\] ∉ 𝐶1. 这意味着以下⾄少有⼀个是正确的：:𝐷\[𝑛+1\] \[1\] ∉ 𝐶𝑛+1, . . . , 𝐷\[2𝑛\] \[1\] ∉ 𝐶2𝑛。 这是因为 𝐶𝑛+1, . . . ,𝐶2𝑛扩展⾃𝐶1, . . . ,𝐶𝑛 ，𝐷\[𝑛 + 1\] \[1\], . . . , 𝐷\[2𝑛\] \[1\]扩展⾃ 𝐷\[1\] \[1\], . . . , 𝐷\[𝑛\] \[1\]。因此，这种攻击被轻客⼾端以压倒性的概率捕获。 遇到攻击3时，恒常查询样本的轻客⼾端可以高度信任数据确实可⽤。这是由于前⾯讨论的数据中的冗余。对于⼀个全节点来说，它需要⾄少 从每⼀列下载提取n个数据块，以便它重建整个扩展数据。它检查承诺以了解下载的数据是否正确。⼀个列全节点需要执⾏类似的操作，但只处理⼀列数据。 因此，这种⽅法减轻了所有讨论过的攻击并实现了设定的⽬标。 7 实施 ---- 在本节中，我们将讨论 Avail 的实现细节。在上⾯讨论的两种技术中，我们使⽤基于 Kate 承诺的⽅法来避免欺诈证明并提供强⼤的数据可⽤性保证，即使存在强⼤的对⼿也是如此。 ### 7.1 共识 我们需要我们的验证者就下⼀个区块达成共识，该区块包含有序交易集以及冗余纠删码数据。尽管存在许多可能的区块链共识协议，但我们选择了权益证明 (PoS) 系列的共识算法。我们想要⼀个⽀持⼤量验证者、可证明的确定性和强⼤的安全框架的 PoS 共识。特别是，我们选择了 Polkadot 使⽤的 BABE/GRANDPA 混合共识 。它使⽤两个独⽴的协议来进⾏区块⽣产和最终确定。 区块⽣产是使⽤区块链扩展协议（BABE）的盲分配完成的。区块⽣产者基于可验证随机函数 (VRF) ⽣成区块。该协议不假定访问中央时钟。如果没有选择验证者作为特定槽的区块⽣产者，或者如果选择的⽣产者出现故障，则有⼀个⼆级区块⽣产者可以介⼊。BABE 确保了活跃性，这保证了提交给诚实玩家的交易最终将被插⼊到链中。 GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) 是⼀个确定性⼩⼯具，确保可证明的确定性。如果没有确定性⼩⼯具，⽤⼾只能拥有概率确定性，就像在传统区块链系统中⼀样。GRANDPA 保证区块达到更快的最终确定性，并且最终确定的区块永远不会被还原。 ### 7.2 全节点 为了在独⽴的区块链中实现我们的设计，我们使⽤了 Substrate 框架. Substrate 提供了极⼤的灵活性来实现具有固有 BABE/GRANDPA 共识⽀持的⾃定义运⾏时间逻辑。我们的设计需要对Substrate的底层代码库进⾏重⼤更改，因此我们开发了⼀个分⽀。 我们所做的主要更改是： * 区块的内容被排列成数据矩阵，在区块构建过程中执⾏扩展和多项式承诺⽣成。 * 区块头结构更改为包含承诺作为区块头的⼀部分。 * 根据内存池上的交易数量，区块⼤⼩是动态的。但是，允许的最⼤区块⼤⼩为 4 MB，其中包括数据冗余。 * 引⼊了⽀持数据可⽤性查询的其他 RPC ⽅法。轻客⼾端可以使⽤这些来获得对可⽤性的信⼼。 为了我们的网络发展，我们已经修改了 Polkadot 应⽤程序来构建我们的区块浏览器。 ### 7.3 轻客⼾端 在我们⽬前的设计中，轻客⼾端是参与系统的应⽤程序节点，⽆需投⼊资源来托管完整节点。牢记这⼀点，我们开发了⼀个轻客⼾端，它跟踪链头并执⾏可⽤性查询以获得对感兴趣区块的可⽤性的信⼼。客⼾可以获得被认为适合特定应⽤的尽可能⾼的信⼼。我们设想应⽤程序使⽤我们的链来托管轻客⼾端。 ### 7.4 链上可⽤性保证 DR层，在验证证明或解决争议时，需要确保底层数据确实可⽤。 为了以有机的⽅式实现这⼀点，我们希望保证以太坊（或任何⽀持此逻辑的主链）上的智能 合约的数据可⽤性。这允许检查点/认定/证明接受智能合约，与这个轻客⼾端合约进⾏通信并直获得 DA 保证。 我们讨论了如何提供链上 DA 保证的三种主要⽅法。我们还简要提到了它们的优点和局限性。 **7.4.1 轻客⼾端作为智能合约** 实现 DA 保证最明显的⽅法,是将传统的轻客⼾端托管为智能合约。这提供了与链下轻客⼾端相同的链上保证。但是，这种⽅法存在三个主要挑战： * 智能合约需要 Avail 链头的持续供给。主要关⼼的是谁提交了这些链头，我们如何验证提交的链头，以及我们如何补偿这些提交⽅产⽣的成本。我们可以从现有的跨链桥接解决⽅案中汲取灵感来解决这些问题。 * DA 保证⾼度依赖于查询的随机性。另⼀⽅⾯，智能合约只能运⾏确定性程序。我们可能会使⽤像 RAN-DAO 这样的解决⽅案来消除这个瓶颈。 * 即使链头可⽤于合约，随机⽣成查询并提交证明，智能合约仍需要验证响应以确信数据可⽤。在不⽀持现场操作操作码的情况下，链上 Kate 承诺验证具有挑战性。我们可以提出新的预编译合约来⽀持它们，但实施需要社区内的共识和硬分叉。 **7.4.2 数据可⽤性预言机** 另⼀种被⼴泛接受的从智能合约中卸载昂贵任务的⽅法，是基于预⾔机的⽅法。当需要为特定区块提供链上 DA 保证时，可以激励多个预⾔机节点提交各⾃的可信度因⼦。链上合约可以聚合指标来决定它是否⾜够保证数据可⽤。尽管在社区中被⼴泛接受，但这种⽅法必须信任预⾔机节点，从⽽降低了安全保障。信任的数量可以通过适当的激励和去中⼼化来限制。 **7.4.3 ⾮交互式 DA 证明** 轻客⼾端构造和安全保证基于交互式协议，客⼾端在该协议中查询完整节点，以获取他们验证需要的证明，以获得对可⽤性的信⼼。我们需要探索构建⾮交互式协议，在其中轻客⼾端可以获取可⽤性证明，同时不影响安全性。但是，数据现在可⽤的保证并未强制其未来的可⽤性。我们需要仔细设计协议，同时牢记安全性、效率和实⽤性。 **7.4.4 概念实施证明** 为了强调协议的可⾏性，我们基于上⾯讨论的第⼆种设计，实现了使⽤ Chainlink预言机网络的⼀个链上轻客⼾端。每当链上合约需要特定区块的可⽤性保证时，它会请求链上 Chainlink Oracle，链上 Chainlink Oracle使⽤事件（events）与多个链下预⾔机节点进⾏通信。这些链下节点使⽤⾃⼰的轻客⼾端或托管实例来获得信⼼并将通过Chainlink Oracle传回原始合同。激励是使⽤ LINK代币处理的。 除了基于预⾔机的⽅法外，我们还在研究上⾯讨论的其他⽅法，以开发具有更强数据可⽤性保证的链上轻客⼾端。 8 附加模块 ------ ### 8.1 应⽤特定的数据检索 我们希望我们的构造允许应⽤程序下载仅与它们相关的数据。为了实现这⼀点，我们希望全节点（或列全节点）向应⽤程序客⼾端证明，与应⽤程序相关的完整数据集已被传达。 对于基于Kate承诺的⽅法，让我们假设每个数据块，都以每个应⽤程序特定的应⽤程序标识符 (ID) 开头。让数据矩阵𝐷𝑛×_m_ 按列填充，并让与特定应⽤程序相关的所有交易都放在连续的数据块中。不完整的数据块被适当地填充。让应⽤程序数据从 𝐷\[𝑖1\] \[𝑗1\] 排列到 𝐷\[𝑖2\] \[𝑗2\]，其中 1 ≤ 𝑖1,𝑖2 ≤ 𝑛 and 1 ≤ 𝑗1 ≤ 𝑗2 ≤ 𝑚。 通过此设置，应⽤程序客⼾端可以从完整节点查询其数据。全节点需要为所有数据块提供开⼝ 𝐷\[𝑖1\] \[𝑗1\] to 𝐷\[𝑖2\] \[𝑗2\]，按列取。最重要的是，它还需要为 𝐷\[𝑖1−1\] \[𝑗1\] (或者 𝐷\[𝑛\] \[𝑗1−1\] if𝑖1 = 0) 提供开口，或者 𝐷\[𝑖2 + 1\] \[𝑗2\] (or 𝐷\[0\] \[𝑗2 + 1\] if 𝑖2 = 𝑛)。然后，客⼾可以验证对于内部𝐷\[𝑖1\] \[𝑗1\] to 𝐷\[𝑖2\] \[𝑗2\]的所有开⼝，数据开始具有正确的 ID，⽽对于其余两个开⼝，数据具有不同的 ID。这将证明客⼾端已收到所有相关数据，假设排序正确完成（等效地，绝⼤多数验证者在DA层）。 如果客⼾端处理列全节点，它最多需要处理 (⌈𝑠𝑖𝑧𝑒/𝑛⌉ + 2)列全节点。 > Medium：[https://mirror.xyz/nibajie.eth](https://mirror.xyz/nibajie.eth) > > 微博：泥巴街0601 > > 公众号：泥巴街 > > 推特：[https://twitter.com/Jellyfi1Jellyfi](https://twitter.com/Jellyfi1Jellyfi) --- *Originally published on [泥巴街](https://paragraph.com/@0xb1961a3aaa359de2f096da26771ea205c6031f4e/polygon-avail)*