🛠️AVS Implementation
Every AVS must implement both execution and validation logic.
It's recommended to use the AVS Samples repo as a boilerplate for your AVS. It includes a couple of examples that make it clearer how the network operates and will get you up and running in no time.
Setup
Make sure you already deployed your AVS contracts prior to running the examples. See Contracts Deployment.
To start, clone the AVS Samples repo:
Then, go into the directory and delete the .git directory:
Configuration
Running the demo network included in the repo requires you to configure the AVS details via a .env file.
You can use the .env.example file as a base:
The addresses from the contracts should come from your AVS deployments. Note that you should use the proxy addresses.
The "Performer", "Aggregator" and "Attesters" are all "Operators". They should all be registered as Operators, see Operator Registration
Get AVS Addresses
To find your AVS contract addresses, run the following command:
The output should contain the necessary env variables:
Structure
The AVS implementation is comprised of two parts:
Task Execution
Task Validation
Take a look at the Price_Oracle_AVS_JS directory to see how these are implemented.
They each run as their own service (Task_Performer for execution, AVS_WebAPI for validation), and you can invoke the Task_Performer via a simple curl call (see below).
Task Performer
The Task Performer must create a "proof" which can be validated by Attester Nodes easily. This proof could be the result of a calculation, a ZK proof, the CID of a JSON on IPFS, etc.
Task Validation implementation should be able to use this proof to attest to the task properly.
In order to publish the task, the Task Performer must send a JSON-RPC request to an arbitrary node on the network, which propagates to its peers. See the sendTask function in the Task_Performer module to learn how to send such requests.
Task Validation
The Validation Service must implement the /validate endpoint.
The task validation API is an endpoint used by the Attester nodes. When an Attesters receives a proof from a Task Performer, they use the Validation Service in order to validate the task.
The Attester nodes themselves don't run the validation logic. They rely on the Validation Service for that. You can compare this to how the Consensus Client communicates with the Execution Client in Ethereum.
Check Validation Service example to learn more about how to implement this sort of API.
Run the Price Oracle AVS
Once you configure the necessary details in the .env file, you should be able to run the Price Oracle AVS against your deployed AVS contracts.
We provide a sample docker-compose configuration that sets up the following services:
Aggregator node
3 Attester nodes
Validation Service endpoint
TaskPerformer endpoint
To set up the environment, create a .env file with the usual Othentic configurations (see the .env.example), then run:
Building the images might take a few minutes
Generating a task
The docker-compose environment includes the Task Performer service which exposes an endpoint that lets you manually run a task.
To invoke it, simply use curl:
In the docker-compose logs you should now see the task propagate inside the network as the attester nodes validate the task and the aggregator submits the task on-chain.
Updating the Othentic node version
To update the othentic-cli inside the docker images to the latest version, you need to rebuild the images using the following command:
Last updated