Task & Task Definitions

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

• Task definition creation ⇒ A one-time transaction defines the task parameters.

• Task execution using Execution Service ⇒ Task is executed off-chain.

• Task validation using Validation Service ⇒ Task is validated by the Attesters.

• Task submission by Aggregator ⇒ Finally, the Task is submitted on-chain.

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	The base reward $R$ for the Attester rewards function
baseRewardFeeForPerformer	uint256	The base reward $R$ for the Performer rewards function
baseRewardFeeForAggregator	uint256	The base reward $R$ for the Aggregator rewards function
disputePeriodBlocks	uint256	The amount of blocks needed to wait before payment can be finalized
minimumVotingPower	uint256	Minimum voting power for any operator
_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 Definitions

New Task Definitions are created on-chain via the AttestationCenter smart contract. To create a task definition, call createNewTaskDefinition as shown in the example below:

Ethers

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();

Foundry

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);
    }
}

Define Minimum Voting Power For a task

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 here.

setTaskDefinitionMinVotingPower

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.

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.

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 AVSGovernance.

setTaskDefinitionRestrictedOperators

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.

---

Task Execution

Triggering a Task

To execute a specific task, Performer node invokes the Execution Service using taskDefinitionId. Othentic framework allows you to customize the logic to trigger a task based on the different use cases.

1. Manual Tasks can be manually triggered through an API call using curl.

2. Event-based

   Tasks can be 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. For example, a smart contract event can initiate a task execution as shown in the PRNG AVS example.

3. Time-based Tasks can be scheduled to trigger at specific times or after certain time intervals.

4. 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.

5. 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.

---

Task allocation to Operators

Leader election mechanisms are used to determine which operator (or Performer) executes a task 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. 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. Here is an example demonstrating the implementation.

2. Random Selection

   • Description: The leader (Performer node) is chosen randomly from the pool of operators. 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. 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.

4. Leader Election via Consensus

   • Description: In this approach, operators participate in a consensus mechanism, such as RAFT, 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.