Three perspectives to understand AO’s disruptive innovation

Author: 0xmiddle

AO can be understood as a network with infinite shards and infinite expansion. Each process is a shard.

AO is not a blockchain in the traditional sense. Its unconventional and anti-common sense design can easily confuse researchers who have just learned about AO in some aspects, especially when researchers try to frame AO with the architecture of traditional blockchain:

1. Non-PoS, non-PoW, what kind of consensus mechanism is the "holographic consensus" mentioned by AO?

2. Without a hash chain or even a block, how does AO ensure that data is immutable?

3. Without a coordination center, how does AO ensure the consistency of the global state?

4. Without a redundant computing mechanism, who will guarantee the reliability of the calculation? What if the calculation goes wrong?

5. Without shared security, how to ensure the interoperability between processes?

I will use 3 perspectives and concepts that everyone is familiar with in blockchain to help everyone go from the known to the unknown, turn the unknown into the known, and understand AO at a perceptual level.

Sharding perspective

After the education of 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 a shard, while 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, and the parachain independently collects and packages its own blockchain, and a group of verifiers is randomly assigned by the relay chain to verify it. Parallel chains use a unified XCM message format to communicate and achieve interoperability.

AO's Ultimate Sharding

From the perspective of sharding, AO can be understood as an extreme "sharding": each process is a shard. Imagine what it would be like if each smart contract in Ethereum ran on a separate shard? Yes, this is AO. Each process is independent, and the 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?

AO's consensus layer 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. In other words, 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 has an optimistic arbitration mechanism. Arweave accepts all message data uploaded by the AO network. Each message will carry its sender process id, 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, create the correct fork, discard the original wrong fork, and confiscate the deposit of the wrong 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 confiscation.

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 certainty of Arweave takes more than half an hour to form. 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 they will be accounted.

The Process in AO actually determines the verification strength autonomously.

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 redundancy is also determined by Process.

In actual applications, the verification strength is often related to the amount of the transaction. For example, for small transactions, a fast verification strategy is adopted, and the transaction is processed after a single point confirmation.

For medium-amount transactions, a multi-point confirmation and processing strategy with different redundancy is adopted according to the specific amount.

For large transactions, a cautious verification strategy is adopted, and the transaction is processed after the Arweave network confirms.

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 is not on the network itself, but on the receiving process itself, or on the application developer.

It is precisely because of this consensus model that AO can adopt the hub-free and infinite expansion model of "extreme sharding".

Of course, elastic verification leads to different verification strengths for different processes. In complex interoperation, the trust chain may be broken. The failure of individual links in a longer call chain will lead to the 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 will be available in the upcoming official network of AO.

Resource perspective

In traditional blockchain systems, resources are abstracted as "block space". Block space 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 needs to consume 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 them, CU is the core that carries computing tasks. MU and SU carry communication tasks. When a process needs to interact with other processes, it will generate a message and store it 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, MU in the AO network only needs to store temporary data required for calculation, which can be discarded after the calculation is completed. Arweave is responsible for permanent storage. Although Arweave cannot be horizontally expanded, its storage performance ceiling is extremely high. The storage requirements of the AO network will not be able to 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 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 scalable according to demand. This adjustment will be very sensitive, and nodes can be added and removed very quickly. Looking back at Ethereum, we will find that when resource demand rises sharply, everyone has no choice but to endure high gas fees, because Ethereum cannot improve its performance by expanding the number of nodes.

Summary

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 first few questions, do you understand them?

1. 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. At the hard consensus level, it relies on Arweave. 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 can 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 "block", these structures used to ensure data immutability, are available in the Arweave chain.

3. Without a coordination center, how can AO ensure the consistency of the global state?

Each Process is an independent "shard" that manages its transactions and status independently, and the Process interacts 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, and combined with the optimistic challenge mechanism, it can be used for dispute resolution.

4. Without a redundant computing mechanism, who will guarantee the reliability of the calculation? What if the calculation goes wrong?

AO does not have a globally mandatory redundant computing mechanism. Each process can decide for itself how to verify the reliability of each message sent. If the calculation goes wrong, it can be discovered and corrected in the form of an optimistic challenge.

5. Without shared security, how to ensure interoperability between processes?

Processes need to manage the credit of each process that interoperates with it, and different levels of verification strength can be used for processes with different security levels. For interoperability with complex call chains, in order to avoid the high error correction costs caused by the break of the trust chain, AO may have a minimum verification strength requirement.