Aligned Layer

Caution

To be used in testnet only.

Basic repo demoing a Stark/Snark verifier AVS middleware with full EigenLayer integration.

The Project

Aligned Layer works with EigenLayer to leverage ethereum consensus mechanism for ZK proof verification. Working outside the EVM, this allows for cheap verification of any proving system. This enables the usage of cutting edge algorithms, that may use new techniques to prove even faster. Even more, proving systems that reduces the proving overhead and adds verifier overhead, now become economically feasable to verify thanks to Aligned Layer.

Full documentation and examples will be added soon

Dependencies

You will need go, foundry, zap-pretty and eigenlayer-cli to run the examples below.

To install

make deps

To install foundry

make install-foundry

Then follow the command line instructions Make sure to run foundryup

To install eigenlayer-cli

make install-eigenlayer-cli

How to use Devnet

Start anvil

Start anvil with every relevant contract deployed with:

make anvil-start

The above command starts a local anvil chain from a saved state with EigenLayer and AlignedLayer contracts already deployed (but no operator registered).

Start aggregator

Make sure to set config file variables to correct value at config-files/config.yaml.

To start the aggregator, run:

make aggregator-start

To run dummy operator to test aggregator SubmitTaskResponse endpoint, run:

make aggregator-send-dummy-responses

Make sure to have aggregator running on another terminal.

Start operator

To do the full process (register with EigenLayer, deposit into strategy and register with AligendLayer), run:

make operator-full-registration

Starting the operator is a WIP

Send task

To send a task to the ServiceManager using the TaskSender CLI, run:

make send-plonk-proof

This will send a dummy task to the ServiceManager. Make sure to have the ServiceManager deployed and anvil running on another terminal or background.

The plonk proof is located at task_sender/test_examples.

Developing workflows in testnet

Upgrade contracts

When changing EigenLayer contracts, the anvil state needs to be updated with:

make anvil-deploy-eigen-contracts

You will also need to redeploy the MockStrategy & MockERC20 contracts:

make anvil-deploy-mock-strategy

Then make sure to change the 0_strategy in the script/deploy/devnet/aligned.devnet.config.json file to the new address.

When changing AlignedLayer contracts, the anvil state needs to be updated with:

make anvil-deploy-aligned-contracts

Also make sure to re-generate the Go smart contract bindings:

make bindings

Operator registration step by step (WIP Guide)

When not using the default address, get eth with:

make operator-get-eth

Update the config in:

operator/config/devnet/config.yaml operator/config/devnet/operator.yaml

To register with EigenLayer, run:

make operator-register-with-eigen-layer

To deposit into strategy, and register with AlignedLayer, run:

make operator-deposit-and-register

To just deposit into the strategy, run:

make operator-deposit-into-strategy

To just register an operator with AlignedLayer, run:

make operator-register-with-aligned-layer

Testnet/Mainnet Deployment

To deploy the contracts to Testnet/Mainnet, you will need to set environment variables in a .env file in the same directory as the deployment script (contracts/scripts/). The variables are as follows:

Variable	Description
RPC_URL	The RPC URL of the network you want to deploy to.
PRIVATE_KEY	The private key of the account you want to deploy the contracts with.
EXISTING_DEPLOYMENT_INFO_PATH	The path to the file containing the deployment info about EigenLayer.
DEPLOY_CONFIG_PATH	The path to the deployment config file.
OUTPUT_PATH	The path to the file where the deployment info will be saved.

Then run the following command:

make deploy-aligned-contracts

To get the existing deployment info about EigenLayer, you can download it from EigenLayer repo.

You need to complete the DEPLOY_CONFIG_PATH file with the following information:

{
    "chainInfo": {
      "chainId": "<chain_id>"
    },
    "permissions" : {
      "owner": "<owner_address>",
      "aggregator": "<aggregator_address>",
      "upgrader": "<upgrader_address>",
      "churner": "<churner_address>",
      "ejector": "<ejector_address>",
      "deployer": "<deployer_address>",
      "initalPausedStatus": 0
    },
    "minimumStakes": [],  
    "strategyWeights": [],
    "operatorSetParams": [],
    "uri": ""
  }

You can find an example config file in contracts/script/deploy/config/holesky/aligned.holesky.config.json.

Notes on project creation / devnet deployment

Eigenlayer middleware was installed as a submodule with:

mkdir contracts
cd contacts
forge init . --no-commit
forge install Layr-Labs/eigenlayer-middleware@mainnet

Then to solve the issue Layr-Labs/eigenlayer-middleware#229, we changed it to:

forge install yetanotherco/eigenlayer-middleware@yac-mainnet --no-commit

As soon as it gets fixed in mainnet we can revert it.

Base version of middleware used is 7229f2b

The script to initialize the devnet can be found on contracts/scripts/anvil

The addresses of the relevant contracts after running the anvil script is dumped on contracts/script/output/devnet.

The state is backuped on contracts/scripts/anvil/state

Eigenlayer contract deployment is almost the same as the EigenLayer contract deployment on mainnet. Changes are described on the file.

Strategies

The strategy contract is a contract where operators deposit restaked tokens. For test purposes, we have a dummy strategy contract that takes a Mock ERC20 token.

Aggregator

Current aggregator implementation is WIP. The RPC method Aggregator.SubmitTaskResponse expects a SignedTaskResponse as body and returns 0 if args.TaskResponse is not empty, and 1 otherwise.

Check common/types/signed_task_response.go for specification on SignedTaskResponse.

Operator

The following section is instructions on how to create an operator from scratch. You can find more details on the EigenLayer documentation.

To create an operator, you will need to generate keys, generate a config, and register with EigenLayer.

To generate the operator keys, run:

make operator-generate-keys

This will output key paths & address, make sure to store them for following steps.

To generate a new operator config, run the command

make operator-generate-config

Then follow the instructions to populate the file

You will then need to populate two additional values, which are metadata_url and el_delegation_manager_address

To get the Delegation Manager Address of the last devnet deployment you can run:

make get-delegation-manager-address

For the metadata URL you can either use our example URL: https://yetanotherco.github.io/operator_metadata/

Or Deploy your metadata to your own sever (can be GitHub Pages)

You can get devnet Ether for gas by running:

make operator-get-eth

Make sure to set OPERATOR_ADDRESS enviroment variable to your own address before running command. This will send 1 eth to that address

Then you can register with EigenLayer by running:

make operator-register-with-eigen-layer

Config File

In config-files/config.yaml you can find the configuration file for the project.

There is a section for operator, aggregator, and keys. Also, there are common variables for the project.

FAQ

What is the objective of Aligned Layer?

Aligned Layer’s mission is to extend Ethereum’s zero-knowledge capabilities. We are certain the zero-knowledge proofs will have a key role in the future of blockchains and computation. We don’t know what that future will look like, but we are certain it will be in Ethereum. The question we want to share is: If we are certain zero-knowledge proofs are the future of Ethereum but we are not certain which of the many possible zero-knowledge futures will win. How can we build an infrastructure for Ethereum to be compatible with any future zero-knowledge proving system?

Why do we need a ZK verification layer?

Verifiable computation allows developers to build applications that help Ethereum scale or even create applications that were not possible before, with enhanced privacy properties. We believe the future of Ethereum will be shaped by zero-knowledge proofs and help it increase its capabilities.

What are the use cases of Aligned Layer?

Among the possible use cases of Aligned Layer we have:

Soft finality for Rollups and Appchains, fast bridging, new settlement layers (use Aligned + EigenDA) for Rollups and Intent based systems, P2P protocols based on SNARKs such as payment systems and social networks, alternative L1s interoperable with Ethereum, Verifiable Machine Learning, cheap verification and interoperability for Identity Protocols, ZK Oracles, new credential protocols such as zkTLS based systems, ZK Coprocessor, encrypted Mempools using SNARKs to show the correctness of the encryption, protocols against misinformation and fake news, and on-chain gaming.

Why build on top of Ethereum?

Ethereum is the most decentralized and biggest source of liquidity in the crypto ecosystem. We believe it is the most ambitious and long-term project on the internet. Aligned Layer is being built to help Ethereum achieve its highest potential, and we believe this is only possible through validity/zero-knowledge proofs.

Why not do this directly on top of Ethereum?

In order to do this we would have to aggregate all the proofs into a single proof. This is not a good solution considering that we would need some way to wrap proofs (for example, by means of recursion), which involves complex operations such as field emulation, bitwise, and/or elliptic curve operations.

Why not make Aligned Layer a ZK L1?

An L1 would not have the security properties of Ethereum consensus, and bootstrapping a new decentralized network is not only expensive but might be an impossible task. Zero-knowledge proofs are a nascent technology, and change is a constant. The best solution for today may not be the best for tomorrow; modifying L1s is extremely costly, especially as time progresses.

Why not a ZK L2?

An L2 needs to use the EVM to settle in Ethereum. This means that the proofs need to be efficiently verified in the EVM, and their data made available there.

The EVM is not designed for ZK Verification, so most verifications are expensive.

To solve this, for pairing-based cryptography, Ethereum has added a precompile for verifications using the curve BN254.

But technology changes fast. BN254 security was demonstrated to be around 100 bits instead of the expected 128. Fast Starks need efficient hashing for fields. Which is the best field? Mersenne’s? Goldilocks? Binary fields? What about the sumcheck protocol? Is Jolt the endgame? Or is GKR going to be faster?

The amount of progress in the field is big, and nobody can predict the endgame.

Even more, it would be naive to think that only one optimized prover will exist in the future. In the world of ZK, as in many others, there are trade-offs and systems that solve different problems.

Maybe we want faster proving and don't care about proof size. Maybe we want the fastest proof verification and smallest size and can do more work on the prover. The system may be optimized to prove Keccak really fast. Or we can skip the traditional hashes altogether and just optimize for Poseidon, Rescue, or one hash not created yet.

Aligned Layer solves all of this. No matter how or what you want to prove, it can be verified efficiently here while still inheriting the security of Ethereum as other L2s.

Why EigenLayer?

We believe Ethereum is the best settlement layer, and zero-knowledge will play a key role in helping it be THE settlement layer of the internet. We want to build a verification layer that helps Ethereum achieve this goal. This layer needs to have a decentralized group of validators that will just re-execute the verification of different proofs, but how can we build such a decentralized network that will help Ethereum? Creating a new L1 doesn’t benefit Ethereum because using it will add new trust assumptions to the Ethereum protocols relying on it. So, if we must have:

1. A decentralized network of verifiers
2. A similar economic security level that can be easily measured in Ethereum
3. Part of the Ethereum ecosystem
4. Flexible enough to support many current and future proving systems

Will you aggregate proofs?

Proof aggregation can also be supported by proving the verification of many of these different verifications. This will likely not be an urgent feature, but it will be needed in the future with more demand.

How does it compare to the Polygon aggregation layer?

Aligned Layer is just a network of decentralized verifiers renting security from Ethereum. On the other hand, the Polygon aggregation layer, in essence, is a rollup verifying multiple proofs. That is not the case for Aligned Layer, which just executes a rust binary from different verifiers directly in multiple Ethereum validators.