Execution Service
Overview
The Execution Service is responsible for task execution logic, locally run and called by the Performer node. The Execution Service can be written in any programming language.
Key Responsibilities
Task Execution: Execute task logic specific to your use case.
Proof Generation: Generate and return Proof-of-Task upon successful task execution.
When a task is triggered, the Performer is responsible for ensuring the task is executed by the execution service, and submit the result to the peer-to-peer (p2p) network via an RPC call.
Operation Flow
A task is triggered using a pre-defined task trigger
The Performer calls the locally-run Execution Service with a request to perform the task.
The Execution service executes the task and produces a Proof-of-Task as output.
The Performer signs the Proof-of-Task and submits it to the AVS P2P network.
Implementation and Packaging
Since it acts as a local service run by the operator, the Execution Service can be written in any programming language and packaged in any way.
We recommend containerizing the Execution Service and publishing it to a public registry.
Docker Containerization
The Execution Service can 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.
Other Methods
Execution Service can be a simple call to an internet-based service maintained by the developers.
Execution Service can be run as a systemd service.
Any method that produces a Proof-of-Task and sends it via
sendTaskRPC call is supported.
Example Implementations
The following are example implementations of a simple Execution Service that fetches and submits price data from centralized exchanges, implemented in three different programming languages:
In the Simple Price Oracle AVS, tasks are triggered via an API call to /task/execute. Upon triggering, the Execution Service retrieves the price of the requested assets and generates a proof of task. This proof is then gossiped to the p2p network using the sendTask RPC call until it is attested and successfully submitted as a valid on-chain task.
Example Use Cases
Uniswap Dynamic Fee
In this AVS, Tasks are triggered every hour to dynamically calculate fee based on market volatility. When triggered, the Execution Service retrieves the ETH/USDT volatility, calculates swap fee, stores the results in IPFS and generates a proof of task. This proof is then gossiped to the p2p network using the sendTask RPC call. Once the task is successfully submitted on-chain, the updated fee is reflected in the Uniswap Hook contract.
Parallel EVM Transactions
In this AVS, Tasks are run every 5 seconds using a cron job that makes an API call to /task/execute. Once triggered, the service retrieves the latest block from a custom client, enabling parallel processing. It uses a ParallelPool to keep track of pending transactions and groups parallelizable transactions into batches and uses smart prioritization to determine optimal execution order. The full block data is then published to IPFS, while the generated hash is used as proof of task. The storage key for this data is included in the task payload and propagated to the p2p network using the sendTask RPC call.
AI Powered Prediction Markets
In this AVS, the Execution Service retrieves real-time currency price data from Binance and leverages a Social Media Analysis Oracle to assess Twitter sentiment and detect content patterns for resolving prediction markets. All processed data is stored on IPFS, and a proof of task is generated. Additionally, it integrates Uniswap v4 Hooks for binary betting and sentiment-driven market analysis.
Distributed GPU
In this AVS, the Execution Service is responsible for handling and executing computational tasks on remote GPU nodes through a REST API. The service invokes GPU-optimized computation via the compute_tensor function, which communicates with a remote tensor processing engine. This proof is then gossiped to the p2p network using the sendTask RPC call.
DNS Registry
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.
Components
Execution Service should implement:
Task Execution
The Execution Service should execute the task based on the task logic as defined by the Task Definition.
Proof Generation
Execution Service must produce a Proof-of-Task - verifiable evidence of correct Task execution.
This can be any piece of data that Attesters could independently verify, to validate the task was executed as intended.
Task Submission
Executed Tasks must be submitted to the AVS network via the sendTask RPC call. The format for the call is as follows:
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
performerAddress
address
Public address of the Task Performer
signature
bytes
Task Performer signature
signatureType (optional)
string
An optional parameter to specify the type of the signature: 'ecdsa' (default) or 'bls'.
targetChainId(optional)
uint
Chain ID for the network to submit the task on.
To use this parameter, signatureType must be explicitly specified.
Important Notes:
data
In order to significantly reduce transaction gas fees, consider storing large decoded data in an 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.
taskDefinitionId
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.
Task definitions can be configured as outlined in Create Task guide. Tasks can be initiated either manually via an API call or automatically in response to specific events.
signature
A cryptographic signature that authenticates the task submission. This proves that the performer node is the one submitting the task.
signatureType optional
Specifies the type of cryptographic signature used to authenticate the Performer to the P2P network. The supported values are:
'ecdsa'(default)'bls'
If using BLS signatures, you must explicitly set signatureType to 'bls'. This enables the P2P network to correctly verify the signature using BLS.
targetChainId optional
L2 chain ID for transaction submission in Multi chain AVS. The submitTask transaction will then be sent to the Attestation Center contract deployed on the specified chain.
Defaults to the first chain in the
L2_CHAINenvironment variable if not provided (e.g.,L2_CHAIN=base-sepolia,amoythe transaction will be submitted to the Base Sepolia network).Its required to populate
signatureTypewhen usingtargetChainIdparameter.
Task Execution Triggers
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:
Read More
Last updated