ao computer protocol specification

Authors: Tyler Hall, Vince Juliano, Ivan Morozov, Sam Williams, Tom Wilson; Translator: PermaDAO

What is Ao?

Ao is an Actor Oriented computer running on Arweave, composed of a network of nodes that follow the Core Data protocol. This article briefly introduces the protocol specification, features, and technical details to allow builders to implement or integrate the service.

Ao is a single, unified computing environment (a single system image) hosted on a heterogeneous set of nodes in a distributed network. Ao is designed as an environment that can host any number of parallel processes, coordinated by an open messaging layer.

This messaging standard connects processes running independently on machines to form a "network", just like websites run on independent servers, but are connected through hyperlinks to form an overall system with a unified experience.

Unlike existing decentralized computing systems, AO supports flexible computing operations that are not subject to the inherent capacity limitations and forms of the protocol, while maintaining the verifiability of the network itself (thus minimizing trust).

In addition, AO's distributed and modular architecture allows existing smart contract platforms to easily "connect" to the network, starting a single process that can send and receive messages with any other process.

AO does not impose a set of rules on all user computing environments. AO is built in a modular form: allowing users to choose the virtual machine, sorting model, messaging security guarantee, and payment options that best suit them.

This modular environment performs settlement processing on Arweave's decentralized data layer through unified messages (all messages use the same format). This modular environment is a unified computing environment that can meet extremely wide workload requirements, and each process can easily pass messages and collaborate.

AO's core goal is to achieve trustless and mutually cooperative computing services without scale restrictions. This opens up new possibilities for applications that were impossible in the past: combining the advantages of smart contract applications (services that only require trust in the code) with the advantages of traditional computing environments (such as Amazon EC2, etc.).

AOS (AO's decentralized operating system) allows developers to launch command-line processes similar to smart contracts in a decentralized network. This process is similar to starting a server on a cloud service, but decentralization and trustless computing are its key advantages.

These processes are not restricted to a specific physical location when running, and seamless user interaction is achieved through the network. The result is a single (Single System Image), unified, global computing platform that transcends physical and scalability limitations and is used by all participants.

In short, ao forms a large, scalable computer on which users can interact with any process, forming a highly collaborative ecosystem.

For users, ao represents a shared computer on which they can execute multiple processes. These processes are not restricted to any specific server and are not subject to the control of any individual or group. Once activated, these processes provide services in a cryptographically secure manner, ensuring objective and persistent operation.

This design gives users the right to use applications in a long-term and stable manner, thereby providing a trustworthy environment for users to interact with the system.

Core Features

Compared to existing decentralized and distributed computing systems, the ao protocol provides the following features:

Any number of processes (processes are similar to smart contracts) running in parallel:In ao, applications are built from any number of communicating processes. Inspired by the original actor model (Carl Hewitt, 1973) and Erlang, ao does not allow shared memory between processes, but allows them to communicate through native message passing standards.

Each of these processes can then run at the full speed of available computing resources without interfering with each other. By focusing on messaging, ao implements a scaling mechanism that is more similar to a traditional Web2/distributed system environment than a traditional smart contract.

Unlimited Computational Resources:Building on the lazy computation architecture of the original version of SmartWeave and LazyLedger (later called Celestia), nodes in the ao network do not need to perform any computation when reaching consensus on program state transitions.

All logs of each process are stored, and the final holographic state of the process is retained on Arweave. The computational cost is then delegated to users, who can compute their state themselves or request that the computation be performed by a node of their choice.

Access to Arweave, an unlimited hard disk:ao processes can seamlessly load and execute data of any size directly into its memory and write back to the network. This setup eliminates typical resource constraints and enables fully parallel execution, greatly expanding the possibilities of application development beyond the limitations of traditional smart contract platforms.

Therefore, it opens the door to complex applications that require large amounts of data processing and computing resources, such as machine learning tasks and computationally intensive autonomous agents.

Automated Contracts:In traditional smart contract environments (such as Ethereum, Solana, Polygon, etc.), contracts must be "woken up" to perform computations at the request of user transactions. In this environment, programs are not "active" unless users interact with them, reducing the range of applications that can be built on them.

AO removes this limitation by allowing contracts to schedule tasks, which can automatically wake up and perform computations at set intervals. Any user, or the process itself, can pay a fee to a node to "subscribe" to a process to trigger computations at the appropriate frequency.

Modular architecture that supports extensions: AO's core architecture is an open data protocol that anyone can build. From the sorter, the messaging relayer, and even the system-level virtual machine can be replaced and extended at will.

This flexibility will allow existing smart contract systems in the Arweave ecosystem (Warp, everPay, Mem, etc.) to plug into ao and be able to send and receive messages with the unified network. This will also allow all these smart contract systems to share some of the same infrastructure and tools, making the computing experience on Arweave more consistent.

ao Architecture Introduction

The basic components of ao are as follows:

Process:The computing unit in the network. Processes can be represented as interaction logs stored on Arweave, which are composed of information data items. When initializing a process, you need to define the computing environment (including virtual machines, schedulers, memory, and necessary extensions).

The state of a process can be computed and consensus can be obtained by computing units that meet the requirements. In addition to receiving messages from user wallets, processes also receive messages from other processes through messenger units. The developer of the process is free to choose how to determine the credibility of these messages (see below).

Messages: Every interaction with a process in ao is represented by a message. Fundamentally, a message is a data item that conforms to the ANS-104 standard. Users and processes (through their outboxes and messenger units) can send messages to other processes in the network through the dispatch unit.

The semantic definition of ao messages is between UDP and TCP: it is guaranteed to be sent only once, but if the message is never forwarded by the messenger unit, or the recipient never actually processes it, it is equivalent to the message never happening.

Scheduling Units (SUs): The dispatch unit is responsible for assigning atomically increasing slot numbers (similar to Ethereum nonce) to information sent to the process. Once allocated, the scheduler needs to ensure that the data is uploaded to Arweave, making it permanently accessible to others.

Processes are free to choose their preferred sorter, which can be implemented in a variety of ways: decentralized, centralized, or even user-hosted.

Computation Units (CUs): A computation unit is a node that computes the state of a process in the ao, using information provided by users and messenger units as input. The scheduler only sorts process messages, requiring additional computation units to perform the state calculation of the process.

This creates a peer-to-peer computation market in which computation units offer services to compute the state of processes and compete with each other. These computation units make trade-offs between price, computation requirements, and other parameters. Once the state calculation is complete, the computation unit will return a signed output proof to the caller.

Computation units may also generate and publish signed state proofs, which other nodes can choose to load - optionally paying a fee specified by the UDL.

Messenger Units (MUs): Messenger units are responsible for passing messages in the ao network, and these messages are passed through a process called cranking (a proper noun with meanings such as "starting" and "repeated execution").

Essentially, when messenger units process a message in the system, they send the information to the appropriate SU for processing, the information is delivered by the SU to the CU for calculation output and then returned to the SU, and the messenger unit repeats this process.

This process continues until there are no more messages to process. Users and processes can also pay a fee to MU to subscribe to a process and process any messages generated by the interaction of their scheduled tasks. A process can also optionally mark a message as broadcast (cast), which will cause the MU to send the message to its SU but not listen for a response.

In this way, ao is able to provide a dynamic environment that provides users and processes with maximum freedom of choice - virtual machines (VMs), payment methods, scheduler types, message security, etc. - without having to reach consensus on expensive computations themselves.

Related Work

There are currently no similar cases to describe ao and its usage experience. However, there are many related projects and networks that can be compared with ao to illustrate its characteristics. In this section, we discuss each related work in turn.

Actor Model

The Actor Model was introduced by Carl Hewitt, Peter Bishop, and Richard Steiger in their paper "A General Modular Actor Formalization for Artificial Intelligence" as a basic framework for understanding and implementing concurrency in computer systems.

The model considers the fundamental unit of computation to be an "actor," an entity that can make local decisions, create more actors, send messages, and determine how to respond to messages received. This approach to system design and programming facilitates the creation of distributed, highly concurrent, and scalable applications.

Erlang

ao is heavily inspired by the Erlang computing environment and its programming language. Erlang is an implementation of the Actor Model that provides extremely lightweight processes that are handled by a scheduler in the runtime for efficient utilization in massively parallel systems (machines and networks with multiple physical threads).

These features give rise to a form of "process-oriented" programming, where developers naturally divide their computations into many cooperating and parallel components to achieve their goals. While Erlang is not very well-known in the mainstream computing world, it is widely used in many environments that require high performance: telephone switches, instant messaging services such as WhatsApp, etc.

ao computers directly inherit Erlang's process-oriented approach. Erlang demonstrated that environments that implement distributed computing by passing messages through processes without sharing memory can be very efficient. ao applies this approach to the field of smart contracts, while providing a single system image of an Erlang-style environment for the first time.

Smart Contract Platforms (such as Ethereum)

Ethereum is a decentralized computing network with all users sharing memory and a single execution thread. Originally based on the idea of ​​adding Turing-complete computing to the blockchain, Ethereum evolved into a project to build a "world computer".

When it launched, Ethereum successfully demonstrated for the first time the ability to trustlessly compute arbitrary code — without spawning a separate blockchain network. While the network has gained tremendous traction among users and developers, the core network’s throughput has not improved since its launch in 2015.

Rather than attempting to scale the base network beyond the processing power of a single small thread of execution, the Ethereum ecosystem has moved to a “rollup-centric” roadmap.

This approach to scaling focuses on supporting additional “rollup” networks that inherit some, but not all, of Ethereum’s properties. As of this writing, there are 14 rollup networks in the Ethereum ecosystem, with the projects behind these programs collectively valued at over $100 million.

Each of these 14 rollup projects represents another single-threaded (a “process” in AO terminology) computation that can be executed in parallel.

ao has been committed to building an architecture that focuses on parallel execution rather than shared memory from the beginning, providing a completely new architecture for any number of independent processes while keeping programs decentralized and trustless.

Decentralized Computing Market (such as Akash)

On traditional smart contract platforms like Ethereum, the shared thread architecture limits each user to only small computing tasks. This limitation constrains the complexity and scalability of operations on the network. This shared resource model inherently limits the scalability and efficiency of applications, affecting the potential of more computationally intensive smart contracts.

Some networks are designed to facilitate large-scale computing in a decentralized environment, such as Akash. Unlike platforms that emphasize verifiable and reproducible computing, Akash and similar networks provide a decentralized market for container hosting services.

This approach allows traditional, non-deterministic programs to be executed on x86 architecture physical machines. However, this approach sacrifices the ability to create trustless services, such as those powered by smart contracts.

ao allows developers to choose their preferred virtual machine (VM), and the initial reference implementation focuses on using WebAssembly (WASM) to execute processes. WASM containers in ao can manage up to 4 GB of memory, and this limit is expected to increase with the adoption of WASM64, making long-duration computations possible.

The rich compilation tools in the WASM ecosystem support a diverse range of programs. Recent examples of WASM use include executing large language model (LLM) transformer models, speech recognition, and even computationally intensive image processing software (such as Photoshop) in a web browser.

ao not only has significant computational power, but also maintains the properties of traditional smart contracts thanks to its holographic state mechanism. ao does not reach consensus on the state of the computation itself, but focuses on ensuring that the interaction log is written to Arweave and has persistent availability.

Through deterministic billing VMs and the availability of all process messages on Arweave, a "hologram" can be projected: the state may not have been actually computed by any participant yet, but once the computation is complete, we can guarantee that its output is always consistent.

In addition, the holographic state system enabled by the message log on Arweave enables the ao process to respond to implicit messages based on time, wake itself up and perform actions.

In conjunction with its holographic state mechanism, ao also provides a distributed network of Compute Units that provide users with cryptographically signed statements about the results of computations. These computing nodes compete with each other in a market, reducing the cost of users parsing holographic states.

Peer-to-peer VM hosting (e.g. Urbit)

Urbit is a peer-to-peer computing system that has some similarities to ao. By focusing on the transport and availability of interaction logs, Urbit is able to provide a distributed computing environment where “servers” can migrate from one physical host to another.

In the process of switching from one host to another, the interaction log with the hosted computation can be executed to recompute the current state. Urbit processes can also send messages to each other to communicate.

Unlike ao, Urbit does not reach decentralized consensus on its interaction logs. In practice, this means that there is no authoritative agreement on its “rollups” or guarantees of their availability — and therefore, no guarantees on the state of its processes.

In this way, Urbit can be seen as similar to Akash and other decentralized computing markets, but with the additional ability to migrate computation from one host to another in a verifiable manner if the host is willing to transition.

ao expands on this model by ensuring the availability of log messages sent to processes through scheduling units (SUs), which upload them to Arweave. By enforcing the availability of this log, user processes are decentralized - no longer residing on specific compute nodes - allowing their state to be resolved in real time by a distributed network of compute units (CUs).

This architectural difference ensures that ao processes have the necessary properties to enable the deployment of trustless smart contracts (verifiable decentralized computation), as well as the ability to host an arbitrary number of processes. This latter capability arises because processes can still be represented holographically (their message logs are permanently available) without any compute units currently attached to execute them.

Flexible Trust and Security Model

As described in this document, the ao Core Data Protocol provides a framework for secure computation, but does not itself provide or enforce any form of economic guarantees. Instead, ao provides a flexible system of cryptographic security elements that enable economic security mechanisms.

To fulfill the role of providing economic security to users, the ao staking contract and token are being developed, which are able to economically enforce the correct operation of units in the network.

While the detailed specification of such a mechanism is outside the scope of this data protocol definition, we provide a blueprint in the next section to illustrate how such a system can be built on top of ao.

The state of a process is primarily implicit in the interaction log stored on Arweave. Although the state is not stored, any participant can deterministically calculate it. This approach ensures that the state of a process, while not directly observable, can be independently verified and remains consistent across the network.

Full protocol specification:

https://permadao.com/permadao/ao-1353cc109d434941a6757560ef35dcc2