From Storing the Past to Computing the Future: AO Super-Parallel Computer

Original title: "From storing the past to calculating the future: AO Hyperparallel Computer"

Original author: Zeke, YBB Capital Researcher

Foreword

Web3 The two mainstream blockchain architecture designs that have been differentiated today have inevitably caused some aesthetic fatigue, whether it is the proliferation of modular public chains It is still the new L1 that always emphasizes performance but fails to reflect performance advantages. Its ecology can be said to be a replica or slight improvement of the Ethereum ecology. The highly homogeneous experience has long made users lose their sense of freshness. The latest AO protocol proposed by Arweave is eye-catching, achieving ultra-high-performance computing on the storage public chain and even achieving a quasi-Web2 experience. This seems to be hugely different from the expansion methods and architectural designs we are currently familiar with. So what exactly is AO? Where does the logic to support its performance come from?

How to understand AO

The name of AO comes from one of the concurrent computing models Actor Model The abbreviation of the programming paradigm Actor Oriented, its overall design idea is derived from the extension of Smart Weave, and also follows the message passing as the core concept of the Actor Model. Simply put, we can understand AO as a "hyper-parallel computer" running on the Arweave network through a modular architecture. From an implementation perspective, AO is actually not the modular execution layer we see today, but a communication protocol that standardizes message passing and data processing. The core goal of the protocol is to realize the collaboration of different "roles" within the network through information transfer, thereby achieving a computing layer whose performance can be infinitely superimposed, ultimately enabling Arweave, the "giant hard drive", to have a center in a decentralized trust environment. Cloud-level speed, scalable computing power and scalability.

AO’s architecture

The concept of AO seems to be somewhat similar to the "Core Time" segmentation and recombination proposed by Gavin Wood at last year's Polkadot Decoded conference. Both of them use the scheduling and coordination of computing resources to achieve the so-called "High Performance World Computer". But there are actually some differences between the two in essence. Exotic Scheduling is the deconstruction and reorganization of the relay chain block space resources. It has not changed much to the architecture of Polkadot. Although the computing performance has exceeded that of plug-in The limit of a single parachain under the slot model is still limited by the maximum number of idle cores of Polkadot. AO can theoretically provide nearly unlimited computing power (in actual situations it depends on the level of network incentives) and a higher degree of freedom through horizontal expansion of nodes. Architecturally, AO standardizes data processing methods and message expressions. , and completes the sorting, scheduling and calculation of information through three network units (subnetworks). Its standardization method and the functions of different units can be summarized as the following points according to official data analysis:

●     Process: A process can be regarded as a collection of execution instructions in AO. The process can define what it needs during initialization. computing environment, including virtual machines, schedulers, memory requirements, and necessary extensions. These processes maintain a "holographic" state (each process data can be independently stored in Arweave's message log. The holographic state will be explained in detail in the "Verifiable Issues" section below). The holographic state means that the process can Works independently, and execution is dynamic and can be performed by appropriate computing units. In addition to receiving messages from user wallets, processes can also forward messages from other processes through the messenger unit;

●     Message: Each interaction between the user (or other process) and the process is represented by a message, and the message must conform to Arweave's native ANS-104 data items , thereby keeping the local structure consistent so that Arweave can save information. From a more understandable perspective, the message is somewhat similar to the transaction ID (TX ID) in the traditional blockchain, but the two are not exactly the same;

●     Messenger Unit (MU): The MU is responsible for relaying messages through a process called 'cranking' The delivery of communications within the system to ensure seamless interactions. Once a message is sent, the MU routes it to the appropriate destination (SU) within the network, coordinating the interaction and recursively processing any resulting outbox messages. This process continues until all messages have been processed. In addition to message relay, MU provides a variety of functions, including managing process subscriptions and handling scheduled cron interactions;

●      Scheduler Unit (SU): When a message is received, the SU initiates a series of critical operations to maintain the continuity and integrity of the process. Upon receipt of a message, SU assigns a unique increment nonce to ensure ordering relative to other messages in the same process. This allocation process is formalized through cryptographic signatures, guaranteeing authenticity and sequence integrity. To further improve the reliability of the process, SU uploads signature assignments and messages into the Arweave data layer. This ensures message availability and immutability and prevents data tampering or loss;

●     Computing Unit (CU) : CU competes with each other in a peer-to-peer computing market to complete the service of solving the computing process status between users and SU. Once the state calculation is complete, the CU returns a signed certificate with the specific message result to the caller. In addition, CU can generate and publish signed state certificates that other nodes can load, of course this also requires paying a certain percentage of the fee.

Operating system AOS

AOS can be regarded as the operating system or terminal tool in the AO protocol, which can be used to download, run and manage threads. It provides an environment in which developers can develop, deploy and run applications. On AOS, developers can use the AO protocol to develop and deploy applications and interact with the AO network.

Running logic

Actor Model advocates a model called "everything is an actor" Philosophical perspective. All components and entities in this model can be regarded as "actors". Each actor has its own status, behavior and mailbox. They carry out message passing and collaboration through asynchronous communication, so that the entire system can be distributed in a distributed manner. and organize and run in a concurrent manner. The same is true for the operating logic of the AO network. Components and even users can be abstracted as "actors" and communicate with each other through the message passing layer, so that processes are linked to each other. A distributed work system that can be calculated in parallel and has no shared state is intertwined. was established.

The following is a brief description of the steps of the information transfer flow chart:

1. Initiation of messages:

○     Users or processes create messages to send requests to other processes.

○     MU (Messenger Unit) receives the message and sends it to other services using a POST request.

2. Message processing and forwarding:

○     MU processes the POST request and forwards the message Forwarded to SU (Scheduling Unit).

○     SU interacts with the Arweave storage or data layer to store messages.

3. Retrieval results based on message ID:

○     CU (computing) receives GET request, retrieve the results based on the message ID, and evaluate the message's status on the process. It can return results based on a single message identifier.

4. Retrieve information:

○     SU receives a GET request, based on the given Time range and process ID to retrieve message information.

5. Push Outbox Messages:

○     The final step is to push all outbox messages.

○     This step involves inspecting the messages and builds in the result object.

○     Depending on the results of this inspection, steps 2, 3, and 4 can be repeated for each relevant message or build.

What did AO change? 「1」

Differences from common networks:

1. Parallel processing capabilities:Unlike networks such as Ethereum, where the base layer and each Rollup actually run as a single process, AO supports any number of processes running in parallel while ensuring that the verifiability of the computation remains intact. In addition, these networks operate in a globally synchronized state, while AO processes maintain their own independent state. This independence enables AO processes to handle a higher number of interactions and computational scalability, making them particularly suitable for applications that require high performance and reliability;

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

The difference between AO's node network and the traditional computing environment:

●     Compatibility: AO supports various forms of threads, whether based on WASM or EVM, they can be connected to AO through certain technical means.

●     Content co-creation projects: AO also supports content co-creation projects, which can publish atomic NFTs on AO, upload data and combine 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 on multiple platforms while maintaining the consistency and original properties of the data source. When the content is updated, the AO network can broadcast these updated states to all relevant platforms to ensure the synchronization of the content and the dissemination of the latest status.

●     Value feedback and ownership: Content creators can sell their works as NFTs and transfer ownership information through the AO network to achieve Content value feedback.

Support for the project:

1. Built on Arweave: AO uses the features of Arweave , eliminating the vulnerabilities associated with centralized providers such as single points of failure, data breaches, and censorship. Computations on AO are transparent and can be verified through decentralized trust minimization features and reproducible message logs stored on Arweave;

2 .Decentralized Foundation: AO’s decentralized foundation helps overcome scalability limitations imposed by physical infrastructure. Anyone can easily create an AO process from their terminal, with no need for specialized knowledge, tools or infrastructure, ensuring that even individuals and small-scale entities can have global reach and engagement.

Verifiable issues of AO

After we understand the framework and logic of AO, There is usually a common problem. AO does not seem to have the global characteristics of traditional decentralized protocols or chains. Can it achieve verifiability and decentralization just by uploading some data to Arweave? ? In fact, this is the secret of AO design. AO itself is an off-chain implementation and does not solve the issue of verifiability or change the consensus. The AR team's idea is to separate the functions of AO and Arweave and then connect them in a modular manner. AO only performs communication and calculation, and Arweave only provides storage and verification. The relationship between the two is more like mapping. AO only needs to ensure that the interaction log is stored on Arweave, and its state can be projected to Arweave to create a hologram. This holographic state projection ensures the consistency and reliability of the output when calculating the state. sex, certainty. In addition, the AO process can be triggered in reverse to perform specific operations through the message log on Arweave (it can wake up on its own according to preset conditions and schedules, and perform corresponding dynamic operations).

According to Hill and Outprog’s sharing, if the verification logic is simpler point, then you can think of AO as an inscription computing framework based on a hyper-parallel indexer. We all know that to verify the inscription, the Bitcoin inscription indexer needs to extract JSON information from the inscription, record the balance information in the off-chain database, and complete the verification through a set of indexing rules. Although the indexer is verified off-chain, users can verify the inscription by changing multiple indexers or running the index themselves, so there is no need to worry about the indexer doing evil. We mentioned above that the data such as the sorting of messages and the holographic status of the process are uploaded to Arweave, so it only needs to be based on the SCP paradigm (storage consensus paradigm, which can be simply understood as SCP is the indexer of the index rules on the chain. In addition It is worth noting that SCP appeared much earlier than the indexer), and anyone can restore AO or any thread on AO through the holographic data on Arweave. Users do not need to run the whole node to verify the trusted status. Just like changing the index, users only need to make query requests to single or multiple CU nodes through SU. Arweave has high storage capacity and low cost, so under this logic, AO developers can implement a supercomputing layer that far exceeds the functions of Bitcoin inscriptions.

AO and ICP

Let’s use some keywords to summarize the characteristics of AO: giant native hard disk, wireless Capped parallelism, uncapped computing, modular overall architecture, and holographic state processes. This all sounds very good, but friends who are familiar with various public chain projects in the blockchain may find that AO is particularly similar to a "Death-level" project, which is the once popular "Internet Computer" ICP.

ICP was once hailed as the last king-level project in the blockchain world. It was highly favored by top institutions and reached the top level among the 21 years of crazy bulls. FDV exceeds US$200 billion. But as the wave receded, ICP’s token value also plummeted. Until the 2023 bear market, the value of ICP tokens had dropped nearly 260 times compared to its historical high. However, if the performance of Token price is not considered, even if ICP is re-examined at this time, its technical features still have many unique features. Many of the amazing advantages and features of AO today were also possessed by ICP back then. So will AO fail like ICP? Let’s first understand why the two are so similar. ICP and AO are both designed based on the Actor Model and focus on locally running blockchains, so the characteristics of the two have many similarities. The ICP subnet blockchain is formed by a number of independently owned and controlled high-performance hardware devices (node machines) that run the Internet Computer Protocol (ICP). The Internet Computer Protocol is implemented by a number of software components, which as a bundle are replicas in that they replicate state and computation across all nodes in a subnet blockchain.

ICP’s replication architecture can be divided into four layers from top to bottom:

Point-to-point ( P2P) Network layer: used to collect and advertise messages from users, other nodes in their subnet blockchain, and other subnet blockchains. Messages received by the peer layer will be replicated to all nodes in the subnet to ensure security, reliability and resiliency;

Consensus layer: Select and Messages received from users and different subnets are sequenced to create blockchain blocks that can be notarized and finalized through a Byzantine fault-tolerant consensus that forms the 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 and manage Dapps input and output queues, and arrange message execution;

Execution environment layer: Calculate the time involved in executing smart contracts by processing messages received from the message routing layer Deterministic calculations.

Subnet Blockchain

A so-called subnet is a collection of interacting replicas that run separate instances of the consensus mechanism in order to create its own blockchain 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 cryptography. ICP uses subnets to allow it to scale infinitely. The problem with traditional blockchains (and individual subnets) is that they are limited by the computing power of a single node machine, because 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 of the ICP architecture is, in simple terms, a decentralized cloud server. This idea was as shocking as AO a few years ago, but why did it fail? In simple terms, it is neither high nor low. There is no good balance between Web3 and its own ideas, which eventually leads to the embarrassing situation that the project is not as good as Web3 and is not as good as centralized cloud. In summary, there are three problems. First, ICP's program system Canister, which is the "container" mentioned above, is actually a bit similar to AOS and process in AO, but the two are not the same. ICP's program is encapsulated and implemented by Canister, which is not visible to the outside world and requires access to data through specific interfaces. Under asynchronous communication, it is not friendly to the contract call of DeFi protocol, so in DeFi Summer, ICP did not capture the corresponding financial value.

The second point is that the hardware requirements are extremely high, which makes the project not decentralized. The figure below is the minimum hardware configuration diagram of the node given by ICP at that time. Even now, it is very exaggerated, far exceeding Solana's configuration, and even the storage requirements are higher than the storage public chain.

The third point is the lack of ecology. ICP is still a public chain with extremely high performance even now. If there is no DeFi application, what about other applications? Sorry, ICP has not produced a killer application since its birth. Its ecology has neither captured Web2 users nor Web3 users. After all, with such insufficient decentralization, why not directly use rich and mature centralized applications? But in the end, it is undeniable that ICP's technology is still top-notch. Its advantages of reverse Gas, high compatibility, and unlimited expansion are still necessary to attract the next billion users. In the current AI wave, if ICP can make good use of its own architectural advantages, it may still have the possibility of turning around.

So back to the question above, will AO fail like ICP? I personally think that AO will not repeat the same mistakes. The last two points that led to the failure of ICP in the first place are not problems for AO. Arweave already has a good ecological foundation. Holographic state projection also solves the centralization problem. In terms of compatibility, AO Also more flexible. More challenges may focus on the design of the economic model, support for DeFi, and a century-old problem: In the non-financial and storage fields, what form should Web3 take?

Web3 should not stop at narrative

The words that appear most frequently in the world of Web3 must be It is "narrative". We have even become accustomed to using narrative perspective to measure the value of most tokens. This naturally stems from the dilemma that most Web3 projects have great vision but are very embarrassing to use. In comparison, Arweave already has many fully implemented applications, and they all target Web2-level experience. For example, Mirror and ArDrive. If you have used these projects, it will be difficult to feel the difference from traditional applications. However, Arweave still has great limitations in value capture as a storage public chain, and calculation may be the only way to go. Especially in today's external world, AI has become a general trend. There are still many natural barriers to the integration of Web3 at this stage, which we have also talked about in past articles. Now Arweave's AO uses a non-Ethereum modular solution architecture, giving Web3 x AI a good new infrastructure. From the Library of Alexandria to ultra-parallel computers, Arweave is following a paradigm of its own.

Reference article:

AO Quick Start: Introduction to Super Parallel Computers: https://medium.com/@permadao/ao-Quick Getting Started - Introduction to Super Parallel Computers - 088ebe90e12f

X Space Event Record | Is AO an Ethereum killer? How will it promote the new narrative of the blockchain? ：https://medium.com/@permadao/x-space-Activity Record-ao-Is it an Ethereum killer-How will it promote the new narrative of the blockchain-bea5a22d462c

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

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

AO— —Hyper-parallel computer you can’t imagine: https://medium.com/@permadao/ao-Hyper-parallel computer you can’t imagine-1949f5ef038f

Analysis of the reasons for the decline of ICP from multiple angles: maverick Technology and thin ecosystem: https://www.chaincatcher.com/article/2098499

This article comes from a contribution and does not represent the views of BlockBeats.

Welcome to join the rhythmic BlockBeats official community:

Telegram subscription group: https://t.me/theblockbeats

Telegram exchange group: https://t.me/theblockbeatsApp

Twitter official account: https://twitter.com/BlockBeatsAsia