FAQ
Definitions
What is an autonomous service?
An autonomous service is a decentralized service that runs off-chain and provides functionalities to objects living on-chain. Autonomous services are outside the purview and control of a single authority, and can be designed for a variety of purposes, including acting as a decentralized oracle for smart contracts, or executing complex investing strategies that cannot be easily encoded on-chain.
What is an AI agent?
An AI agent is an autonomous service which is implemented as a multi-agent system using Autonomous Economic Agents (AEAs) using the Open Autonomy framework, which is built on top of Open AEA.
What is an FSM App?
An FSM App is an application that implements the business logic of an AI agent as a finite-state machine. The internal state of an FSM App is replicated and synchronized across all the agent instances forming the AI agent.
What is a keeper agent?
It is one of the agent instances for which the agent instances have voted to be in charge of executing a certain operation (e.g., settling a transaction on a blockchain).
What is the consensus gadget?
The consensus gadget is the infrastructure, local to an AI agent, that enables the agent instances in that AI agent to run a consensus algorithm to synchronize and replicate the AI agent state. It consists of the consensus gadget nodes (one node per agent instance) plus the consensus gadget network (which can be the Internet or a dedicated network).
What is a period?
In the context of AI agents, a period is the sequence of states in the FSM App that execute the main functionality of the AI agent. Usually, AI agents are designed to cycle through these states, for example, an oracle AI agent will cycle through states like "collect observations" - "compute value" - "publish value on-chain".
How it works
Can I reuse the same FSM App multiple times when creating a composed FSM App?
No. The Open Autonomy framework currently only supports a single instance of a given FSM App in a composition.
Composability, extensibility and reusability are advantages also present in other tech stacks. What makes Autonolas different?
Autonolas is not just a framework where devs can build on: it is a complete, novel ecosystem that provides an SDK, a reward system for developers and operators and a governance protocol on top, all of them decentralized.
In the same way companies like Apple or Google offer SDKs to accelerate devs work plus an app store to monetize their work, Autonolas offers the same capabilities but in a decentralized way: developers register components, operators run AI agents that use those components, consumers use and pay for those AI agents so both developers and operators are compensated for their work. And all the parameters that govern the network can be voted on.
How do agent instances communicate with other agent instances?
Different forms of communication are used depending on the AI agent status. Before the agent instances can establish a temporary blockchain (Tendermint network) that serves as consensus engine they need to exchange the necessary information with others in order to be able to do so. This information includes the network address of their Tendermint node and the associated public key. They do so by connecting to the Agent Communication Network (ACN), where they can send messages to other agent instances, in this case requesting their Tendermint configuration details, using their on-chain registered address. The list of registered addresses is retrieved from the service registry smart contract and can be used to filter out request coming from any party that is not registered to operate in this AI agent as well. Once all configurations have been exchanged the Tendermint network can be established and is used as a consensus engine.
Can AI agents use other AI agents?
Yes, an AI agents can be composed from other AI agents, analogously to microservices. Sub-AI-agents can deliver all sorts of results which are consumed by a higher level AI agent to create a higher level outcome.
How do AI agents communicate with other AI agents?
AI agents use a native message protocol based on protobuf that allows them to have arbitrary message-based communication between compatible agent instances in the network. The network they use for this is the Agent Communication Network (ACN), and protocols define the structure of communication flow, ranging from simple atomic request-response pairs to arbitrarily complicated dialogues (e.g. FIPA). To communicate with traditional services, agent instances can both make API calls and expose REST APIs.
What happens when agent instances are deployed?
Agent instances are able to interact with the Autonolas on-chain Protocol so they can monetize their work and connect to other AI agents. Apart from that, "island deployments" can also be operated, which are AI agents that run as one-off AI agents, not anchored in the protocol.
How many composition levels does Open Autonomy offer?
Composition starts at the component level of the agent blueprints (multiple rounds make a skill), then continues on agent blueprint level (multiple skills make an agent) and ends at AI agent level (multiple agent instances make an AI agent).
How do agent instances settle a transaction?
- Negotiation happens through Tendermint messages.
- A threshold of agent instances agree on a transaction hash.
- One of the agent instances is randomly selected as the keeper using a deterministic function based on a public, verifiable randomness source (currently DRAND).
- All agent instances sign the transaction using a multi-sig like Gnosis Safe.
- The keeper collects all the signatures and sends the transaction on-chain. If it does not do its job, another keeper will be selected.
- All agent instances wait for the transaction to be mined and validate the output.
- Done
Do all AI agents have to be implemented as FSM Apps with Open Autonomy?
Certainly not. For extremely simple applications, you can consider implementing an AI agent by appropriately extending the ABCIHandler class to handle the consensus gadget callbacks, and if required, manually implement the agent blueprint Behaviours that execute client calls to the consensus gadget. However, we strongly advise against this approach, as the complexity, maintainability and composability of the resulting AI agent will be severely affected.
Security
How are AI agents run?
AI agents are composed of multiple agent instances that run the same code and agree on its output. These agent instances are executed by independent operators. Each operator can select and setup the infrastructure that best suits their needs.
What happens if my node is hacked?
As in any other online service, nodes are exposed to the risk of being breached. At the individual level, the framework does not provide a solution to this and it’s up to the agent instance operator to keep the agent instance safe. At the AI agent level, on the other hand, AI agents are secured in two ways:
- Each AI agent implements a custom protocol that expects a very narrow message flow, so a hypothetical agent instance running malicious code would need to express its intentions within this protocol, otherwise the other agent instances will ignore its messages.
- Even in the case of an agent instance sending valid, malicious messages in the AI agent, the decentralized nature of AI agents means that the majority threshold of agent instances (2/3 + 1) must agree before committing a malicious transaction, so it is not enough to breach an individual agent instance.
Costs
How much does it cost to run an AI agent using the framework?
AI agents are not limited in what they do or how they are configured (e.g. number of agent instances in them), therefore the costs are subjective to each AI agent. At the very minimum there will be the costs of running the agent instance on cloud or local infrastructure.
On top of that, if an AI agent sends transactions to a chain, it will incur in fee costs that will depend on the selected chain.
As an example, for a simple AI agent of four agent instances that makes a simple contract call every five minutes, a monthly cost of $3000 in Ethereum and $1.5 in Polygon is presently estimated (at gas cost of 60 wei per gas), but this number will wildly vary depending on gas costs.
Apart from transaction costs, agent instance operators also incur infrastructure costs. A rough, quite conservative estimation can be calculated using the following example: a simple AI agent running on top of an AWS m5.large instance (8GB, 2vCPU) with four agent instances. The following table shows how server costs would vary depending on the number of operators and number of instances per operator.
| Operators | Instances per operator | Total instances | Total agent instances | AI agent daily costs (USD) | Daily costs per operator (USD) |
|---|---|---|---|---|---|
| 1 | 1 | 1 | 4 | 2.304 | 2.304 |
| 2 | 2 | 8 | 4.608 | 4.608 | |
| 3 | 3 | 12 | 6.912 | 6.912 | |
| 4 | 4 | 16 | 9.216 | 9.216 | |
| 2 | 1 | 2 | 8 | 4.608 | 2.304 |
| 2 | 4 | 16 | 9.216 | 4.608 | |
| 3 | 6 | 24 | 13.824 | 6.912 | |
| 4 | 8 | 32 | 18.432 | 9.216 | |
| 3 | 1 | 3 | 12 | 6.912 | 2.304 |
| 2 | 6 | 24 | 13.824 | 4.608 | |
| 3 | 9 | 36 | 20.736 | 6.912 | |
| 4 | 12 | 48 | 27.648 | 9.216 | |
| 4 | 1 | 4 | 16 | 9.216 | 2.304 |
| 2 | 8 | 32 | 18.432 | 4.608 | |
| 3 | 12 | 48 | 27.648 | 6.912 | |
| 4 | 16 | 64 | 36.864 | 9.216 |
Ethereum topics
How does EIP-1559 transaction pricing mechanism work?
EIP-1559 has introduced significant changes in how the transaction pricing is determined. Previously, setting the gasPrice was sufficient; now, two new parameters have to be specified, maxFeePerGas and maxPriorityFeePerGas.
The new pricing structure comprises three key elements:
- Base Fee: This fee is determined autonomously by the network and is subsequently burned. It aims to target 50% full blocks and is adjusted based on the contents of the most recent confirmed block. Depending on block usage, the Base Fee automatically increases or decreases.
- Max Priority Fee Per Gas: This fee is optional and set by the user. It is paid directly to miners. Although technically optional, most network participants estimate that transactions generally require a minimum 2.0 GWEI tip to be competitive for inclusion.
- Max Fee Per Gas: This parameter is the absolute maximum amount you are willing to pay per unit of gas to have your transaction included in a block. If the sum of the Base Fee and Max Priority Fee exceeds the Max Fee, the Max Priority Fee is reduced to maintain the upper bound of the Max Fee. A heuristic formula for Max Fee calculation is: Max Fee = (2 * Base Fee) + Max Priority Fee. Doubling the Base Fee in this calculation ensures that your transaction remains marketable for six consecutive 100% full blocks.
Transactions containing these new parameters are designated as Type 2, while legacy transactions retaining the original Gas Price field are referred to as Type 0. Notably, EIP-1559 does not alter the Gas Limit, which remains the maximum amount of gas a transaction is authorized to consume.
For further information, please refer to the EIP-1559 FAQ
How does a delegate call differ from a call in the context of Safe transactions?
When you initiate a delegate call in a Safe transaction (i.e., with the operation set to delegatecall), it essentially instructs the Safe to "load the code from the specified address and run it." In other words, it retrieves the code from the contract address provided and executes it. This operation allows for dynamic code execution, enabling flexibility in Smart Contract interactions.