Autonolas Oracles—Technical Details

On March 31st of 2022, we wrote this blog post about an exciting new development in the Autonolas story, our Autonolas Oracle Service. You can see the service running live here. What we didn’t get into in that post were the technical details–how does it actually work under the hood? Today we’re happy to be able to share some of that information with you. Let’s dive in!

The Oracle Service running live.

What Are the Key Components of an Autonolas Agent Service?

To explain the Oracle Service, first let’s look at an Autonolas Agent Service in general terms, and the three main ingredients that make them possible. Namely:

• a collection of agents (i.e., a multi-agent system) which form the core building block that implements the service itself,
• a consensus gadget, which is the mechanism that facilitates the synchronization of the shared, global state between agents, and
• an on-chain protocol, which ensures the crypto-economic security of the services operated with the Autonolas tech stack.

Today we’ll discuss how agents and the consensus gadget work together in the Oracle Service, and leave the details of the on-chain protocol for another time. For now, it is sufficient to know that the on-chain protocol facilitates a mechanism where developers can publicly publish and find reusable components to build and extend new Autonolas Services.

Agents and their Components

Agents are the software components in charge of executing the actual actions of the service, and they can interact with agents within the same service, with external agents, or with any other external service (e.g., a web server or a blockchain node). The basic packet of information that an agent can process is called a message. The particularities of each message depend on what protocol the message is related to (e.g., HTTP), and the Agent has communication capabilities to process protocols that are relevant for each service.

Agent knowledge is encapsulated in what we call skills. Each skill implements a self-contained capability that an agent can dynamically adopt in order to expand its effectiveness in different situations. Each skill can be designed to execute both reactive actions (i.e., responding to a particular received message) and proactive actions (i.e., taking the initiative to execute some action). Skills can be programmed from scratch, or reused from the component registry.

Each agent can include as many skills as they wish, but agents belonging to an Autonolas Service need to implement a special skill that has a mechanism to replicate and synchronize their internal state. This skill is in charge of interacting with the consensus gadget, which in our case is currently based on Tendermint. The interaction between the skill and the consensus gadget is achieved through an interface known as the Application Blockchain Interface, or ABCI for short. You can read more about Tendermint and the ABCI here. In the case of the Oracle Service, we call this special skill the Oracle ABCI App.

The Oracle ABCI App is in charge of executing a number of actions within and on behalf of the service, including contacting the appropriate data source (through its API), aggregating the observed prices, and publishing the results on the blockchain. Additionally, the Oracle ABCI App is tasked with ensuring that all the agents have the same consistent, synchronized view of the global state of the service (e.g., what stage the service is currently executing). The Autonolas Stack provides a framework to easily develop such kinds of ABCI Apps, where the developer needs to focus on the business logic, and the framework is in charge of handling the replication of the global state.

The Role of the Oracle ABCI App in the Service

Every Autonolas Service can be thought of as a “virtual” finite state machine (FSM) shared across the agents in the service. In the case of a complex service like the Oracle Service, the Autonolas Stack allows to split functionalities in different “stages” which are meaningful by themselves, so that they can be later composed. Namely, the Oracle ABCI App for the Oracle Service can be split into the following stages:

• Agent Registration: implements the registration of agents, i.e., the commitment of the agents to participate in the service.
• Safe Deployment: deploys a Gnosis safe contract, which is a multisig smart contract wallet that requires a minimum number of signers from a signers group to approve a transaction before it can occur. Obviously, in this case, the group of signers are the agents that are part of the service. This assures that no single agent from the group can compromise the funds contained in it and means agents do not hold any meaningful funds themselves.
• Oracle Deployment: deployments of an oracle contract, a simple implementation of an oracle contract that was forked from Chainlink.
• Price Aggregation: implements off-chain aggregation of observations by the agents.
• Transaction Submission: Submission of the transaction of the aggregated observations to the blockchain.
• Reset and Pause: wait for a while and restart again.

Each of these stages is actually implemented internally as an FSM, and the overall FSM implemented by the Oracle ABCI app is a composition of these FSMs. The diagram below shows how these stages are composed in order to create the overall FSM:

If we zoom into the “Price Aggregation” FSM, we can see how it is internally implemented:

This FSM represents the Price Aggregation stage of the service, where the agents:

1. Contact and share the value observed at a given data provider (Collect Observation state).
2. Reach a consensus on the aggregated value of their observations (Estimate Consensus state). Note that agents can use any kind of arbitrarily complex estimation strategy, e.g. from a simple median to a full machine learning model, unlike the simpler calculations that are possible when limited to on-chain only.
3. Finally, they reach consensus on the hash of the transaction to be sent on-chain (Transaction Hash state).

A special state (Finished state) is used as the linking point to the next stage of the service: Transaction Submission. You can also see a number of events that trigger the change between these states, which are launched when certain conditions are met (e.g, when there is no majority agreement on the value to be submitted on chain).

Again, this is just one of the stages implemented as an FSM, and as you can see, it has only four states. To give you an idea of the scale, the full Oracle ABCI app, composed of all the FSMs depicted above, contains about 25 states.

By composing FSMs as above, the Autonolas Stack enables the developer to create complex services by facilitating the reusability of FSMs already developed.

The Architecture of the Oracle Service

Putting all together, the architecture of the Oracle Service is summarized as follows:

Each operator is in control of an agent which, in turn, implements the Oracle ABCI App. As described above, this app is in charge of (1) observing the values of a data provider, (2) aggregating the result observed by all the agents and (3) submitting the observed value on-chain. Moreover, the Oracle ABCI App ensures that all the agents have a consistent and synchronized view of the stages that the application is executing.

It is worth noting that each agent of the service is essentially executing the same piece of code, except that each individual agent is parameterized with appropriate values, including their public and private keys, and the particular data provider (e.g., CoinGecko) that they must observe.

Oracle Service Owned by Protocol Governance

A separate innovation of Autonolas is an on-chain protocol that owns off-chain productive services, such as an oracle, and derives profits from them. We call this primitive “Protocol-owned Services”, or PoSe for short. Benefits of PoSe include:

• Ownership through on-chain governance: the protocol can decide to spin an Oracle Service via a governance vote. A percentage of the fees obtained by the oracle accrue to the protocol.
• Operation by independent agent operators: when the protocol acts as service owner, it will open bidding slots for agent operators (think of similar to node operators but with lighter workloads) to run the oracle and receive compensation for their work.
• Unlimited application scope: this can be applied to virtually every application, although it is especially tailored at application stacks that are highly composable, such as Autonolas.

In the face of uncertain regulation, the PoSe primitive provides the level of decentralization necessary for the ecosystem to thrive long-term. For the first time, off-chain services–which today are mostly centrally operated–can be run in a decentralized manner.

Get Involved

We hope that you’ve enjoyed this very brief introduction to the technical details of the Autonolas Oracle Service. More details will be available soon, and we’re looking forward to being able to share those with you. In the meantime, if you’ve found what we’ve described here interesting, we invite you to reach out to us on Discord and follow us on Twitter.

You may also want to consider signing up for the Autonolas Academy. The Academy is a self-paced learning experience, with the option, on completion, to apply for a more intensive, cohort-based Builder Track. The program is designed to teach you everything you need to know to develop your own apps and services using our framework. You can get started with those materials here.