Validation Service

Overview

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.

Building your Validation Service

This guide explains how to create your own Validation Service, using the Simple Price Oracle AVS Example as a reference.

1

Task validation logic

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.

2

Expose an API endpoint

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/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	bytes	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"
}

3

Containerization with Docker

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.

4

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 Use Cases

Price Oracle AVS

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.

Health Check AVS

In the Health check AVS, When an Attester calls /task/validate endpoint, the service fetches the relevant task details, including the block hash and chosen operator's data. It checks if the task is valid based on the block number, the operator's information, and the associated health check results. If the task is valid, the service approves it; otherwise, it rejects the task.

DNS Registry AVS

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.

Intent-Based AVS

In this example, the Validation Service validates tasks by verifying the performer of a specific block. It receives a proofOfTask and performer from the request body. It extracts the block number from the proofOfTask and retrieves the elected performer for that block. The task is considered valid if the performer matches the elected performer. The result is returned as a JSON response indicating whether the task is valid, along with a success message.

Access Control AVS

The Validation Service verifies tasks based on on-chain data and specified criteria. It uses the proofOfTask to retrieve task information from IPFS, then compares it against the whitelist methods. The validation checks if the task parameters match a valid method, queries on-chain data, and compares it with the expected result. If all conditions are met, the task is validated as correct; otherwise, it is invalid.