yetanotherco/aligned_layer

Aligned Layer is a verification layer for zero-knowledge proofs using Eigen Layer. Our mission is to accelerate the adoption of zero-knowledge and validity proofs on Ethereum..

Aligned

Caution

To be used in testnet only.

Table of Contents

• Aligned
  • Table of Contents
  • The Project
  • How to use the testnet
  • Operator Guide
  • Aligned Infrastructure Guide
  • FAQ

The Project

Aligned is a decentralized network of nodes that verifies Zero-Knowledge and Validity proofs, and post the results in Ethereum.

These proofs can be generated and used for a tenth of the price, and with extremely low latency, allowing novel types of applications that weren't possible before in Ethereum.

How to use the testnet

1. Download and install Aligned to send proofs in the testnet:

curl -L https://raw.githubusercontent.com/yetanotherco/aligned_layer/main/batcher/aligned/install_aligned.sh | bash

2. Then run the source command that should appear in the shell

3. Download an example SP1 proof file with it's ELF file using:

curl -L https://raw.githubusercontent.com/yetanotherco/aligned_layer/main/batcher/aligned/get_proof_test_files.sh | bash

We are downloading a proof previously generated, sending it to Aligned, and retrieving the results from Ethereum Holesky testnet. Aligned is using EigenLayer to do a fast and cheap verification of more than one thousand proofs per second.

4. Let's send the proof to be verified in Aligned:

rm -rf ~/.aligned/aligned_verification_data/ &&
aligned submit \
--proving_system SP1 \
--proof ~/.aligned/test_files/sp1_fibonacci.proof \
--vm_program ~/.aligned/test_files/sp1_fibonacci.elf \
--aligned_verification_data_path ~/.aligned/aligned_verification_data \
--conn wss://batcher.alignedlayer.com

5. You should get a response like this:

[2024-07-01T19:17:54Z WARN  aligned] Missing keystore used for payment. This proof will not be included if sent to Eth Mainnet
[2024-07-01T19:17:54Z INFO  aligned] Submitting proofs to the Aligned batcher...
[2024-07-01T19:19:18Z INFO  aligned] Batch inclusion data written into ./aligned_verification_data/e367d76e_0.json
[2024-07-01T19:19:18Z INFO  aligned] Proofs submitted to aligned. See the batch in the explorer:
[2024-07-01T19:19:18Z INFO  aligned] https://explorer.alignedlayer.com/batches/0xe367d76e832edec893d3a9027b3c231b2e3994c47acfac2e67197c13c9be0c4c

You can use the link to the explorer to check the status of your transaction.

6. After three Ethereum blocks, you can check if it has been verified with:

aligned verify-proof-onchain \
--aligned-verification-data ~/.aligned/aligned_verification_data/*.json \
--rpc https://ethereum-holesky-rpc.publicnode.com \
--chain holesky

This is reading the result of the verification of the proof in Ethereum.

7. You should get this result:

[2024-06-17T21:58:43Z INFO  aligned] Your proof was verified in Aligned and included in the batch!

If the proof wasn't verified you should get this result:

[2024-06-17T21:59:09Z INFO  aligned] Your proof was not included in the batch.

Aligned works in:

• MacOS Arm64 (M1 or higher)
• Linux x86 with GLIBC_2.32 or superior (For example, Ubuntu 22.04 or higher) If you don't meet these requirements, clone the repository, install rust, and then run:

make uninstall_aligned
make install_aligned_compiling

Reading the results of proof verification in Ethereum

Using CURL and an Ethereum RPC

In step 6 of the previous section, we used the aligned verify-proof-onchain to check that our proof was verified in Aligned.

Internally, this is making a call to our Aligned contract, verifying commitments are right, and that the proof is included in the batch.

That command is doing the same as the following curl to an Ethereum node.

curl -H "Content-Type: application/json" \
    --data '{"jsonrpc":"2.0","method":"eth_call","id":1, "params":[{"to": "0x58F280BeBE9B34c9939C3C39e0890C81f163B623", "data": "<CALL_DATA>"}]}' \
    -X POST https://ethereum-holesky-rpc.publicnode.com

This will return 0x1 if the proof and it's associated data is correct and verified in Aligned, and 0x0 if not.

For example, this a correct calldata for a verified proof:

curl -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_call","id":1,"params":[{"to": "0x58F280BeBE9B34c9939C3C39e0890C81f163B623", "data": "0xfa534dc0c181e470901eecf693bfa6f0e89e837dcf35700cdd91c210a0ce0660e86742080000000000000000000000000000000000000000000000000000000000000000836371a502bf5ad67be837b21fa99bc381f7e8124f02042ffb80fa7ce27bc8f6f39fd6e51aad88f6f4ce6ab8827279cfffb922660000000000000000000000007553cb14bff387c06e016cb3e7946e91d9fe44a54ad5d888ce8343ddb16116a700000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000007600000000000000000000000000000000000000000000000000000000000001007b2f4966c3ab3e59d213eda057734df28c323055a2a02f50bd286585cc80128c967250f2b9ad990485338fd2d49e83f47917983f5566da551d4c32e9063ea5641d94b04bac222e06ea18cbb617d0d52c7007cc8f8b30c435b8b8101bdff0ea8482436acf251652f00397f4cefa0bb8eea1c8addb6cf2ca843004b89d80c7e1e41344fd2387535fe4afcaafde27b04543d993bbbc7286154044913e5bd65b86d7cc4d47a90132a95d9ffecb913b414ba2d2f0b1d7b826eb5025a27bcadcc0d94cb125c9c9d556eac08dd6b0f5f55f68afe699f3c529442dbf1b47e968b3705ee2e1be4acb884d184a139a390cb94e9e5806686605dc0a025269bc3afd990c8302"}]}' \
  -X POST https://ethereum-holesky-rpc.publicnode.com

To generate the calldata yourself, follow these steps:

1. Clone the repository and move into it
2. Create a Python virtual environment and install the dependencies with

python3 -m venv .aligned_venv
source .aligned_venv/bin/activate
python3 -m pip install -r examples/verify/requirements.txt

3. Encode your proof verification data with

python3 examples/verify/encode_verification_data.py --aligned-verification-data ~/.aligned/aligned_verification_data/*.json

If your verification data is in another path, just change the --aligned-verification-data parameter.

Using a caller contract

To verify a proof in your own contract, use a static call to the Aligned contract. You can use the following Caller Contract as an example. The code will look like this:

(bool callWasSuccessfull, bytes memory proofIsIncluded) = targetContract.staticcall(
    abi.encodeWithSignature(
        "verifyBatchInclusion(bytes32,bytes32,bytes32,bytes20,bytes32,bytes,uint256)",
        proofCommitment,
        pubInputCommitment,
        provingSystemAuxDataCommitment,
        proofGeneratorAddr,
        batchMerkleRoot,
        merkleProof,
        verificationDataBatchIndex
    )
);
require(callWasSuccessfull, "static_call failed");

Operator Guide

If you want to run an operator, check our Operator Guide

Aligned Infrastructure Guide

If you are developing in Aligned, or want to run your own devnet, check our setup Aligned guide

aligned_layer's Issues

(feat): Check if taskResponse is valid

In aggregator/internal/pkg/server.go, a validity check of taskResponse is needed.

feat: add max retries for WaitForTransactionReceipt

Description

• When doing WaitForTransactionReceipt, instead of making an infinite loop, set a number of max retries.

chore: config deployer to deploy to generic network

Currently, the deployer takes files from hardcoded paths

Changes

• Take deploy files as input in AlignedLayerDeployer
• Upload eigenlayer config for holesky
• Add deploy script without anvil

feat: implement task sender CLI

feat (aggregator): check fee is sufficient before responding to task

• Add check that task fee is sufficient to pay for gas before responding to task
• Need to estimate gas for tx

feat (aggregator): query if task exists if missing

When receiving task response from operator, and the aggregator does not know about task, it should check with rpc if it might be missing task with task index.

On aggregator/internal/pkg/server.go SubmitTaskResponse method

feat (aggregator): verify operator signature

Verify operator signature when getting signed task response

feat (aggregator): verify operator is registered with aligned layer when receiving task response

• Verify operator is registered with aligned layer before validating & aggregating signatures
• Return error if operator is not registered

feat: Add linter to our ethereum contracts, now only servicemanager

feat: Aggregate signature and send to ServiceManager

chore (aggregator): retry listening for tasks

When aggregator subscription to new tasks on ServiceManager gets disconnected, retry connection up to N times.

feat(task_sender): add send tasks in loop to task sender CLI

Description

Add a subcommand loop-tasks to send a task every INTERVAL seconds.

fix (operator): retry connection to aggregator when disconnected

When killing aggregator while operator is running, operator never tries to reconnect to aggregator. Its connection is shut down until operator is restarted again.

To reproduce

In separate terminals

1. make anvil-start
   2.make aggregator-start
2. make operator-full-registration operator-start

Then wait for operator to be started correctly & kill and restart aggregator.
Then run:
make send-plonk-proof

See error in operator session:
Received error from aggregator {"err":"connection is shut down"}

Expected behavior:
Operator should try to reconnect to aggregator when connection is shut down

test: integration test

Create integration test of full flow to avoid manual testing.

An integration test should execute succesfully before allowing merge to main

feat (aggregator): subscribe to task events & post dummy result on chain

Use avs_subscriber in aggregator to listen for new tasks on service manager contract.

For now just print out new tasks

Then post dummy result on smart contract

feat: implement createNewTask in ServiceManager

• Implement createNewTask method in ServiceManager Smart Contract
• Allow Task Sender CLI to interact with the new method

Adding Event Emission for Service Manager Subscription

Adding Event Emission for Service Manager Subscription

Issue Description:

The current implementation lacks a mechanism to subscribe to events from the Service Manager. In real-world scenarios, this subscription is crucial for handling task submissions, especially for proof verification tasks.

Proposed Solution:

1. Event Emission in getMeaning() Test Function:

   • To address this, we recommend adding an event emission within the existing getMeaning() test function.
   • Emit an event when a new task (such as proof verification) is submitted to the Service Manager.
   • This event should carry relevant information about the task (e.g., task ID, type, etc.).

2. Event Handling in the Operator:

   • The Operator, being responsible for fetching new tasks, can listen for this emitted event.
   • Upon receiving the event, the Operator can initiate the necessary actions (e.g., fetching the task details, processing the proof, etc.).

Benefits:

• Real-Time Task Notification: With this event-based approach, the Operator will be instantly notified of new tasks, improving responsiveness.
• Modularity: By emitting events within the Service Manager, we keep the code modular and maintain separation of concerns.

feat: implement payable on createNewTask

Description

When a user creates a new task, they should send a payment to the ServiceManager
For now it will be hardcoded to 0.001 ETH

chore (operator): separate minting & depositing into strategy

There will be no MockERC20 in testnet & mainnet. Therefore deposit into strategy should not try to mint token, it should just check it has sufficient balance and deposit the requested amount into the corresponding strategy.

A different script can be created for minting the MockERC20.

chore: add multiple config for multiple operators

Add 3 config files for 3 different operators
It will use the account 1, 2 and 3 from anvil
Accounts:
(1) 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 (10000.000000000000000000 ETH)
(2) 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC (10000.000000000000000000 ETH)
(3) 0x90F79bf6EB2c4f870365E785982E1f101E93b906 (10000.000000000000000000 ETH)

Private Keys
(1) 0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d
(2) 0x5de4111afa1a4b94908f83103eb1f1706367c2e68ca870fc3fb9a804cdab365a
(3) 0x7c852118294e51e653712a81e05800f419141751be58f605c371e15141b007a6

perf (aggregator): send agg.sendAggregatedResponseToContract to go routine

when calling agg.sendAggregatedResponseToContract we wait for response before subscribing back to channel. This limits the amount of responses we can send, since it is slow to submit response on chain. It should be sent to separate go routine so that aggregations can be handled in parallel.

An issue may arise with tx nonces and we may need to implement our own sequential nonces.

feat (aggregator): Allow different configuration files or environment variabels

aggregator-start make target currently runs:

go run aggregator/cmd/aggregator.go --config aggregator/config/config.yaml \
		--aligned-layer-deployment contracts/script/output/devnet/alignedlayer_deployment_output.json \
		--ecdsa-private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80

We should figure out a better way to pass in configuration files, since make targets don't do well with parameters, a good way to do this might be a .env file + a bash script

aggregator: timeToExpiry parameter when initializing new task

We should research about this parameter and how to set it with some sensible value

Send task waits 2 seconds instead of waiting for ETH answer

Send task should wait for ethereum receipt

EthClient does not have a method to wait for receipt.

EigenSDK has a method called WaitForTransactionReceipt in InstrumentedEthClient
But is needs telemetry to work

https://github.com/Layr-Labs/eigensdk-go/blob/master/chainio/clients/eth/instrumented_client.goreceipt := avsWriter.Client.WaitForTransactionReceipt(context.Background(), tx.Hash())

feat (operator): sign tasks

feat (ci) compile service manager contract

feat: implement dashboard

We need a dashboard / explorer to view current and past tasks made by the Operators.

feat(CI): add integration test

An integration test should execute succesfully before allowing merge to main

fix(task sender): add config flag to loopTasksFlags

feat (service-manager): verify aggregated signature

Add aggregated signature field to TaskResponse struct

Verify aggregated signature on respondToTask

refactor (config): split config.go into different files

config.go File is too long, might be nice to split into different files on same package. e.g:

• base.go
• operator.go
• aggregator.go
• task_sender.go

This is just a suggestion, some files can be added / excluded

feat (aggregator): receive operator signatures

Open aggregator port to receive new signatures from operators

feat: deploy EigenLayer contracts to anvil

Deploy EigenLayer contracts to anvil & save state

feat (task-sender): allow users to configure quorum stake % when submitting new task

• Needs to change Task struct in AlignedLayerServiceManager.sol and add parameter in Task Sender

feat (operator): verify operator is registered with aligned layer on startup

• When operator is starting up it should first verify its registered with aligned layer
• Print error with instructions and exit if its not

AVS Subscriber - Subscribe to event of AlignedLayerServiceManager.sol

We need a way to subscribe to events of the service manager. In a real use case, this should be the submission of a task of verification of a proof. For this PR, is enough to add an event emission in the getMeaning() test function and catch it.

This could be tested in the operator, since it's one of the entities who need to do fetch new tasks.

feat (operator): register with EigenLayer & AlignedLayer

1. Create operator ecdsa & bls key pairs
2. Create operator config file
3. Create scripts to:
   a. Register operator with EigenLayer
   b. Register operator with AlignedLayer

(fix): Make the number of responses needed configurable

The amount of responses needed to submit the TaskResponse should be configurable based on quorumPercentage.

fix: add missing dependencies to make deps

missing:

• jq (cli)
  • mac:
    • brew install jq
• abigen (go)
  • go install github.com/ethereum/go-ethereum/cmd/abigen@latest

chore: add .idea directory to gitignore

AVS Writer / Reader - Load config from file

Currently AVS Reader Writer config is hardcoded. It should be loaded from a file. Addresses for dev mode should be loaded from

contracts/script/output/devnet/alignedlayer_deployment_output.json

Private key and other data can be in a special config file, with some default dev config to be used in devnet

chore (deps): add abigen in make deps

Description

• make deps is missing in abigen dependencies.

feat: add indexed taskIndex to Event TaskResponded

In AlignedLayerServiceManager.sol, the TaskResponded event does not have a uint64 indexed taskIndex parameter, which is necessary to search and get a subset of these Events from a RPC.

bug: deployment scripts

When doing a full deploy, after deploying the mock strategy contracts with

make anvil-deploy-mock-strategy

and executing

make anvil-deploy-aligned-contracts

there is a parsing error in the aligned layer deployer script. This happens because of a parsing error, there is scientific notation in the aligned.devnet.config.json file that generates the error, more precisely in the 1_multiplier key that has to be manually changed from 1E+18 to 1e+18:

 "strategyWeights": [
    [
      {
        "0_strategy": "0x09635F643e140090A9A8Dcd712eD6285858ceBef",
        "1_multiplier": 1E+18
      }
    ]
  ],

We should identify why this is happening and solve it

bug(aggregator): BLS aggregation service returns an empty response

In some cases, specially some seconds after the aggregator is started, if a proof is sent to verify the aggregator service returns an empty response, causing the aggregator to fail.

We should check if this is due to some error on our side or if it is from the eigensdk's side.

It may have something to do with using only one operator or with a race condition between threads, but just making a random guess.

feat: change deploy_mock_strategy script to update erc20mockstrategy value in aligned.devnet.config.json

• When running make anvil-deploy-mock-strategy the value of erc20MockStrategy updates in contracts/script/output/devnet/strategy_deployment_output.json and you have to manually replace it in contracts/script/deploy/config/devnet/aligned.devnet.config.json.
• The idea of this issue is to change the deploy_mock_strategy script to do it automatically.

(feat): Check if operator has missed the task

In SubmitTaskResponse function, from aggregator/internal/pgk/server.go, checking whether the operator missed any task is needed.

refactor: modularize base config and add Task Sender Config

Changes

• Use cli v2 across all the project
• BaseConfig does not need Private Keys
• Add a Config for BLS keys
• Add a Config for ECDSA keys
• Add a Config for Task Sender

refactor: make config more modular

• Remove logger and eth clients creation from config.
• Create logger and eth clients outside config.
• Inject the logger and the eth clients to the config to make the code more modular and testable.

feat (aggregator): allow users to configure quorum stake % when submitting new task

• Need to change aggregator to use configured threshold before submiting response