Fuel：模块化执行案例（第 1 部分）

Notes

0xa785

November 3rd, 2022

模块化执行案例

区块链空间正越来越多地转向模块化架构，以实现真正的可扩展性。即使是像以太坊这样以前完全单片的链，也正在转向模块化设计，以克服单片区块链设计带来的挑战。

模块化区块链堆栈的核心组件之一是执行层，Fuel正在为模块化区块链堆栈构建最快的执行层。

什么是模块化执行层？他们将如何实现更具可扩展性的区块链系统？

与单片执行层相比，模块化执行层具有两个核心优势：

1，单片链将计算和验证耦合在同一层，导致安全性低于标准和有限的可扩展性。模块化执行层通过解耦计算和验证来避免这种情况，从而大规模提供更强大的安全保证。

2，单片链在可以支持的速度和计算种类方面被锁定在低效的技术中。另一方面，可以专门设计模块化执行层，以优化高效计算。

这篇文章会详细阐述了第一个核心好处，第二个好处将在第2部分中探讨。

单片区块链基础：计算与验证

要了解模块化执行层（MEL）带来的创新，首先我们需要了解单体区块链如何处理计算和验证。

区块链依赖于执行交易并将它们捆绑成一个区块的实体网络 - 这些被称为区块生产者。如果没有制衡，恶意区块生产者可能会在区块中包含无效交易（例如，将代币铸造到他们自己的地址）。为了防止这种情况，区块链依靠其他节点的网络来确定区块的有效性，然后再将其添加到其链版本中。

这导致了区块链运行所需的两个核心功能：

区块生产（即计算） - 执行交易并应用单个状态转换来构建区块。

块验证（即验证） - 确认状态转换有效。

单片链的计算与验证

注意：为了便于理解，本文提供了关于区块生产和验证如何在单片区块链上工作的简化说明。实际上，该过程更为复杂，并且可能因特定链的设计而异。但是，许多相同的核心原则适用。

在大多数单体区块链设计中，计算和验证由相同的实体执行 - 验证者（即全节点）。当用户发送交易时，验证器将执行交易，然后将相应的状态转换包含在块中。

一旦一个区块被创建和传播，其他完整节点就会下载该区块并重新执行该区块中的交易，以确认其有效。如果区块是有效的，假设它们是诚实的，则全节点将该区块附加到他们的链版本上，从而证明其有效性。

有时，应用程序或用户需要访问区块链的状态，但不希望产生运行完整节点和独立验证所有交易的高资源需求。为此，它们可以运行轻量级客户端，这些客户端假定全节点提供的区块仅包含有效交易。

他们不会下载完整的区块链，也不会验证所有以前的交易是否有效。相反，他们必须相信大多数完整节点是诚实的（即只在他们的链副本中包含有效的区块）。

这被称为诚实多数假设，也是大多数单体区块链容易受到51%攻击的原因。在单片模型下，由于需要诚实的大多数完整节点来验证区块链是否有效，因此轻客户端被迫信任大多数。

如果超过一半的完整节点是不诚实的，轻客户端无法知道这一点，因此他们最终将遵循无效链。

诚实多数假设 - 可扩展性的限制

单片链的可扩展性受到它们对这种诚实多数假设的依赖的严重限制。这是因为，为了增加交易吞吐量，必须增加区块大小和/或频率，以便在相同的时间内处理更多的交易。这增加了全节点的资源需求（和相关成本）;更大/更快的块=更多的计算=更高的成本。

随着运行全节点的成本增加，更多的实体将选择运行轻客户端，依靠越来越小的全节点网络来验证链的有效性。区块验证的日益集中化是对单体链安全的主要威胁，因为更集中的验证者池更容易受到攻击，也更容易串通。

模块化执行：解耦计算和验证

好消息是，区块链系统可以摆脱依赖于诚实多数假设的设计。为了避免这种单片设计的陷阱，模块化区块链堆栈将计算与验证分离。通过将执行（即计算）移出基础链（通常称为“父链”），可以在不影响去中心化的情况下实现更大的规模。

什么是模块化执行层？

在模块化区块链堆栈中，执行层负责计算 - 换句话说，处理交易和应用单个状态转换。

Fuel将模块化执行层定义为：为模块化区块链堆栈设计的可验证计算系统。更具体地说，一种欺诈或有效性可证明的区块链（或其他计算系统），它利用模块化区块链来实现数据可用性。

为了进一步澄清，如果计算系统：1）不能证明欺诈或有效性，或者2）不将数据可用性卸载到另一层，则计算系统不是模块化执行层。

与单体区块链一样，模块化执行层采用专用区块生产者网络。这些实体处理执行交易和生成区块的资源密集型过程。然而，与单片系统不同，验证不是在执行层处理的，而是在模块化区块链堆栈的较低级别处理的。

验证 - 保持区块生产者的诚实

模块化执行的天才之处在于，只要验证（即区块验证）是去中心化的，计算（即区块生产）就不需要去中心化。区块大小可以增加，导致产生区块的节点中心化 - 但只要验证解耦，无效区块就不会添加到链中。

但这是如何工作的呢？如果我们允许区块生产保持中心化，我们如何确保安全性得到保护？这就是模块化发挥作用的地方。

模块化执行层将执行的资源密集型功能抽象为强大的区块生产者，这些生产者捆绑并执行批量交易，并定期将这些交易作为区块发布到父链（结算/共识/数据可用性层）。为了保持这些区块生产者的诚实，还有其他非区块生产的完整节点（通常称为“验证者”或“证明者”），它们下载并重新执行发布到父链的区块，以确保它们只包含有效的交易。

这些全节点如何传达交易的有效性或无效性的细节取决于模块化执行层是采用乐观模型还是零知识模型。在乐观 MEL 的情况下，全节点仅在检测到无效交易时才采取行动（通过欺诈证明）。相反，在零知识MEL的情况下，全节点主动证明交易的有效性（通过有效性证明）。在任何一种情况下，区块生产者提供的所有交易的有效性或无效性都在父链上得到证明，而不是在模块化执行层上。

示例：Optimistic模块化执行层上的欺诈证明

为了提供更深入的说明，让我们探讨Optimistic MEL 的情况（假设所有交易都是有效的，除非另有证明）。如果即使是模块化执行层上的单个完整节点在父链上发布的区块中检测到无效交易，它们也可以生成欺诈证明（在预定义的“争议解决窗口内”），以加密方式证明交易无效。

根据特定模块化堆栈的结构，可以通过多种方式处理，例如：

1，在具有沉降层的模块化堆栈中：

全节点将欺诈证明提交给结算层上的专用争议解决合约，该合约直接重新执行交易（请注意，这要求MEL交易的结构使其能够以确定性的方式在结算层的虚拟机上证明欺诈 - 例如，FuelVM被设计为在EVM中可证明欺诈，以便在以太坊上进行结算）。

如果交易无效，违规的区块生产者将受到砍杀的惩罚（即他们损失资金），“举报人”将获得这些资金的一部分奖励，并且链的状态将恢复到无效交易之前的状态。由于无法保证无效事务之后的任何事务都对应于有效状态，因此这些后续事务将重新执行。

2，在没有沉降层的模块化堆栈中：

全节点通过点对点网络八卦欺诈证明，以警告轻客户端该区块包含无效交易。使用欺诈证明作为区块生产者不诚实行为的证据，全节点可以在父链上提出惩罚交易，从而削减区块生产者的资金。

由于没有结算层来决定链的“规范”版本，恶意全节点理论上可以选择不拒绝该区块;但是，欺诈证明已经传达给轻客户端，因此他们知道不要遵循恶意全节点的链版本。因此，社会共识保证了无效区块将被拒绝。

在任何一种情况下，由于验证过程被载入在父链而不是执行层上，因此安全性被外包给父链，这意味着执行层本身可以在较低的安全保证下运行。即使执行层上99%的全节点是不诚实的，也只需要一个诚实的全节点来确保执行层只包含有效的交易。

这意味着模块化执行层（和 MEL 轻客户端）可以基于单个诚实的少数假设运行，而不是依赖于诚实的多数全节点。

在模块化执行层上，轻客户端只需要依靠一个诚实的全节点来保证链的有效性。

无效区块只能由单片系统中的大多数完整节点还原，而模块化系统中的单个完整节点可以使用欺诈/有效性证明强制还原无效交易。

这如何实现可扩展性

允许计算在父链下进行，可以大幅增加交易吞吐量。区块大小可以显着增加，而不必担心区块生产的集中化，因为单独的区块验证过程使区块生产者保持诚实。

虽然较大的区块确实给执行验证的完整节点带来了更高的负担，但诚实的少数假设意味着该领域的中心化威胁较小，因为依赖于不诚实多数的基于中心化的漏洞变得不可能。

轻客户端还可以在模块化架构下以更高的安全保证运行，因为欺诈证明使他们能够根据来自单个诚实完整节点的证明来识别无效交易（与单片系统相反，单片系统要求轻客户端相信至少有一半的完整节点是诚实的）。

模块化执行层上的轻型客户端比单片客户端具有更高的安全保证

此外，区块生产者知道任何恶意活动都会被检测到并导致砍伐，因此他们甚至不太可能试图做出不诚实的行为。因此，执行层可以进行计算优化（即处理大量事务），同时依赖于模块化堆栈的安全优化的较低级别。

模块化执行：潜在挑战

这种模块化架构确实带来了一些额外的技术和博弈论挑战。

数据可用性

虽然欺诈/有效性证明使诚实的完整节点能够证明欺诈，但还有一个问题：数据可用性。为了生成证明，全节点依赖于区块可用性，因为它们需要下载并重新执行区块中的所有交易以确定其有效性并生成证明。

理论上，恶意区块生产者可以只将区块头发布到父链，可能会扣留部分或全部相应数据。这可以防止全节点生成欺诈/有效性证明来提醒轻客户端注意该问题。

在尝试验证块时，全节点很容易识别数据何时被恶意块生产者扣留。在这种情况下，他们可以简单地假设链是无效的，并从中分叉。但是，轻客户端如何在不下载整个区块的情况下确定数据是否被区块生产者扣留？

一种称为数据可用性抽样（DAS）的新技术使轻客户端能够概率地确定整个块是否已发布。简而言之，轻客户端从全节点请求块的一小部分随机小部分（或“样本”）。

如果所有请求的样本都可用，则假设有足够的轻客户端执行数据可用性采样，这很可能证明整个块都可用。如果块的任何部分不可用，轻客户端知道数据已被保留，因此可以从该版本的链中分叉。

这项技术的完整解释超出了本文的范围，但您可以在此处阅读有关它的更多信息。最终，重要的一点是，DAS 使轻客户端能够识别无效块，即使恶意块生产者隐瞒数据也是如此。

验证者的困境

另一个潜在的问题是被称为“验证者困境”的现象。简化版本如下：

如果区块生产者知道全节点会识别不诚实的活动，他们将诚实行事以避免被砍伐。

随着时间的推移，如果全节点假设区块生产者将继续诚实行事，他们就没有动力继续验证区块，因为他们永远不会因识别无效交易而获得奖励。

如果全节点没有经济激励继续验证区块，他们可能会停止这样做。在这一点上，区块生产者不诚实的行为变得可行。即使仍然有非零数量的全节点，区块生产者贿赂剩余的全节点以忽略足够有价值的无效交易在财务上也可能变得可行。

这以一个循环难题告终，即模块化执行层变得越安全（即区块生产者不诚实行为的动机越小），它就越倾向于降低安全性（即全节点不再被激励来验证区块）。另一方面，它的安全性越低，安全性就越高。

这种困境可以通过多种途径来缓解（有关这些因素的博弈论分析，请参阅这篇广泛的文章）：

利他主义 - 因为 MEL 只需要一个诚实的验证者，只要至少有一个利他主义的完整节点在运行，系统就会保持安全。然而，虽然这在实践中可能足够安全，但对于控制大量资产的系统来说，这并不能提供足够的保证。

经济利益 - 有许多实体有经济激励来运行超出潜在举报人奖励的完整节点。例如，区块浏览器、流动性提供商或 dapp 等产品和服务需要访问 MEL 的完整状态才能有效地运行其业务。然而，这些实体（理论上）容易受到恶意区块生产者的贿赂。

鲸鱼 - 在MEL上拥有大量资产的实体可以选择运行一个完整的节点，以确保他们的利益得到保护并且链是安全的。

快速提款 - 由于乐观的 MEL 在保证模块化堆栈的较低层的最终性之前依赖于争议解决窗口，因此在此窗口过后，从 MEL 到和解层的提款不会最终确定。因此，第三方服务有一个市场，这些服务提供快速提款，接受MEL上的代币，并立即将相同的代币（减去费用）发送给结算层的用户。为了确保在结算层发送资金后不会恢复MEL状态，服务提供商被激励在进行此类交易之前验证链的有效性。

区块生产者 - 可以对提交基于先前无效区块构建的区块的区块生产者进行处罚。有了这样的机制，区块生产者将被激励在提交区块之前验证链的有效性。

虽然上述缓解策略本身可能并不完全有效，但当结合起来时，有明显的动机让许多不同的各方继续在 MEL 上运行完整节点并验证链的状态。