chimera-defi / avs4rpc-ethglobal-london-24

AVS4RPC is an EigenAVS to incentivize and track RPC providers. Demo for Ethglobal London 17-mar-2024

AVS 4 RPC

Eigenlayer Actively validated service for RPC providers.

Goal

Incentivize independent smaller RPC providers.
Incentivize LST protocols and small/solo stakers to offer public RPCs to users.
Diversify RPC landscape. Reduce payment for order flow and mev capture at main centralization points like infura/metamask default RPC.
Reduce total network censorship.
Decentralize RPC providers geographically vs current centralization with infura arch running in US.

Want to get a headstart on running your own RPC node? Try my eth2-quickstart scripts to setup a CL+EL+mev-boost+nginx rpc and secure the server: https://github.com/chimera-defi/eth2-quickstart

Steps / Overview

1. Rpc operator purchases token (mockERC20 here, ref RPCOPToken)
2. RPC operator signs up via registry contract (provided by eigenlayer) by running make cli-setup-operator using their RPCOPToken as a stake and their default rpc uri.
3. Task generator in aggregator.go runs offchain, creating tasks to check RPC ping response times/censorship status.
4. Validators that opt into this AVS run operator.go from geographically distinct locations. Consume Task stream generated by aggregator.go. Generate response times from RPC URI in task
5. Aggregator aggregates responses
6. RPC operators are incentivized and awarded tokens (MockERC20/RPCOPToken here, same as used to sign up/register for the service
7. RPC operators with prolonged downtime or heavy censoring or incorrect responses have stakes slashed (TODO/not impl)

Notes

• deploy the contracts - make start-anvil-chain-with-el-and-avs-deployed modded to deploy new contract
• make bindings - run after SC changes to gen go bindings
• changes to aggregator go and tests - to supply tasks with rpc url
• changes to operator.go to add in a responseMS against the rpc url in the task
• OOG? - make send-fund <- no luck ; set DepositIntoStrategy token count to 100
• Final upload -- file hierarchy is a bit messed up, -- TODO: Rm folders that should be in contracts from root. -- TODO: Add lib to contracts (is shipping a 100+ file lib with the repo the only way? feels regressive)

Contact

[email protected]
X: @ChimeraDefi
TG: Ask me
IG/LinkedIn: Lol no

OLD - this is forked from the Eigenlayer repo Incredible Squaring AVS

Incredible Squaring AVS

Do not use it in Production, testnet only.

Basic repo demoing a simple AVS middleware with full eigenlayer integration. See this video walkthrough.

Dependencies

You will need foundry and zap-pretty to run the examples below.

curl -L https://foundry.paradigm.xyz | bash
foundryup
go install github.com/maoueh/zap-pretty@latest

Also make sure to build the contracts:

make build-contracts

Running via make

This simple session illustrates the basic flow of the AVS. The makefile commands are hardcoded for a single operator, but it's however easy to create new operator config files, and start more operators manually (see the actual commands that the makefile calls).

Start anvil in a separate terminal:

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

The above command starts a local anvil chain from a saved state with eigenlayer and incredible-squaring contracts already deployed (but no operator registered).

Start the aggregator:

make start-aggregator

Register the operator with eigenlayer and incredible-squaring, and then start the process:

make start-operator

By default, the start-operator command will also setup the operator (see register_operator_on_startup flag in config-files/operator.anvil.yaml). To disable this, set register_operator_on_startup to false, and run make cli-setup-operator before running start-operator.

Running via docker compose

We wrote a docker-compose.yml file to run and test everything on a single machine. It will start an anvil instance, loading a state where the eigenlayer and incredible-squaring contracts are deployed, start the aggregator, and finally one operator, along with prometheus and grafana servers. The grafana server will be available at http://localhost:3000, with user and password both set to admin. We have created a simple grafana dashboard which can be used as a starting example and expanded to include AVS specific metrics. The eigen metrics should not be added to this dashboard as they will be exposed on the main eigenlayer dashboard provided by the eigenlayer-cli.

Avs Task Description

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

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.

Below is a more detailed uml diagram of the aggregator and operator processes:

Avs node spec compliance

Every AVS node implementation is required to abide by the Eigenlayer AVS Node Specification. We suggest reading through the whole spec, including the keys management section, but the hard requirements are currently only to:

• implement the AVS Node API
• implement the eigen prometheus metrics

If you are using golang, you can use our metrics and nodeapi implementation in the eigensdk, just like this repo does. Otherwise, you will have to implement it on your own.

StakeUpdates Cronjob

AVS Registry contracts have a stale view of operator shares in the delegation manager contract. In order to update their stake table, they need to periodically call the StakeRegistry.updateStakes() function. We are currently writing a cronjob binary to do this for you, will be open sourced soon!

Integration Tests

See the integration tests README for more details.