Author: YBB Capital Researcher Zeke

Introduction

The two mainstream blockchain architecture designs that have emerged from Web3 today have inevitably led to some aesthetic fatigue. Whether it is the overwhelming modular public chains or the new L1s that emphasize performance yet fail to demonstrate performance advantages, their ecosystems can be said to be either replicas or slight improvements of the Ethereum ecosystem. The highly homogeneous experience has long made users lose their sense of novelty. However, the latest AO protocol proposed by Arweave is refreshing, achieving ultra-high performance computing on a storage public chain, even reaching a quasi-Web2 experience. This seems to differ greatly from the scaling methods and architectural designs we currently know. So, what exactly is AO? Where does the logic supporting its performance come from?

Understanding AO

The name AO is derived from the Actor Oriented programming paradigm in the Actor Model of concurrent computation. Its overall design concept stems from an extension of Smart Weave and adheres to the Actor Model's core idea of message passing. In simple terms, we can understand AO as a "super parallel computer" running on the Arweave network through a modular architecture. In terms of implementation, AO is not the modular execution layer we commonly see today, but rather a communication protocol that standardizes message passing and data processing. The core goal of this protocol is to facilitate collaboration among different "roles" within the network through information transmission, thereby creating a computing layer with performance that can be infinitely scalable, ultimately enabling Arweave, this "giant hard drive," to achieve centralized cloud-level speed, scalable computing power, and extensibility in a decentralized trust environment.

AO Architecture

The concept of AO appears to have some similarities with Gavin Wood's "Core Time" segmentation and recombination proposed at last year's Polkadot Decoded conference. Both aim to achieve a so-called "high-performance world computer" through the scheduling and coordination of computing resources. However, there are some essential differences between the two. Exotic Scheduling is the deconstruction and reorganization of relay chain block space resources, which does not significantly change the Polkadot architecture. Although the performance of computing has broken through the limitations of a single parallel chain under the slot model, the upper limit is still constrained by the maximum idle core count of Polkadot. In contrast, AO can theoretically provide nearly unlimited computing power through horizontal scaling of nodes (in practice, this should depend on the level of network incentives) and greater freedom. Architecturally, AO standardizes data processing methods and message expression, completing information sorting, scheduling, and computation through three network units (subnets). The standardized methods and functions of different units can be summarized as follows based on official documentation:

• Process: A process can be viewed as a collection of instructions executed in AO. When initialized, a process can define the computing environment it requires, including virtual machines, schedulers, memory requirements, and necessary extensions. These processes maintain a "holographic" state (each process's data can independently store its state in Arweave's message log, which will be specifically explained in the "verifiable issues" section below). The holographic state means that processes can operate independently, and execution is dynamic, allowing it to be performed by appropriate computing units. In addition to receiving messages from user wallets, processes can also forward messages from other processes through messenger units;

• Message: Each interaction between a user (or another process) and a process is represented by a message, which must conform to Arweave's native ANS-104 data item to maintain structural consistency for Arweave's information storage. From a more understandable perspective, a message is somewhat similar to a transaction ID (TX ID) in traditional blockchains, but the two are not entirely the same;

• Messenger Unit (MU): The MU is responsible for relaying messages through a process called 'cranking', ensuring seamless communication within the system. Once a message is sent, the MU routes it to the appropriate destination (SU) within the network, coordinating interactions and recursively processing any generated inbox messages. This process continues until all messages are processed. In addition to message relaying, the MU also provides various functions, including managing process subscriptions and handling scheduled cron interactions;

• Scheduler Unit (SU): Upon receiving a message, the SU initiates a series of critical operations to maintain the continuity and integrity of processes. After receiving a message, the SU assigns a unique incremental nonce to ensure the order relative to other messages within the same process. This assignment process is formalized through cryptographic signatures, ensuring authenticity and sequential integrity. To further enhance the reliability of processes, the SU uploads the signature assignments and messages to the Arweave data layer. This ensures the availability and immutability of messages, preventing data tampering or loss;

• Computing Unit (CU): The CU competes within a peer-to-peer computing market to fulfill user requests and resolve the computing process state with the SU. Once the state computation is completed, the CU returns a signed proof with specific message results to the caller. Additionally, the CU can generate and publish signed state proofs that other nodes can load, of course, this also requires a certain proportion of fees.

Operating System AOS

AOS can be viewed as the operating system or terminal tool within the AO protocol, used for downloading, running, and managing threads. It provides an environment for developers to develop, deploy, and run applications. On AOS, developers can utilize the AO protocol for application development and deployment, interacting with the AO network.

Running Logic

The Actor Model advocates a philosophical view called "everything is an actor." All components and entities within this model can be seen as "actors," each with its own state, behavior, and mailbox, communicating and collaborating through asynchronous communication to organize and operate the entire system in a distributed and concurrent manner. The operational logic of the AO network is similar; components and even users can be abstracted as "actors," communicating with each other through the message-passing layer, linking processes together, thus establishing a distributed working system capable of parallel computation and non-shared states.

The following is a brief description of the steps in the information transmission flowchart:

1. Initiation of the message:

• A user or process creates a message to send a request to other processes.

• The MU receives the message and sends it to other services using a POST request.

1. Processing and forwarding of the message:

• The MU processes the POST request and forwards the message to the SU.

• The SU interacts with Arweave's storage or data layer to store the message.

1. Retrieving results based on message ID:

• The CU receives a GET request, retrieves results based on the message ID, and evaluates the message's status within the process. It can return results based on a single message identifier.

1. Retrieving information:

• The SU receives a GET request and retrieves message information based on the given time range and process ID.

1. Pushing inbox messages:

• The final step is to push all inbox messages.

• This step involves checking messages and generations in the result object.

• Based on the results of this check, steps 2, 3, and 4 can be repeated for each relevant message or generation.

What Has AO Changed? "1"

Differences from Common Networks:

1. Parallel Processing Capability: Unlike networks such as Ethereum, where the base layer and each Rollup effectively run as a single process, AO supports an arbitrary number of processes running in parallel while ensuring the integrity of verifiable computation. Furthermore, these networks operate under a globally synchronized state, whereas AO processes maintain their independent states. This independence allows AO processes to handle a higher number of interactions and scalability of computation, making it particularly suitable for applications that demand high performance and reliability;

2. Verifiable Reproducibility: While some decentralized networks, such as Akash and peer-to-peer systems like Urbit, do provide large-scale computing capabilities, unlike AO, they do not offer verifiable reproducibility of interactions or rely on non-permanent storage solutions to retain their interaction logs.

Differences Between AO's Node Network and Traditional Computing Environments:

• Compatibility: AO supports various forms of threads, whether based on WASM or EVM, which can be bridged to AO through certain technical means.

• Content Co-creation Projects: AO also supports content co-creation projects, allowing for the publication of atomic NFTs and uploading data combined with UDL to build NFTs on AO.

• Data Composability: NFTs on AR and AO can achieve data composability, allowing an article or content to be shared and displayed across multiple platforms while maintaining consistency and original attributes of the data source. When content is updated, the AO network can broadcast these updated states to all relevant platforms, ensuring synchronization and dissemination of the latest status.

• Value Return and Ownership: Content creators can sell their works as NFTs and convey ownership information through the AO network, realizing value return for their content.

Support for Projects:

1. Built on Arweave: AO leverages Arweave's characteristics, eliminating vulnerabilities associated with centralized providers, such as single points of failure, data leaks, and censorship. Computation on AO is transparent and can be verified through decentralized trust-minimized features and reproducible message logs stored on Arweave;

2. Decentralized Foundation: The decentralized foundation of AO helps overcome scalability limitations imposed by physical infrastructure. Anyone can easily create an AO process from their terminal without specialized knowledge, tools, or infrastructure, ensuring that even individuals and small entities can have global influence and participation.

Verifiable Issues of AO

After understanding the framework and logic of AO, a common question usually arises. AO seems to lack the global characteristics of traditional decentralized protocols or chains, achieving verifiability and decentralization merely by uploading some data to Arweave?? This is precisely the brilliance of AO's design. AO itself is implemented off-chain, does not address the verifiability issue, nor does it alter consensus. The AR team's idea is to decouple the functions of AO and Arweave, modularly connecting them, with AO only handling communication and computation while Arweave provides storage and verification. The relationship between the two is more like a mapping; AO only needs to ensure that the interaction logs are stored on Arweave, and its state can be projected onto Arweave, thus creating a hologram. This holographic state projection guarantees the consistency, reliability, and determinism of the output during computation. Additionally, messages in the Arweave message log can also trigger AO processes to execute specific operations (which can wake up and perform corresponding dynamic operations based on preset conditions and schedules).

According to the sharing from Hill and Outprog, if we simplify the verification logic further, we can imagine AO as a computation framework based on a super-parallel indexer. We all know that Bitcoin inscription indexers verify inscriptions by extracting JSON information from the inscriptions and recording balance information in an off-chain database, completing verification through a set of indexing rules. Although the indexer verifies off-chain, users can verify inscriptions by switching between multiple indexers or running their own indexers, thus not having to worry about indexers acting maliciously. We mentioned earlier that data such as message sorting and the holographic state of processes are uploaded to Arweave, so based on the SCP paradigm (Storage Consensus Paradigm, which can be simply understood as SCP being the indexer on-chain), anyone can restore AO or any thread on AO using the holographic data on Arweave. Users do not need to run full nodes to verify trustworthy states; similar to switching indexers, users only need to query a single or multiple CU nodes through the SU. Since Arweave's storage capacity is high and costs are low, under this logic, AO developers can achieve a supercomputing layer far exceeding the functionality of Bitcoin inscriptions.

AO and ICP

Let’s summarize AO's characteristics with some keywords: giant native hard drive, unlimited parallelism, unlimited computation, modular overall architecture, and holographic state processes. All of this sounds particularly promising, but friends familiar with various public chain projects in the blockchain world may find AO particularly similar to a "heavenly-level" project, namely the once-popular "Internet Computer" (ICP).

ICP was once hailed as the last heavenly-level project in the blockchain world, highly favored by top institutions, and reached a market cap of $200 billion during the crazy bull market of 2021. However, as the wave receded, the value of ICP's tokens also saw a straight-line decline. By the bear market of 2023, the value of ICP tokens had dropped nearly 260 times compared to its historical peak. But if we overlook the performance of token prices, even at this current time, revisiting ICP reveals that its technical characteristics still have many unique aspects. Many of the impressive advantages of AO were also present in ICP back then. So, will AO fail like ICP? First, let’s understand why the two are so similar. Both ICP and AO are designed based on the Actor Model, focusing on locally running blockchains, which is why they share many common characteristics. The subnet blockchain of ICP is formed by some independently owned and controlled high-performance hardware devices (node machines) that run the Internet Computer Protocol (ICP). The Internet Computer Protocol is implemented by many software components, which, as a bundle, are a copy since they replicate state and computation across all nodes in the subnet blockchain.

The replication architecture of ICP can be divided into four layers from top to bottom:

Peer-to-Peer (P2P) Network Layer: Used to collect and announce messages from users, other nodes in its subnet blockchain, and other subnet blockchains. Messages received by the peer layer are replicated to all nodes in the subnet to ensure security, reliability, and resilience;

Consensus Layer: Selects and orders messages received from users and different subnets to create blockchain blocks, which can be notarized and finalized through Byzantine fault-tolerant consensus that forms an evolving blockchain. These finalized blocks are passed to the message routing layer;

Message Routing Layer: Used to route user and system-generated messages between subnets, manage input and output queues for Dapps, and schedule message execution;

Execution Environment Layer: Computes deterministic calculations involved in executing smart contracts by processing messages received from the message routing layer.

Subnet Blockchain

The so-called subnet is a collection of interactive replicas that run separate instances of consensus mechanisms to create their own blockchains, where a set of "containers" can run. Each subnet can communicate with other subnets and is controlled by a root subnet, which delegates its authority to each subnet using chain key encryption technology. ICP uses subnets to allow for infinite scalability. The problem with traditional blockchains (and various subnets) is that they are limited by the computing power of a single node machine, as each node must run everything that happens on the blockchain to participate in the consensus algorithm. Running multiple independent subnets in parallel allows ICP to break through this single-machine barrier.

Why It Failed

As mentioned above, the purpose that the ICP architecture aimed to achieve can be simply described as a decentralized cloud server. A few years ago, this concept was as shocking as AO, but why did it fail? Simply put, it was a case of being too ambitious without finding a good balance between Web3 and its own vision, ultimately leading to a project that was neither Web3 nor as user-friendly as centralized clouds. In summary, there are three main issues. First, ICP's program system, Canister, which is similar to AOS and processes in AO, is not the same. ICP's programs are encapsulated by Canister, making them invisible to the outside world and requiring specific interfaces to access data. Under asynchronous communication, this is not friendly for contract calls in DeFi protocols, so during DeFi Summer, ICP did not capture corresponding financial value.

The second issue is the extremely high hardware requirements, leading to a lack of decentralization. The following image shows the minimum hardware configuration provided by ICP at that time, which is still quite exaggerated even now, far exceeding Solana's configuration, and even requiring more storage than storage public chains.

The third issue is the lack of ecosystem; even now, ICP is a high-performance public chain. If there are no DeFi applications, what about other applications? Sorry, ICP has not produced a killer application since its inception, and its ecosystem has neither captured Web2 users nor Web3 users. After all, in a situation where decentralization is so insufficient, why not directly use rich and mature centralized applications? However, it cannot be denied that ICP's technology is still top-notch, and its reverse gas, high compatibility, and unlimited scalability advantages are essential for attracting the next billion users. Under the current AI wave, if ICP can leverage its architectural advantages, there may still be a chance for a comeback.

So, returning to the earlier question, will AO fail like ICP? I personally believe that AO will not repeat the same mistakes. First, the last two points that led to ICP's failure are not issues for AO; Arweave already has a solid ecological foundation, and the holographic state projection resolves the centralization problem, while AO is also more flexible in terms of compatibility. More challenges may focus on the design of the economic model, supporting DeFi, and the century-old question: in non-financial and storage fields, what form should Web3 take?

Web3 Should Not Stop at Narrative

The most frequently occurring term in the world of Web3 is undoubtedly "narrative." We have even become accustomed to measuring the value of most tokens from a narrative perspective. This naturally stems from the awkward predicament where many Web3 projects have grand visions but are difficult to use. In contrast, Arweave already has many fully realized applications, and the benchmarks are all at the Web2 level. For example, Mirror and ArDrive; if you have used these projects, you should find it hard to feel the difference from traditional applications. However, the value capture of Arweave as a storage public chain still has significant limitations, and computation may be a necessary path. Especially in today's external world, AI is an unstoppable trend, and there are still many inherent barriers in the current integration of Web3, which we have discussed in previous articles. Now, with Arweave's AO using a non-Ethereum modular solution architecture, it provides a great new infrastructure for Web3 x AI. From the Library of Alexandria to the super parallel computer, Arweave is forging its own paradigm.

References

1. AO Quick Start: Introduction to Super Parallel Computers: https://medium.com/@permadao/ao-快速入门-超级并行计算机简介-088ebe90e12f

2. X Space Event Record | Is AO an Ethereum Killer, and How Will It Drive a New Narrative for Blockchain?: https://medium.com/@permadao/x-space-活动实录-ao-是不是以太坊杀手-它将怎样推动区块链的新叙事-bea5a22d462c

3. ICP White Paper: https://internetcomputer.org/docs/current/concepts/subnet-types

4. AO CookBook: https://cookbook_ao.arweave.dev/concepts/tour.html

5. AO --- The Super Parallel Computer You Can't Imagine: https://medium.com/@permadao/ao-你无法想象的超并行计算机-1949f5ef038f

6. Multi-Angle Analysis of the Reasons for ICP's Decline: Unique Technology and Sparse Ecosystem: https://www.chaincatcher.com/article/2098499