文章宣发：深度解析 AO 全息状态与日志驱动的合约架构

日志驱动的智能合约，通过将合约状态存储与实时更新解耦，使得合约状态可按需重建，提供了一种异步区块链用于减少状态冲突和计算负担的替代方案。本文阐述以 AO 全息态为代表的创新合约范式，更多精彩内容请阅读……

作者：橙子大元帅

审阅：Pignard

来源：内容公会 - 投研

根据广谱的定义，EVM 智能合约是由事件驱动的、具有状态的、部署于可共享的分布式数据库上的计算机程序。这种设计原本旨在确保去中心化和安全性，每个节点都必须执行智能合约的所有操作，且每个合约的状态变化都需要实时记录并持久存储在区块链中，而 EVM 智能合约的每次交易都可能更改区块链的状态，然而，随着链上状态的复杂性增加，各个节点管理和同步这些状态变得越来越困难，尤其是当多个智能合约需要频繁更新时，状态锁冲突（Lock Conflict）和状态同步的风险更加突出。

在这种背景下，日志驱动的智能合约成为了突破传统架构限制的一种全新范式。通过将合约状态存储从链上解耦，并将其隐含在不可篡改的消息日志中，这种架构不仅提升了扩展性，还极大减少了全节点计算的负担。AO 全息态正是这一新范式的典型代表，它利用 Arweave 的永久存储和分布式计算，开创了一种更透明、可扩展的智能合约执行方式。

什么是日志驱动的智能合约？

日志驱动的智能合约不同于传统的智能合约，传统的智能合约是由状态驱动，直接存储当前系统的最新状态，而不保留所有变化过程的历史记录；而日志驱动的智能合约并不实时存储合约的当前状态，而是通过记录用户的交互日志（或交易事件日志）来驱动状态的动态计算。这意味着，智能合约的每一次交互（例如交易、状态更新等）都会生成一个不可篡改的日志，而这些日志会被永久保存在一个永久存储层中。当需要查询当前状态时，任何节点只需通过这些日志重新计算当前的合约状态。

• 交互日志：每次智能合约的操作或交易都会生成一条日志，这些日志记录了合约的状态变化，类似于事件驱动编程中的事件触发。
• 动态状态重建：合约的当前状态并不是直接存储的，而是通过读取所有相关日志并进行计算得到的。任何时候都可以通过读取日志重构智能合约的状态。
• 不可篡改的存储层：日志通常存储在 Arweave 这种专门用于长期存储的不可篡改存储层，确保了所有的日志记录是永久且无法篡改。

以太坊扩容方案 Optimistic Rollup 的验证机制也有点类似于这种日志驱动的智能合约架构，Rollup 子链会生成交易 batch 然后并提交到以太坊主链，但它不存储完整的合约状态，而是通过“状态根”和“交易日志”来驱动状态的重构和验证。而主链上只有子链提交的简易交易证明，然后通过 7 天挑战的解决机制去验证状态。任何人（只是理论上，目前只能是 OP 验证白名单才能）都可以通过提交的交易日志重新计算出状态，并提出争议。

AO 历史状态变更日志 —— 全息状态

全息状态（holographic state）是 AO 的一项关键创新，它为去中心化计算提供了无限的可扩展性，AO 不是就计算本身的状态达成共识，而是确保交互日志存储在 Arweave 上，从而创建状态的“全息图”。 —— AO 白皮书

在传统架构中，每个节点都需要存储完整的合约状态，并且随着时间推移，状态存储的需求不断增加。为了克服这些瓶颈，AO 全息态架构应运而生：AO 全息态以独特的日志驱动方式来记录合约的每一次状态变更，保证了状态的一致性与完整性，同时简化了复杂交互场景下的处理逻辑。进程的状态主要隐含在 Arweave 上存储的交互日志，任何参与者都可以确定性地计算它。这种方法确保进程的状态虽然不能直接监测，但可以独立验证并且在整个网络中保持一致。同时利用 Arweave 的不可变存储功能来确保可扩展性并减少计算开销，强调了 AO 对增强去中心化计算的承诺。

而这也恰恰体现出了全息状态的“无限可扩展性”：仅记录合约历史状态变更日志，而状态是按需重建的，节点不需要不断地进行实时计算，从而减少了计算资源的消耗。

日志驱动 vs. 状态驱动

注意：此章介绍一种全新的合约方案并阐述客观事实，不存在方案孰优孰劣的倾向！

数据日志存储区别

难道以太坊就不会存储合约的历史状态变更日志吗？以太坊确实也存储合约的历史状态变更日志，但它的处理方式与 AO 全息态架构存在显著差异。

以太坊节点保留整个网络的当前状态树（MPT 树，Merkle Patricia Tree），每当新的交易被打包进区块并执行，状态树会立即更新以反映最新的状态，每个全节点都需要存储并维护这棵状态树。状态树会记录账户的状态更新（如余额、nonce、智能合约的存储变化等），并将这些更新写入区块的状态根（State Root）。日志只是一种附加信息，存储在交易收据中，它并不会影响或记录状态树的任何部分。

虽然以太坊确实记录了每笔交易和相关的事件日志，但这些数据与合约的具体状态变化不同。日志的设计初衷是用于事件监听和查询功能。以太坊的日志通常记录的是事件数据，而不是状态数据。在智能合约中可通过 emit 关键词生成事件，而这些事件仅记录交易执行过程中的一些重要信息，便于外部应用程序查询。而这些事件并不会包含有关合约存储变量或合约状态的详细变化，所以以太坊的日志无法像 AO 全息态那样用于重建合约状态。

为了重建合约状态，必须依赖对所有历史交易的重放和状态树的重建。故 AO 全息态会比以太坊的日志存储更多的信息，所以本质上是一种通过牺牲硬盘存储来降低内存和实时计算负担的策略。以太坊的数据存储成本过大，即使 EIP-4844 引入了「blobs」临时数据类型，让 Rollup 以更低的成本提交更多数据到以太坊主链。但 blobs 数据在共识层节点存储约 18 天后删除，不符合日志永久存储永久可回溯的理念，所以短期内不适用于以太坊，也许升级分片（Sharding）后采用此种范式，而对于其他公链或许可以继承 Arweave 这种存储链实现更加廉价且容易扩展的硬盘存储，内存和计算资源也得到释放。

状态膨胀和容错问题

以太坊的设计导致了状态膨胀的问题隐患。由于每个全节点需要实时维护所有合约和账户的最新状态，状态数据不像区块数据，日志数据是静态的，永久保存后并不需要频繁读写；但状态数据每多一个区块就要读写许多次，随着状态数据量的增大，读写的负担也会越来越重。

相比以太坊直接存储完整的状态树，全息态通过日志的方式减少了对全局状态的依赖。通过将状态存储从实时内存转移到硬盘上，节点不需要实时更新和维护全局状态，而是可以按需重建状态，将状态的更新分解为离散的日志记录。

这一设计理念带来了几个显著的优势：首先，日志驱动模型减少了状态冲突和竞态条件的发生，因为所有操作都是基于日志的顺序执行，可保证状态变更的一致性和可验证性。其次，日志驱动的智能合约天然支持状态回溯，AO 全息态能够以较低的开销实现状态重建，使得智能合约具备更高的容错性和透明度。

异步区块链 DeFi 难题

不得不说的是，目前从实际应用角度来看，尤其在 DeFi 领域，虽然 AO 此类的异步区块链在可扩展性方面具有理论上的优势，但在异步区块链上保持以太坊那样的组合性依旧具有挑战，因为需要协调多个 actor 在特定时间点达成一致状态，这要求精确协调所有交易的顺序和依赖关系，如果某个交易在网络的某个节点上被延迟处理，可能导致整体交易逻辑出错或状态不一致。异步环境中高并发的 DeFi 交易又非常容易产生双花问题（double spending）或状态错乱等问题，实际上对生态 DeFi 应用的安全性和可靠性构成了威胁。

而日志驱动的智能合约在一定程度上可以缓解这些问题，通过日志驱动的架构，交易的执行可以在多个节点上异步处理，同时通过日志系统记录每笔交易的变更，这样即使交易的执行顺序在不同节点上存在差异，最终系统可以通过回溯日志重构正确的状态。另一大优势在于失败恢复。通过日志驱动，系统可以记录每一步交易的详细信息，如果某个交易失败，可以依赖日志来回滚到之前的正确状态，或进行异步补偿。这种机制对 DeFi 系统的高容错性非常重要，尤其是在高并发交易的环境中，日志驱动的设计可以让部分交易在失败后不影响全局的稳定性，而是通过日志追踪来确保最终一致性。除此之外，在供应链管理场景中，通过日志驱动的智能合约可实现全流程商品追溯与验证：每个商品在生产、运输、仓储等各个环节的状态变化都通过日志记录，可以清晰展示产品的整个生命周期。

结语

在当今快速发展的区块链技术领域，日志驱动的智能合约架构为解决传统架构中的状态管理和扩展性问题提供了全新的视角。通过将状态存储从链上解耦，并将合约的状态变更记录在不可篡改的交互日志中，AO 全息态架构不仅降低了计算资源的消耗，还大幅提升了系统的可扩展性。

日志驱动的智能合约的核心在于其通过日志驱动的方式确保了状态的动态计算与重建，从而减少了对全局状态的实时维护需求。这种设计允许节点按需重建合约状态，避免了因状态膨胀而引发的存储和计算负担问题。同时，合约本身会根据日志顺序执行，也有效减少了状态冲突和竞态条件，增强了合约执行的一致性和透明度。

随着区块链应用的日益复杂，AO 全息态所代表的日志驱动智能合约将成为未来去中心化计算的重要趋势，为开发者提供了一种在异步区块链有望解决可组合性挑战的新思路。通过结合 Arweave 的永久存储能力，AO 全息态将继续推动区块链技术的演进，助力构建更强大和可扩展的去中心化应用生态系统。

免责声明：本文不代表 PermaDAO 的观点或立场。PermaDAO 不提供投资建议，亦不为任何项目背书。请读者遵守所在国法律，合规进行 Web3 活动。

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