AO's Modular Architecture & Computing Model (Part II)

Previously, we explored how the AO Computer, rooted in the actor-oriented paradigm and leveraging the Arweave network, represents a leap forward in decentralized computing.

Now, let's unpack the building blocks of ao: Modules, Processes, Messages, Scheduler Units (SUs), Compute Units (CUs), and Messenger Units (MUs).

Modules

Modules encapsulate WebAssembly-compiled code that processes execute. Unlike traditional libraries or packages that offer supplemental functionalities, modules represent the entire application logic and can run in a self-contained, sandboxed environment. Each module is uniquely identified by a Transaction ID (TXID) and deployed on the AO network, ensuring processes can precisely reference and utilize its functionalities.

A module defines the operational logic and sets parameters for the execution environment, such as memory limits and computational boundaries. This ensures that the module operates within defined resource constraints

For example, a task management module may specify:

{
  "Data-Protocol": "ao",
  "Variant": "ao.TN.1",
  "Type": "Module",
  "Module-Format": "wasm32-unknown-emscripten",
  "Input-Encoding": "JSON-V1",
  "Output-Encoding": "JSON-V1",
  "Memory-Limit": "64-mb",
  "Compute-Limit": "2000",
  "Extension": "TaskManagement"
}

Processes

Processes are the primary units of computation within the AO network, represented by a log of messages stored on Arweave and an initial data item.

Each Process is uniquely identified and operates based on pre-defined computing requirements, such as virtual machine (VM) type, memory allocation, and specific scheduler units (SUs) for message sequencing. These specifications are outlined at the initiation of a Process, ensuring it has the necessary resources and environment to execute its tasks effectively.

They interact by sending and receiving messages facilitated by Messenger Units (MUs). This interaction allows for dynamic communication between different Processes and with user interfaces, enabling a broad range of decentralized applications.

The AO Computer leverages Arweave to store a log of messages associated with each Process, providing transparency, traceability, and immutability.

Here's what this data item might look like:

{
  "Data-Protocol": "ao",
  "Variant": "ao.TN.1",
  "Type": "Process",
  "Module": "{TXID-of-Module}",
  "Scheduler": "{Wallet-Address-of-Scheduler-Unit}",
  "Memory-Limit": "32-mb",
  "Compute-Limit": "500",
  "Cast": "False",
  "Custom-Tag-Example": "AppV1"
}

Messages

Messages are the medium of interaction within AO, compliant with ANS-104. They allow communication between processes, either from users or other processes.

It is modeled to offer reliable delivery (akin to a mix between UDP and TCP), ensuring a message is delivered exactly once.

Here's what this data item might look like:

{
  "Data-Protocol": "ao",
  "Variant": "ao.TN.1",
  "Type": "Message",
  "Load": "{TXID-of-User-Message}",
  "Read-Only": "False",
  "From-Process": "{TXID-of-User-Process}",
  "From-Module": "{TXID-of-Module}",
  "Pushed-For": "{TXID-of-Target-Message}",
  "Cast": "False",
  "Message-Content": "Hello, AO world!",
  "Sent-Time": "YYYY-MM-DDTHH:MM:SSZ"
}

Scheduler Units (SUs)

They are responsible for sequencing messages (sequencing means ordering the messages in a specific sequence before they are processed) sent to processes, assigning a unique slot number to each message. This sequencing ensures that all messages are processed in a consistent and predictable order, a necessity for the integrity of decentralized applications.

Developers can choose their SU based on specific needs, ranging from decentralized options for enhanced trust to centralized ones for potentially faster processing times. This choice directly impacts the application's performance, with different SUs offering varying degrees of latency and reliability.

Compute Units (CUs)

Compute Units (CUs) are the powerhouse of the AO Computer, executing the WebAssembly code defined within modules. CUs transform instructions into actions, directly impacting the process's state based on predefined requirements.

They operate within a peer-to-peer marketplace, CUs vie for tasks, offering computation services based on various factors such as price and computational requirements.

Upon task completion, a CU issues a signed attestation detailing the outcome, including any changes in state, generated messages, or additional process requests.

This attestation serves as a verifiable record of the computation, ensuring transparency and accountability. Developers can publish these attestations, allowing others within the network to utilize or verify the computed results.

In essence, CUs ensure that the AO network remains a dynamic, efficient, and trustable computing environment where tasks are executed with precision and integrity.

Messenger Units (MUs)

MUs ensure efficient message flow within the network. They handle the routing and delivery of messages between processes, Scheduler Units (SUs), and Compute Units (CUs) through "cranking."

MUs enable both broad and targeted message broadcasts, crucial for real-time interactions in applications like chatrooms. They support process subscriptions for automated responses to events or triggers, enhancing network adaptability.

What is cranking?

Cranking involves taking a message, determining its next destination based on its content and tags, and then passing it on to the appropriate unit, such as a Compute Unit (CU) for processing or a Scheduler Unit (SU) for sequencing. This action ensures messages are delivered to their intended recipients or processes efficiently, maintaining the flow of information within the decentralized system

Example: Voting dApp

Let’s use a real-world example to illustrate how ao works: A decentralized voting application on AO allows users to cast votes for their favorite fruit in a straightforward, secure process.

Step 1: Creating the Process

A developer creates a Process with logic for vote collection and tallying. This Process specifies a Module, which contains the executable code and is identified by a unique Transaction ID (TXID). The process, through referencing this Module, is executed within the AO network's Compute Units (CUs) capable of running the specified module.

Step 2: Users Vote

Users send their votes (e.g., "Apple", "Banana", "Cherry") through a website interface. Each vote is a Message sent to the voting process.

Step 3: Handling Votes

Messenger Units (MUs) pick up these vote messages and pass them to Scheduler Units (SUs). The SU organizes these votes in the order they were received, ensuring a fair counting process.

Step 4: Counting Votes

Sequential votes reach Compute Units (CUs), which tally the votes for each fruit using the process deployed by the developer earlier

Step 5: Announcing Results

The CU compiles the final count (e.g., "Apple: 50, Banana: 75, Cherry: 25") and communicates this to the website through an MU. The site then updates to reflect the majority's choice.

Simplified Flow:

1. Process Created: The developer launches a voting process.
2. Users Vote: Each vote is sent as a simple message.
3. MU & SU: Votes are collected and organized.
4. CU Counts: Votes are tallied.
5. Results Shared: Winning fruit is displayed on the website.