Do not use it in Production, testnet only.
You will need foundry and zap-pretty and docker to run the examples below.
curl -L https://foundry.paradigm.xyz | bash
foundryup
go install github.com/maoueh/zap-pretty@latest
You will also need to install docker, and build the contracts:
make build-contracts
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 blockless-avs contracts already deployed (but no operator registered).
Start the aggregator:
make start-aggregator
Register the operator with eigenlayer and blockless-avs, and then start the process:
make start-operator
By default, the
start-operator
command will also setup the operator (seeregister_operator_on_startup
flag inconfig-files/operator.anvil.yaml
). To disable this, setregister_operator_on_startup
to false, and runmake cli-setup-operator
before runningstart-operator
.
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.
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
-
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 squarenumberToBeSquared^2
.createNewTask
also takesquorumNumbers
andquorumThresholdPercentage
which requests that each listed quorum (we only use quorumNumber 0 in incredible-squaring) needs to reach at least thresholdPercentage of operator signatures. -
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.
-
[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.
-
[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.
-
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:
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.
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!
See the integration tests README for more details.
make clean
make build-contracts
make bindings
make start-anvil-all-deployed
make start-aggregator
make cli-setup-operator
make cli-run-avs
curl -X POST -d '{ "number": "2" }' http://127.0.0.1:8080/v1/api/task
testnet-holesky
branch has issues deploying EL contracts to devnet (local anvil).
The referenced directory and config file does not exist: https://github.com/Layr-Labs/eigenlayer-contracts/blob/testnet-holesky/script/deploy/M2_Deploy_From_Scratch.s.sol#L103
Hence we need to patch the solidity script to point to the correct directory and config file.
cd contracts/lib/eigenlayer-middleware/lib/eigenlayer-contracts
git checkout testnet-holesky
git apply ../../../../../eigenlayer-contracts-holesky.diff
cd -
make blockless-holesky-deploy-avs
Note: This has already been done, and is not required for the steps below.
make clean
make build-contracts
make bindings
make holesky-start-anvil-all-deployed
go run cli/*.go run-avs-aggregator \
--role head \
--function-db ./data/head/function-db \
--peer-db ./data/head/peer-db \
--blockless-avs-deployment contracts/script/output/17000/blockless_avs_deployment_output.json \
--ecdsa-private-key 0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6 \
2>&1 | zap-pretty
make holesky-cli-setup-operator
# run worker node - using exposed peer id from head node
P2P_ID=$(curl -s http://localhost:6000/api/v1/meta | jq -r .peer_id)
go run cli/*.go run-avs-operator --boot-nodes "/ip4/127.0.0.1/tcp/6000/p2p/$P2P_ID" --port 6010
# oracle price request
curl --location 'http://localhost:6000/api/v1/functions/execute' \
--header 'Accept: application/json, text/plain, */*' \
--header 'Content-Type: application/json;charset=UTF-8' \
--data '{
"function_id": "bafybeic222vtsk64qid6gtjfw33wvt27d76pshadk4c6yagcz2kidvjpkm",
"method": "blockless-avs-price-oracle.wasm",
"config": {
"permissions":["https://api.coingecko.com"],
"stdin": "bitcoin",
"number_of_nodes": 0,
"result_aggregation": {
"enable": false,
"type": "none",
"parameters": [
{
"name": "type",
"value": ""
}
]
}
}
}'