AO-Core launched along with AO’s native tokens on February 9th, and today the first community-operated mainnet nodes are beginning to be deployed in the network. As well as the general availability of HyperBEAM -- AO’s new groundup node implementation -- we are excited to announce today early access for mainnet Milestone 2: allowing users to run their own nodes on Trusted Execution Environments (TEEs).

In this post we’ll describe AO’s main components and what their significance is to the system. We will cover:

1. AO-Core: Blockchains expressed inside the HTTP layer of the internet.

2. Hashpaths: The atomic units of verifiability.

3. HyperBEAM: An Operating System for AO devices.

Finally, we’ll conclude with an overview of the current and upcoming state of development of AO-Core, as well as how best to get involved.

AO-Core is a new primitive for the internet. In essence, it is a simple but powerful protocol for describing how programs transform state from one form to another, while providing security guarantees and attestations of correctness. In doing so, it is a meta machine. AO-Core boiled down the main characteristics of what blockchains really are, and instead of using bespoke, unique chains and languages, it is expressed inside the protocols and languages that are already popular and widespread.

At the heart of this architecture is the new internet standard HTTP Message Signatures. This new standard, which became a ratified member of the HTTP protocol specification family last year, simply provides an open framework and language that allows HTTP request messages and responses to be signed with cryptographic keys. Arweave data responses have similar headers and responses to HTTP Message Signatures, which allows us easily use them as a new form of data item that can be uploaded to the network.

AO-Core adds new capabilities to these primitives: An open representation of blockchain semantics inside HTTP message. The crucial addition that AO-Core adds in order to make this possible is the revolutionary concept of hashpaths: A means of verifying and attesting to program state-transformations using HTTP Signed Messages. Unlike traditional internet systems where transactions exist in isolation yet causes downstream changes to other systems in a non-verifiable way, hashpaths allow us to track downstream effects of messages throughout the entire network, stacking attestations of correctness on top of one another as messages move around the system.

Hashpaths tell you who claimed what, when, and why. They are pre-computable, global references to states of computations, available to all without needing to perform any computation.

When data from one execution is used in another, their hashpaths merge together, creating a single Merkle root for both executions. This process happens recursively, such that any single hashpath from a popular computation contains a Merkle tree root of almost all other computations that have occurred in the system. Almost the entire network’s history, represented inside a single 32 byte value. Because this merkle root is constructed iteratively as interactions occur in the system, its benefits come with zero communication overhead. This stands in radical contrast to traditional blockchain networks, in which the process of state consensus requires interactions by a large proportion -- often all -- of the nodes in the system.

HyperBEAM is a host environment for AO-Core executions. It is an Operating System that allows its operators to choose which AO devices they would like to run, and offer them to users for a fee. Devices are small modules which offer blockchain-like services. Any number of devices can be combined and composed together to create new types of applications. You can think of it like a lego kit for building blockchain-like services, recombinable by anyone to create new exciting applications easily, yet still utilizing the same decentralized network of nodes. Devices can be added and updated over time and operators can change which devices they are running, just like applications in an app-store.

HyperBEAM’s design is powerfully modular, giving node operators flexibility over the services they want to offer to their users, while also commoditizing provision of the hardware to run them via market mechanisms.

Today, you can already use HyperBeam nodes to:

• Render dynamic webpages and make AOS processes browsable via the URL bar.

• Offer full HTTP API’s for AO processes without dry-runs. HyperBEAM’s architecture allows developers to call data from other sources without having to do simulated executions of messages on processes, giving developers and users drastically improved performance.

• Run web assembly containers of any size as decentralized, serverless functions. This offers developers a similar experience to services like AWS’s compute offerings (Lambda, etc) while being able to instantly switch between providers. This means that if you find a better offer for your compute, you can instantly take it. No more cloud platform ‘lock in’.

HyperBEAM and AO-Core are hyper modular. As such, their base installation offers around 25 devices for you to start playing around with, but can be extended by anyone to provide additional functionality.

Table 1 below provides an overview of the current state of the devices built on AO-Core in HyperBEAM. The elements in green are “candidate” phase: robust and stable, releases which are not expected to change much over time, if at all. Orange elements are “preview releases”, which developers can already use and try but that are not yet sufficiently robust to be depended on for all production use-cases.  Lastly, red elements are “Early Access releases” that have partial functionality, with components still being developed or missing.

The transition between legacynet and mainnet HyperBEAM nodes is progressing in a “live” way, without downtimes. This is possible since both systems share much of the same data structures, stored on Arweave, thus making them interoperable.

While the AO-Core protocol itself is a candidate release in a robust state, the HyperBEAM implementation still requires heavy testing on a large scale in order to reach the status of candidate release.

February 9th saw the release of Milestone 1, with AO-Core and many of its first devices reaching candidate-level maturity. The first batch of devices to reach this status were focused on enabling payment infrastructure for the network, such that users can opt to pay operators for ‘fast lane’ access to computation. Integrations that use milestone 1’s payments are already available in key developer tooling -- AOS and aoconnect -- with end-user facing integrations ongoing.

Today we are excited to release the early access version of Milestone 2,  which allows you to try out HyperBEAM-resident compute with embedded CUs. This means that you are able to run AO processes in preview-mode fully native inside HyperBEAM (using its native scheduling, messaging, and compute devices) for the first time. Additionally, node operators are able to execute all of these devices inside TEE-enabled secure compute environments, giving veracity to their hashpath attestations.

AO is already live, having handled over 1.5 billion user messages since launch, and with AO-Core in place our ecosystem now has a solid base from which to build. Here are some of the additions to HyperBEAM’s device landscape that we are excited about:

• Launch of the first community-built devices. While Forward Research led the development of AO-Core and HyperBEAM, an important facet of its design is that it offers an open framework in which any developer can add devices to its functionality. Already, we are seeing the development of two GPU-based devices for AO and HyperBEAM: A WASI-NN compliant deterministic GPU implementation for the accelerated execution of LLMs by Apus Network, and a WebGPU implementation by the developers of Reality Protocol.

• Legacynet process compatibility. As part of the phased migration to AO-Core, users will be able to run compute from legacynet processes inside HyperBEAM nodes. This provides a route for existing processes to make use of HyperBEAM’s multitude of differing security devices without having to re-implement or re-issue their process.

• The Green-zone. Once there are a sufficient number of TEE-resident nodes online, the ‘green zone’ device will be activated. The green zone lets many different TEE-nodes act as one in the network, signing and attesting to hashpaths and state. Node operators will use stake their AO tokens (providing Sybil-resistance) in order to join the green zone.

• WASM Ahead-Of-Time Compilation. HyperBEAM already features a native WASM execution environment that is capable of executing computations using a mechanism called ‘AOT’. AOT entails the host environment pre-compiling user-given WASM modules into native code, allowing them to execute at approximately 90% of native speeds. While this implementation already exists, certain modifications will need to be made before it can be safely used in practice.

Anyone can get involved in running HyperBEAM nodes today, as well as building new devices for this system. Community members are already beginning to contribute, with Apus Network and Reality Protocol already adding their GPU integrations to the system. We are thrilled to see such contributions and are excited to see what the community builds in the future.

Resources available for running an AO node include the HyperBEAM repository, the HyperBEAM-specific Discord for developer and user discussions, and AO on X for updates and insights.