EigenLayer AVS

Glacier is building on AVS secured by EigenLayer

EigenLayer AVS(Actively Validated Services) are blockchain-based applications that operate outside the Ethereum Virtual Machine (EVM). They include layer-2 chains, data availability layers, sequencers, dApps, cross-chain bridges, and virtual machines, offering diverse utilities to the blockchain ecosystem. AVSs use decentralized consensus mechanisms like PoS or Proof of Work (PoW) for transaction validation. The key difference is that they handle consensus independently, rather than relying on Ethereum’s consensus layer.

Operators can either directly secure AVS applications for additional validation rewards or act as service providers. They validate AVS-related transactions and earn fees, while Ethereum validators delegate their ETH stakes to them. This allows Ethereum validators to earn a share of the AVS validation rewards without being directly involved in the validation process. It’s worth noting that operators on EigenLayer are subject to slashing mechanisms to ensure security and prevent malicious behavior. This mechanism penalizes bad behavior by operators, thereby protecting the network from potential attacks.

Components

The architecture of the AVS contains:

• Eigenlayer core contracts

• AVS contracts

  • ServiceManager which will eventually contain slashing logic but for M2 is just a placeholder.

  • TaskManager which contains task creation and task response logic.

  • The challenge logic could be separated into its own contract, but we have decided to include it in the TaskManager for this simple task.

  • Set of registry contracts to manage operators opted in to this AVS.

• Task Generator

  • in a real world scenario, this could be a separate entity, but for this simple demo, the aggregator also acts as the task generator.

• Aggregator

  • aggregates BLS signatures from operators and posts the aggregated response to the task manager.

  • For this simple demo, the aggregator is not an operator, and thus does not need to register with eigenlayer or the AVS contract. It's IP address is simply hardcoded into the operators' config.

• Operators

  • Square the number sent to the task manager by the task generator, sign it, and send it to the aggregator.

Avs Task Description

1. A task generator (in our case, same as the aggregator) publishes tasks once every regular interval (say 10 blocks, you are free to set your own interval) to the IncredibleSquaringTaskManager contract's createNewTask function. Each task specifies an integer numberToBeSquared for which it wants the currently opted-in operators to determine its square numberToBeSquared^2. createNewTask also takes quorumNumbers and quorumThresholdPercentage which requests that each listed quorum (we only use quorumNumber 0 in incredible-squaring) needs to reach at least thresholdPercentage of operator signatures.

2. A registry contract is deployed that allows any eigenlayer operator with at least 1 delegated mockerc20 token to opt-in to this AVS and also de-register from this AVS.

3. [Operator] The operators who are currently opted-in with the AVS need to read the task number from the Task contract, compute its square, sign on that computed result (over the BN254 curve) and send their taskResponse and signature to the aggregator.

4. [Aggregator] The aggregator collects the signatures from the operators and aggregates them using BLS aggregation. If any response passes the quorumThresholdPercentage set by the task generator when posting the task, the aggregator posts the aggregated response to the Task contract.

5. If a response was sent within the response window, we enter the [Dispute resolution] period.

   • [Off-chain] A challenge window is launched during which anyone can raise a dispute in a DisputeResolution contract (in our case, this is the same as the TaskManager contract)

   • [On-chain] The DisputeResolution contract resolves that a particular operator’s response is not the correct response (that is, not the square of the integer specified in the task) or the opted-in operator didn’t respond during the response window. If the dispute is resolved, the operator will be frozen in the Registration contract and the veto committee will decide whether to veto the freezing request or not.