Optimizing SVM Merklization on SOON for Enhanced Blockchain Performance

随着区块链技术的不断发展，Solana虚拟机（SVM）正逐渐成为多个Layer-2（L2）解决方案的首选执行层。然而，SVM原始设计中存在一个关键限制——其全局状态根的模糊性，这对构建可靠的汇总系统构成了重大挑战。在区块链系统中，全局状态根对于确保数据完整性、支持欺诈证明以及实现跨层操作至关重要。

在典型的汇总系统中，提议者会定期向Layer-1（L1）提交L2状态根（Merkle根），为L2链建立检查点。这些检查点不仅支持对任何账户状态的包含证明，还能实现从一个检查点到另一个检查点的无状态执行。欺诈证明机制正是依赖于此，参与者可以通过提供包含证明来验证争议中的有效输入。此外，Merkle树还能增强规范化桥接的安全性，允许用户为提现交易生成包含证明，从而确保L2和L1之间的无信任交互。

针对这些挑战，SOON Network在SVM执行层中创新性地引入了Merkle树技术，使客户端能够提供包含证明。SOON通过独特的条目设计，将状态根直接嵌入基于SVM的区块链，并与历史证明（Proof-of-History）相结合。这一技术突破使得SOON技术栈能够支持新型SVM汇总系统，显著提升了系统的安全性、可扩展性和实用性。

Solana的Merkle化难题

Solana在设计之初就以高吞吐量为核心目标，这使其在早期开发中不得不做出一些设计上的权衡。其中最具影响力的决定之一是关于何时以及如何对其状态进行Merkle化处理。这一决策虽然提升了性能，但也给客户端在证明全局状态、交易包含性和简单支付验证（SPV）方面带来了重大挑战。

由于缺乏一个持续哈希的状态根来代表Merkle化的SVM状态，这为轻客户端和汇总系统等项目带来了相当大的困难。接下来，我们将通过对比其他区块链的Merkle化实现，深入分析Solana协议架构带来的独特挑战。

比特币的Merkle树实现

在比特币网络中，交易通过Merkle树存储在区块中，Merkle树的根则存储在区块头中。比特币协议会对交易的输入和输出（以及其他元数据）进行哈希运算，生成交易ID（TxID）。当用户需要在比特币上证明状态时，只需计算Merkle证明，将TxID与区块的Merkle根进行验证即可。

值得注意的是，比特币交易还可以包含Taproot脚本，这些脚本会生成交易输出。在验证时，可以通过重新执行脚本，使用交易的输入和脚本的见证数据，并与输出进行比对验证。

以太坊的Merkle树架构

与比特币类似，以太坊使用一种源自Merkle树的自定义数据结构，称为Merkle Patricia Trie（MPT）来存储交易。这种数据结构专为支持快速更新和大规模数据集优化而设计，因为以太坊需要管理的输入和输出数量远超比特币。

以太坊虚拟机（EVM）作为全局状态机，本质上是一个巨大的分布式计算环境，支持可执行的智能合约。每个合约在全局内存中保留自己的地址空间，这使得验证以太坊上的状态变得更加复杂。客户端不仅需要考虑交易的结果（如日志、返回代码等），还需要考虑交易所引发的全局状态变化。

EVM巧妙地利用了三种重要的Trie结构，它们的根都存储在每个区块头中：状态Trie、交易Trie和收据Trie。状态Trie是以太坊上所有状态的巨型键值存储；交易Trie存储区块中所有交易；收据Trie则存储每个交易的执行信息。通过这些结构，客户端可以全面验证交易包含性、执行结果和状态变化。

Solana的独特设计

Solana实现高吞吐量的关键之一是其不同于以太坊的多层树结构。虽然Solana的领导节点在创建区块时确实会计算Merkle树，但其结构与EVM中的Merkle树存在显著差异。这正是SVM基础汇总系统面临的主要问题所在。

Solana将交易Merkle化为所谓的”条目”，每个插槽可以包含多个条目，因此每个区块可以有多个交易根。此外，Solana仅在每个时代（约2.5天）计算一次账户状态的Merkle根，且该根不会存储在账本中。实际上，Solana区块头根本不包含任何Merkle根，而是包含前一个和当前区块的区块哈希，这些哈希通过Solana的历史证明（Proof of History，PoH）算法计算得出。

历史证明的设计使得从区块哈希中证明状态变得非常困难。Solana被设计为流式传输PoH哈希以维持其时间流逝的概念，交易根仅在PoH刻度包含带有交易的条目时才可用，且没有状态根存储在任何条目中。虽然客户端可以使用银行哈希（bank hash）来验证状态，但由于银行哈希包含多个哈希输入，且SlotHashes系统变量账户只保留最新的512个银行哈希，这大大增加了验证的复杂性。

SOON的创新解决方案

SOON网络作为基于以太坊的SVML2，在集成Merkle化时优先考虑使用经过验证的成熟解决方案。在数据结构选择上，SOON团队评估了与Optimism Stack的L1合约的兼容性、与Solana架构的集成能力，以及在Solana账户模型下的性能表现。

研究发现，基于LSM-Tree的Merkle Patricia Trie（MPT）存储模型在账户数量增加时会导致性能下降。因此，SOON决定基于rETH团队在Rust上的工作成果，增加对Solana账户模型的支持，集成Erigon MPT。

系统架构设计

SOON的状态Trie是一个支持Solana账户的MPT，定义了一种兼容SVM的账户类型作为每个叶子节点的数据。为了使MPT模块能够实时订阅SVM账户的最新状态，SOON引入了账户通知器（account notifier）。在银行阶段（Banking Stage），账户通知器会通知MPT模块账户状态的变化，MPT模块则会在Trie结构中增量更新这些变化。

值得注意的是，MPT模块并非在每个插槽结束时都计算状态根，而是每50个插槽更新一次子树。这种设计有两个主要原因：首先，频繁计算状态根会显著影响性能；其次，状态根仅在提议者向L1提交outputRoot时才需要，因此可以基于提议者的提交频率进行周期性计算。

SOON的MPT模块同时维护两种Trie结构：一个用于全局状态的状态Trie，另一个用于提现交易的提现Trie。提议者会定期生成由状态根和提现根组成的outputRoot，并将其提交给L1。目前，SOON每450个插槽计算一次状态根和提现根，并将其附加到L2区块链中，确保网络中其他节点的MPT数据一致性。

由于Solana的区块结构不包括区块头，SOON创新性地引入了UniqueEntry来存储状态根。UniqueEntry重新定义了num_hashes的语义，使其第一个位标志用于区分条目和UniqueEntry，后面63位用于定义负载类型。这种设计使SOON能够重用Solana现有的存储层、网络层和RPC框架，同时在L2区块链上存储额外数据。

提现与桥接机制

本地桥接是Layer2解决方案中的关键基础设施，负责L1与L2之间的信息传输。SOON引入了专门的桥接程序来处理提现交易。当用户发起提现交易时，桥接程序会为每个提现交易生成一个全局唯一的索引，并创建一个新的程序派生账户（PDA）来存储对应的提现交易。

这一设计与OPStack类似，用户需要完成三个步骤才能完成整个提现流程。提现交易的包含证明确保了提现确实发生在L2上，大大增强了规范桥接的安全性。与EVM不同，SVM合约数据存储在账户的data字段中，所有类型的账户都处于同一层级，这使得SOON的桥接设计具有独特优势。

故障证明机制

当提议者提交outputRoot到L1后，如果质疑者发现错误状态，可以发起质疑以保护桥接资金。构建故障证明的关键是确保区块链能够以无状态方式从状态S1转换到状态S2，使L1上的仲裁合约能够无状态地重放程序指令。

与EVM不同，SVM自然将账户状态与计算分离。Anza的SVMAPI允许通过TransactionProcessingCallback特征将账户传递到SVM，质疑者只需使用状态S1和输入账户的包含证明来验证质疑程序输入的有效性。

未来展望

SOON在SVM生态系统的发展中标志着一个关键里程碑。通过整合Merkle化技术，SOON解决了Solana缺乏全局状态根的问题，实现了故障证明的包含证明、安全提现和无状态执行等关键功能。这些创新设计不仅支持基于SVM的链上的轻客户端，还可能为将轻客户端引入主链提供思路。

通过采用Merkle Patricia Tries（MPT）进行状态管理，SOON与以太坊基础设施保持兼容，增强了互操作性，推动了基于SVM的L2解决方案发展。这一创新通过提高安全性、可扩展性和兼容性，不仅强化了SVM生态系统，还将促进去中心化应用程序的进一步发展。

免责声明：

1. 本文转载自【Medium】，所有版权归原作者【@0xandrewz和@realbuffalojoe】所有。若对本次转载有异议，请联系Gate Learn团队，他们会及时处理。
2. 免责声明：本文表达的观点和意见仅代表作者个人观点，不构成投资建议。
3. Gate Learn团队将该文章翻译成其他语言。除非另有说明，否则禁止复制、分发或抄袭翻译文章。