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
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:
{
"jsonrpc": "2.0",
"method": "sendTask",
"params": [
<proofOfTask>,
<data>,
<taskDefinitionId>,
<performerAddress>,
<signature>,
<signatureType>,
<targetChainId>
]
}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.
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:
curl -X POST \
http://localhost:4003/task/execute \
-H 'Content-Type: application/json' \
-d '{
"taskDefinitionID": "your_task_definition_id"
}'Read More
Last updated