Author: 0xmiddle
Reviewer: Sandy
Source: Content Association - Investment Research
AO is not a blockchain in the traditional sense. Its unconventional and counterintuitive design can easily confuse researchers who have just learned about AO, especially when researchers try to define AO using the traditional blockchain architecture:
- Non-PoS, non-PoW, what kind of consensus mechanism is the “holographic consensus” mentioned by AO?
- Without a hash chain or even a block, how does AO ensure that data is immutable?
- Without a coordination center, how does AO ensure the consistency of the global state?
- Without a redundant computing mechanism, who will guarantee the reliability of the calculation? What if the calculation goes wrong?
- Without shared security, how to ensure interoperability between processes?
I will use three perspectives and concepts that everyone is already familiar with in blockchain to help everyone travel from the known to the unknown, turn the unknown into the known, and understand AO on a perceptual level.
Sharding perspective
After being educated on public chains such as Ethereum 2.0, Polkadot, and Near, everyone should be familiar with "sharding".
The concept of sharding : In blockchain, sharding is a solution to improve network scalability by splitting the network into multiple shards. Each shard independently verifies and processes transactions and generates its own blocks, thereby improving the overall network efficiency. Synchronous interoperability can be achieved within the shard, and asynchronous interoperability can be achieved between shards through certain communication protocols.
Polkadot is the most typical sharding architecture. In Polkadot, each parachain is a shard. Parachains independently collect and package their own blockchains, and the relay chain randomly assigns a validator group to verify. Parachains communicate with each other in a unified XCM message format to achieve interoperability.
AO's Ultimate Sharding
From the perspective of sharding, AO can be understood as an extreme form of "sharding": each process is a shard. Imagine what it would be like if each smart contract of Ethereum ran on a separate shard? Yes, that's AO. Each process is independent, and calls between processes are message-driven and carried out in a completely asynchronous manner.
Modular perspective
But we found a key point. In the design of Polkadot, there is a "relay chain" and in ETH2.0 there is also a "beacon chain". Their role is to serve as a unified consensus layer and provide shared security. The unified consensus layer is responsible for providing direct or indirect verification services for all shards and message transmission between shards. AO does not seem to have this component, so how is AO's consensus layer designed?
The consensus layer of AO is actually Arweave. From a modular perspective, AO can be understood as Arweave's L2, with Arweave as the Rollup of L1. All message logs generated during the operation of the AO network will be uploaded to Arweave for permanent storage, that is, there is an immutable record of the operation of the AO network on Arweave. Then you may ask, Arweave is a decentralized storage platform and does not have much computing power. How does Arweave verify the data uploaded by the AO network?
The answer is: Arweave does not verify, and the AO network itself will have an optimistic arbitration mechanism. Arweave accepts all message data uploaded from the AO network. Each message will carry the process id of its sender, the signature of the CU (computing unit) that runs it, and the signature of the SU (sorting unit) that sorts it. When a dispute occurs, you can rely on the immutable message records on Arweave, introduce more nodes for recalculation to create the correct fork, discard the original erroneous fork, and confiscate the deposit of the erroneous CU or SU in the correct fork. It should be noted here that MU is only responsible for collecting the pending messages of Process and passing them to SU. It is trustless, does not require a deposit, and does not involve confiscations.
AO is very similar to Optimistic Rollup with Arweave as L1, except that the verification challenge process does not occur on L1, but in the AO network itself.
However, there is still a problem here. It is impossible for every message to be confirmed after being included in Arweave. In fact, the final confirmation time of Arweave is more than half an hour. Therefore, AO will have its own soft consensus layer, just like Ethereum's Rollups have their own soft consensus layer. Most transactions will not wait for L1 confirmation before being recorded.
The Process in AO actually determines the verification strength independently.
As the message receiver, Process must decide whether to wait for Arweave confirmation before processing the message, or to process the message immediately after confirmation at the soft consensus layer. Even in the soft consensus layer confirmation stage, Process can adopt a flexible strategy. It can be processed immediately after confirmation by a single CU, or it can be redundantly confirmed by multiple CUs and cross-validated before processing. The degree of redundancy is also determined by Process.
In practical applications, the verification strength is often related to the transaction amount, for example
For small transactions, a fast verification strategy is adopted and the transaction is processed after a single point of confirmation
For medium-sized transactions, a multi-point confirmation post-processing strategy with different redundancy levels is adopted according to the specific amount.
For large transactions, a cautious verification strategy is adopted and the transaction is processed after confirmation by the Arweave network.
This is what AO calls the "holographic consensus" + "elastic verification" model. By decoupling the "verifiability" and "verification" behaviors themselves, AO has adopted a completely different approach to the consensus problem from the traditional blockchain. The responsibility for message verification does not lie with the network itself, but with the receiving Process itself, or in other words, with the application developer.
It is precisely because of this consensus model that AO is able to adopt the hub-less, infinite expansion model of "extreme sharding".
Of course, elastic verification leads to different verification strengths for different processes, which may lead to a break in the trust chain in complex interoperation. Failure of individual links in a longer call chain will lead to failure or error of the overall transaction. In fact, such problems have been exposed in the AO test network stage. I think AO should set a minimum verification strength standard for all verification tasks. Let us wait and see what new designs AO's upcoming official network will have.
Resource perspective
In traditional blockchain systems, resources are abstracted as "block space", which can be understood as a collection of storage, computing and transmission resources provided by nodes, and organically combined through on-chain blocks to provide a carrier for on-chain applications to run. Block space is a limited resource. In traditional blockchains, different applications need to compete for block space and pay for it, and nodes make profits through such payments.
There is no concept of blocks in AO, and naturally there is no concept of "block space". But like smart contracts on other chains, each process on AO also consumes resources when running. It needs nodes to temporarily store transactions and status data, and it also needs nodes to consume computing resources to perform computing tasks for it. The messages it sends need to be transmitted to the target process by MU and SU.
In AO, nodes are divided into three categories: CU (computing unit), MU (message unit), and SU (sorting unit), among which CU is the core that carries computing tasks. MU and SU carry communication tasks. When a process needs to interact with other processes, a message will be generated and stored in the outbound queue. The CU running the process will sign the message. MU extracts the message from the outbound queue and submits it to SU. SU assigns a unique serial number to the message and uploads it to Arweave for permanent storage. Then MU passes the message to the inbound queue of the target process, and the message delivery is completed. MU can be understood as the collector and deliverer of messages, and SU can be understood as the sorter and uploader of messages.
As for storage resources, the MU in the AO network only needs to store temporary data required for calculations, which can be discarded after the calculations are completed. Arweave is responsible for permanent storage. Although Arweave cannot be expanded horizontally, its storage performance ceiling is extremely high. The storage requirements of the AO network will not reach the ceiling of Arweave in the foreseeable future.
We found that the computing resources, transmission resources, and storage resources in the AO network are all decoupled. In addition to the unified storage resources provided by Arweave, computing resources and transmission resources can be expanded horizontally without any restrictions.
The more and higher-performance CU nodes join the network, the higher the computing power of the network will be, and the more processes can be run. Similarly, the more and higher-performance MU and SU nodes join the network, the faster the network transmission efficiency will be. In other words, the "block space" in AO can be continuously created. For applications, you can purchase public CU, MU, and SU node services in the open market, or you can run your own private nodes to serve your own applications. If the business of an application expands, you can improve performance by expanding your own nodes, just as Web2 applications do. This is unimaginable on traditional blockchains.
At the resource pricing level, AO can flexibly adjust supply and demand, so that the supply of resources can be scaled up and down according to demand. This adjustment will be very sensitive, and nodes can join and leave very quickly. Looking back at Ethereum, we will find that when the demand for resources rises sharply, everyone has no choice but to endure the high gas fees, because Ethereum cannot improve its performance by expanding the number of nodes.
Summarize
Above, we started with concepts familiar to most crypto researchers, such as "sharding", "modularization", "Rollup", "block space", etc., and cut into the principles and mechanisms of AO, helping everyone understand how AO achieves almost unlimited expansion through disruptive innovation.
Now look back at the questions at the beginning, do you understand them?
- Non-PoS, non-PoW, what kind of consensus mechanism is the “holographic consensus” mentioned by AO?
AO's consensus mechanism is actually a design close to Op Rollup. It relies on Arweave at the hard consensus level, and at the soft consensus level, each process can independently determine the verification strength and how many CU nodes are used for redundant calculations.
2. Without a hash chain or even a block, how does AO ensure that data is immutable?
DA data uploaded to Arweave is immutable, providing verifiability for all calculations and transmission processes on AO. AO itself does not need to limit the processing capacity per unit time, so there is no need to set blocks. "Hash chain" and "blocks", these structures used to ensure data immutability, are available on the Arweave chain.
3. Without a coordination center, how does AO ensure the consistency of the global state?
Each process is an independent "shard" that manages its transactions and status independently, and processes interact in a message-driven manner. Therefore, there is no need for global state consistency. Arweave's permanent storage provides global verifiability and historical backtracking capabilities, combined with an optimistic challenge mechanism, which can be used for dispute resolution.
4. Without a redundant computing mechanism, who will ensure the reliability of the calculation? What if the calculation goes wrong?
AO does not have a globally enforced redundant computation mechanism. Each process can decide for itself how to verify the reliability of each message sent. If a computation error occurs, it can be discovered and corrected through optimistic challenges.
5. Without shared security, how to ensure interoperability between processes?
A process needs to manage the trust of each process it interoperates with, and can use different levels of verification strength for processes of different security levels. For interoperation with complex call chains, in order to avoid the high error correction costs caused by the break of the trust chain, the AO may have a minimum verification strength requirement.
