The world of blockchain can be complex, but innovative solutions like EigenLayer and Actively Validated Services (AVS) are emerging to streamline processes and enhance security. This blog serves as a beginner-friendly introduction to these concepts, using the practical example of "Incredible Squaring AVS" by LayrLabs, the creators of EigenLayer.

As we know, Ethereum runs on Proof-of-Stake (PoS). Traditionally, staked Ethereum is locked up and not readily available for other purposes. If you stake your ETH, it's locked until the task is completed. This limitation forces any new application built on Ethereum to establish its own security measures, which can be slow and expensive. Additionally, Ethereum's base layer (Layer 1) can get congested, leading to slow transactions and high fees.

Imagine a system where validators can leverage their existing stake to secure various blockchain services. That's the core idea behind EigenLayer. It acts as a bridge, allowing validators to "restake '' their assets and participate in new functionalities beyond just securing the main blockchain. Users who stake ETH can opt-in to EigenLayer smart contracts to restake their ETH or liquid staking tokens (LST), extending crypto economic security to additional applications on the network and earning additional rewards.

By creating a pool of staked ETH, EigenLayer makes it easier for new applications to leverage the security of the Ethereum network without needing to build it themselves.

An AVS is a system that requires its own validation process to ensure its accuracy. This validation can involve tasks like data verification, running computations, or even connecting different blockchains.

• Stakers: The foundation of the system, stakers contribute their assets to EigenLayer. These assets are then distributed across various AVSs based on security needs and potential returns. Stakers earn rewards based on the performance of the AVSs they've chosen.

• Strategy Manager: This smart contract within EigenLayer allocates restaked assets across AVSs based on predefined strategies.

• Delegation Manager: Stakers use this contract to delegate their stake to specific operators they trust to perform validation tasks for chosen AVSs.

• Operators: These are the entities running the off-chain client software for chosen AVSs. They perform validation tasks to secure the service and earn rewards based on their stake and the performance of the AVS.

1. Stakers deposit their assets into the Strategy Manager, which then distributes them across AVSs.

2. Stakers delegate their stake to operators through the Delegation Manager.

3. Operators run the off-chain client software for chosen AVSs, performing validation tasks.

4. Stakers earn rewards based on the performance of the AVSs they've restaked to.

Let's delve into a simple implementation of AVS, called the Incredible-Squaring AVS, created by LayrLabs. This example includes both on-chain and off-chain components and serves as an illustrative example of how AVSs work.

GitHub Repo Link : incredible-squarring-avs.

Dependencies: To run this implementation, you'll need:

• This demonstration uses WSL in Windows to run it.

  • Distribution: Ubuntu 22.04 | Installation steps.

• Go: Steps to install, here.

• Foundry:

  curl -L https://foundry.paradigm.xyz | bash
  foundryup
  

• Docker can be installed from here.

• zap-pretty, a tool for better logging of output, can be installed with:

  go install github.com/maoueh/zap-pretty@latest
  

The Incredible-Squaring AVS operates as follows:

1. Task Initialization: The Task Generator (in this case, the aggregator plays this role) calls the Task Manager contract at ten-second intervals, dispatching a number for squaring, thereby initiating the task cycle.

2. Event Emission: The Task Manager contract emits an event with relevant information regarding the task.

3. Task Processing: The operator, configures an AVS subscriber, which listens for this event and proceeds to process the designated task.

4. Task Execution: The operator computes the square of the provided number and signs the task response using the BLS signature scheme.

5. Response Dispatch: This signed task response is transmitted to the Aggregator via an RPC call.

6. Aggregation Processing: The aggregator processes the incoming operator responses through the BLS aggregation service integrated within the Eigen SDK.

7. Signature Aggregation: The aggregator receives the aggregated signature from the BLS aggregation service, subsequently broadcasting these aggregated responses back to the Task Manager contract.

8. Quorum Verification and Response Finalization: The Task Manager contract verifies whether the gathered signatures meet the predefined quorum threshold. Following verification, the task response is emitted via an event.

Verifying individual signatures from every operator can be computationally expensive. This implementation utilizes BLS signatures, a cryptographic technique that allows efficient aggregation of multiple signatures into a single, compact one. This significantly reduces the verification workload for the aggregator.

Let's walk through running the Incredible-Squaring AVS on a machine using Make files to streamline the process.

Build Contracts:

make build-contracts

Start EigenLayer, AVS, Chain from Saved State:

make start-anvil-chain-with-el-and-avs-deployed

This builds all contracts required to run the AVS on your local chain. The chain starts from block number 100. The account details can be view from tests/anvil/avs-and-eigenlayer-deployed-anvil-state.json .

Start the aggregator with

make start-aggregator

This command sets up an aggregator from the main function in the  aggregator.go  file. The base configurations for  avsWriter,  avsRegistryService,  blsAggregationService, and authentication keys of network operators are set up. It also deploys a Go routine for launching the RPC server for communication.

Additionally, it initiates a 10-second timer, which dispatches a  sendNewTask()  function. Every 10 seconds, a new task with a number to be squared is passed. If blsAggServiceResp is received from operators, it initiates  sendAggregatedResponseToContract()  function to send the aggregated signatures to Task Manager contract.

Start an operator with

make start-operator

Unlike the aggregator, operators need to register themselves. Upon running this command, the registerOperatorOnStartup method triggers, registering the operator on EigenLayer and the AVS. It also makes the operator deposit into a strategy.

The BLS key password is read from the environment, and blsKeypair is set up. The avsReader, avsWriter, and avsSubscriber are all configured. Using avsSubscriber, the operator subscribes to new tasks, meaning it listens for tasks to perform in an indefinite loop.

Whenever the aggregator creates a new task, the Task Manager emits a NewTaskCreated event. The operator listens for this event using newTaskCreatedChan. It receives the task, squares the number, and signs it using its BLS key pair, which is then passed to the aggregator.

• createNewTask Function: Called by the aggregator (task generator) every 10 seconds with inputs numberToBeSquared, quorumThresholdPercentage, and quorumNumbers. The NewTaskCreated event is emitted, which operators listen for to start working on the task.

• respondToTask Function: Called by the aggregator when the response from the BLS aggregation service channel reaches a quorum threshold of operators who have performed and signed.

• raiseAndResolveChallenge Function: Operators can challenge claims if their stakes are subject to slashing. This requires a fully functional slasher logic on EigenLayer and an on-chain consensus mechanism, which are not yet implemented but can be designed for specific AVSs.

Following the steps above, we run the local chain, start aggregator and operator.

We see the interactions as shown in below logs:

• Terminal #1: Local chain initialized.

• Terminal #2: Starting aggregator.

• Aggregator initialized and sends a new task at 10 second intervals.

• Terminal #3: Starting Operator.

• Operator registered and initialized, listens to a task and executes it. Then it signs it and sends it to aggregator.

• Aggregator receives response from operator, aggregates the signatures using BLS signature scheme, and forwards it to Task Manager. After that, it moves on forward to creating a new task.

• Both operator and aggregator will run a infinite loop, so they will keep on communicating until stopped.

• All the transactions are recorded on local chain.

• Details of local chain can be explored using local blockchain explorers like Ethernal (RPC server runs on ws://localhost:8545). The from address is that of aggregator node, and to address is of IncredibleSquarringTaskManager.sol .

Addresses of nodes are broadcasted upon initialization. Addresses of contracts can be found in JSO files at contracts/script/output/31337/ . 

We've covered the basics of AVS and a simple implementation of the Incredible-Squaring AVS. This example provides a valuable resource for those interested in exploring AVS development. By understanding its architecture and components, you can gain insights into building your own AVSs for various blockchain applications. AVS design is flexible, allowing you to tailor it to your specific needs and functionalities.

This blog has hopefully provided a clear introduction to EigenLayer and AVS. As you delve deeper into the world of blockchain, these concepts will play an increasingly important role in shaping a more secure and efficient future.