ao computer protocol specification

What is ao?

ao is an Actor Oriented computer running on Arweave, composed of network nodes that adhere to a core data protocol. This article briefly introduces the protocol specifications, functionalities, and technical details to enable builders to implement or integrate this service.

ao is a single, unified computing environment (Single System Image) hosted on a heterogeneous set of nodes in a distributed network. ao is designed as an environment capable of hosting an arbitrary number of parallel processes, which coordinate through an open messaging layer. This messaging standard connects independently running processes together to form a "network," similar to how websites run on separate servers but are linked together to create a cohesive system with a unified experience through hyperlinks.

Unlike existing decentralized computing systems, ao supports flexible computational operations that are not constrained by inherent capacity limitations and forms of the protocol, while maintaining the verifiability of the network itself (thus minimizing trust). Additionally, ao's distributed and modular architecture allows existing smart contract platforms to easily "plug into" the network, enabling a single process that can send and receive messages with any other process.

ao does not impose a set of rules on all users' computing environments; instead, it is built in a modular form: allowing users to choose the virtual machine, sorting model, messaging security guarantees, and payment options that best suit them. This modular environment settles transactions on Arweave's decentralized data layer through unified messages (all messages use the same format). This modular environment is a unified computing environment capable of meeting an extremely broad range of workload demands, where each process can easily pass messages and collaborate.

The core goal of ao is to provide trustless and collaborative computing services without scale limitations. This opens up new possibilities for applications that were previously impossible: combining the advantages of smart contract applications (services that only require trust in the code) with the benefits of traditional computing environments (like Amazon EC2).

aos (the decentralized operating system of ao) allows developers to launch command-line processes similar to smart contracts in a decentralized network. This process is akin to launching servers on cloud services, but decentralized and trustless computing is its key advantage. These processes are not limited to specific physical locations during execution, enabling seamless user interactions over the network. This results in a single (Single System Image), unified, global computing platform that transcends physical and scalability limitations, shared by all participants. In short, ao forms a vast, scalable computer where users can interact with any process, creating a highly collaborative ecosystem.

For users, ao represents a shared computer on which they can execute multiple processes. These processes are not bound to any specific server and are not controlled by any individual or group. Once activated, these processes provide services in a cryptographically secure manner, ensuring objective and persistent operation. This design grants users the right to use applications stably over the long term, providing a trustworthy environment for user-system interactions.

Core Features

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

• Arbitrary number of processes (similar to smart contracts) running in parallel: In ao, applications are built from an arbitrary number of communicating processes. Inspired by the original actor model (Carl Hewitt, 1973) and Erlang, ao does not allow processes to share memory but permits them to communicate via a native messaging standard. Each of these processes can then run at full speed using available computing resources without interfering with each other. By focusing on messaging, ao achieves a scaling mechanism more akin to traditional Web2/distributed system environments rather than conventional smart contracts.
• Unlimited computing resources: Built on the original versions of SmartWeave and LazyLedger (later known as Celestia) with a lazy computation architecture, nodes in the ao network do not need to perform any computations when reaching consensus on program state transitions. All logs of each process are stored, and the final process's Holographic State is retained on Arweave. The computational costs are then delegated to users, who can compute their states themselves or request computations from nodes of their choice.
• Access to Arweave, an infinite hard drive: ao processes can seamlessly load and execute any size of data directly into their memory and write back to the network. This setup eliminates typical resource constraints, enabling fully parallel execution and greatly expanding the possibilities for application development beyond the limitations of traditional smart contract platforms. Thus, it opens doors for complex applications requiring substantial data processing and computational resources, such as machine learning tasks and high-computation autonomous agents.
• Automated contracts: In traditional smart contract environments (like Ethereum, Solana, Polygon, etc.), contracts must be "awakened" to perform computations at the request of user transactions. In this environment, programs remain "inactive" unless users interact with them, thus limiting the range of applications that can be built on them. ao eliminates this limitation by allowing contracts to be awakened and execute computations automatically through scheduled tasks at set intervals. Any user or the process itself can pay a fee to a node to "subscribe" to a process, triggering computations at appropriate frequencies.
• Support for extensible modular architecture: The core architecture of ao is an open data protocol that anyone can build upon. Sorters, messaging relays, and even system-level virtual machines can be freely replaced and extended. This flexibility will allow existing smart contract systems in the Arweave ecosystem (such as Warp, everPay, Mem, etc.) to plug into ao and be able to send and receive messages with the unified network. This will also enable all these smart contract systems to share some of the same infrastructure and tools, making the computing experience on Arweave more coherent.

Overview of ao Architecture

The basic components of ao are as follows:

• Processes: The computational units in the network. Processes can be represented as interaction logs stored on Arweave, consisting of information data items. When initializing a process, it is necessary to define the computing environment (including the virtual machine, scheduler, memory, and necessary extensions). The state of a process can be computed through computational units that meet the demands and achieve consensus. In addition to receiving messages from user wallets, processes also receive messages from other processes through messenger units. Developers of processes can freely choose how to determine the trustworthiness of these messages (see below).
• Messages: Each interaction with a process in ao is represented by a message. Fundamentally, messages are data items that conform to the ANS-104 standard. Users and processes (through their inboxes and messenger units) can send messages to other processes in the network via scheduling units. The semantics of ao messages lie between UDP and TCP: guaranteeing that messages are sent only once, but if a message is never forwarded by the messenger unit or never actually processed by the recipient, it is as if that message never occurred.
• Scheduling Units (SUs): Scheduling units are responsible for assigning atomic incrementing time slot numbers (similar to Ethereum nonce) to messages sent to processes. Once assigned, the scheduler must ensure that the data is uploaded to Arweave for permanent access by others. Processes can freely choose their preferred sorter, which can be implemented in various ways: decentralized, centralized, or even user-hosted.
• Computational Units (CUs): Computational units are nodes that compute the state of processes in ao, using information provided by users and messenger units as input. The scheduling unit only sorts process messages and requires additional computational units for state computation of the processes. This creates a peer-to-peer computing market where computational units offer services to compute process states and compete with each other. These computational units negotiate trade-offs between price, computational demands, and other parameters. Once the state computation is complete, the computational unit returns an output proof with a signature to the caller. Computational units may also generate and publish signed state proofs, which other nodes can choose to load—potentially paying the fees specified by UDL.
• Messenger Units (MUs): Messenger units are responsible for transmitting messages in the ao network, which are relayed through a process called Cranking (a proprietary term meaning "to start" and "to repeat"). Essentially, when messenger units process a message in the system, they send the information to the appropriate SU for processing, which delivers the information to the CU for computation output and returns it to the SU, repeating this process continuously. This continues until there are no more messages to process. Users and processes can also pay fees to MUs to subscribe to a process, handling any messages generated by its scheduled task interactions. Processes can also optionally mark a message as broadcast (cast), causing the MU to send the message to its SU without listening for a response. In this way, ao can provide a vibrant environment, offering users and processes maximum freedom of choice—virtual machine (VM), payment methods, types of schedulers, messaging security, etc.—without needing to reach consensus on the expensive computation itself.

Related Work

Currently, there are no similar cases to describe ao and its user experience. However, there are many related projects and networks that can be compared with ao to elucidate 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 Universal Modular Actor Formalism for Artificial Intelligence” as a fundamental framework for understanding and implementing concurrency in computer systems. The model posits that the basic unit of computation is the "actor," which can make local decisions, create more actors, send messages, and determine how to respond to received messages. This system design and programming approach aids in creating distributed, highly concurrent, and scalable applications.

• Erlang

ao is largely inspired by the Erlang computing environment and its programming language. Erlang is an implementation of the Actor Model, providing extremely lightweight processes managed by a scheduler in the runtime to efficiently utilize large-scale parallel systems (machines and networks with multiple physical threads). These features produce a "process-oriented" programming form, where developers naturally divide their computations into many collaborative and parallel components to achieve their goals. Although Erlang is not very well-known in mainstream computing, it is widely used in many high-performance environments: telephone switches, instant messaging services like WhatsApp, etc.

The ao computer directly inherits Erlang's process-oriented approach. Erlang's empirical evidence shows that environments that achieve distributed computing by passing messages through processes without sharing memory can be very efficient. ao applies this approach to the realm of smart contracts while providing a single system image of an Erlang-like environment for the first time.

• Smart Contract Platforms (e.g., Ethereum)

Ethereum is a decentralized computing network where all users share memory and a single execution thread. Initially based on the idea of adding Turing-complete computation to the blockchain, Ethereum has evolved into a project to build a "world computer." At launch, Ethereum successfully demonstrated the capability of trustless arbitrary code computation for the first time—achieved without creating a separate blockchain network. While the network has garnered significant attention from users and developers, the throughput of the core network has not improved since its launch in 2015.

The Ethereum ecosystem has not attempted to scale the underlying network beyond the processing capacity of a single small thread but has instead turned to a "rollup-centric" roadmap. This scaling approach focuses on supporting additional "rollup" networks that inherit some but not all properties of Ethereum. As of the writing of this article, there are 14 rollup networks in the Ethereum ecosystem, with a total value of over $100 million behind the projects of these programs. Each of these 14 rollup projects represents another single-threaded computation (a "process" in ao terminology) that can be executed in parallel. ao is committed from the outset to building an architecture focused on parallel execution rather than shared memory, providing a completely new architecture for an arbitrary number of independent processes while maintaining the ability for programs to be decentralized and trustless.

• Decentralized Computing Markets (e.g., Akash)

On traditional smart contract platforms like Ethereum, the shared thread architecture limits each user to executing smaller computational tasks. This limitation constrains the complexity and scalability of operations on the network. This shared resource model inherently restricts the scalability and efficiency of applications, impacting the potential for more computation-intensive smart contracts.

Some networks aim to facilitate large-scale computing in a decentralized environment, such as Akash. Unlike platforms that emphasize verifiable and reproducible computation, Akash and similar networks provide a decentralized marketplace for container hosting services. This approach allows traditional, non-deterministic programs to be executed on x86 architecture physical machines. However, this method sacrifices the ability to create trustless services, such as those supported by smart contracts.

ao allows developers to choose their preferred virtual machine (VM), with the initial reference implementation focusing on using WebAssembly (WASM) to execute processes. In ao, WASM containers can manage up to 4 GB of memory, and this limit is expected to increase with the adoption of WASM64, enabling long-duration computations. The rich compilation tools in the WASM ecosystem support diverse programs. Recent examples of WASM usage include executing large language model (LLM) transformer models, speech recognition, and even computation-intensive image processing software like Photoshop in web browsers.

In addition to significant computational capabilities, ao benefits from its holographic state mechanism, which allows it to maintain the attributes of traditional smart contracts. ao does not reach consensus on the state of the computation itself but focuses on ensuring that interaction logs are written to Arweave and have persistent availability. Through deterministic billing virtual machines and the availability of all process messages on Arweave, a "hologram" can be projected: the state may not yet have been computed by any participant, but once the computation is complete, we can guarantee that its output will always be consistent. Furthermore, the holographic state system enabled by message logs on Arweave allows ao processes to respond to implicit messages based on time, waking themselves up and executing actions. Combined with its holographic state mechanism, ao also provides a distributed network of Compute Units (CUs) that offer users encrypted signed statements about computation results. These computational nodes compete in a market, reducing the cost for users to interpret the holographic state.

• Peer-to-Peer Virtual Machine Hosting (e.g., Urbit)

Urbit is a peer-to-peer computing system that shares some similarities with ao. Urbit provides a distributed computing environment by focusing on the transmission and availability of interaction logs, allowing "servers" to migrate from one physical host to another. During the transition from one host to another, interaction logs can be executed to recompute the current state. Urbit processes can also send messages to each other for communication.

Unlike ao, Urbit does not reach decentralized consensus on its interaction logs. In fact, this means there is no authoritative protocol for its "rollup" or assurance of its availability—thus, the state of its processes is not guaranteed. In this case, Urbit can be seen as similar to Akash and other decentralized computing markets, but it has the additional capability to verifiably migrate computations from one host to another if the host is willing to transition. ao expands upon this model by ensuring that log messages sent to processes via scheduling units (SUs) are available, which these scheduling units upload to Arweave. By enforcing the availability of this log, user processes are decentralized—not residing on specific computational nodes—allowing their states to be resolved in real-time by a distributed network of computational units (CUs). This architectural difference ensures that ao processes possess the necessary attributes to deploy trustless smart contracts (verifiable decentralized computation) and to host an arbitrary number of processes. This latter capability arises because processes can still be holographically represented (their message logs are permanently available) without currently attaching any computational units to execute them.

• Flexible Trust and Security Models

As described in this document, the core data protocol of ao provides a framework for secure computation but does not itself provide or enforce any form of economic guarantees. Instead, ao offers a flexible system of cryptographic security elements that can implement economic security mechanisms.

To fulfill the role of providing economic security to users, ao staking contracts and tokens are being developed that can economically enforce the correct operation of units in the network. While the detailed specifications of this mechanism are beyond the scope defined by this data protocol, we provide a blueprint in the next section to illustrate how such a system can be built on top of ao.

Complete Protocol Specification: https://permadao.com/permadao/ao-1353cc109d434941a6757560ef35dcc2