# Table of Contents - [Abstract | Othentic](#abstract-othentic) - [Othentic Consensus | Othentic](#othentic-consensus-othentic) - [Proof of Task | Othentic](#proof-of-task-othentic) - [Voting Power | Othentic](#voting-power-othentic) - [Rewards and Penalties | Othentic](#rewards-and-penalties-othentic) - [Leader Election | Othentic](#leader-election-othentic) - [Internal Tasks | Othentic](#internal-tasks-othentic) - [Task & Task Definitions | Othentic](#task-task-definitions-othentic) - [Execution Service | Othentic](#execution-service-othentic) - [Validation Service | Othentic](#validation-service-othentic) --- # Abstract | Othentic [PreviousOthentic Consensus](/main/avs-framework/othentic-consensus) [NextTask & Task Definitions](/main/avs-framework/othentic-consensus/task-and-task-definitions) Last updated 20 days ago 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. Othentic Consensus is a scheme to execute, validate, and approve any given task. Powered by a modular consensus engine, the Othentic Consensus allows the execution and validation of any computational use case. In the peer-to-peer consensus process, Operators perform several roles – Performer, Attester, and Aggregator. _**Performers**_ execute the off-chain computations, whereas _**Attesters**_ make claims about the execution and cast their attestation using BLS. These claims are cryptographically signed to ensure the authenticity and immutability of task execution. The weight of their attestation is proportional to the amount of (re)stake assets locked to secure the network, and determine the influence of individual Attester over the consensus process. _**Aggregators**_ collect the attestations, calculate the voting power of individual Attester, aggregate the signatures into one BLS signature, and submit the execution results on-chain. The RPC call that the Task Performer sends to the p2p network: Copy { "jsonrpc": "2.0", "method": "sendTask", "params": [, , , , ] } Task Attesters are AVS Operators that attests to the validity of the executed task. Each task must be attested as either "valid" or "invalid". Copy curl -X POST \ http://localhost:4002/task/validate \ -H 'Content-Type: application/json' \ -d '{ "proofOfTask": "your_proof_of_task_data", "taskDefinitionID": "your_task_definition_id" }' The Aggregator listens to events from the Attester nodes and monitors the necessary voting power contribution to a certain task. The Aggregator aggregates the signatures of the Attesters into a BLS aggregated signature and submits a transaction to the `AttestationCenter` smart contract. After successful validation, the Performer, Attesters, and Aggregator are eligible to claim task rewards. #### [](#task-performer) Task Performer is an AVS Operator that executes a task. Task execution is handled by the , which runs as a **Docker container** and can be implemented in **any programming language**. Execution Service generates a , and publishes the results to peer-to-peer network for Attester nodes to discover. #### [](#attesters) The Operator's is proportional and calculated against the amount of re-stake assets staked on the shared security layer, referred to as “**dynamic voting power.”** The re-staked effective balance determines each Operator's influence in the consensus process. If over ⅔ of the quorum's voting power attest "valid", the task is considered approved. If over ⅓ of the quorum's voting power attest "invalid", the task is rejected, and the quorum executes a slashing event to the Performer. The Attesters run the validation logic using a local HTTP request to the . #### [](#aggregator) [Task Performer](https://docs.othentic.xyz/main/avs-framework/othentic-cli/node-operators#performers) [**Execution Service**](/main/avs-framework/othentic-consensus/execution-service) [Proof of Task](/main/avs-framework/othentic-consensus/proof-of-task) [Task Attesters](https://docs.othentic.xyz/main/avs-framework/othentic-cli/node-operators#attesters) [voting power](/main/avs-framework/othentic-consensus/voting-power) [Validation Service](/main/avs-framework/othentic-consensus/validation-service) [Task Aggregator](https://docs.othentic.xyz/main/avs-framework/othentic-cli/node-operators#aggregators) ![](https://docs.othentic.xyz/~gitbook/image?url=https%3A%2F%2F740349061-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FOU9BNZyLM0Zg4ujkq3Zn%252Fuploads%252F2lkk3nD8o2BKbV4LKv6l%252FAbstract---consensus.png%3Falt%3Dmedia%26token%3Dc6253c3c-afe6-44ad-96e3-aa94daf5c8c0&width=768&dpr=4&quality=100&sign=aef3931e&sv=2) --- # Othentic Consensus | Othentic [PreviousMessage Handlers](/main/avs-framework/smart-contracts/message-handlers) [NextAbstract](/main/avs-framework/othentic-consensus/abstract) Last updated 8 months ago [Abstract](/main/avs-framework/othentic-consensus/abstract) [Task & Task Definitions](/main/avs-framework/othentic-consensus/task-and-task-definitions) [Leader Election](/main/avs-framework/othentic-consensus/leader-election) [Proof of Task](/main/avs-framework/othentic-consensus/proof-of-task) [Execution Service](/main/avs-framework/othentic-consensus/execution-service) [Validation Service](/main/avs-framework/othentic-consensus/validation-service) [Voting Power](/main/avs-framework/othentic-consensus/voting-power) [Rewards and Penalties](/main/avs-framework/othentic-consensus/rewards-and-penalties) [Internal Tasks](/main/avs-framework/othentic-consensus/internal-tasks) --- # Proof of Task | Othentic [PreviousLeader Election](/main/avs-framework/othentic-consensus/leader-election) [NextExecution Service](/main/avs-framework/othentic-consensus/execution-service) Last updated 3 months ago [](#overview) 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) Usage --------------------- The Performer sends an 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) 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) **Data verification proof** #### [](#oracle-data) **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. Copy const ethPrice = oracleService.getPrice("ETHUSD"); const btcPrice = oracleService.getPrice("BTCUSDT"); const task = { ethPrice: ethPrice, btcPrice: btcPrice }; proofOfTask = JSON.stringify(task); #### [](#tls-proofs) **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: 1. **Proving the existence of a transaction or communication**: Verifying that a specific data exchange occurred during a given session. 2. **Ensuring data integrity**: Proving that the data sent over TLS has not been tampered with. 3. **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. Copy // Create a secure TLS connection const socket = tls.connect(options, () => { if (socket.authorized) { console.log('TLS Session Established'); console.log('Session ID:', socket.getSession()?.toString('hex')); } else { console.error('TLS Connection Failed:', socket.authorizationError); } socket.end(); // Close the connection }); * * * ### [](#cryptographic-proofs) Cryptographic proofs Homomorphic proofs ensure that the computations performed on encrypted data are valid without revealing the data itself. #### [](#zero-knowledge-proofs-zkp) **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. Copy async function generateZKProof(secret: any): Promise<{ proof: any, publicSignals: any }> { const {proof, publicSignals} = await snarkjs.groth16.fullProve({ secret }, "circuit.wasm", "circuit.zkey") // Return the proof and public signals (hash) return { proof, publicSignals }; } * * * ### [](#state-verification-proofs) **State Verification Proofs** #### [](#merkle-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) **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) **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. The Task Attesters then cross-verify these details using their monitoring systems. * * * [](#using-distributed-storage) **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. Copy // Task Performer sending task to Attesters const taskDefinitionId = Number(req.body.taskDefinitionId) const result = await oracleService.getPrice("ETHUSDT"); const cid = await dalService.publishJSONToIpfs(result); const data = req.body.data; await dalService.sendTask(cid, data, taskDefinitionId); // Attesters validating Proof of Task const taskResult = await dalService.getIpfsTask(proofOfTask); const data = await oracleService.getPrice("ETHUSDT"); return taskResult == data; 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. ### [](#use-cases) **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. 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 . #### [](#ipfs-content-identifiers-cids) The Performer uploads the data to IPFS (i.e. via ) to ensure secure, verifiable, and immutable storage and generate a CID. #### [](#eigenda) For more details, check the example . [Astral Location Proof Protocol](https://docs.astral.global/docs/location-proof-protocol/introduction) [IPFS Content Identifiers (CIDs)](https://docs.ipfs.tech/concepts/content-addressing/) [piñata](https://pinata.cloud/) [EigenDA](https://docs.eigenda.xyz/overview) [here](https://github.com/Othentic-Labs/price-oracle-example-eigenda/blob/main/Execution_Service/src/dal.service.js#L52C1-L68C1) [RPC call](/main/avs-framework/othentic-consensus/execution-service#building-your-execution-service) --- # Voting Power | Othentic [PreviousValidation Service](/main/avs-framework/othentic-consensus/validation-service) [NextRewards and Penalties](/main/avs-framework/othentic-consensus/rewards-and-penalties) Last updated 1 month ago ### [](#overview) Overview Operators receive staking contract _**shares**_, which signal their proportional ownership within a specific contract. For consensus to be reached, a supermajority threshold quorum of attestations must be met to successfully execute a given task. Importantly, the value of a share varies between staking contracts, as each corresponds to a different asset with unique economic and security characteristics. ### [](#dynamic-voting-power-dvp) **Dynamic Voting Power (DVP)** Dynamic Voting Power (DVP) determines an Operator’s influence in the consensus process, proportional to the amount of (re)staked assets securing the network. It is calculated by summing the total value of all assets (re)staked by an Operator, each weighted by its respective multiplier. The **multiplier** reflects the asset’s value within the staking contract. By multiplying the staked amount and the asset’s price, the USD equivalent of the staked assets in that contract is derived, which is then used to determine voting power. ### [](#validated-voting-power-vvp) **Validated Voting Power (VVP)** ### [](#total-voting-power) **Total Voting Power** ### [](#minimum-and-maximum-voting-power) Minimum and Maximum Voting Power **Minimum Voting Power** The AVS can set a policy of requirements for minimum voting power per task to participate in the AVS (register / work). #### [](#maximum-effective-balance) Maximum Effective Balance When building a PoS (proof of stake) network, you can often run into a problem where a particular operator has a disproportionately large amount of voting power, such that their vote can drastically swing the outcome. Formula for Voting Power with max effective balance: ### [](#minimum-shares-per-strategy) **Minimum Shares Per Strategy** The main feature for dual staking. The AVS developer can set a policy of requirements for minimum amount of shares per strategy that operators must (re)stake to participate in the AVS. A consensus-based mechanism that calculates the fluctuations in asset value and changes in an Operator’s stake. A quorum continuously monitors and updates the voting power of individual Operators, with updates finalized through consensus among Operators within the network. This process is executed using within the CLI. Total voting power is the sum of voting power of all the operators. If the total voting power of the Task Definition is zero, the task will revert with error. If an operator registers with more than the max effective balance that you set, its voting power is set to that value. This way, you can have an operator set where a single operator's voting power does not dominate over the consensus of task validation. Check the method to set it for your AVS. [Internal Tasks](/main/avs-framework/othentic-consensus/internal-tasks) [`InvalidRequiredVotingPower`](https://github.com/Othentic-Labs/core-contracts/blob/main/src/NetworkManagement/Common/OBLS.sol#L68) [setMaxEffectiveBalance](/main/avs-framework/smart-contracts/avs-governance#setmaxeffectivebalance-uint256) ![](https://docs.othentic.xyz/~gitbook/image?url=https%3A%2F%2F740349061-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FOU9BNZyLM0Zg4ujkq3Zn%252Fuploads%252FM0icU3RLa0L6K0e1vYe9%252FScreenshot%25202024-09-12%2520at%252017.53.42.jpg%3Falt%3Dmedia%26token%3D13135a79-7452-48dc-a832-7f5d9ea35740&width=768&dpr=4&quality=100&sign=a5171afa&sv=2) ![](https://docs.othentic.xyz/~gitbook/image?url=https%3A%2F%2F740349061-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FOU9BNZyLM0Zg4ujkq3Zn%252Fuploads%252FE1R7T4nEPFSX5FPxSAGf%252Fimage.png%3Falt%3Dmedia%26token%3D3ac3df33-69dd-4348-a1eb-26b097e0aadd&width=768&dpr=4&quality=100&sign=d47a7e09&sv=2) --- # Rewards and Penalties | Othentic [PreviousVoting Power](/main/avs-framework/othentic-consensus/voting-power) [NextInternal Tasks](/main/avs-framework/othentic-consensus/internal-tasks) Last updated 1 month ago [](#overview) Overview --------------------------- Operators in a shared security environment are incentivized through rewards for making attestation and executing tasks. Rewards scale with the effective balance, which provides an economic incentive for Operators to behave honestly and act in the networks’ best interest. To maximize reward, a single Operator opt-in to validate multiple networks, and puts its staked ETH at additional risk of penalties. Operators are penalized for missed, late or incorrect attestations. Violating a consensus rule of chain A, carries consequences on effective balance, which results in a lower reward and voting power on AVS B and C, alongside A. [](#rewards-calculation) Rewards Calculation ------------------------------------------------- Operator rewards depend both on the amount of base reward per task and the frequency at which an operator is chosen to perform a task. AVS developers must configure the task rewards and utilize a to determine the frequency at which operators are selected for tasks. Othentic Stack allows the configuration of diverse types of tasks with different corresponding rewards. ### [](#stake-weighted-rewards) **Stake-weighted Rewards** Most Proof-of-Stake networks include a "stake-weighted" Leader Election mechanism where the more stake an operator has the more tasks they'll be chosen to perform. The Othentic Stack supports any Leader Election mechanism implemented by the AVS developer. When using a stake-weighted algorithm, for operator nnn, we denote the total reward TnT\_nTn​, with the expected value E(Tn)E(T\_n)E(Tn​) described as: E(Tn)\=SnST⋅C⋅RE(T\_n) = \\frac{S\_n}{S\_{T}} \\cdot C \\cdot RE(Tn​)\=ST​Sn​​⋅C⋅R Where * RRR is the base reward per task * SnS\_nSn​ is the effective balance of operator nnn * ST\=∑n\=1NSnS\_T = \\sum\\limits\_{n=1}^{N}S\_nST​\=n\=1∑N​Sn​ is the total effective stake for the network * CCC is the number of tasks the network produced overall. #### [](#constructing-the-rewards-function) Constructing the Rewards Function To generalize for any Leader Election algorithm, a probability function P(n)P(n)P(n) can be derived from the selected algorithm such that ∑n\=1NP(n)\=1\\sum\\limits\_{n=1}^{N}P(n) = 1n\=1∑N​P(n)\=1 to rewrite the expected value formula as: E(Tn)\=E(P(n))⋅C⋅RE(T\_n) = E \\Bigl( P(n) \\Bigl) \\cdot C \\cdot RE(Tn​)\=E(P(n))⋅C⋅R There are two configurable components for the rewards function: * P(n)P(n)P(n) — The probability of operator nnn to be elected for a task * RRR — The base reward for each task P(n)P(n)P(n) is derived from your Leader Election algorithm. Different algorithms could have different PPP functions. RRR is the base reward and is configurable via the `AttestationCenter` contract. ### [](#configuring-base-rewards) Configuring Base Rewards * * * [](#rewards-distribution) Rewards Distribution --------------------------------------------------- For example, a leader election mechanism — which is not stake-weighted — would have P(n)\=1NP(n)=\\frac{1}{N}P(n)\=N1​ . Task Definitions are used to configure base rewards for the operators. Each task definition includes the base reward for all entities participating in the consensus: the performer, the attesters, and the aggregator. You can configure task definition based on section in the Task Page. For details on how rewards are distributed, refer to the section. [leader election mechanism](https://en.wikipedia.org/wiki/Leader_election) [uniformly random](https://en.wikipedia.org/wiki/Discrete_uniform_distribution) [**Rewards Distribution**](/main/avs-framework/othentic-cli/rewards-distribution) [Creating Task Definition](/main/avs-framework/othentic-consensus/task-and-task-definitions#creating-task-definitions) --- # Leader Election | Othentic [PreviousTask & Task Definitions](/main/avs-framework/othentic-consensus/task-and-task-definitions) [NextProof of Task](/main/avs-framework/othentic-consensus/proof-of-task) Last updated 26 days ago [](#overview) Overview --------------------------- are used to determine which operator (or ) executes a at any given time. These mechanisms ensure the orderly allocation of tasks and optimal system performance while avoiding conflicts. Conflicts can occur when multiple operators try to execute the same task simultaneously, leading to duplicate efforts or inconsistent system states. Developers can write their own algorithm to determine the Task Performer. ### [](#leader-election-mechanisms) **Leader Election Mechanisms** Below are different leader election mechanisms commonly used in decentralized networks: 1. **Round Robin** * **Description**: The "Task Performer" is chosen in a round-robin manner, where operators take turns performing tasks in a fixed sequence based on their IDs. The system cycles through the list of operators, ensuring an even distribution of tasks. * **Implementation**: This can be implemented by taking the block number modulo the number of operators (plus one). The result gives a number in the range \[1..count\], corresponding to the chosen performer's ID. * . 2. **Prevrandao Selection** * **Description**: The "Task Performer" is chosen randomly and deterministically from the pool of nodes. This method ensures that no operator is favored over another, and it can prevent systematic bias in task distribution. * **Implementation**: A random number generator can be used to select a task performer from the pool of operators. * . 3. **Stake Weighted Leader Selection** * **Description:** The **"**Task Performer" is selected based on a weighted probability. It ensures that operators with higher Voting Power (or other assigned weights) have a greater likelihood of being chosen while still maintaining an element of randomness. * **Implementation:** This can be implemented by retrieving the list of all the active operators, Performing a weighted random selection to determine the Task Performer. * . 4. **Priority-based Selection** * **Description**: Operators are assigned different priority levels, and the highest priority operator is chosen to perform the task. This priority can be based on factors such as reputation, available resources, or past performance. * **Implementation**: A priority queue can be used to select the operator with the highest priority for the task. 5. **Leader Election via Consensus** * **Description**: In this approach, operators participate in a consensus mechanism, such as , to elect a leader to perform the task. This is commonly used in distributed systems, where the leader coordinates task execution and ensures system consistency. * **Implementation**: Operators vote on who should be the leader, and the one with the majority of votes is chosen to perform the task. * * * ### [](#using-custom-messaging-for-leader-election-in-external-task-triggers) **Custom Leader Election Logic** When a Task execution is triggered, the Operator node broadcasts a custom message to the P2P network. Upon receiving this message, the peers run a leader election algorithm to select the operator responsible for executing the task. 1. **Publishing the Task Request** Copy async function publishTask(taskData) { const rpcUrl = "http://127.0.0.1:8545"; // Replace with your RPC server URL const hexData = Buffer.from(taskData, "utf8").toString("hex"); const payload = { jsonrpc: "2.0", method: "sendCustomMessage", params: [`0x${hexData}`], id: 1, }; const response = await axios.post(rpcUrl, payload); } 1. **Invoke the Leader Election Algorithm** When a peer receives a **custom message**, the `/p2p/message` endpoint triggers the **leader election algorithm** to determine which peer will execute the task. Copy // Endpoint to process custom P2P messages app.post('/p2p/message', (req, res) => { const { data } = req.body; const electedLeader = leaderElectionAlgorithm(nodes); if (electedLeader === nodeAccount.address) { //execute task } }); Publish the task request as a to the P2P network using the JSON-RPC method. [Custom Message](/main/avs-framework/othentic-cli/p2p-config/custom-p2p-messaging) [Leader election mechanisms](https://en.wikipedia.org/wiki/Leader_election) [Round Robin implementation](https://github.com/Othentic-Labs/PRNG-avs-example/blob/main/Execution_Service/src/leaderElection.service.js#L73) [Prevrandao Selection implementation](https://github.com/Othentic-Labs/PRNG-avs-example/blob/main/Execution_Service/src/leaderElection.service.js#L61) [Stake Weighted implementation](https://github.com/Othentic-Labs/PRNG-avs-example/blob/main/Execution_Service/src/leaderElection.service.js#L92) [RAFT](https://thesecretlivesofdata.com/raft/) [Task](/main/avs-framework/othentic-consensus/task-and-task-definitions#task) [Performer](/main/avs-framework/othentic-cli/node-operators#task-performer) --- # Internal Tasks | Othentic [PreviousRewards and Penalties](/main/avs-framework/othentic-consensus/rewards-and-penalties) [NextFAQ](/main/avs-framework/faq) Last updated 15 days ago [](#overview) Overview --------------------------- Internal Tasks are consensus-based modules for ongoing maintenance of the AVS network. Each module is purpose-built for a specific function and is carried out by the AVS Operators. * Each internal task is uniquely identified and configured with a specific task definition ID. * These tasks are scheduled based on a specified frequency, which can vary depending on the operational requirements. The execution and validation of internal tasks are facilitated by the same operator set and consensus engine used by the AVS, ensuring that they adhere to the same consensus standards as core AVS Tasks. ### [](#usage) Usage Copy Othentic-cli node aggregator --internal-tasks * * * [](#types-of-internal-tasks) Types of Internal Tasks --------------------------------------------------------- ### [](#sync-voting-power) Sync Voting Power The Operator's voting power is proportional to the amount of (re)stake assets locked to secure the AVS, and determine the influence of individual Operators over the consensus process. The module factors the fluctuations in the value of the underlying assets and adjustments to an Operator's stake * `VotingPowerSyncTask` for synchronizing voting power updates is registered as an internal task with the Task definition ID `10001`. * `VotingPowerPerTaskDefinitionSyncTask` for synchronizing voting power per task definition is registered as an internal tasks with Task definition ID `10002` . To verify that the internal tasks are running as expected, check your **Attestation Center submitTask transactions** for these tasks. #### [](#usage-1) Usage Use the `--sync-interval ` flag to configure synchronization intervals. For example, `--sync-interval 5400000` sets the interval to 1 hour and 30 minutes (equivalent to 5,400,000 milliseconds). Copy Othentic-cli node aggregator --internal-tasks --sync-interval 5400000 **Voting Power Calculation and Syncing Logic** The Voting Power Calculator is responsible for calculating the voting power of operators across Layer 1 (L1) and Layer 2 (L2) blockchains. The task logic contains fetching the voting power from both chains, computing the difference, identifying operators whose voting power has either increased or decreased. #### [](#key-features) Key Features: * Periodic scheduling of the voting power synchronization process. * Validation of proposed voting power updates against recalculated values. * Broadcasting results through the P2P framework. #### [](#logging-and-error-handling) Logging & Error Handling The task logs important events, including scheduling, execution, and validation results, to facilitate debugging and monitoring. * Errors encountered during execution are logged using the `Logger` service. * Validation errors are handled by comparing calculated and proposed values. Whenever an internal task is executed, a proof of task is generated. The generated proof, along with task execution data, is broadcasted internally to the P2P network. validate the execution by verifying the proof and recalculating expected outcomes. Internal tasks are executed by nodes when the `--internal-tasks` option is enabled. [**Attesters**](/main/avs-framework/othentic-cli/node-operators#attesters) [Aggregator](/main/avs-framework/othentic-cli/node-operators#aggregators) ![](https://docs.othentic.xyz/~gitbook/image?url=https%3A%2F%2F740349061-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FOU9BNZyLM0Zg4ujkq3Zn%252Fuploads%252F5KaRc7KEIRuG17sRbHxl%252Fimage.png%3Falt%3Dmedia%26token%3D2555e87f-2743-4cdf-91f0-b98a8c8dca39&width=768&dpr=4&quality=100&sign=ea82e9fa&sv=2) --- # Task & Task Definitions | Othentic [PreviousAbstract](/main/avs-framework/othentic-consensus/abstract) [NextLeader Election](/main/avs-framework/othentic-consensus/leader-election) Last updated 6 days ago [](#task) Task ------------------- AVS Protocol core service can be broken down into “Tasks", each representing a unit of work to be carried out by the Operators. A Task is any off-chain computation the AVS network performs, from fetching price feeds to training ML models. Othentic Stack enables AVS developers to **configure multiple tasks** for operators to execute, each with customizable parameters, rewards, and operator clusters. Through Task Definitions, you can specify the required security levels, number of operators, and other operational criteria necessary for task execution. This flexibility ensures that tasks requiring consensus can be precisely tailored to meet your security and operational needs. ### [](#lifecycle-of-a-task) Lifecycle of a Task * _Task_ definition creation ⇒ A one-time transaction defines the task parameters. * _Task_ execution using ⇒ Task is executed off-chain. * _Task_ validation using ⇒ Task is validated by the . * _Task_ submission by ⇒ Finally, the Task is submitted on-chain. * * * [](#task-definition) Task Definition ----------------------------------------- Task definition specifies the task parameters including required security levels, number of operators, and other operational criteria for task execution. These parameters ensure that the Tasks requiring consensus can be clearly defined as per the security and operational needs. Othentic Stack enables you to configure Tasks with the following parameters: Parameter Type Description taskDefinitionId uint16 Auto-generated incremental ID name string A human-readable name for the task blockExpiry uint256 The block after which tasks of this type are no longer valid and will be rejected by the AttestationCenter baseRewardFeeForAttesters uint256 baseRewardFeeForPerformer uint256 baseRewardFeeForAggregator uint256 minimumVotingPower uint256 \_restrictedOperatorIndexes uint256\[\] An array of operators allowed to execute the task Each task defines the base rewards for all entities participating in consensus: the Performer, the Attesters, and the Aggregators. [](#creating-task-definition) Creating Task Definition ----------------------------------------------------------- EthersFoundry Copy const attestationCenter = new ethers.Contract( ATTESTATION_CENTER_ADDRESS, ['function createNewTaskDefinition(string,(uint256,uint256,uint256,uint256,uint256,uint256,uint256[])) external'] ); const tx = await attestationCenter.createNewTaskDefinition( "Example Task", // Human-readable name { ethers.MaxUint256, // Never expires ethers.parseEther('0.01'), // Reward for attestation ethers.parseEther('0.1'), // Reward for performer ethers.parseEther('0.005'), // Reward for aggregation 0, // Disable disputes 0, // Minimum Voting Power [] // Restricted Operator Set } ); await tx.wait(); Copy import { Script, console } from 'forge-std/Script.sol'; interface IAttestationCenter { struct TaskDefinitionParams { uint256 blockExpiry; uint256 baseRewardFeeForAttesters; uint256 baseRewardFeeForPerformer; uint256 baseRewardFeeForAggregator; uint256 disputePeriodBlocks; uint256 minimumVotingPower; uint256[] restrictedOperatorIndexes; } function createNewTaskDefinition( string memory _name, uint256 _blockExpiry, uint256 _baseRewardFeeForAttesters, uint256 _baseRewardFeeForPerformer, uint256 _baseRewardFeeForAggregator, uint256 _disputePeriodBlocks, uint256 _minimumVotingPower, uint256[] _restrictedOperatorIndexes ) external returns (uint16 _id); } contract CreateNewTask is Script { function run () external { IAttestationCenter attestationCenter = IAttestationCenter(ATTESTATION_CENTER_ADDRESS); uint16 taskId = attestationCenter.createNewTaskDefinition({ _name: "Example Task", // Human-readable name _params: TaskDefinitionParams( blockExpiry: type(uint256).max, // Never expires baseRewardFeeForAttesters: 0.01 ether, // Reward for attestation baseRewardFeeForPerformer: 0.1 ether, // Reward for task baseRewardFeeForAggregator: 0.005 ether, // Reward for aggregation disputePeriodBlocks: 0 // Disable disputes minimumVotingPower: 0 // Minimum Voting Power restrictedOperatorIndexes: new uint256[](0) // Restricted Operator Set ) }); console.log('New task ID: %s', taskId); } } ### [](#using-cli) Using CLI To create a task definition, execute the following command: Copy othentic-cli network create-task-definition --l1-chain --l2-chain Follow these steps when prompted: 1. Provide the private key of the multi-sig address. 2. Enter the Attestation Center contract address. 3. Specify all the task parameters as specified above. * * * [](#define-minimum-voting-power-for-a-task) Define Minimum Voting Power For a task --------------------------------------------------------------------------------------- Parameter Type Description \_taskDefinitionId uint16 Task Definition ID \_minimumVotingPower uint256 Minimum Voting Power (in wei) * If an operator attests to a task and has less than the minimum voting power, the task would fail with a `OperatorDoesNotHaveMinimumVotingPower(operatorIndex)` error. * The AVS Governance Multisig should not set this value too high so that no attester passes the threshold. ### [](#using-cli-1) Using CLI To configure the minimum voting power for a specific Task ID, execute the following command: Copy othentic-cli network set-min-voting-power-per-taskid Follow these steps when prompted: 1. Provide the private key of the multi-sig address. 2. Enter the Attestation Center contract address. 3. Specify the Task ID and its corresponding minimum voting power. * * * [](#set-restricted-operator-set-for-a-task) Set Restricted Operator Set for a Task --------------------------------------------------------------------------------------- AVS can have an unlimited number of tasks, and each task can be executed by different Operator clusters. For certain tasks, you may want to restrict execution to a specific group of operators. Parameter Type Description \_taskDefinitionId uint16 Task Definition ID \_restrictedOperatorIndexes uint256\[\] Restricted Operator Set * If a task that has restricted operators is submitted, the system checks that the Operators are part of the `restrictedOperatorIndexes` list. If an unrestricted operator attests to this task, then it will revert with a `InvalidRestrictedOperator(taskDefinitionId, attesterId)` error. ### [](#using-cli-2) Using CLI To configure the restricted operator set for a specific Task ID, execute the following command: Copy othentic-cli network set-restricted-attesters Follow these steps when prompted: 1. Provide the private key of the multi-sig address. 2. Enter the Attestation Center contract address. 3. Specify the Task ID and restricted attester Ids. [](#set-maximum-number-of-attesters-for-a-task) Set Maximum number of Attesters for a Task ----------------------------------------------------------------------------------------------- #### [](#settaskdefinitionmaximumnumberofattesters) setTaskDefinitionMaximumNumberOfAttesters Parameter Type Description \_taskDefinitionId uint16 Task Definition ID \_maximumNumberOfAttesters uint256 Maximum number of Attesters * * * [](#task-execution) Task Execution --------------------------------------- ### [](#triggering-a-task) Triggering a Task #### [](#manual) **Manual** Tasks can be triggered manually via an API call. This can be done using `curl` or any HTTP client to send a request to the execution service. Copy curl -X POST http://localhost:4003/task/execute #### [](#event-based) **Event-based** Tasks can be automatically triggered based on external events or conditions. This includes factors like data changes, user actions, or events from external systems that indicate the task should be executed. The system listens for specific events and executes tasks when conditions are met. * Implementation * Monitor specific contract addresses for predefined event signatures * Parse and decode emitted events from transaction logs * Trigger task execution when qualifying events occur #### [](#time-based) **Time-based** Tasks can be scheduled to trigger at specific times or after certain time intervals. #### [](#queue-based) **Queue-based** Tasks can be queued and executed in order of arrival or priority. A task enters a queue and is executed when its turn comes, or when resources become available. #### [](#custom) **Custom** Triggers may include specific conditions or thresholds that must be met before the task is executed. For example, a task might be triggered when a user reaches a specific condition in an application or when a predefined error threshold is exceeded. * * * The for the Attester rewards function The for the Performer rewards function The for the Aggregator rewards function for any operator New Task Definitions are created on-chain via the smart contract. To create a task definition, call as shown in the example below: You can set a minimum voting power per task definition. By default, the minimum voting power is **zero**, which means that any active operator can participate in any consensus role and task execution. You can restrict this to having only operators with minimum shares. Learn more about voting power . #### [](#settaskdefinitionminvotingpower) You can define a **restricted operator set**—an "**allowlist**" of operators—who are eligible to execute a particular task. This can be specified within the task definition or set as registration criteria in the `.` #### [](#settaskdefinitionrestrictedoperators) You can define a maximum number of Attesters—who are eligible to validate a particular task. This can be specified within the task definition or set as registration criteria in the To execute a specific task, Performer node invokes the using taskDefinitionId. Othentic framework allows you to customize the logic to trigger a task based on the different use cases. [`AttestationCenter`](/main/avs-framework/smart-contracts/attestation-center) [`createNewTaskDefinition`](https://github.com/Othentic-Labs/core-contracts/blob/main/src/NetworkManagement/L2/AttestationCenter.sol#L247) [setTaskDefinitionMinVotingPower](https://github.com/Othentic-Labs/core-contracts/blob/main/src/NetworkManagement/L2/AttestationCenter.sol#L259) [`AVSGovernance`](/main/avs-framework/smart-contracts/avs-governance) [setTaskDefinitionRestrictedOperators](https://github.com/Othentic-Labs/core-contracts/blob/main/src/NetworkManagement/L2/AttestationCenter.sol#L267) [`AVSGovernance`](/main/avs-framework/smart-contracts/avs-governance) [Execution Service](/main/avs-framework/othentic-consensus/execution-service) [Smart Contract Events Based Trigger Implementation](https://github.com/Othentic-Labs/PRNG-avs-example/blob/main/Execution_Service/src/event.trigger.task.controller.js) [Execution Service](/main/avs-framework/othentic-consensus/execution-service) [Validation Service](/main/avs-framework/othentic-consensus/validation-service) [Attesters](/main/avs-framework/othentic-cli/node-operators#task-attesters) [Aggregator](/main/avs-framework/othentic-cli/node-operators#aggregator) RRR RRR RRR [here](/main/avs-framework/othentic-consensus/voting-power#minimum-voting-power-per-task-definition) [Minimum voting power](/main/avs-framework/othentic-consensus/voting-power#overview) [base reward](/main/avs-framework/othentic-consensus/rewards-and-penalties#overview) [base reward](/main/avs-framework/othentic-consensus/rewards-and-penalties#overview) [base reward](/main/avs-framework/othentic-consensus/rewards-and-penalties#overview) --- # Execution Service | Othentic [PreviousProof of Task](/main/avs-framework/othentic-consensus/proof-of-task) [NextValidation Service](/main/avs-framework/othentic-consensus/validation-service) Last updated 18 days ago ### [](#overview) Overview The **Execution Service** is a container with the task execution logic, called by the Performer node. The service acts as a micro-service for executing tasks and can be written in **any programming language**. #### [](#key-responsibilities) Key Responsibilities * **Task Execution**: Execute task logic specific to your use case. * **Proof Generation**: Generate and return a upon successful task execution. * **RPC Communication**: Communicate with other AVS operators via JSON-RPC calls. When a task is triggered, the Performer is responsible for ensuring the task is executed by the execution service and submitted to the peer-to-peer (p2p) network via an RPC call. ### [](#building-your-execution-service) Building your Execution Service 1 #### [](#task-execution-logic) Task execution logic Your service should: * Receive task execution requests. * Execute the task logic (e.g., fetching data from an API or performing calculations). * Generate a `proofOfTask` (e.g., storing results in IPFS and returning the CID). 2 #### [](#triggering-task-execution) Triggering Task Execution 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: Copy curl -X POST \ http://localhost:4003/task/execute \ -H 'Content-Type: application/json' \ -d '{ "taskDefinitionID": "your_task_definition_id" }' 3 #### [](#send-task-results) **Send Task Results** Once the task is executed, submit the `proofOfTask` to the p2p network using the `sendTask` RPC call. A new task is generated off-chain when the Performer node initiates the `sendTask` RPC call. This is the format for the RPC call: Copy { "jsonrpc": "2.0", "method": "sendTask", "params": [\ , \ , \ , \ , \ \ ] } Parameter Type Description 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 taskDefinitionId uint16 performerAddress address The address of the Task Performer signature bytes Task Performer ECDSA signature **Note**: * **data**: Consider storing large decoded data in a more 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. This helps significantly reduce transaction gas fees once its submitted on chain. * **taskDefinitionId**: The unique identifier for the task definition. 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. 4 #### [](#containerization-with-docker) Containerization with Docker * * * ### [](#avs-boilerplates) AVS Boilerplates 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) Example Use Cases --------------------------------------------- In this AVS, Tasks are triggered every hour to dynamically calculate fee based on market volatility. When triggered, the Execution Service retrieves the ETH/USDT volatility, calculates swap fee, stores the results in IPFS and generates a proof of task. This proof is then gossiped to the p2p network using the `sendTask` RPC call. Once the task is successfully submitted on-chain, the updated fee is reflected in the Uniswap Hook contract. In this AVS, Tasks are run every 5 seconds using a cron job that makes an API call to `/task/execute`. Once triggered, the service retrieves the latest block from a custom client, enabling parallel processing. It uses a **ParallelPool** to keep track of pending transactions and groups parallelizable transactions into batches and uses smart prioritization to determine optimal execution order. The full block data is then published to IPFS, while the generated hash is used as proof of task. The storage key for this data is included in the task payload and propagated to the p2p network using the `sendTask` RPC call. In this AVS, the Execution Service retrieves real-time currency price data from Binance and leverages a Social Media Analysis Oracle to assess Twitter sentiment and detect content patterns for resolving prediction markets. All processed data is stored on IPFS, and a proof of task is generated. Additionally, it integrates Uniswap v4 Hooks for binary betting and sentiment-driven market analysis. In this AVS, the Execution Service is responsible for handling and executing computational tasks on remote **GPU nodes** through a REST API. The service invokes GPU-optimized computation via the `compute_tensor` function, which communicates with a remote tensor processing engine. This proof is then gossiped to the p2p network using the `sendTask` RPC call. This example demonstrates how a DNS Registry AVS can manage domain name registration tasks. The Task Performer triggers the Execution Service to process tasks like registering or updating domain records. Upon successful execution, the service generates a `proofOfTask`, which is then submitted to the p2p network via an RPC call. This guide explains how to create your own Execution Service, using the as a reference. Task definitions can be configured using `attestationCenter` contract, as outlined . Tasks can be initiated either manually via an API call or automatically in response to specific events. You can find different methods for triggering events in the section below. **Via Events:** Alternatively, task execution can be triggered automatically through events, such as system signals or , without the need for manual API requests. The ID of specific The Execution 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 in the Simple Price Oracle AVS repository for guidance on how to set up your containerized service. #### [](#uniswap-dynamic-fee) #### [](#parallel-evm-transactions) #### [](#ai-powered-prediction-markets) #### [](#distributed-gpu) #### [](#dns-registry-avs) [Simple Price Oracle AVS Example](https://github.com/Othentic-Labs/simple-price-oracle-avs-example/tree/main/Execution_Service) [blockchain events](https://github.com/Othentic-Labs/PRNG-avs-example/blob/main/Execution_Service/src/task.controller.js#L17) [example](https://github.com/Othentic-Labs/simple-price-oracle-avs-example/blob/main/Execution_Service/Dockerfile) [Simple Price Oracle AVS Example JS](https://github.com/Othentic-Labs/simple-price-oracle-avs-example/blob/main/Execution_Service/src/task.controller.js) [Simple Price Oracle AVS Example Go](https://github.com/Othentic-Labs/avs-examples/blob/main/simple-price-oracle-avs-go-example/Execution_Service/handlers/task_handler.go) [Simple Price Oracle AVS Example Rust](https://github.com/Othentic-Labs/avs-examples/blob/main/simple-price-oracle-avs-rust-example/Execution_Service/src/handlers/task.rs) [Uniswap Dynamic Fee](https://github.com/Othentic-Labs/avs-examples/blob/main/uniswap-v4-hook-avs-example/Execution_Service/src/task.controller.js) [Parallel EVM Transactions](https://github.com/Othentic-Labs/Parallel-EVM/blob/main/AVS/Othentic-AVS/Execution_Service/src/task.controller.js) [AI Powered Prediction Markets](https://github.com/Othentic-Labs/Prediction-markets/blob/main/AVS/Execution_Service/src/task.controller.js) [Distributed GPU](https://github.com/Othentic-Labs/Distributed-GPU/blob/main/anytensor-avs/Execution_Service/src/handlers/task.rs) [DNS Registry AVS](https://github.com/Othentic-Labs/dnsRegistry-avs/blob/main/Task_Performer/src/task.controller.js) [proofOfTask](/main/avs-framework/othentic-consensus/proof-of-task) [`proofOfTask`](/main/avs-framework/othentic-consensus/proof-of-task) [examples](/main/avs-framework/othentic-consensus/execution-service#example-use-cases) [here](/main/avs-framework/othentic-consensus/task-and-task-definitions#creating-task-definitions) [Task definitio](/main/avs-framework/othentic-consensus/task-and-task-definitions#task-definition) [n](/main/avs-framework/othentic-consensus/task-and-task-definitions#task-definition) ![](https://docs.othentic.xyz/~gitbook/image?url=https%3A%2F%2F740349061-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FOU9BNZyLM0Zg4ujkq3Zn%252Fuploads%252FgEZGQOEBh7p9yCcMVACq%252Fimage.png%3Falt%3Dmedia%26token%3D1564f561-1502-45fd-97f5-713a798df97c&width=768&dpr=4&quality=100&sign=dd175938&sv=2) --- # Validation Service | Othentic [PreviousExecution Service](/main/avs-framework/othentic-consensus/execution-service) [NextVoting Power](/main/avs-framework/othentic-consensus/voting-power) Last updated 18 days ago ### [](#overview) 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) Building your Validation Service 1 #### [](#task-validation-logic) 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) 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) `POST` /task/validate **Headers** Name Value Content-Type `application/json` **Body** Parameter Type Description 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. 200 (Approved)200 (Rejected)500 (Internal server error) Copy { "data": true, "error": false, "message": null } Copy { "data": false, "error": false, "message": null } Copy { "data": null, "error": true, "message": "Something went wrong" } 3 #### [](#containerization-with-docker) Containerization with Docker 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) Specifying the IPv4 Address for Task Attester Nodes Copy --avs-webapi "http://" * * * ### [](#avs-boilerplates) AVS Boilerplates 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) Example Use Cases 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`. This guide explains how to create your own Validation Service, using the as a reference. The ID of specific 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 in the Simple Price Oracle AVS repository for guidance on how to set up your containerized service. When configuring the Task Attester nodes in the Docker file, you must specify the server using the `--avs-webapi` . 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: #### [](#uniswap-dynamic-fee) #### [](#parallel-evm-transactions) #### [](#ai-powered-prediction-markets) #### [](#distributed-gpu) #### [](#dns-registry-avs) [Simple Price Oracle AVS Example](https://github.com/Othentic-Labs/simple-price-oracle-avs-example/tree/main/Validation_Service) [example](https://github.com/Othentic-Labs/simple-price-oracle-avs-example/blob/main/Validation_Service/Dockerfile) [IPv4 address of the Validation Service](https://github.com/Othentic-Labs/simple-price-oracle-avs-example/blob/582bed7c97e6216e39d5b8981b3521d5fc34f95b/docker-compose.yml#L113) [argument](https://github.com/Othentic-Labs/simple-price-oracle-avs-example/blob/582bed7c97e6216e39d5b8981b3521d5fc34f95b/docker-compose.yml#L26) [Simple Price Oracle AVS Example JS](https://github.com/Othentic-Labs/simple-price-oracle-avs-example/blob/main/Validation_Service/src/validator.service.js) [Simple Price Oracle AVS Example Go](https://github.com/Othentic-Labs/avs-examples/blob/main/simple-price-oracle-avs-go-example/Validation_Service/services/validation_service.go) [Simple Price Oracle AVS Example Rust](https://github.com/Othentic-Labs/avs-examples/blob/main/simple-price-oracle-avs-rust-example/Validation_Service/src/services/validation_service.rs) [Uniswap Dynamic Fee](https://github.com/Othentic-Labs/avs-examples/blob/main/uniswap-v4-hook-avs-example/Validation_Service/src/task.controller.js) [Parallel EVM Transactions](https://github.com/Othentic-Labs/Parallel-EVM/blob/main/AVS/Othentic-AVS/Validation_Service/src/validator.service.js) [AI Powered Prediction Markets](https://github.com/Othentic-Labs/Prediction-markets/blob/main/AVS/Validation_Service/src/validator.service.js) [Distributed GPU](https://github.com/Othentic-Labs/Distributed-GPU/blob/main/anytensor-avs/Validation_Service/src/handlers/task.rs) [**DNS Registry AVS**](https://github.com/Othentic-Labs/dnsRegistry-avs/blob/main/AVS_WebAPI/src/validator.service.js) [proofOfTask](/main/avs-framework/othentic-consensus/proof-of-task) [Task definition](/main/avs-framework/othentic-consensus/task-and-task-definitions#task-definition) ![](https://docs.othentic.xyz/~gitbook/image?url=https%3A%2F%2F740349061-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FOU9BNZyLM0Zg4ujkq3Zn%252Fuploads%252F1Jpo9m9l8GLIqxXyRvjC%252Fimage.png%3Falt%3Dmedia%26token%3D448cf871-76d8-4a4e-a1c0-f183d78b9a37&width=768&dpr=4&quality=100&sign=a7009182&sv=2) ---