Othentic
  • Introduction
    • Introducing Othentic Stack
    • Use Cases
  • AVS Framework
    • Abstract
    • Quick Start
    • Othentic CLI
      • Key Management
      • Contracts Deployment
      • Operator Registration
      • AVS Logic Implementation
      • Operator Deposit
      • Node Operators
      • Rewards Distribution
      • P2P Config
        • Custom P2P Messaging
        • P2P Auth Layer
        • Metrics and Monitoring
        • Logging
        • Persistent storage
        • Latency
      • CLI Command Reference
    • Smart Contracts
      • AVS Governance
      • Attestation Center
      • Hooks
        • Task Logic
        • Operator Management
        • Rewards Fee Calculator
      • OBLS
      • Othentic Registry
      • Message Handlers
    • Othentic Consensus
      • Abstract
      • Task & Task Definitions
      • Leader Election
      • Proof of Task
      • Execution Service
      • Validation Service
      • Voting Power
      • Rewards and Penalties
      • Internal Tasks
    • FAQ
    • Supported Networks
    • Explainers
      • Networking
      • Multichain
      • Production Guidelines
      • Operator Allowlisting
      • Governance Multisig
  • External
    • AVS Examples
  • GitHub
  • Othentic Hub
Powered by GitBook
On this page
  • Overview
  • Contract Address
  • Core Functions
  • Register/unregister operators
  • Dynamic voting power management
  • BLS signature verification and aggregation
  • OBLS Storage
  1. AVS Framework
  2. Smart Contracts

OBLS

PreviousRewards Fee CalculatorNextOthentic Registry

Last updated 2 months ago

Overview

Othentic introduces , a consensus component that enables network Operators to submit distinct execution specifications. Beyond efficient signature verification, the OBLS is responsible for managing the BLS keys and ensuring that only authorized Operators are able to perform secure operations. OBLS leverages BLS (Boneh-Lynn-Shacham) signatures.

are a cryptographic tool used to aggregate and verify multiple signatures efficiently, supporting scalable consensus mechanisms.

Contract Address

The OBLS contract address can be obtained from the transaction on L2. When the othentic-cli network deploy command is executed, the OBLSDeployed event is emitted on L2. Also, the deployed contract addresses can be found in the .othentic/state.output.json file.

Core Functions

The primary role of OBLS is to manage operators, aggregate voting power, and verify signatures based on a threshold of required votes.

Register/unregister operators

The OBLS contract is responsible for managing the BLS keys and ensuring that only registered operators can perform secure operations that require BLS signatures. When operators are registered, their BLS public keys are associated with their operator index, allowing for the secure verification of actions on the network.

The above functions are triggered from the Attestation Center contract based on operator registration performed by AVS governance on L1.

Dynamic voting power management

To fit the consensus engine into the shared security environment, the Operator's voting power is proportional to the amount of re-stake assets locked on the L1, which is referred to as Dynamic voting power.

In the OBLS smart contract, an Operator's voting power is determined based on their re-staked balance. This means their influence in the consensus process depends directly on how much they have (re)staked. The contract supports functions to:

  • Manage voting power per Task Definition.

BLS signature verification and aggregation

One of the key advantages of OBLS is its ability to verify aggregated signatures efficiently. While signature aggregation is performed off-chain by the Aggregator, OBLS calculates the aggregated public key for the provided attester IDs and verifies the combined signature on-chain.

This approach reduces computational overhead, minimizes transaction size, and lowers gas costs, ensuring a more cost-effective network.

  • OBLS aggregates public keys from active operators.

  • It ensures operators have sufficient voting power based on a predefined threshold.

  • Each operator's BLS public key is validated for eligibility.

  • The aggregated public key is used to verify the combined BLS signature against the submitted message.

The verification process fails if:

  • Any operator is inactive.

  • An operator’s voting power is insufficient.

  • The aggregated voting power of the task is below the required threshold.

If all checks pass, the task is marked as signed and is submitted successfully.

OBLS Storage

oblsManager: Address managing OBLS operations, which is usually the Attestation Center.

totalVotingPower: Combined voting power of all operators.

operators: Mapping operator details, including BLS public keys, voting power, and activation status.

oblsSharesSyncer: Address syncing voting power shares.

totalVotingPowerPerTaskDefinition: Voting power allocated per task definition.

: This function associates the operators with their BLS public key and voting power, establishing the operator as an active participant in the network.

: This function deactivates the operator by resetting their status and voting power, removing their BLS public key, and ensuring that no further actions can authorized by them within the network.

Increase/decrease voting power: Whenever an operator's re-staked balances change on L1, their voting power is updated by by invoking and methods.

When a task is submitted to the Attestation center, the process invokes verifying signatures using the method in OBLS. When verifying signatures,

manages operator-related data for task submission and signature verification:

registerOperator
unRegisterOperator
increaseBatchOperatorVotingPower
decreaseBatchOperatorVotingPower
verifySignature
OBLS storage
OBLS
BLS signatures
contracts deployment