Proof of Task
Overview
Protocol core service can be broken down into units called “Tasks". Each Task represents a unit of work to be carried out by the Operators.
A Task is any off-chain computation performed by the AVS network, such as fetching price feeds or training machine learning models.
Proof of Task is a string that the Execution service generates and sends to the p2p network. Attesters use this proof to verify if the Performer has executed the task correctly.
If >⅔ of voting power attests the task as "valid," it is approved.
If >⅓ of voting power attests "invalid," the task is rejected, and a penalty will be imposed on the Performer, ensuring a balance between rewarding good behavior and addressing bad behavior.
Usage
The Performer sends an RPC call to broadcast the executed task's information to Task Attesters. The call params consist of proofOfTask
, data and other information, enabling the Attesters to validate the task.
Generating Proof of Task
Proof of Task can be generated based on the nature of the task. Depending on the task type, several methods are available to produce Proof of Task.
Data verification proof
Oracle Data
For tasks that involve retrieving data, such as fetching API results, the proof can be a JSON string representing the data.
Oracle AVS can fetch data from various endpoints and set the result as the Proof of Task. This proof can be sent to the Task Attesters, which will also fetch the data independently and check the validity of the results.
TLS Proofs
TLS is a cryptographic protocol used to secure communications between two parties (client and server) over an insecure network (such as the internet).
TLS Proofs are primarily used for:
Proving the existence of a transaction or communication: Verifying that a specific data exchange occurred during a given session.
Ensuring data integrity: Proving that the data sent over TLS has not been tampered with.
Attesting to secure communication: Confirming that a connection was established with the proper encryption and authentication mechanisms.
Each TLS session has a unique identifier, which can be used to prove that the session existed. TLS Session Data can be used as proof of task.
Cryptographic proofs
Homomorphic proofs ensure that the computations performed on encrypted data are valid without revealing the data itself.
Zero-Knowledge Proofs (ZKP)
Prove knowledge of a value without revealing the value.
Homomorphic properties enable:
Verifying computations (e.g., mathematical operations) over encrypted inputs.
Proving correctness of results derived from these operations.
State Verification Proofs
Merkle Proofs
If your AVS involves a state, you can ensure a valid state update via Merkle trees. After the task, the Task Performer can pass the state and Merkle proof as the Proof of Task, which the Task Attesters can verify.
State verification involves ensuring that the system's state is valid after a task is performed. This is typically achieved using Merkle Trees, which allow efficient and secure state verification.
Example:
After completing a task (e.g., updating a ledger), the Task Performer provides the updated state and a Merkle proof as the Proof of Task. Task Attesters verify the update using the Merkle proof.
Location Proofs
If the AVS is designed to verify the authenticity of location data, Proof of location protocols can be used to generate the necessary proof. This ensures that location information is securely captured and verified, building trust in systems that rely on accurate location data.
For instance, Proof of Location can be leveraged in file storage systems to confirm that data is distributed across geographically diverse locations, ensuring data redundancy, security, and compliance with location-based requirements. Check Astral Location Proof Protocol.
The Task Attesters then cross-verify these details using their monitoring systems.
Using Distributed Storage
If AVS involves operating on large amounts of data, such as JSON, images, videos, and ML models, the Task Performer can upload the data to the distributed storage layer and share the unique identifier.
This identifier can then be used as Proof of Task, which the Task Attesters can use to verify the task.
The Performer uploads the data to IPFS (i.e. via piñata) to ensure secure, verifiable, and immutable storage and generate a CID.
EigenDA functions as the data availability layer for the AVS. The Performer submits the price data as a blob to EigenDA and then shares the corresponding blobId.
For more details, check the example here.
Use Cases
ML Model Training
When training ML models, the Performer:
Uploads the trained model to IPFS.
Provides the CID as the Proof of Task.
Task Attesters verify the model’s validity by evaluating its performance (e.g., accuracy, loss).
Data Analysis
For large analytical reports or logs:
The Performer uploads the reports to IPFS.
The CID is used as the Proof of Task.
Task Attesters ensure the results align with the raw data inputs.
Last updated