The Hyper Parallel Computer: AO by Arweave
Key Takeaways
- AO is a highly scalable blockchain network built on Arweave, the permanent data storage platform
- AO is a hyper-parallel computer which allows computation to be carried out simultaneously in parallel
- Computation synchronization is achieved through message-passing, creating a single, unified computing environment
What is Arweave
Arweave offers permanent data storage based on the storage-based consensus paradigm (SCP) and allows for the creation of a persistent, immutable internet. This makes Arweave highly suitable for applications that require both data provenance and long-term data integrity, with examples including storage of legal documents, academic research papers, etc.
To understand Arweave in deeper detail, refer to this article.
For this article, we can keep in mind that Arweave is a highly performant data storage platform. This will help us understand why AO is built on Arweave and the deep coupling between AO and Arweave.
What is AO (Actor-Oriented) Computer
AO is a hyper-parallel computer built on Arweave, where its decentralized computing environment allows for parallel executions.
This results in the scalability of AO being significantly higher as compared to existing blockchains. In addition, AO grants sovereignty and flexibility to applications building on it by modularizing its architecture (more on this later).
This enhanced scalability makes it possible for AO to handle large datasets and carry out intensive computation, typically required in artificial intelligence (AI) applications. By building on Arweave, and having access to permanent storage, AO can offer trustless computation verification.
More will be explored in future articles, but an exciting aspect to look forward to from AO is the possibility of embedding autonomous agents and large language models (LLMs) within smart contracts.
Note: The author’s thoughts and insights will be represented in italics.
AO’s Architecture
Let’s move on to understand AO’s architecture, which consists of 5 elements
1. Processes
Each process refers to code stored on Arweave. The code represents a set of instructions to be executed, which will result in an eventual state. Based on what’s to be built, every individual process can customize a specific computing environment.
Each process within AO has access to permanent on-chain data storage by posting messages to Arweave.
We can think of each process as a smart contract (could be an app or a chain). These smart contracts can communicate with each other through message-passing solutions, enabling interoperability. To understand message passing in detail, refer to this.
2. Messages (Native to Individual Processes)
These are interactions with processes and can originate from either users or other processes. Messages are written to Arweave’s decentralized data layer (the mechanics and benefits of this will be explained in more detail later).
Think of messages as user transactions/chains calling certain functions on other chains (for example for bridging (lock and mint, burn and mint, etc.), cross-chain money market, etc.).
3. Scheduler Units (Global)
In charge of sorting and scheduling messages for execution. The contents of these messages are uploaded to Arweave for permanent storage.
Assuming that processes send their messages to the same scheduler, we can be optimistic that AO won’t run into dependencies issues where the execution of certain messages touches the same state. This is because the order of message execution is global and accounts for all processes.
To draw parallels, SUs are similar to rollup sequencers or builders, who both have access to the list of transactions submitted by users and order them accordingly to be propagated further for execution.
4. Compute Units (Global)
These are nodes that execute the messages and determine the state of processes (similar to how nodes that validate a chain carry the chain state). Computation is completed upon the user receiving a signed attestation of the output. The output of the message execution is then uploaded to Arweave.
AO provides a peer-to-peer (P2P) market for CUs. Based on the messages scheduled by the SU, the CU that is most suitable will take up the execution of that message (could be based on speed, cost, etc.)
The P2P market poses similarities to much of the existing decentralized GPU marketplaces, as well as solver networks within DeFi applications. We will explore in detail later the importance of data upload to Arweave, as it lays the ground for ease of computation verification.
5. Messege Units (MUs)
The MU passes messages through cranking, which is the coordination of message transfer to a scheduler, and then to a compute unit.
AO can support cron messages, which are messages that are automatically executed at certain intervals. This is a feature that allows for the creation of solutions like autonomous AI agents, which will take certain actions upon certain triggers. This will be explored further in future articles, but the further integration of an LLM into processes will allow these AI agents to learn from the executions and optimize their functions.
Cron messages seem to have some resemblance to hooks that are being used in DeFi applications such as Uniswap v4, which allows certain conditions to be included in the code, and upon triggering these conditions, certain actions (pre-specified) will be carried out. To put it in simpler terms, you can think of it as a dollar-cost-average (DCA) strategy where you can automate for a token to be bought at regular intervals (e.g. buy 1 BTC every month).
AO offers privacy by allowing processes to label messages as a cast. Under this arrangement, MUs will send the message to SUs as normal, but SUs will not know the output of that message execution.
We will have to wait for more details to understand how the privacy aspect will be achieved. In addition, if the SUs are able to schedule the messages without having to know the execution output, why not make it a feature for all messages propagated to the SU?
Features of AO
Now that we have a better understanding of AO’s architecture, let’s explore the features it brings.
1. High Scalability with Holographic State (Parallel Execution)
Each process within AO can maintain an independent state, allowing an unlimited number of processes to run in parallel. Each process can customize its mechanisms and does not have to be constrained by the limitations of other processes (e.g. block sizes, block time, execution method, consensus, etc.).
This is a highly appealing benefit provided and has been highlighted in prominent projects including the likes of EigenLayer.
2. Modular Architecture
Processes built on AO are granted full sovereignty, where they can make decisions on the type of virtual machines (VMs), sequencer style, and other design choices. Arweave uses this to reach a wide group of developers and recently announced support for Rust developers.
3. Interoperability through a Single Unified Computing Environment
AO, being built on Arweave, is hosted on a heterogeneous set of nodes. Despite being independent, processes can coordinate through an open message-passing layer. Thus, the above-mentioned modular environment is unified through the eventual settlement of all messages onto Arweave’s decentralized data layer.
This is similar to websites, which operate on independent servers but are joined together by hyperlinks. Each of these websites has its own memory space while being able to communicate data with other websites.
A mental framework to adopt for this would be the existing cross-chain message-passing solutions we have e.g. Layer Zero, Axelar, etc.
In the words of AO’s founder, Sam: ‘We took essentially the orchestration of a normal blockchain and sliced it up into different modular components and then made each of those into horizontally scalable subnetworks’
Benefits of AO
Now that we have a better understanding of AO (I sure hope my writing didn’t bore you out), let’s take a look at the advantages AO has.
1. Infinite Scalability
As mentioned in the above sections, AO allows for parallel execution of processes, which are the computation units on AO. This is made possible as the processes maintain a holographic state, where their computation will not affect the computation being carried out on other processes.
It is theoretically thus, possible for an infinite number of processes to be spun up on AO, to be used in different use cases.
2. Trustless Computation and Permissionless Verification
In AO, all pre and post-calculation states of processes are uploaded to Arweave and are stored permanently. Any 3rd party will be able to download the stored data, run the same computation, and derive the same results. This is known as permissionless verifiability. This ensures that data is kept pristine, and resilient against data tampering.
Since all stakeholders within the AO ecosystem have access to stored data on Arweave, there is no need for consensus on the final state of the computation, since it will always be a consistent output from the same input and same execution environment. This is known as trustless computation.
This felt very similar to the concept of a public mempool, which in this case can be proxied to Arweave. All processes in AO, and other stakeholders have a purview of what’s in this ‘mempool’, and can make certain decisions or claims on this mempool without having to communicate with each other. This is similar to Sei Network, where blocks are optimistically built and propagated by nodes that listen in to their mempool for transactions.
In addition to being able to achieve core blockchain features (permissionless verifiability and trustless computation), AO can potentially offer lower latency in certain applications, given that there is no need to reach for consensus to be reached.
3. Decentralized Cloud Service Network
AO’s parallel processing architecture makes it possible to share and exchange cloud resources in its network. Resources including processing power, storage bandwidth, etc. can be shared across processes, maximizing the usage of such resources.
Should AO decide to focus on this path, the uptake might be accelerated, given the plethora of GPU / computation marketplaces that exist, with prominent ones including Render, Akash, and more recently io.net. In addition, Peaq, the DePIN-centric L1 has recently announced its fundraise, the similarities and differences in these architectures will be interesting to study.
4. Broad Composability of AO Ecosystem
AO is creating an execution environment where even nodes and validators of other networks can be hosted on their platform, as mentioned in this article.
This is beneficial in AO’s go-to-market and ability to capture both builders and users.
5. Plug and Play Model for Ease of Building
It is very easy for smart contract platforms to plug into AO as a singular process, given the modular architecture. The message-passing framework also removes the need for platforms to worry about interoperability.
NBA Analogy
Okay time for the fun stuff, let’s understand AO using the example of NBA.
Processes = Stadiums
Messages = Results of games
Compute Unit = NBA teams
Message Unit = Communication of game results
Scheduler Unit = Scheduling of games
Arweave = Result slip
Parallel execution for processes: Games are being held concurrently at the various stadiums
Message unit: Convey the winners and losers at each tier
Scheduler unit: Games are being scheduled based on the winners
Compute unit: NBA teams are playing to find the winner
Arweave: Game results are being stored in a database
Questions
To end off, there are some questions and thoughts I will keep at the back of my mind while AO continues to develop.
1. Sam mentions that the key differentiation between AO and the other parallel chains is that it can store large amounts of data
In this case, if other parallel EVMs integrate a highly scalable database → Would it be possible for them to achieve the same level of scalability and performance?
2. Eddy from a16z mentioned that all system messages can be signed and saved in 1 place for verification of materials
Are there any downsides in terms of storage burden?
3. Are there any possibilities for miscommunication between the different units in AO
What happens when there is a lack of synchronization or the messages don’t get transferred?
4. Is it possible for the economic security guarantee of AO to come from EigenLayer?
Appendix
Why is it named AO (actor-oriented)?
- Inspired by the Actor model in Computer Science
- Suited for designing and implementing systems that are highly concurrent, distributed, and fault-tolerant
Features of AOS (decentralized operating system built by Arweave based on AO)
- Utilizes the Lua programming language which is used commonly in games, examples include Angry Bird and Roblox
- Compatible with EVM and other VMs through the integration of WASM, Rust, etc.
Details on AO components