Author: Arweave Oasis, Source: Twitter @ArweaveOasis
Recently, Messari, a well-known research institution in the industry, published an article entitled "Arweave, AO, and AI - Modular Framework and Flexible Security", written by Seth Bloomberg. The content is very rich and has great reference value for understanding the AO and AR architecture and future development prospects. However, due to copyright issues, the full text cannot be translated and presented to readers. Therefore, the author hopes to extract fragments from it and present them to you in the form of interpretation. The original content can be obtained from Messari (paid).
On May 30, Seth Bloomberg, the author of this article, published some content summaries of the article on X. As follows:
Arweave has historically relied on external applications and ecosystems to transmit data to its network. AO is a new network built on Arweave, which will now create consistent demand for Arweave. AO will be a growth catalyst for Arweave and a new platform for application development.
I think one of the biggest technical values of AO is that it separates the consensus mechanism from the computation required by the application. Splitting these out gives AO a modular architecture and allows developers to scale the security and computational power of their applications.
Applications in AO incentivize computing providers to process state updates and other messages. This creates a new market for applications and computing providers. It ensures that applications get the level of resources they need on demand. This is very different from most smart contract platforms.
AO is a virtual machine-agnostic platform, which opens up the potential for deploying compute-intensive applications. Teams like @autonomous_af are already developing DeFi automation. However, on-chain LLM (Large Language Model) will be a completely different species.
Reading through the full text later, you will find interest in AO, a distributed world computer implemented in a completely different form. The main insights summarized are:
AO is a brand new protocol built on the permanent data storage network Arweave. One of the core value propositions of AO is its ability to run applications (such applications are called processes in AO terminology) in full parallelism without scalability limitations, and maintain related states locally without sharing global states across the entire network.
All applications on AO communicate through defined message (called Message in AO terminology) standards, providing processes with a ready-to-use read and write data solution.
A unique feature of AO is the ability to flexibly expand the security of processes. Process developers can configure the security required for their applications and expand security by effectively paying additional validators (called computing units CU in AO terminology) to calculate the state of the application.
Due to AO's scalability, VM-agnostic architecture (here refers to AO can support multiple VMs, allowing developers to choose different VMs to run their applications according to specific needs without being limited to a single VM environment.) and native cron job functions (referring to the system's native support for scheduled task scheduling without relying on external tools or third-party services), many teams hope to build automation tools and AI-driven products on the network.
Modularity and Flexible Security
The author summarizes the two main infrastructures that have emerged in the past few years: modular frameworks and flexible security.
Modular frameworks: enable developers to select common blockchain modular components (e.g., execution, data availability, settlement, and consensus) and combine them together. The article uses Base's Rollup and Celestia data availability layers as representative examples.
Flexible and scalable security: refers to the ability of some networks to protect their services more efficiently by leasing security, rather than launching a very heavy validator network themselves. The author uses Eigenlayer as a case to explain accordingly.
The goal of a modular framework is to encourage optionality and specialization of each component. For example, developers are free to choose the execution environment that best suits their needs. Flexible security providers help networks better manage and fine-tune the economic security of their systems.
AO is a typical example of leveraging both infrastructure models at the same time. This new system built on Arweave provides developers with the flexibility to choose execution environments and security models.
Unlike chains like Ethereum and Solana, which have a single global state concept (e.g., user account balances, smart contract data, etc.), AO localizes the state to each application (called a process in AO terminology). Localized state makes it easier for applications to parallelize computations, completely releasing overall performance limitations compared to non-parallel environments, and security can be customized for computations.
Unlike other Rollup ecosystems, AO defines a unified global message standard (Message) for all applications. The author believes that this approach is conceptually similar to the Cosmos ecosystem, which uses IBC for chain-to-chain communication. Therefore, AO can maintain its modular framework, and as its ecosystem grows, applications will benefit from this native communication standard. In the long run, AO, which has broken away from the traditional smart contract platform model and formed its own unique architecture, promotes a prosperous ecosystem for application development.
AO's Architecture
The author believes that the relationship between AO and Arweave is roughly similar to the relationship between sovereign Rollup and data availability layer. But AO provides a general framework similar to a smart contract platform, and its main goal is to achieve trust interoperability of these different applications through scalable computing services.
Interoperability between applications is derived from AO's message standards. Ecosystems such as Optimism, Polygon, Arbitrum, and zkSync usually develop on-chain economic activities first, and then develop interoperability solutions to solve fragmented user experience problems. AO will start its journey with native interoperability.
We have introduced the architecture of AO in various articles, and in this article we have also made some interpretations from the author's perspective:
Process
From the end user's perspective, a process can be regarded as an application. If a consumer is using a product built on AO, it usually appears in the form of a process.
A process can also be regarded as a series of ordered logs (i.e., messages) written to Arweave, representing its state at any given point in time.
Each process runs independently of other processes on AO, enabling them to parallelize operations without affecting each other. Processes interact with each other through messages. AO is actually a message delivery protocol, so the concept of message is the core structure.
Messages and Message Units (MU)
Whether the interaction with a process is initiated by the end user or by another process, it is represented as a message. Each message in AO conforms to the specific format of ANS-104 for reading and writing data in the Arweave ecosystem. As for what ANS-104 is, you can refer to this link for details.
The author compares the direct difference between AO and Ethereum. In AO, a process requests information from another process through a message and waits for the data to be returned to complete the interaction between processes. But on Ethereum, applications (i.e. smart contracts) can directly access the state of any other application due to the global nature of EVM.
There is a fundamental difference between the two. From a modular perspective, it is advantageous to pre-standardize the interoperability of different processes; most modular networks (such as Optimism's Superchain) are also developing similar standards.
Scheduling Unit (SU)
The author simply likens the scheduling unit to the sorter in many Rollup systems. Since the sorter is responsible for a series of operations in many Rollups (e.g., transaction processing, transaction ordering, zero-knowledge proof generation, etc.), the scheduling unit is more like a subset of the typical sorter.
The scheduling unit has two main process functions associated with it:
Ensure that each message is unique and in order. This is conceptually similar to nonce incrementing in other blockchain environments such as Ethereum. This is critical for the normal operation of a process.
Ensure that each message is written to Arweave. This enables processes to access each other's data.
Each AO process will have an associated scheduling unit.
Computing Unit (CU)
Computing units provide computing power for updating AO processes. Message units notify computing units of their service needs.
A market is formed between computing units (supply side) and users (demand side) who need a particular process to compute. Once again, this architecture is different from the traditional blockchain model. Nodes on traditional platforms (such as Ethereum) need to process transactions, and computing units can selectively bid for their updated processes.
Once the calculation is completed, the computing unit returns the signed proof of the calculation output to the original message unit.
AO Security Model
In the security model part, there is currently little relevant information, and more details will be available after the AO white paper is released. However, the author of the article gave his own understanding.
He believes that in this regard, AO has also taken a completely different path from Ethereum. In the Ethereum ecosystem, security is uniformly guaranteed by the Ethereum PoS mechanism, so whether it is a simple transfer operation or a complex DeFi interaction, they all share the same security level, which often leads to a waste of resources.
In AO's security framework, although all data uses the security guarantee of Arweave's SPoRes consensus mechanism, at the AO level, there is also more flexibility to customize the security level according to different needs and goals.
At present, although there is no exact information, it is generally believed in the ecosystem that the PoS mechanism will most likely be used in the security mechanism of AO (for example, staking and punishing AO tokens). With Arweave, a fully decentralized permanent storage network, and the AO computing platform that improves scalability and flexibility, the PoS mechanism is obviously in line with development needs.
Therefore, AO can propose certain different staking schemes for each component role and set up corresponding penalty mechanisms.
Computational Unit - The computational unit stakes the output proof of its signature. Anyone can question the output of the computational unit, and if it is proven to be malicious, its stake can be slashed.
Message Unit - The message unit stakes the message it transmits in the system. If it is found that it transmits and signs invalid messages, its stake can be slashed. If the invalid signature is due to the misbehavior of the computation unit, the message unit can initiate a slash event against the computation unit.
Scheduling unit - If the scheduling unit fails to correctly order messages or does not upload messages to Arweave, it can be slashed. The latter slash event is similar in design to the data availability guarantee.
Finally, a process can design its own security model in a sense. During the code execution of the process, for example, it can decide to ignore a computation unit or message unit that is considered untrustworthy.
The figure shows the security consistency of traditional smart contract platforms and the security customizability of the AO platform. This allows AO to customize different levels of security for different businesses, such as small transfers between friends do not need to be consistent with the security of large B2B transactions.
The Future of AO and AI
The author further expressed his views on the future combination of AO and AI. He believes that AI can be classified into two types:
Fully deterministic and fully parameterized, such as robots with configurable settings;
Non-deterministic, with adaptability, such as ChatGPT or LLM applications.
In the development of AO, the author thinks that the starting point will be the former, such as DeFi automation tools.
DeFi Automation
An early DeFi automation project on AO is @autonomous_af. The team built a "DCA agent" that enables users to buy specified tokens with dollar cost averaging (DCA).
DCA agent products follow the pattern:
Users define the tokens they want DCA to buy, as well as other parameters such as slippage tolerance, specific DeFi pools, the frequency of DCA transactions, and the amount of each DCA transaction.
The DCA agent responds to received notifications (i.e., scheduled tasks) and executes DCA transactions when predefined conditions are met.
Users can eventually suspend the DCA agent or permanently deactivate it.
It should be clear that this agent performs operations in a rule-based manner and effectively follows the instructions defined in its underlying script. This is classified as the former - fully deterministic and parameterized AI.
In this regard, Arweave founder @samecwilliams has also expressed similar views. In the current mainstream financial system, a large number of transactions are not operated by investors, but by various robots in automatic transactions. So this is also naturally applicable to DeFi interaction scenarios. In fact, the safest way to achieve certain goals is to set strict rules and operations for agents. This actually brings these products closer to the same level as traditional financial products and functions (e.g., setting stop losses, setting up DCA products from bank accounts, etc.), which is a good thing from a user experience perspective.
Beyond DeFi Automation
In addition to the simpler AI mentioned above, the current mainstream AI routines in the technology industry are focused on non-deterministic, adaptive AI, such as Chatgpt and LLM models.
Obviously, this type of system will be more advanced than a "DCA agent". But it is also very expensive. Generally speaking, LLM products require GPUs to provide the necessary computing power, and GPU computing is more expensive than typical CPU computing. The cost of self-hosting an LLM base model can easily reach about $20,000 per month. The author gives a data from a16z that some generative AI startups spend 80% of their funds on AI computing alone.
So, if you want to build applications that use LLM on AO, economic cost considerations are inevitable. But compared to other smart contract platforms, AO's architecture enables developers to scale and fine-tune the security level of their processes. This structure will greatly benefit AO developers because most LLM-generated messages are of low value.
Final Thoughts
The author gives his thoughts on AO's organization at the end:
AO's unique architecture provides an attractive platform for the development of applications, from DeFi to AI-driven applications.
Asynchronous messaging combined with parallel computing makes applications richer and more complex than typical smart contract applications.
The scalable and flexible security that supports processes is also unique to AO, and LLM-driven products in particular will take advantage of this property.