Validation Service

Overview

The Validation Service is responsible for task validation logic, locally run and 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.

After the Performer node sends a Proof-of-Task to the P2P network for Task Attesters to validate, the Attesters interact with the Validation Service endpoint to verify and validate the task.

Othentic CLI handles the process of receiving tasks, interacting with the validation service, and sending signed responses back to the P2P network.

Operation Flow

1. Attesters run the Validation Service, and listen to incoming Proof-of-Task messages that are sent by the Performer.

2. The Validation Service operates as a black box:

   • Input: Receives a Proof-of-Task

   • Process: Executes arbitrary validation logic to verify the proof

   • Output: Returns a boolean — true (valid) or false (invalid) — representing the Attester's opinion.

3. Once validation is completed, The Attester signs the result using their Consensus Key and broadcasts to the AVS network for Consensus.

Attesters can only return a signed approval or rejection and cannot change or edit the task details.

Attestations

Attestations are digital records that serve as evidence or confirmation of information made by Operators. At its core, an attestation is a digital signature on structured data. Think of it as a digital stamp of approval or verification.

Attestations are crucial because they offer a means of establishing trust and credibility for distributed systems. Attestations provide validation and a cryptographically signed confirmation of the authenticity of a piece of information, making it easier for others to trust and depend on that information.

---

Implementation and Packaging

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.

Create your own Validation Service, using the Simple Price Oracle AVS Example as a reference.

Specifying the IPv4 Address for Task Attester Nodes

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:

--avs-webapi "http://<Validation_Service_IP>"

---

Example Implementations

• Simple Price Oracle AVS Example JS

• Simple Price Oracle AVS Example Go

• Simple Price Oracle AVS Example Rust

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.

Example Use Cases

Uniswap Dynamic Fee

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.

Parallel EVM Transactions

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.

AI Powered Prediction Markets

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.

Distributed GPU

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.

DNS Registry

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.

---

Components

Validation Service should implement:

Task Validation Endpoint

Validation Services must implement the /task/validate endpoint to enable Attester nodes to validate task execution proof

POST /task/validate

Headers

Name	Value
Content-Type	application/json

Body

Parameter	Type	Description
proofOfTask	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	The ID of specific Task definition
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.

200 (Approved)

{ 
    "data": true,
    "error": false,
    "message": null 
}

200 (Rejected)

{ 
    "data": false,
    "error": false,
    "message": null 
}

500 (Internal server error)

{ 
    "data": null,
    "error": true,
    "message": "Something went wrong"
}