<!--StartFragment-->

<!--EndFragment-->

此前，我们分别发布了两篇文章， We need a PST consensus! 与 Native and Bundle mixed sequencing optimization solution，第一篇主要抛出我们发现的问题，第二篇从交易数据定序上提出了优化方案。但最主要的数据去中心化可验证性的问题一直没有进行讨论。本文将从这个角度来对 SmartWeave 可验证性的重要性与解决方案展开探讨。

注：此文中所提到的问题在 2023 年初，通过社区的努力已经得到解决，在此仅做案例分析，希望能对感兴趣的人提供一定的参考。

去信任化共识的前提

在区块链行业中，去中心化一直是被人提及的指标，但我们始终认为去中心化并不是最终的目的，它所要达成的目标是：去信任化共识。

这个概念比较抽象，我们可以将其拆解出三个维度：

1. 可验证性，数据可以被验证；
2. 去准许性，任何第三方都可以作为节点来参与验证，无需准许；
3. 抗审查性，数据是不可被审查并篡改的。

只要满足以上三个维度即可。当然条条大路通罗马，目前主流的链上计算 EVM 公链可以达成这样的目标，无准许可验证的链下计算模式也同样可以达成去信任化的共识，Arweave 上的智能合约就是使用了这种模式。

那什么是可验证性？

可验证性是不同的人或机构通过检查相同的证据、数据和记录，能够得出相同的结论。

在一个系统中，为了达成可验证性，所有节点必须对原始数据具备相同的访问权，即节点可以在任何时刻获取完整数据；但是仅有完整数据仍然无法达成去信任化，另一个必要条件是验证这些数据是不可篡改的，也就是具备抗审查性。数据只要满足了这两个条件，就能够转化为证据，任何第三方都可以通过计算该证据得出唯一结果，这就是通过无准许的可验证性达成了去信任化共识。

以比特币为例，所有人能够平等地获得比特币的数据，并可验证其账目是唯一不可篡改的，这是比特币达成去信任化共识的重要前提。试想，如果比特币不具备无准许的可验证性，那还有谁会相信这套系统呢？

原生 SmartWeave 的可验证性优势

之前我们提到，Arweave 上的智能合约使用的是无准许可验证的链下计算模式来达成去信任化共识的。之所以采用这种模式是因为 Arweave 是一条存储公链，只有存储能力，不具备链上计算能力。但也正是这种特性，让 Arweave 可以作为 Layer0，为数据提供不可篡改，可追溯的存储环境。而承担链下计算重任的智能合约系统，我们称为 SmartWeave。

原生的 SmartWeave 设计非常聪明，所有交易都在用户个人的浏览器上运算，不需要依赖任何人。

我们不防用实际案例来对比 Ethereum 智能合约和原生 SmartWeave 的验证。

如果用户在 Ethereum 上发行了一个 Token，而该 Token 仅有两笔转账交易，在这种情况下用户想要验证状态，必须完成以下动作：

1. 下载 Ethereum geth 客户端，运行 Ethereum 节点；
2. geth 会从创世区块开始，运算所有 Ethereum 智能合约，这些合约包括 Compound、Uniswap、成千上万的代币等等；
3. geth 同步到最新区块，交易中包含了该 Token 的两笔转账，完成验证。

那如果用户使用原生 SmartWeave 来发行 Token，验证 Token 的余额状态仅需几步：

1. 下载 Arweave 所有区块头；
2. 下载这两笔交易数据；
3. 使用区块头的交易信息验证这两笔交易的 data_root；
4. 运算这两笔交易，完成验证。

可以看出，原生 SmartWeave 只需进行两笔交易验证计算，成本远远低于对所有 Ethereum 智能合约的验证计算，这是原生 SmartWeave 设计上的优势，用更简单的无准许可验证来达到去信任化共识。

但去信任化也有不同的概念，我在过去的一篇文章 Evolution of the Blockchain Application Model along with Changing Consensus 中提过：

• 绝对去信任化：不信任任何人，自行验证区块链所有交易，获得完全去中心化的账本；
• 相对去信任化：信任服务商，通过服务商获得账本数据，并使用其他多个服务商的数据进行交叉验证。

原生 SmartWeave 就属于绝对去信任化，由于完全去中心化，会在性能与费用上有所限制，所以开发者们为了能在用户体验上达成一种平衡，将共识模式向相对去信任化的方向演进，Bundle SmartWeave 就这样出现了。

Bundle SmartWeave 的可验证性挑战

注：以下问题在 2023 年初，通过社区的努力已经得到解决，在此仅做案例分析使用，希望能对感兴趣的人提供一定的参考。

Bundle SmartWeave 的机制我们在之前的文章中都有提及，简单说就是通过一个定序器 Sequencer 将智能合约在 L1 与 L2 上的交易数据进行收集与排序，然后再由一个服务商分批 Bundle 这些交易数据上传至 Arweave 永存。这种模式可以将海量数据捆绑在一块一次性上链存储，大大提升了系统效率，降低上链成本，是帮助 Arweave 生态扩容的有力创新。但同时其中的两个点也面临了去准许的可验证性挑战：

• 混合定序器的可验证难题。这部分内容我们在之前的文章 Native and Bundle mixed sequencing optimization solution 已经作了详细介绍，并提出了相应的优化方案想法，感兴趣的可以作为参考；
• Bundle 交易的可验证难题。这里的 Bundle 交易指的是将各种文件、数据混合在一起捆绑上链的模式，这是一种非常常规的模式。其验证性挑战为，假如一笔仅有 1 KB 的 SmartWeave 交易被打包到了一个超过 30 GB 的 Bundle 交易中，那用户想要验证这笔 1KB 大小的 SmartWeave 交易就需要下载所有 30 GB 的无关数据，这将大大提升可验证性难度，降低验证效率。

在这种情况下，如果用户想要通过去准许可验证方式来验证交易状态的话，则需要：

1. 下载 Arweave 所有的区块头
2. 下载包含这两笔交易的 Bundle 数据包，使用区块头的交易信息验证这两笔交易的 data_root。但这两笔交易可能分别打包到了一个 30 GB 和一个 40 GB 的 Bundle 数据包中，此时用户需要下载 70 GB 的数据包。
3. 从数据包中找到这两笔交易，并运算完成验证

此外，用户在后续验证中，由于无法预判未来的交易会如何打包，因此需要下载并验证所有的 Bundle 数据包。只要漏掉任意一笔交易都有可能造成不小的后果。这无疑是一条行不通的方案。

用户唯有通过信任 Sequencer，Sequencer 信任混合 Bundle 交易方这一条信任链条来达成高效运行。但这就失去了去信任化共识。

<!--StartFragment-->

<!--EndFragment-->

提升可验证性的解决方案

我们经过长期的实践与研究，可以针对 Bundle SmartWeave 可验证性弱的问题提出两个解决方案。

单 Merge 节点方案

在上节中提到的可验证性挑战其核心问题在于数据被常规 Bundle 交易混合打包上传导致。所以一个可行的解决方案是为 SmartWeave 设计特殊的 SmartWeave Bundle 节点，该节点只接收和上传 SmartWeave 相关交易，SmartWeave 的运算环境也仅认可该节点上传的交易数据。我们称其为Sequencer 与特殊 ANS-104 Bundle 节点的 Merge 方案。

在这个方案中，Merge 节点兼具了 Sequencer 与 Bundle 角色。不管是来自 L1 还是 L2 的 SmartWeave 交易数据，Merge 节点都会按照规则进行排序，然后只将 Bundle 这些 SmartWeave 数据并上传至 Arweave 进行永存。这样做的好处在于任何第三方都可以轻松地下载到所有 SmartWeave 数据包进行验证，做到无准许的可验证性，以此达到去信任化共识。

<!--StartFragment-->

<!--EndFragment--> 多 Merge 节点网络方案

在单 Merge 节点方案中，只服务于 SmartWeave 数据的特殊 Bundle 交易保障了可验证性，Sequencer 的混合定序模式保障了抗审查性与去准入性。但尽管如此，数据上传的单点化问题依然存在。从长远来看，我们需要一个更加去中心化解决方案。

那就是多 Merge 节点方案。该方案将单 Merge 节点转化为一个去中心化的多 Merge 节点网络，通过该网络的原生代币来达到类似 PoS 链的运行模式，每个 Merge 节点都需要质押一定数量的代币才能成为合法的数据节点。只有合法的 Merge 节点上传的数据才被认为是合法数据，并可被所有其它 Merge 节点下载用于验证。作恶节点将被 Slash 质押代币作为惩罚。

在该网络中，每个 Bundle 数据包的上传者可以通过 Arweave 的最新区块 Hash 作为种子进行随机选举，保证网络不会被单节点垄断。各 Merge 节点之间只需要共享交易池即可。

<!--StartFragment-->

<!--EndFragment--> 这是一个非常奇妙的模型。如果把多 Merge 节点网络与 Arweave 数据共识合并起来，你将得到一个 PoS 公链，与传统 PoS 公链不同的是，你只需关注在业务侧需求的处理上，系统的共识已经通过 Arweave 得到了很好的保障。由于这个模型已经具备了可验证性，去准许化与抗审查性的特点，Merge 节点中的混合定序部分都可以从代码库中移除。

这种想象空间是空前的，也许它将会是去信任化共识的最终章，开启以 Arweave 作为 Layer0 的无限扩容的新方向。由于篇幅关系，我们会在未来的文章中再作更加深入的探讨。

最后

本文深度探讨了 SmartWeave 可验证性的重要性与解决方案，其核心观点是作为在未来会承载各种重要业务的智能合约平台，无准许的可验证性是其重点要达成的目标。必须用只服务于 SmartWeave 数据的特殊 Bundle 模式取代常规 Bundle 模式，以此提高数据可验证性，让去信任化共识保障整个生态发展的未来。

关于 PermaDAO：Website | Twitter | Telegram | Discord| Medium | Youtube