From storing the past to computing the future: AO super parallel computer

Preface

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 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 a refreshing change, achieving ultra-high performance computing on a storage public chain, even reaching a quasi-Web2 experience. This seems to differ significantly from the scaling methods and architectural designs we are currently familiar with. So, what exactly is AO? What is the logic that supports its performance?

Understanding AO

The name AO is derived from a programming paradigm called Actor Oriented in the Actor Model of concurrent computation. Its overall design concept stems from an extension of Smart Weave and follows 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. From an implementation perspective, 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 achieve collaboration among different "roles" within the network through information transmission, thereby creating a computational 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.

Architecture of AO

The concept of AO seems to resonate with Gavin Wood's proposal of "Core Time" segmentation and recombination at last year's Polkadot Decoded conference. Both approaches aim to achieve a so-called "high-performance world computer" through the scheduling and coordination of computational 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 alter the Polkadot architecture. Although the computational performance breaks 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 theoretically can 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 normative approach and the 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 its required computing environment, 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, capable of being 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 allocation process is formalized through cryptographic signatures, ensuring authenticity and sequential integrity. To further enhance the reliability of processes, the SU uploads the signed allocations 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 computational state of processes with the SU. Once the state computation is complete, 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, requiring 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 and interact with the AO network.

Operational Logic

The Actor Model advocates a philosophical viewpoint called "everything is an actor." All components and entities within this model can be viewed 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, and 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 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 by Message ID:

• The CU receives a GET request, retrieves results based on the message ID, and evaluates the status of the message in 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 Does AO Change? "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. Additionally, these networks operate under a globally synchronized state, while AO processes maintain their independent states. This independence allows AO processes to handle a higher number of interactions and computational scalability, 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, they do not offer the verifiable reproducibility of interactions like AO does, or they 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 atomic NFTs to be published on AO, and data to be uploaded to build NFTs on AO in conjunction with UDL.
• 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 Feedback and Ownership: Content creators can sell their works as NFTs and convey ownership information through the AO network, achieving value feedback for their content.

Support for Projects:

1. Built on Arweave: AO leverages the characteristics of Arweave, 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 impact 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?? In fact, this is 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 approach is to decouple the functions of AO and Arweave and modularly connect them, with AO focusing solely on 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 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 outputs during computation. Furthermore, messages in the Arweave message log can also trigger AO processes to execute specific operations (which can be awakened autonomously based on preset conditions and schedules and perform corresponding dynamic operations).

According to the sharing from Hill and Outprog, if we simplify the verification logic, we can imagine AO as a computation framework based on a super-parallel indexer. We all know that Bitcoin's inscription indexer verifies 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 is off-chain verification, users can verify inscriptions by switching between multiple indexers or running their own indexes, thus not having to worry about indexers acting maliciously. As mentioned earlier, the sorting of messages and the holographic state of processes are all uploaded to Arweave, so based on the SCP paradigm (Storage Consensus Paradigm, which can be simply understood as SCP being the indexer of indexing rules on-chain, and it is worth noting that SCP appeared long before the indexer), anyone can restore AO or any thread on AO through the holographic data on Arweave. Users do not need to run full nodes to verify trusted states; similar to switching indexers, users only need to submit query requests to single or multiple CU nodes through the SU. Moreover, Arweave's high storage capacity and low costs allow AO developers to implement a supercomputing layer far exceeding Bitcoin's inscription functionality.

AO and ICP

Let’s summarize the characteristics of AO with some keywords: giant native hard drive, unlimited parallelism, unlimited computation, modular overall architecture, and holographic state processes. All of this sounds particularly appealing, but friends familiar with various public chain projects in the blockchain space may find AO strikingly 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 tide receded, the value of ICP tokens also plummeted. By the bear market of 2023, the value of ICP tokens had fallen nearly 260 times compared to its historical peak. But if we overlook the performance of the token price, even at this current time, re-evaluating ICP reveals that its technical characteristics still have many unique aspects. Many of the impressive advantages of AO today 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. ICP's subnet blockchains are formed by independent, high-performance hardware devices (node machines) that run the Internet Computer Protocol (ICP). The Internet Computer Protocol is implemented by many software components, which are bundled as 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 a continuously evolving blockchain. These finalized blocks are passed to the message routing layer;
• Message Routing Layer: Used to route messages generated by users and systems 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

A subnet is a collection of interactive replicas that run separate instances of consensus mechanisms to create their own blockchains, on which 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 individual subnets using chain key encryption technology. ICP uses subnets to allow for infinite scalability. The problem with traditional blockchains (and individual subnets) is that they are limited by the computational 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 goal 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 caught between being too high and too low, failing to find a good balance between Web3 and its own vision, ultimately leading to an awkward situation where the project 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 and are not visible from the outside, 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 the time, which is still quite exaggerated even now, far exceeding Solana's configuration, and even storage requirements are higher than those of storage public chains.

The third issue is the lack of ecosystem. Even today, ICP is a high-performance public chain. If there are no DeFi applications, what about other applications? Unfortunately, ICP has not produced a single killer application since its inception; 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 are essential for attracting the next billion users. In the current wave of AI, 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 solves the centralization problem. AO is also more flexible in terms of compatibility. More challenges may focus on the design of the economic model, support for DeFi, and a century-old question: in non-financial and storage fields, how should Web3 be presented?

Web3 Should Not Stop at Narrative

The term that appears most frequently 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 predicament that most Web3 projects have grand visions but are awkward to use. In contrast, Arweave already has many fully realized applications, and the benchmarks are all at the Web2 level of experience. 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. We have discussed this in previous articles. Now, with Arweave's AO using a non-Ethereum modular solution architecture, it provides a solid new infrastructure for Web3 x AI. From the Library of Alexandria to super parallel computers, Arweave is carving out 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