OBLS
Last updated
Last updated
Othentic introduces OBLS, 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.
BLS signatures are a cryptographic tool used to aggregate and verify multiple signatures efficiently, supporting scalable consensus mechanisms.
The OBLS contract address can be obtained from the contracts deployment 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.
The primary role of OBLS is to manage operators, aggregate voting power, and verify signatures based on a threshold of required votes.
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.
registerOperator: This function associates the operators with their BLS public key and voting power, establishing the operator as an active participant in the network.
unRegisterOperator: 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.
The above functions are triggered from the Attestation Center contract based on operator registration performed by AVS governance on L1.
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:
Increase/decrease voting power: Whenever an operator's re-staked balances change on L1, their voting power is updated by by invoking increaseBatchOperatorVotingPower and decreaseBatchOperatorVotingPower methods.
Manage voting power per Task Definition.
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.
When a task is submitted to the Attestation center, the process invokes verifying signatures using the verifySignature method in OBLS. When verifying signatures,
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 manages operator-related data for task submission and signature verification:
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.
