Execution Service

Overview

The Execution Service is a container with the task execution logic, called by the Performer node. The service acts as a micro-service for executing tasks and can be written in any programming language.

Key Responsibilities

• Task Execution: Execute task logic specific to your use case.

• Proof Generation: Generate and return a proofOfTask upon successful task execution.

• RPC Communication: Communicate with other AVS operators via JSON-RPC calls.

When a task is triggered, the Performer is responsible for ensuring the task is executed by the execution service and submitted to the peer-to-peer (p2p) network via an RPC call.

Building your Execution Service

This guide explains how to create your own Execution Service, using the Simple Price Oracle AVS Example as a reference.

Task definitions can be configured using attestationCenter contract, as outlined here. Tasks can be initiated either manually via an API call or automatically in response to specific events. You can find different methods for triggering events in the examples section below.

1

Task execution logic

Your service should:

• Receive task execution requests.

• Execute the task logic (e.g., fetching data from an API or performing calculations).

• Generate a proofOfTask (e.g., storing results in IPFS and returning the CID).

2

Triggering Task Execution

Task execution can be initiated through different methods, depending on the architecture:

• Via API Endpoint: You can define an endpoint (e.g., /task/execute) that allows operator nodes (Performers) to trigger task execution. For example, a curl request to trigger task execution could look like this:

  curl -X POST <http://localhost:4003/task/execute>

• Via Events: Alternatively, task execution can be triggered automatically through events, such as system signals or blockchain events, without the need for manual API requests.

3

Send Task Results

Once the task is executed, submit the proofOfTask to the p2p network using the sendTask RPC call. A new task is generated off-chain when the Performer node initiates the sendTask RPC call. This is the format for the RPC call:

{
  "jsonrpc": "2.0",
  "method": "sendTask",
  "params": [
    <proofOfTask>, 
    <data>, 
    <taskDefinitionId>, 
    <performerAddress>, 
    <signature>
  ]
}

Parameter	Type	Description
proofOfTask	string	Any string that the Attesters can use to verify that the Performer has executed its task as expected
data	bytes	Additional data to be added to the consensus
taskDefinitionId	uint16	The ID of specific Task definition
performerAddress	address	The address of the Task Performer
signature	bytes	Task Performer ECDSA signature

Note:

• data: Consider storing large decoded data in a more efficient storage solution such as IPFS (InterPlanetary File System). Instead of including the entire data payload in the transaction, you can include a reference link (e.g., an IPFS URI) that points to the stored data. This helps significantly reduce transaction gas fees once its submitted on chain.

• taskDefinitionId: The unique identifier for the task definition. This is typically provided as part of the request, allowing the performer to know which task logic to execute. In the example, it is retrieved from the request body as req.body.taskDefinitionId.

• signature: A cryptographic signature that authenticates the task submission. This proves that the performer node is the one submitting the task.

4

Containerization with Docker

The Execution Service should be containerized using Docker for ease of deployment and scalability. This ensures the service is isolated and easily managed, replicated, and scaled across different environments. Refer to the example in the Simple Price Oracle AVS repository for guidance on how to set up your containerized service.

Example Use Cases

Price Oracle AVS

In the Price Oracle AVS, tasks can be triggered after a set number of blocks (or for each block). When the task is triggered by its scheduler, the performer node makes a call to the Execution Service, which fetches the price of the requested assets. It will then return a proof of task, which the performer node can gossip in the p2p network until it is attested and submitted as a valid task on-chain.

Health Check AVS

In the Health check AVS, tasks are triggered every set number of blocks (epoch). When triggered, the performer node calls the Execution Service to validate block data. The service runs the health check, encodes the results, and generates a proof of task. Finally, the proof is submitted via the sendTask RPC call.

DNS Registry AVS

This example demonstrates how a DNS Registry AVS can manage domain name registration tasks. The Task Performer triggers the Execution Service to process tasks like registering or updating domain records. Upon successful execution, the service generates a proofOfTask, which is then submitted to the p2p network via an RPC call.

Intent-Based Task Execution

This example demonstrates how to trigger task execution when an IntentSent event is received. The Task Performer listens for this event, checks if the current block number meets the criteria, and if so, executes the task by signing and submitting the task data to the network.

Access Control AVS

In an Access Control AVS, tasks can be triggered based on specific conditions, such as block numbers or scheduled intervals. When a task is triggered, the performer node interacts with the Execution Service to retrieve the necessary access control data. The service processes the data, generates a proof of task, and then shares this proof with the network for validation.