Architecture

Othentic Stack allows developers to self-deploy:

  • Customized off-chain service

  • Network of Operators that run and verify arbitrary tasks

Designed to balance scalability, cost-efficiency, and security by leveraging both L1 and L2 layers.

Key Components

The following Smart Contracts are deployed during initialization:

Layer 1

The governance layer is deployed on L1 (Ethereum) to ensure the highest level of security, integrate with the shared security protocol contracts, and manage critical governance operations.

Contract
Description

Manage operators and governance policies.

Cross-chain messaging contract to broadcast messages to L2 via AVS governance.

Manage rewards and handling protocol fee.

Layer 2

The task verification layer is deployed on L2 (or Multichain) to minimize operational costs while maintaining availability, high throughput, and low latency. L2s provide a faster and cost-effective environment for handling task submissions and attestations.

Contract
Description

Manages verification and historical footprint.

Implements Multisig operations and handles BLS signature aggregation.

Complementary to l1MessageHandler , used for communicating with L1 via Attestation center

Manages rewards and handling protocol fee.

Manages and handles Internal Tasks.


The service is distributed over a set of Operators who run various roles:

Role
Responsibility

Execute off-chain tasks and generate a Proof-of-Task.

Validate the work of Performers and cast attestations.

Collect attestations, aggregate signatures, and submit the final result on-chain.

Serve as initial points of contact for peers joining the network.


Consensus Engine

The Othentic Consensus Engine enables scalable off-chain task execution with full traceability, ultimately delivering validated results on-chain. The Engine enables the execution and validation of arbitrary computational tasks over a distributed set of nodes (referred to as Operators).

The consensus scheme:

1

Task Execution

When a task is triggered, a Performer node executes the task, then generates a Proof-of-Task and submits it to the AVS network.

  • The Performer node is selected via a Leader Election mechanism which can be customized by the developer.

  • Developers can configure multiple Task Definitions with custom logic based on their use cases.

2

Task Validation

Attester nodes validate the Proof-of-Task submitted by the Performer, casting BLS-signed attestations.

The weight of their attestation - proportional to the amount of (re)staked assets - is called Voting Power, and determines the influence of an Attester over the consensus process.

3

Aggregation

Finally, an Aggregator node collects all valid attestations cast by operators and monitors for the quorum:

  • Task Approval: >â…” of total network voting power attests "valid"

  • Task Rejection: >â…“ of total network voting power attests "invalid"

Once quorum is reached, the Aggregator aggregates all the attestations and submits an on-chain transaction to the AttestationCenter contract to finalize the task.

4

Verification and Finality

The AttestationCenter smart contract plays a key role in verifying the off-chain execution and maintaining a transparent on-chain record of all activities.

When the submitTask transaction is executed, the AttestationCenter contract verifies the aggregated signature submitted by the Aggregator, and if valid, the task is successfully processed by the contract and finalized onchain.


Business Logic

Developers implement two primary services:

The Execution Service runs on Performer nodes and is responsible for executing Tasks and generating a Proof-of-Task.

This service is responsible for:

  • Task execution

  • Proof generation

  • Submitting the task via the sendTask JSON-RPC call to the AVS network

A Proof-of-Task could be the result of a calculation, a ZK proof, the CID of a JSON on IPFS, etc.

Task Validation implementation should be able to use this proof to attest to task validity.

The Validation Service runs on Attester nodes and is responsible for verifying the validity of a Task execution submitted by a Performer.

The Attester:

  • Receives the task

  • Uses the Validation Service API endpoint at /task/validate to verify the proofOfTask

This is similar to how the Consensus Client communicates with the Execution Client in Ethereum.


The peer-to-peer layer is responsible for establishing and maintaining a secure and efficient communication channel between network nodes, including peer discovery and message propagation.

The layer utilizes signature-based authentication to manage peer connectivity and handshaking, ensuring that only valid peers are able to communicate.

Additional Features

Last updated