Validation Service
Last updated
Last updated
The Validation Service is a container with the task validation logic that can be called by the Attester nodes. It acts as a micro-service for validating tasks and can be written in any programming language.
Key Responsibilities
Task Validation: Execute verification logic specific to the task.
Response Generation: Based on the task verification, the service returns either an approval or rejection response.
When the Performer node sends a task to the P2P network to Task Attesters for validation, the Attesters interact with the Validation Service endpoint to verify and validate the task.
When the Task Attesters are spin up, Othentic CLI internally handles the process of receiving tasks, interacting with the validation service, and sending signed responses back to the P2P network.
This guide explains how to create your own Validation Service, using the Simple Price Oracle AVS Example as a reference.
Your service should:
Receive requests containing task details for validation.
Execute the task validation logic.
Return a response, either approving or rejecting the task.
The Validation Service uses the task details to verify whether the task was executed as expected. If an issue arises during the validation process, the service returns a custom error message and appropriate HTTP status codes (e.g., 500 for server errors).
Attesters can only return a signed approval or rejection and are not authorized to change or edit the task details.
Define an endpoint (/task/validate) that allows operator nodes (Attesters) to trigger task validation. This endpoint should accept parameters such as proofOfTask and other task-specific data to validate the task.
POST /task/validateHeaders
Content-Type
application/json
Body
string
Any string that the Attesters can use to verify that the Performer has executed its task as expected
data
string
Represent an additional data to be added to the consensus
taskDefinitionID
uint16
performer
address
The address of the Task Performer
Response The validation service should return responses in the following structure, based on the validation outcome:
data: Indicates the validation result (true for approval, false otherwise).
error: Boolean value indicating whether an error occurred.
message: Contains additional context; typically null for successful responses or a descriptive error message for failures.
The Validation 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.
Each Task Attester must spin up its own Validation Service and perform local endpoint calls to ensure an immutable and distributed task validation process.
When configuring the Task Attester nodes in the Docker file, you must specify the IPv4 address of the Validation Service server using the --avs-webapi argument. This ensures that the Task Attesters can properly connect to the Validation Service for task validation. For example, in the Docker configuration, the --avs-webapi argument should be set as follows:
In the Price Oracle example, the Validation Service exposes the /task/validate endpoint in an express server that the Attesters can call.
The Attester node calls the endpoint to initiate the validation logic. In the Price Oracle example, the Validation Service fetches the data source price and matches the result with the corresponding results of the Task Performer. If the results are within a defined threshold or margin of error, the service approves the task and returns it back to the Attester, which signs the response and propagates its attestation back to the network for aggregation discovery.
In this AVS, The Validation Service cross-checks task execution results with an oracle-derived fee estimate to ensure accuracy. It retrieves the proof of task data from IPFS and fetches the expected fee from the oracle. The service then establishes an acceptable range, allowing a 5% deviation from the expected fee. If the fee falls within this range, the validation succeeds.
In this AVS, the Validation Service ensures the integrity of parallel execution by verifying that proposed transaction batches are valid and collision-free. It retrieves task results from IPFS and computes a SHA-256 hash of the block data. This computed hash is then compared with the provided block hash to validate the task execution. If the hashes match, the validation succeeds, proving that the batch was correctly processed.
In this AVS, the Validation Service independently verifies proof of task using the Llama-3-8B-262k model while utilizing distinct AI models from the Execution Service to prevent collusion. It enforces strict validation rules to ensure prediction accuracy. If the results fall within a predefined threshold or margin of error, the service approves the task and returns it to the Attester.
The Validation Service verifies the proof of task by independently validating task results against oracle-computed values. It processes tensor data from serialized byte formats and reconstructs multi-dimensional arrays for comparison. To prevent collusion, it utilizes different AI models than the Execution Service. Using the Manhattan distance metric, the service measures the discrepancy between the submitted proof of task and the oracle’s computed result. If the difference falls within a predefined threshold, the task is approved and sent back to the Attester.
The Validation Service verifies a task by comparing a provided proofOfTask with a hashed value derived from a DNS public key. The service fetches the public key for the domain using the dnsService.getDnsPubKey function and hashes it using the Keccak256 algorithm. If the hash matches the provided proof, the task is considered approved. If any issues arise during this process, the service returns null.
The ID of specific
