作者：0xmiddle

可以把 AO 理解为无限分片，无限扩容的网络。每个 Process 都是一个分片。

AO 不是传统意义上的区块链。它反常规、反常识的设计，容易让刚刚了解 AO 的研究者在某些关节陷入困惑，尤其是研究者试图用传统区块链的架构框定 AO 时：

1. 非 PoS, 非 PoW，AO 所说的“全息共识”究竟是什么样的共识机制呢？

2. 没有哈希链，甚至没有区块，AO 是如何保证数据不可变？

3. 没有一个协调中枢， AO 如何保证全局状态的一致性？

4. 没有冗余计算机制，谁来保证计算的可靠性？计算出错怎么办？

5. 没有共享安全性，如何保证 Process 之间的互操作性？

我将通过 3个视角，用区块链中大家已经熟悉的概念，帮助大家从已知穿越到未知，把未知变成已知，在感性层面理解 AO。

分片视角

经过以太坊2.0 、波卡、Near 等公链的教育，大家应该对”分片“不陌生。

分片的概念：在区块链中，分片是一种提高网络扩展性的解决方案，通过将网络拆分成多个分片，每个分片独立验证和处理交易，并生成自己的区块，从而提升整体网络效率。分片内可以实现同步互操作，分片之间则通过一定的通信协议实现异步互操作。

Polkadot 是最典型的分片架构。在 Polkadot 中，每个平行链都是一个分片，平行链独立收集打包自己的区块链，并由中继链随机分配一个验证者小组来验证。平行链之间统一的 XCM 消息格式来进行通信，实现互操作。

AO 的极致分片

用分片的视角来看，AO 可以理解为一种极致的“分片”：每个 Process 都是一个分片。想象一下，如果以太坊的每个智能合约都运行在一个单独的分片上会是什么样呢？没错，这就是 AO。每个 Process 都是独立的，Process 之间的调用则依靠消息驱动，以完全异步的方式进行。

模块化视角

但我们发现一个关键，在 Polkadot 的设计中，存在一个“中继链”，在 ETH2.0 中也有“信标链”，他们的作用是作为统一的共识层，提供共享安全性。统一共识层要负责对所有分片以及分片之间的消息传递提供直接或者间接的验证服务。而 AO 似乎没有这个组件，那么 AO 的共识层是如何设计的呢？

AO 的共识层实际上是 Arweave。以模块化的视角理解，AO 可以理解为是 Arweave 的 L2，以 Arweave 为 L1 的 Rollup，AO 网络运行过程中所产生的所有消息的日志都会被上传到 Arweave 永久存储，也就是说，在 Arweave 上有一份 AO 网路运行的不可变的记录。那么你可能会问，Arweave 是去中心化存储平台，并不具备太多计算能力。Arweave 是如何验证 AO 网络上传上来的数据呢？

答案是：Arweave 并不验证，AO 网络自身会有乐观仲裁机制。Arweave 对于 AO 网络上传上来的消息数据来者不拒，每条消息都会携带它的发出者 process id，及运行它的 CU（计算单元） 的签名，也会带有为它排序的 SU（排序单元） 的签名。当发生争议时，可以依赖 Arweave 上不可变的消息记录，引入更多的节点进行重新运算，以创建正确的分叉，舍弃原有的错误分叉，并在正确的分叉中罚没出错 CU 或 SU 的押金。这里需要注意，MU 仅负责收集 Process 的待发消息，传递给 SU，是无信任的，不需要押金，也不涉及罚没。

AO 非常像是以 Arweave 为 L1 的 Optimistic Rollup，只是验证挑战过程并不在 L1 上发生，而是在 AO 网络自身当中发生。

不过这里还是有个问题，不可能每一笔消息都等待 Arweave 上收录之后，才去确认，实际上 Arweave 的最终确定性形成时间要超过半个小时。所以 AO 自己会有一个软共识层，就像以太坊的 Rollups 自己有软共识层，大多数交易不会等待 L1 确认，就会上账。

AO 中的 Process 实际上是自主决定验证强度的。

作为消息接收方的 Process 要决定是否要等 Arweave 确认后再处理该消息，还是在软共识层确认后即处理该消息，即便在软共识层确认环节，Process 也可以采取弹性的策略，可以是单个 CU 确认后即处理，也可以由多个 CU 冗余确认，并进行交叉验证后再处理，冗余度也是由 Process 决定。

在实际应用中，验证强度往往与交易的金额有关，例如

小额交易，采用快速验证策略，单点确认后即处理

中等额度交易，根据具体额度，采取不同冗余度的多点确认后处理的策略

大额交易，则采取谨慎验证策略，在 Arweave 网络确认后再处理

这就是 AO 所说的“全息共识”+“弹性验证”的模式，通过将 “可验证性”和“验证”行为本身解耦，AO 对共识问题采取了完全不同于传统区块链做法，消息验证的责任也不在网络本身，而在 接收方 Process 本身，或者说在应用程序开发者。

正是因为采取了这样的共识模型，AO 才有可能采取“极致分片”的无枢纽、无限扩展模型。

当然，弹性验证导致了不同的 Process 的验证强度不同，在复杂的互操作中，可能导致信任链断裂，一个较长的调用链中的个别环节失败，会导致整体交易的失败或者错误，事实上，在 AO 测试网阶段，这样的问题已经有所暴露。我认为，AO 应该会为所有验证任务设定一个最低验证强度的标准，让我们拭目以待 AO 即将到来的正式网会有什么样的新设计。

资源视角

在传统区块链系统中，资源被抽象为“区块空间”，区块空间可以被理解为节点提供的存储、计算和传输资源的集合，并通过链上区块有机结合，为链上应用提供运行的载体。区块空间是一种有限的资源，在传统区块链中，不同的应用程序需要争夺区块空间，并为其付费，而节点则通过这种付费来盈利。

AO 中没有区块的概念，也自然没有“区块空间”的概念。但和其他链上的智能合约一样，AO 上的 每个 Process 在运行时，也需要消耗资源，它需要节点来临时存储交易和状态数据，也需要节点消耗计算资源，为其执行计算任务，其发出的消息，需要 MU 和 SU 传输到目标 Process 那里。

在 AO 中，节点分为三类，CU（计算单元）、MU（消息单元）、SU(排序单元)，其中 CU 是承载计算任务的核心。MU 和 SU 则承载通信任务。当一个 process 需要和其他 process 交互时，会生成一条消息，存储在出站队列，运行该 process 的 CU 会签名该消息，MU 从出站队列出提取该消息，并提交给 SU，SU 给消息赋予一个唯一的序号，并上传到 Arweave 永久存储。然后 MU 再将消息传递到目标 process 的入站队列，消息投递完成。可以把 MU 理解为消息的收集者和投递者，SU 理解为消息的排序者、上传者。

至于存储资源，AO 网络中的 MU 只需存储计算所需的临时数据，在计算完成后即可丢弃。负责永久存储的是 Arweave，Arweave 虽然不能水平扩展，但其存储性能的天花板极高，AO 网络的存储需求，在可预见的未来，还无法触及 Arweave 的天花板。

我们发现 AO 网络中的计算资源、传输资源、存储资源都是解耦的，除了 Arweave 提供的统一存储资源外，计算资源和传输资源都可以各自水平扩展，没有任何限制。

越多的、越高性能的 CU 节点加入网络，网络就会拥有更高的算力，就可以支撑更多的 Process 运行；同样，越多的，越高性能的 MU、SU 节点加入网络，网络的传输效率就越快。也就是说，AO 中的“区块空间”可以不断被创造。对于应用程序而言，既可以购买开放市场中的公共的 CU 、MU、SU 节点服务，也完全可以自己运行私有节点来为自己的应用程序服务。如果应用程序的业务扩张，则完全可以通过扩容自己的节点来提升性能，正如 Web2 应用所做的那样。这在传统区块链上是无法想象的。

在资源的定价层面，AO 可以通过供需来灵活调节，因而使得资源的供给可以根据需求伸缩。这种调节会非常灵敏，节点的加入和退出可以非常快的进行。我们再回头看以太坊，则会发现，当资源需求急剧上升时，大家除了忍受高昂的 Gas 费之外，别无他法，因为以太坊无法通过扩充节点数来提高其性能。

总结

以上，我们通过大多数加密研究者熟知的概念入手，例如“分片”、“模块化”、“Rollup”、“区块空间”等，切入到 AO 的原理和机制中，帮助大家理解了 AO 是如何通过颠覆式的创新，做到几乎无限扩容的。

现在回过头来看开头的几个问题，你是否已了然呢？

1. 非 PoS, 非 PoW，AO 所说的“全息共识”究竟是什么样的共识机制呢？

AO 的共识机制，实际上是一种接近 Op Rollup 的设计。在硬共识层面依赖 Arweave，在软共识层面，每个 Process 可以自主决定验证强度，自主决定由多少个 CU 节点进行冗余计算。

2. 没有哈希链，甚至没有区块，AO 如何保证数据不可变？

上传到在 Arweave 上的 DA 数据是不可变的，为 AO 上的所有计算和传输过程提供可验证性。AO 本身没有必要限定单位时间内的处理容量，因此不需要设定区块。“哈希链”和“区块”，这些用来保证数据不可变的结构，Arweave 链是有的。

3. 没有一个协调中枢， AO 如何保证全局状态的一致性？

每个 Process 都是一个独立“分片”，独立管理其交易和状态，Process 通过消息驱动的方式来交互。因此并不需要全局状态的一致性。Arweave 的永久存储提供了全局可验证性和历史回溯能力，结合乐观挑战机制，可用于争议解决。

4. 没有冗余计算机制，谁来保证计算的可靠性？计算出错怎么办？

AO 没有全局强制的冗余计算机制，每个 Process 可以自行决定如何验证发来的每个 message 的可靠性。如果计算出错，可以通过乐观挑战的形式发现和纠正。

5. 没有共享安全性，如何保证 Process 之间的互操作性？

Process 需要自行管理每个与之互操作的 Process 的授信，可对不同安全级别的 Process 采用不同级别的验证强度。对于调用链比较复杂的互操作，为了避免信任链断裂带来的较高的纠错成本，AO 可能会有一个最低限度的验证强度要求。