Pull changes from testnet to staging (#1147)

Author: MauroToscano

README.md

@@ -3,190 +3,4 @@
 > [!CAUTION]
 > To be used in testnet only.
 
-## Table of Contents
-
-- [Aligned](#aligned)
-  - [Table of Contents](#table-of-contents)
-  - [The Project](#the-project)
-  - [How to use the testnet](#how-to-use-the-testnet)
-  - [Operator Guide](#operator-guide)
-  - [Aligned Infrastructure Guide](#aligned-infrastructure-guide)
-  - [Submitting Proofs to Aligned](#submitting-proofs-to-aligned)
-  - [Integrating Aligned into your Project](#integrating-aligned-into-your-project)
-  - [Versioning and Networks](#versioning-and-networks)
-
-
-## 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:
-
-```bash
-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:
-
-```bash
-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:
-
-```bash
-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 \
---batcher_url wss://batcher.alignedlayer.com \
---rpc_url https://ethereum-holesky-rpc.publicnode.com \
---payment_service_addr 0x815aeCA64a974297942D2Bbf034ABEe22a38A003
-```
-
-5. You should get a response like this:
-
-```bash
-[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:
-
-```bash
-aligned verify-proof-onchain \
---aligned-verification-data ~/.aligned/aligned_verification_data/*.json \
---rpc_url https://ethereum-holesky-rpc.publicnode.com \
---chain holesky \
---payment_service_addr 0x815aeCA64a974297942D2Bbf034ABEe22a38A003
-```
-
-This is reading the result of the verification of the proof in Ethereum.
-
-7. You should get this result:
-
-```bash
-[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:
-
-```bash
-[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:
-
-```bash
-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.
-
-```bash
-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:
-
-```bash
-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:
-
-```bash
-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:
-
-```bash
-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](examples/verify/src/VerifyBatchInclusionCaller.sol) as an example. The code will look like this:
-
-```solidity
-(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](./docs/operator_guides/0_running_an_operator.md).
-
-## Aligned Infrastructure Guide
-
-If you are developing on Aligned, or want to run your own devnet, check our [setup Aligned guide](docs/3_guides/6_setup_aligned.md).
-
-
-## Submitting Proofs to Aligned
-For submitting proofs generated by your own project to the network via CLI, see the documentation on [submitting proofs to Aligned](docs/3_guides/0_submitting_proofs.md).
-
-
-## Integrating Aligned into your Project
-
-If you are developing applications using Aligned, we offer a [Rust-SDK](docs/3_guides/1_SDK_how_to.md) for submitting proofs directly to the network within your applications.
-
-## Versioning and Networks
-
-Testnet code and documentation is always in sync with the default [Testnet Branch](https://github.com/yetanotherco/aligned_layer/tree/feat/testnet)
-
-Releases are provided for each version of the testnet.
-
-Latest version of the code, deployed on staging network, is always on [Staging Branch](https://github.com/yetanotherco/aligned_layer/tree/feat/staging)
+To learn more about Aligned and how to use it, refer to the [docs page](https://docs.alignedlayer.com/) or [docs folder](./docs/).

docs/1_introduction/0_about_aligned.md

@@ -91,3 +91,7 @@ Since Aligned’s operators only need to run the verification code on bare metal
 - Adding new proof systems is straightforward.
 
 Preliminary numbers show that Aligned can verify more than 1000 proofs per second, over two orders of magnitude than the EVM at nominal capacity. Using effective batching techniques, we can split the task creation and verification cost between thousands of proofs.
+
+## Future additions
+
+- Propagation of the results to different L2s

docs/1_introduction/4_faq.md

@@ -6,6 +6,27 @@ Aligned’s mission is to extend Ethereum’s zero-knowledge capabilities. We ar
 
 The question we want to share is: If we are sure that zero-knowledge proofs are the future of Ethereum, but we don't know which of the many possible zero-knowledge futures will win, **then how do we build infrastructure for Ethereum to make it compatible with any future zero-knowledge proving system?**
 
+### What are the security guarantees and trust assumptions of Aligned?
+
+Aligned verifies proofs by having the operators re-execute the verification code for each proof and, if all of the proofs are valid, each of them signs a message containing a commitment to the proof and public input or the root of the batch. The aggregator is responsible for receiving the signatures, checking the quorum, performing the aggregation and sending them to Ethereum.
+
+- 67% of the operators behaving dishonestly to be able to submit false proofs.
+- 33% of the operators colluding to censor a batch of proofs or task. However, in the case of a batch, the operators can only censor the whole batch, but not a particular proof included in it.
+- The aggregator can censor batches or proofs by not sending the aggregated signature.
+
+### What is the batcher?
+
+We have a service called the batcher that batches enough proofs to send to the AVS in Eigen Layer to reduce on-chain verification costs. Users can submit their proofs to Aligned directly without the batcher. The batcher is fully optional. The batcher is an optimization to reduce on-chain verification costs.
+
+### What are the security guarantees added by the batcher?
+
+A batcher can censor proofs. The user can run their own batcher to avoid censorship or can send a task to verify proofs in Aligned via Ethereum without using the batcher. 
+The batcher cannot transfer user's funds to other accounts, only spend them to create verification tasks and pay to the aggregator. We recommend to only deposit enough funds for a few months of operations.
+
+### How do I send proofs without a batcher?
+
+### How do I run my own batcher?
+
 ### Why build Aligned on top of Ethereum?
 
 Ethereum is the most decentralized and most significant source of liquidity in the crypto ecosystem. We believe it is the most ambitious and long-term project on the internet. Aligned is being built to help Ethereum achieve its highest potential, and we believe this is only possible through validity/zero-knowledge proofs.

docs/2_architecture/0_supported_verifiers.md

@@ -8,12 +8,11 @@ The following is the list of the verifiers currently supported by Aligned:
 - :white_check_mark: gnark [(v0.11.0)](https://github.com/Consensys/gnark/releases/tag/v0.11.0) - Plonk (with BN254 and BLS12-381)
 - :white_check_mark: SP1 [(v1.0.1)](https://github.com/succinctlabs/sp1/releases/tag/v1.0.1)
 - :white_check_mark: Risc0 [(v1.0.1)](https://github.com/risc0/risc0/releases/tag/v1.0.1)
-- :white_check_mark: Halo2 - Plonk/KZG
-- :white_check_mark: Halo2 - Plonk/IPA
+- 🏗️ Circom
+- 🏗️ Lambdaworks
+- 🏗️ Kimchi
 
-The following are going to be added soon:
+The following are in the roadmap to be added:
 
-- :black_square_button: Kimchi
 - :black_square_button: Jolt
 - :black_square_button: Nexus
-- :black_square_button: Circom

docs/3_guides/6_setup_aligned.md

@@ -415,25 +415,25 @@ make batcher_send_risc0_burst
 <details>
 <summary>Plonk</summary>
 
-Send an individual bn254 proof:
+Send an individual BN254 proof:
 
 ```bash
 make batcher_send_plonk_bn254_task
 ```
 
-Send a burst of 15 bn254 proofs:
+Send a burst of 15 BN254 proofs:
 
 ```bash
 make batcher_send_plonk_bn254_burst
 ```
 
-Send an individual bl12 proof:
+Send an individual BLS12-381 proof:
 
 ```bash
 make batcher_send_plonk_bls12_381_task
 ```
 
-Send a burst of 15 bl12 proofs:
+Send a burst of 15 BLS12-381 proofs:
 
 ```bash
 make batcher_send_plonk_bls12_381_burst
@@ -444,19 +444,19 @@ make batcher_send_plonk_bls12_381_burst
 <details>
 <summary>Groth16</summary>
 
-Send an individual bn254 proof:
+Send an individual BN254 proof:
 
 ```bash
 make batcher_send_groth16_bn254_task
 ```
 
-Send bn254 proofs indefinitely:
+Send BN254 proofs indefinitely:
 
 ```bash
 make batcher_send_infinite_groth16
 ```
 
-Send bn254 proof bursts indefinitely:
+Send BN254 proof bursts indefinitely:
 
 ```bash
 make batcher_send_burst_groth16

docs/operator_guides/0_running_an_operator.md

@@ -92,17 +92,27 @@ Update the following placeholders in `./config-files/config-operator.yaml`:
 `"<ecdsa_key_store_location_path>"` and `"<bls_key_store_location_path>"` are the paths to your keys generated with the EigenLayer CLI, `"<operator_address>"` and `"<earnings_receiver_address>"` can be found in the `operator.yaml` file created in the EigenLayer registration process.
 The keys are stored by default in the `~/.eigenlayer/operator_keys/` directory, so for example `<ecdsa_key_store_location_path>` could be `/path/to/home/.eigenlayer/operator_keys/some_key.ecdsa.key.json` and for `<bls_key_store_location_path>` it could be `/path/to/home/.eigenlayer/operator_keys/some_key.bls.key.json`.
 
-The default configuration uses the public nodes RPC, but we suggest you use your own nodes for better performance and reliability.
-Also, from v0.5.2 there is a fallback mechanism to have two RPCs, so you can add a second RPC for redundancy.
+Two RPCs are used, one as the main one, and the other one as a fallback in case one node is working unreliably. 
+
+Default configurations is set up to use the same public node in both scenarios. 
+
+{% hint style="danger" %}
+
+PUBLIC NODES SHOULDN'T BE USED AS THE MAIN RPC. We recommend not using public nodes at all. 
+
+FALLBACK AND MAIN RPCs SHOULD BE DIFFERENT. 
+
+{% endhint %}
+
+Most of the actions will pass through the main RPC unless there is a problem with it. Events are fetched from both nodes.
 
 ```yaml
-eth_rpc_url: "https://ethereum-holesky-rpc.publicnode.com"
-eth_rpc_url_fallback: "https://ethereum-holesky-rpc.publicnode.com"
-eth_ws_url: "wss://ethereum-holesky-rpc.publicnode.com"
-eth_ws_url_fallback: "wss://ethereum-holesky-rpc.publicnode.com"
+eth_rpc_url: "https://<RPC_1>" 
+eth_rpc_url_fallback: "https://<RPC_2>"
+eth_ws_url: "wss://<RPC_1>"
+eth_ws_url_fallback: "wss://<RPC_2>"
 ```
 
-
 ## Step 4 - Deposit Strategy Tokens
 
 We are using [WETH](https://holesky.eigenlayer.xyz/restake/WETH) as the strategy token.
@@ -152,6 +162,66 @@ If you don't have Holesky ETH, these are some useful faucets:
 ./operator/build/aligned-operator start --config ./config-files/config-operator.yaml
 ```
 
+### Run Operator using Systemd
+
+To manage the Operator process on Linux systems, we recommend use systemd with the following configuration:
+
+You should create a user and a group in order to run the Operator and set the service unit to use that. In the provided service unit, we assume you have already created a user called `aligned`
+
+```toml
+# aligned-operator.service
+
+[Unit]
+Description=Aligned Operator
+After=network.target
+
+[Service]
+Type=simple
+User=aligned
+ExecStart=<path_to_aligned_layer_repository>/operator/build/aligned-operator start --config <path_to_operator_config>
+Restart=always
+RestartSec=1
+StartLimitBurst=100
+
+[Install]
+WantedBy=multi-user.target
+```
+
+{% hint style="info" %}
+`aligned-operator.service` is just an arbitrary name. You can name your service as you wish, following the format `<service-name>.service`.
+{% endhint %}
+
+Once you have configured the `aligned-operator.service` file, you need to run the following commands:
+
+```shell
+sudo cp aligned-operator.service /etc/systemd/system/aligned-operator.service
+sudo systemctl enable --now aligned-operator.service
+```
+
+{% hint style="warning" %}
+All paths must be absolute.
+{% endhint %}
+
+Those commands will link the service to systemd directory and then, will start the Operator service.
+
+Also, if the server running the operator goes down, systemd will start automatically the Operator on server startup.
+
+#### Restart operator
+
+If you want to restart the operator, you can use the following command:
+
+```shell
+sudo systemctl restart aligned-operator.service
+```
+
+#### Get Operators logs
+
+Once you are running your operator using systemd, you can get its logs using journalctl as follows:
+
+```shell
+journalctl -xfeu aligned-operator.service
+```
+
 ## Unregistering the operator
 
 To unregister the Aligned operator, run: