diff --git a/.gitbook.yaml b/.gitbook.yaml index e454be0e25..ff78e722b8 100644 --- a/.gitbook.yaml +++ b/.gitbook.yaml @@ -1 +1,52 @@ root: ./docs/ + +# Redirects for the Verification Layer deprecation and the Proof Aggregation +# Layer restructure. Keys are old published URL paths, values are file paths +# relative to `root`. +redirects: + # Introduction + introduction/2_use_cases: 1_introduction/1_use_cases.md + introduction/3_faq: 1_introduction/2_faq.md + introduction/4_why_zk: 1_introduction/3_why_zk.md + introduction/1_try_aligned: 2_proof_aggregation_layer/guides/1_quickstart.md + + # Architecture -> Proof Aggregation Layer + architecture/2_aggregation_mode: 2_proof_aggregation_layer/architecture/1_overview.md + architecture/2_aggregation_mode/1_deep_dive: 2_proof_aggregation_layer/architecture/2_deep_dive.md + architecture/0_supported_verifiers: 2_proof_aggregation_layer/architecture/4_supported_verifiers.md + architecture/0b_key_terms: 2_proof_aggregation_layer/architecture/5_key_terms.md + architecture/3_raas_platform: 3_raas/1_raas_platform.md + + # Guides -> Proof Aggregation Layer + guides/3.1_aggregation_mode: 2_proof_aggregation_layer/guides/5_integration_example.md + guides/10.1_aggregation_mode_cli: 2_proof_aggregation_layer/guides/3_cli.md + guides/1.3_SDK_api_reference_aggregation: 2_proof_aggregation_layer/guides/4_sdk.md + guides/4_generating_proofs: 2_proof_aggregation_layer/guides/2_generating_proofs.md + guides/7_setup_aligned_agg_mode: 2_proof_aggregation_layer/guides/6_local_setup.md + guides/8_contract_addresses: 2_proof_aggregation_layer/guides/7_contract_addresses.md + + # Deprecated Verification Layer pages. These are no longer published, so they + # land on the Proof Aggregation Layer overview rather than 404. + architecture/1_proof_verification_layer: 2_proof_aggregation_layer/architecture/1_overview.md + architecture/1_proof_verification_layer/1_batcher: 2_proof_aggregation_layer/architecture/1_overview.md + architecture/1_proof_verification_layer/2_payment_service_contract: 2_proof_aggregation_layer/architecture/1_overview.md + architecture/1_proof_verification_layer/3_service_manager_contract: 2_proof_aggregation_layer/architecture/1_overview.md + architecture/1_proof_verification_layer/4_operator: 2_proof_aggregation_layer/architecture/1_overview.md + architecture/1_proof_verification_layer/5_aggregator: 2_proof_aggregation_layer/architecture/1_overview.md + architecture/1_proof_verification_layer/6_explorer: 2_proof_aggregation_layer/architecture/3_explorer.md + guides/0_submitting_proofs: 2_proof_aggregation_layer/guides/1_quickstart.md + guides/9_submitting_batch_without_batcher: 2_proof_aggregation_layer/guides/1_quickstart.md + guides/10_aligned_cli: 2_proof_aggregation_layer/guides/3_cli.md + guides/1_SDK_how_to: 2_proof_aggregation_layer/guides/4_sdk.md + guides/1.2_SDK_api_reference: 2_proof_aggregation_layer/guides/4_sdk.md + guides/2_build_your_first_aligned_application: 2_proof_aggregation_layer/guides/5_integration_example.md + guides/2_build_your_first_aligned_application/2.2_modify_zkquiz_questions: 2_proof_aggregation_layer/guides/5_integration_example.md + guides/3_validating_public_input: 2_proof_aggregation_layer/guides/5_integration_example.md + guides/5_using_zkrust: 2_proof_aggregation_layer/guides/2_generating_proofs.md + guides/6_setup_aligned: 2_proof_aggregation_layer/guides/6_local_setup.md + operators/0_running_an_operator: 1_introduction/0_about_aligned.md + operators/1_operator_FAQ: 1_introduction/2_faq.md + operators/2_troubleshooting: 1_introduction/0_about_aligned.md + operators/upgrading-guides/v0_14_0: 1_introduction/0_about_aligned.md + operators/upgrading-guides/v0_10_2: 1_introduction/0_about_aligned.md + operators/upgrading-guides/v0_9_2: 1_introduction/0_about_aligned.md diff --git a/docs/1_introduction/0_about_aligned.md b/docs/1_introduction/0_about_aligned.md index 831501aedb..edb015a3c2 100644 --- a/docs/1_introduction/0_about_aligned.md +++ b/docs/1_introduction/0_about_aligned.md @@ -1,3 +1,5 @@ +# About Aligned + ## What is Aligned? Aligned is a vertically integrated stack for building applications on a verifiable internet. Whether it's financial infrastructure or AI systems, we provide the foundation for provable execution with one-click solutions for wallets, rollups, interoperability, and ZK services in a world where trust is no longer a given. @@ -9,7 +11,7 @@ Aligned is creating the foundation for a trustless, verifiable internet. Our ver By providing the tools for trust to be integrated into every layer of application infrastructure, we’re enabling developers to create verifiable systems that can be trusted across a wide range of use cases. Aligned is here to enable a future where trust is not assumed, but proven by design. {% hint style="info" %} -If you are unfamiliar with ZK and why this is useful, see [Why ZK and Aligned?](./4_why_zk.md) +If you are unfamiliar with ZK and why this is useful, see [Why ZK and Aligned?](3_why_zk.md) {% endhint %} ## What real value does Aligned bring to the table? @@ -18,7 +20,7 @@ Aligned is building a full stack of vertically integrated infrastructure designe Aligned suite of products and services includes: -- ZK Verification Layer (offering Proof Verification Layer and Proof Aggregation Service) +- ZK Verification Layer (the Proof Aggregation Service) - Rollup-as-a-Service (RaaS) Platform - Meta-Proving Services - Interoperability Protocol @@ -26,7 +28,7 @@ Aligned suite of products and services includes: ![Figure 1: Aligned Suite of Products](../images/aligned_suite_of_products.png) -Read more: [The Aligned Roadmap](https://roadmap.alignedlayer.com) +Read more: [The Aligned Roadmap](https://roadmap.alignedlayer.com) and [the Aligned Manifesto](https://blog.alignedlayer.com/aligned-manifesto/) By vertically integrating our stack we can provide the best developer experience and highest performance at the lowest possible cost. @@ -45,24 +47,15 @@ The main limitation for building complex applications on top of blockchains has ZK solves this, but due to slow and complex-to-use proving and expensive verification, progress has been limited. In the case of proving, before the development of general-purpose zero-knowledge virtual machines (zkVMs), users had to express their computation as arithmetic circuits, making the developer experience something like coding in assembler, error-prone, and complex. Moreover, proof systems depended on trusted setups, adding additional trust guarantees, the need to carry out special ceremonies to initialize parameters, and delaying go-to-market times. Besides, having high verification costs (on the order of 10's to 100's of dollars per proof) meant that only those projects with a huge capital could afford to build such applications. -## How much can Aligned Aligned’s ZK Verification Layer reduce costs? +## How much can Aligned’s ZK Verification Layer reduce costs? -Aligned’s ZK Verification Layer operates using two operation modes: Proof Verification Layer and Proof Aggregation Service. The cost reduction depends on throughput, proof system, and mode used. For the least expensive systems, such as Groth16, this can amount to nearly 90%, while STARKs can be nearly 99%. Moreover, Aligned’s stack allows the verification of proofs that cannot be currently verified in Ethereum due to cost or size, such as Kimchi or Binius. The verification cost using Aligned services is independent of the proof system, giving the choice of the proof system back to developers. +Aligned’s ZK Verification Layer is the Proof Aggregation Service. The cost reduction depends on throughput and the number of proofs aggregated together: the cost of verifying the aggregated proof on Ethereum is amortized across every proof in it, so the more proofs are aggregated, the cheaper each one becomes. ## How does Aligned’s stack compare to other solutions? -Aligned has created a new category in crypto: ZK verification layer. It is the only solution for now offering Proof Verification and Proof Aggregation modes while being linked to Ethereum via EigenLayer. The Proof Verification Layer provides very high throughput (over two orders of magnitude more than Ethereum), low latency, and lower costs than the Proof Aggregation Layer. The security is provided by restaking, and this mode is well suited for applications with tight limits on latency and costs. The Proof Aggregation Layer works using the slower proof recursion strategy, also used in rollups to compress proofs. Another key feature is that Aligned’s approach is stateless, simplifying the process greatly. - -Other solutions focus on building a separate L1 for proof verification (which sets them apart from Ethereum and requires bootstrapping the economic security, which can be lowered and subject to volatility, as opposed to that provided by restaking) or focus on the aggregation of proofs from a few proof systems. This last approach adds latency, higher operational costs, and constrains the developer's choice of the proof system. - -The following table contains cost estimates for Aligned, assuming a batch size of 20 proofs. +Aligned's Proof Aggregation Service compresses many proofs into a single recursive proof that is verified directly on Ethereum. Because the final proof is checked by an Ethereum smart contract, it inherits the full cryptographic security of Ethereum — there is no separate trust assumption to reason about, and no new economic security to bootstrap. -| Proof system | Ethereum | Aligned's Proof Verification Layer | Aligned's Proof Aggregation Service | -| ------------ | ---------- | ------------------- | --------------------- | -| Groth16 | 250,000 | 40,000 | TBD | -| STARKs | >1,000,000 | 40,000 | TBD | -| Kimchi-IPA | ?????? | 40,000 | TBD | -| Binius. | ?????? | 40,000 | TBD | +Other solutions focus on building a separate L1 for proof verification, which sets them apart from Ethereum and requires bootstrapping economic security that can be subject to volatility. Another key feature is that Aligned's approach is stateless, simplifying the process greatly. ## Why is Aligned building its stack? @@ -74,20 +67,11 @@ Currently, proof verification in Ethereum is expensive and throughput is limited Proof technology has been evolving over the last decade, with new arguments, fields, commitments and other tools appearing every day. It is hard to try new ideas if verification costs are high, and there is a considerable go-to-market time, as a consequence of development time of new, gas-optimized smart contracts, or the inclusion of new precompiles to make them affordable. -Aligned’s stack provides an alternative to reduce costs and increase throughput significantly. This is achieved by two different products: Proof Verification Layer and Proof Aggregation Service. - -The Proof Verification Layer works with a subset of Ethereum’s validators via restaking. Validators (also known as Operators) receive proofs, verify them using the verification code written in Rust or any other higher-level language, and then sign messages with BLS signatures. If a two-thirds (2/3) majority agrees, the results are posted in Ethereum. - -Since Aligned’s operators only need to run the verification code on bare metal, we have several advantages compared to running it on top of the EVM: - -- The code can be optimized for speed, not gas consumption. -- We can leverage parallelization to increase throughput. -- Since the gas limit does not constrain us, we can verify proof systems that are too expensive for Ethereum, such as Kimchi or Binius. -- Adding new proof systems is straightforward. +Aligned’s stack provides an alternative to reduce costs and increase throughput significantly. This is achieved by the Proof Aggregation Service. -Preliminary numbers show that Aligned’s Verification Layer can verify more than 1000 proofs per second, over two orders of magnitude more than the EVM at nominal capacity. Using effective batching techniques, we can split the task creation and verification cost between thousands of proofs. +The Proof Aggregation Service enables cost-efficient ZK proof verification by combining multiple proofs into one using recursive proof aggregation. Users submit their proofs to the service, which aggregates them into a single recursive proof attesting to the validity of all of them, and verifies that proof on Ethereum. The cost of the on-chain verification is then amortized across every proof in the batch. -On the other hand, Aligned’s Proof Aggregation service enables cost-efficient ZK proof verification by combining multiple proofs into one using recursive proof aggregation. It can be used standalone or with our Proof Verification Layer. Ideal for services like rollups that require Ethereum’s full security but can tolerate higher latency. +Because the final proof is verified by an Ethereum smart contract, this achieves Ethereum's full security. It is ideal for services like rollups that require Ethereum's full security but can tolerate higher latency. To complement these verification capabilities, Aligned’s Meta-proving Services offers an easy interface for accessing centralized and decentralized proving from external providers. Many developers building programs on Aligned with zkVMs will want to delegate proving to different service providers. To address this, we will have a simple SDK that allows developers to code in Rust and easily send their programs for proving to their preferred services. diff --git a/docs/1_introduction/1_try_aligned.md b/docs/1_introduction/1_try_aligned.md deleted file mode 100644 index 060d68cf96..0000000000 --- a/docs/1_introduction/1_try_aligned.md +++ /dev/null @@ -1,84 +0,0 @@ -# Try Aligned - -In this tutorial, you will learn how to send your first SP1 proofs to get verified in Aligned in under 3 minutes. - -{% hint style="warning" %} -This tutorial is for sending proofs on Hoodi network. -To send proofs on Mainnet, please refer to the [submitting proofs](../3_guides/0_submitting_proofs.md) guide. -{% endhint %} - -## Quickstart - -We will download a previously generated SP1 proof, send it to Aligned for verification, and retrieve the results from Ethereum Hoodi testnet. - -1. Download and install Aligned to send proofs in the testnet: - -```bash -curl -L https://raw.githubusercontent.com/yetanotherco/aligned_layer/testnet/crates/cli/install_aligned.sh | bash -``` - -2. Run the `source` command that should appear in the shell - -3. Download the example SP1 proof file together with the ELF file of the proved program using: - -```bash -curl -L https://raw.githubusercontent.com/yetanotherco/aligned_layer/testnet/crates/cli/get_proof_test_files.sh | bash -``` - -4. Send the proof to be verified in Aligned with - -```bash -rm -rf ~/.aligned/aligned_verification_data/ && -aligned submit \ ---proving_system SP1 \ ---proof ~/.aligned/test_files/sp1_fibonacci_5_0_0.proof \ ---vm_program ~/.aligned/test_files/sp1_fibonacci_5_0_0.elf \ ---public_input ~/.aligned/test_files/sp1_fibonacci_5_0_0.pub \ ---aligned_verification_data_path ~/.aligned/aligned_verification_data \ ---network hoodi \ ---rpc_url https://ethereum-hoodi-rpc.publicnode.com -``` - -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 -``` - -Use the link in the response to check the status of your transaction in the Aligned explorer. - -6. After three Ethereum blocks, you should be able to check if it has been verified with the CLI using - -```bash -aligned verify-proof-onchain \ ---aligned-verification-data ~/.aligned/aligned_verification_data/*.cbor \ ---rpc_url https://ethereum-hoodi-rpc.publicnode.com \ ---network hoodi -``` - -This is reading the result of the proof verification 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, you can compile the binaries yourself following the [README](https://github.com/yetanotherco/aligned_layer) - -To try Aligned with other proving systems, check [this](../3_guides/0_submitting_proofs.md) guide diff --git a/docs/1_introduction/1_use_cases.md b/docs/1_introduction/1_use_cases.md new file mode 100644 index 0000000000..c5bb44d976 --- /dev/null +++ b/docs/1_introduction/1_use_cases.md @@ -0,0 +1,109 @@ +# Use cases + +Aligned’s ZK verification layer for Ethereum makes proof verification affordable and scalable through our recursive [Proof Aggregation Service](../2_proof_aggregation_layer/architecture/1_overview.md). Use Aligned when you need to verify many proofs, expensive proofs, or proofs that aren’t economical in the EVM, and you still want results settled to Ethereum with Ethereum's own security. + +The ZK verification layer can be useful anytime ZK is used with Ethereum, but some clear use cases are described in this section. + +## ZK-rollups and Ethereum scaling + +Rollups produce ZK proofs of state transitions and need to verify (settle) those results on Ethereum. Verification can cost ZK-rollup operators millions per year, and infrequent verification to save on gas leads to longer exit windows and worse UX. + +### **How Aligned helps:** + +- Aggregates many rollup proofs into a single recursive proof verified on Ethereum, so the cost of on-chain verification is amortized across the whole batch. +- Keeps full L1 security and adds no cryptoeconomic trust assumptions: the aggregated proof is checked by an Ethereum smart contract like any other ZK proof. + +{% hint style="success" %} +Our RaaS makes launching [based ZK-rollups](https://blog.alignedlayer.com/aligned-raas-based-rollups-to-build-the-future-of-ethereum/) (Ethrex stack) possible in one click and is integrated with our ZK verification layer to reduce costs. +{% endhint %} + +## Fast, trust-minimized bridging & interoperability + +Bridges and cross-chain systems verify source chain state/account proofs on the destination chain. We are also developing an intents and ZK-based fast interoperability protocol in-house to take full advantage of the ZK Verification Layer and to complement our RaaS platform. + +### **How Aligned helps:** + +- Makes verifying proofs economical at scale, so bridges can post consolidated checkpoints to L1 far more often than the raw gas cost would otherwise allow. + +{% hint style="success" %} +The Mina ↔ Ethereum bridge uses Aligned to verify Mina’s Kimchi proofs on Ethereum ([blog post](https://blog.alignedlayer.com/mina-to-ethereum-bridge/)). +{% endhint %} + +## zkTLS & web2-to-web3 data credentials + +Generate proofs about data fetched over TLS (bank account balances, KYC, social graphs) and use them onchain without revealing the raw data. + +### **How Aligned helps:** + +- Turns high-volume zkTLS attestations into a practical UX by amortizing verification cost across many attestations. +- Keeps Ethereum as the root of trust, so a credential accepted onchain carries Ethereum's full security. + +## Verifiable AI (zkML / LLM inference proofs) + +To make AI verifiable, prove that model inference (or parts of a pipeline) ran correctly, or that an output meets policy constraints—then settle the result to Ethereum for auditability or onchain automation. + +### **How Aligned helps:** + +- zkVM proofs from systems like SP1 are supported today, so you can move from POCs to production-grade verification economics. +- High-volume inference checks (micro-payments, agent marketplaces, model-usage attestations) become affordable once verification cost is shared across a batch, and compliance events settle with L1-final proofs. + +{% hint style="success" %} +See our [blog post](https://blog.alignedlayer.com/the-era-of-ai-needs-ethereum-and-zk/) that expands on why we believe ZK and Ethereum will play a major role in the future of AI. +{% endhint %} + +## Identity & verifiable credentials + +Issue/verify privacy-preserving credentials (DID/VC, age/eligibility proofs, reputation). Governments and enterprises can adopt ZK without forcing users to leak data. + +### **How Aligned helps:** + +- Makes credential verification cheap enough for mainstream UX while keeping Ethereum as the root of trust and avoiding the compromise of verifying proofs on a blockchain with lower security. +- Already powering real identity stacks (e.g. [Sovra’s Digital Trust Stack](https://blog.alignedlayer.com/aligned-sovra-partner-to-power-digital-trust-in-latin-america/)). + +## ZK coprocessors & oracles + +Off-chain processes fetch data or perform heavy computations and return a ZK proof that onchain logic can trust. Allows offchain computation to be secured by onchain trust, giving smart contracts greater expressivity. + +### **How Aligned helps:** + +- Lets you run richer computations and affordably verify them onchain. +- A natural way to add computational trust and reduce L1 gas bottlenecks for oracle-like systems, at the highest available security level. + +## Onchain gaming & interactive apps + +Games and interactive dapps that prove game validity, scores/results, or anti-cheat logic with ZK. + +### **How Aligned helps:** + +- Sharing verification cost across many proofs makes regular and frequent proving economical. +- We’ve highlighted early builders in our [hackathon spotlights](https://blog.alignedlayer.com/tag/hackathons/). + +{% hint style="success" %} +_**Coming soon:**_ Our **ZK Arcade** will let users verify proofs of game results using Aligned. +{% endhint %} + +## How it works + +Developers submit their ZK proofs to the Proof Aggregation Service, where they are aggregated into a single recursive proof that is then verified on Ethereum. By aggregating many proofs into one, the cost of on-chain verification is amortized across the batch — you effectively pay a fraction of the full price, plus a small aggregation fee. + +Because the final proof is verified by an Ethereum smart contract, this carries the full cryptographic security of Ethereum. The tradeoff is latency: proofs are settled within the aggregation window, which defaults to 24 hours. + +See the [architecture overview](../2_proof_aggregation_layer/architecture/1_overview.md) and the [deep dive](../2_proof_aggregation_layer/architecture/2_deep_dive.md) for the details. + +## Supported proof systems + +Aligned currently aggregates SP1 compressed proofs, with more zkVMs on the roadmap. See [Supported Verifiers](../2_proof_aggregation_layer/architecture/4_supported_verifiers.md). + +## Featured projects & posts + +- [All the proof aggregation solutions will use RISC-V zkVMs](https://blog.alignedlayer.com/all-the-proof-aggregation-solutions-will-use-risc-v-zkvms/) +- [Aligned RaaS: Based ZK-rollups using Ethrex](https://blog.alignedlayer.com/why-is-aligned-using-ethrex-for-based-zk-rollups/) +- [Mina ↔ Ethereum bridge](https://blog.alignedlayer.com/mina-to-ethereum-bridge/) +- [Why based rollups?](https://blog.alignedlayer.com/aligned-raas-based-rollups-to-build-the-future-of-ethereum/) + +## Future additions + +- Use cases: Aligned RaaS +- Use cases: Meta-proving services +- Use cases: Aligned Wallets-as-a-Service +- Use cases: Aligned Interoperability protocol diff --git a/docs/1_introduction/2_faq.md b/docs/1_introduction/2_faq.md new file mode 100644 index 0000000000..4c1628a9e7 --- /dev/null +++ b/docs/1_introduction/2_faq.md @@ -0,0 +1,104 @@ +# FAQ + +### What is Aligned's objective? + +Aligned is creating the foundation for a trustless, verifiable internet. Our vertically integrated stack empowers developers to build applications across finance, AI, and other sectors with one-click solutions for wallets, rollups, and zero-knowledge services on Ethereum. We’re focused on enabling provable execution in a world where institutional trust is increasingly fragile. + +By providing the tools for trust to be integrated into every layer of application infrastructure, we’re enabling developers to create verifiable systems that can be trusted across a wide range of use cases. Aligned is here to enable a future where trust is not assumed, but proven by design. + +### What are the security guarantees and trust assumptions of Aligned's Proof Aggregation Service? + +The Proof Aggregation Service produces a single recursive proof attesting that every proof it aggregated was verified correctly. That proof is verified by an Ethereum smart contract, so a valid on-chain verification implies the validity of each individual proof. There is no separate validator set to trust and no cryptoeconomic assumption: the security is Ethereum's own. + +The aggregator can censor a proof by not including it in an aggregation, but it cannot cause an invalid proof to be accepted. + +### 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. + +For further reading on this subject, you can refer to [this Aligned blog post](https://blog.alignedlayer.com/why-ethereum/), which explains why we chose Ethereum. + +### How much does it cost to verify proofs using Aligned? + +The cost of verifying the aggregated proof on Ethereum is amortized across every proof it contains. The more proofs are aggregated together, the smaller each one's share of that cost, plus a small aggregation fee and the cost of reading the result on-chain. + +### How long does it take? + +Proofs are aggregated and settled to Ethereum within the aggregation window, which defaults to 24 hours. This is the tradeoff for getting Ethereum's full cryptographic security on a per-proof cost that would otherwise be impractical. + +### Why is Aligned building its stack? + +Aligned is building its stack to provide the infrastructure for a trustless, verifiable internet. Its vertically integrated stack enables developers to create applications across industries like finance and AI, with one-click solutions for rollups, wallets, and several zero-knowledge (ZK) services. Innovations in proving virtual machines, like Risc0, Jolt, SP1, and Valida, allow users to generate proof of computation integrity using languages like Rust or C. However, Ethereum’s proof verification is costly and slow, limiting innovation. Aligned addresses this with its Proof Aggregation Service, reducing verification costs and increasing throughput. In addition, Aligned offers a Wallet-as-a-Service infrastructure for simplifying wallet generation, and a Rollup-as-a-Service (RaaS) platform for easy ZK-rollup deployment. Its Interoperability Protocol also supports trust-minimized cross-chain liquidity movement. Together, these innovations aim to build a scalable, secure, and trustless internet. + +### Is Aligned an Ethereum L2? + +No. Aligned is a vertically integrated stack for building applications on a verifiable internet. However, our stack offers one-click solutions for rollups, as well as wallets, and several ZK services. + +### What is proof recursion? + +Zero-knowledge proofs let you generate proofs that show the correct execution of programs. If a program is the verification of a proof, then we will be getting a proof that we verified the proof and the result was valid. The validity of the second proof implies the validity of the original proof. This is the idea behind proof recursion, and it can be used with two main goals: + +1. Convert one proof type to another (for example, a STARK proof to a Plonk proof) either to reduce the proof size, have efficient recursion, or because the proof system cannot be verified where we want. +2. Proof aggregation: if we have to verify $N$ proofs on-chain, we can generate a single proof that we verified the $N$ proofs off-chain and just check the single proof on Ethereum. + +Proof recursion is the primary tool used by Aligned’s Proof Aggregation Service. + +### Is Aligned an aggregation layer? + +Aligned provides proof aggregation as part of its Proof Aggregation Service, a feature shared with all aggregation layers. Aligned's approach is stateless and settles directly to Ethereum, so proofs verified through it inherit Ethereum's security rather than that of a separate chain. + +### What proof systems do you support? + +Aligned’s stack is designed to support any proof system. The Proof Aggregation Service currently accepts SP1 compressed proofs, with more zkVMs on the roadmap. See [Supported Verifiers](../2_proof_aggregation_layer/architecture/4_supported_verifiers.md). + +### How does Aligned's Proof Aggregation Service work? + +The flow is as follows: + +1. The user deposits into the payment service contract to fund their proof submission quota. +2. The user submits a proof to the Gateway using the CLI or SDK. +3. The Gateway validates the submission against the user's quota and stores the proof. +4. The Proof Aggregator picks up pending proofs and recursively aggregates them into a single proof, committing to a Merkle root of all the proof commitments. +5. The aggregated proof is submitted to Ethereum and verified by the `AlignedProofAggregationService` contract, along with a blob containing the individual proof commitments. +6. The user checks their proof's inclusion by providing a Merkle proof against the stored root. + +See the [deep dive](../2_proof_aggregation_layer/architecture/2_deep_dive.md) for the full details. + +### How can I verify proofs using Aligned's stack? + +You can verify proofs with our stack using our [CLI](../2_proof_aggregation_layer/guides/3_cli.md) or [Rust SDK](../2_proof_aggregation_layer/guides/4_sdk.md). + +### Can you provide an estimate of Aligned’s savings? + +Proof verification directly on Ethereum (not including the cost of accessing/reading) costs: + +- Groth 16 proofs: >250,000 gas +- Plonk/KZG proofs: >300,000 gas +- STARKs: >1,000,000 gas +- Binius/Jolt: too expensive to run! + +With Aligned's Proof Aggregation Service, a single aggregated proof (around 300,000 gas to verify) covers every proof in the batch, so the per-proof cost falls as the batch grows. + +### I want to verify just one proof. Can I use your products and services for cheap and fast verification? + +Yes. Your proof is aggregated together with everyone else's, so you still benefit from sharing the on-chain verification cost. + +### Is Aligned open-source? + +Yes! We are 100% open-source from day one. + +### What’s the role of Aligned in Ethereum? + +Aligned's role is to provide a full stack of vertically integrated infrastructure that simplifies the process of launching, operating, and scaling on the Ethereum network, enabling teams to build applications across finance, AI, and other sectors with one-click solutions for wallets, rollups, and zero-knowledge services. + +### 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 our goal is to help increase its capabilities. + +### What are the use cases for Aligned's stack? + +We believe that there are many things that will be built using Aligned's stack that we have not even imagined yet. For some possible use cases please see [this page](1_use_cases.md). + +### What about TEEs? + +Aligned's stack will also verify remote attestations made by Trusted Execution Environments (TEEs). We believe TEEs provide an alternative to ZK in some applications where ZK is too computationally intensive or as an additional mechanism to provide integrity (_e.g._ in multiproofs). diff --git a/docs/1_introduction/2_use_cases.md b/docs/1_introduction/2_use_cases.md deleted file mode 100644 index 388267988c..0000000000 --- a/docs/1_introduction/2_use_cases.md +++ /dev/null @@ -1,147 +0,0 @@ -# Use Cases: ZK Verification Layer - -Aligned’s ZK verification layer for Ethereum makes proof verification affordable, fast, and scalable—either via our low-latency [Proof Verification Layer](https://docs.alignedlayer.com/architecture/1_proof_verification_layer) (an EigenLayer AVS) or via our recursive [Proof Aggregation Service](https://docs.alignedlayer.com/architecture/2_aggregation_mode). Use Aligned when you need to verify many proofs, expensive proofs, or proofs that aren’t economical in the EVM, and you still want results settled to Ethereum. - -The ZK verification layer can be useful anytime ZK is used with Ethereum, but some clear use cases are described in this section. - -## ZK-rollups and Ethereum scaling - -Rollups produce ZK proofs of state transitions and need to verify (settle) those results on Ethereum. Verification can cost ZK-rollup operators millions per year, and infrequent verification to save on gas leads to longer exit windows and worse UX. - -### **How Aligned helps:** - -- Offloads verification to a decentralized operator set, reducing per-proof gas by 90–99% and increasing throughput from ~tens of proofs/sec on Ethereum to thousands. -- For full L1 security and no cryptoeconomic trust assumptions, aggregate many rollup proofs into a single recursive proof verified on Ethereum. -- Option to use the Proof Verification Layer or Proof Aggregation Service depending on security and latency needs. - -### **Choose a mode:** - -- **Verification Layer (low latency, high volume):** live on mainnet; ideal for the fastest confirmations and very high proof volumes. Economic security with nearly 3 million restaked ETH (>$12B USD value). -- **Aggregation Service (highest security):** recursively compresses many proofs into one proof verified on L1; great when you can trade latency for full Ethereum security. - -{% hint style="success" %} -Our RaaS makes launching [based ZK-rollups](https://blog.alignedlayer.com/aligned-raas-based-rollups-to-build-the-future-of-ethereum/) (Ethrex stack) possible in one click and is integrated with our ZK verification layer to reduce costs. -{% endhint %} - -## Fast, trust-minimized bridging & interoperability - -Bridges and cross-chain systems verify source chain state/account proofs on the destination chain. We are also developing an intents and ZK-based fast interoperability protocol in-house to take full advantage of the ZK Verification Layer and to complement our RaaS platform. - -### **How Aligned helps:** - -- Verifies non-EVM-friendly proofs (e.g., Kimchi, STARKs) economically and at scale. -- Enables fast exits (soft finality) while optionally posting hard-finality checkpoints via aggregation. - -### **Choose a mode:** - -- **Verification Layer** for quick attestations and user UX. -- **Aggregation Service** for periodic consolidated checkpoints to L1. - -{% hint style="success" %} -The Mina ↔ Ethereum bridge uses Aligned to verify Mina’s Kimchi proofs on Ethereum ([blog post](https://blog.alignedlayer.com/mina-to-ethereum-bridge/)). -{% endhint %} - -## zkTLS & web2-to-web3 data credentials - -Generate proofs about data fetched over TLS (bank account balances, KYC, social graphs) and use them onchain without revealing the raw data. - -### **How Aligned helps:** - -- Turns high-volume zkTLS attestations into a practical UX by keeping verification costs low and parallelizable. -- Lets apps pick latency vs. finality per flow (e.g., instant gating on Verification Layer + periodic L1-final checkpoints via aggregation). - -### **Choose a mode:** - -- **Verification Layer** when users need instant attest-and-act. -- **Aggregation Service** when proofs must be verified directly on Ethereum. - -## Verifiable AI (zkML / LLM inference proofs) - -To make AI verifiable, prove that model inference (or parts of a pipeline) ran correctly, or that an output meets policy constraints—then settle the result to Ethereum for auditability or onchain automation. - -### **How Aligned helps:** - -- zkVM proofs from systems like SP1 and Risc0 are supported today, so you can move from POCs to production-grade verification economics. -- High-volume inference checks (micro-payments, agent marketplaces, model-usage attestations) benefit from the Verification Layer’s low latency; compliance/events can use aggregated L1 proofs. - -### **Choose a mode:** - -- **Verification Layer** for per-inference confirmations and low cost at scale. -- **Aggregation Service** for periodic, L1-final attestations (e.g., job batches, epoch summaries). - -{% hint style="success" %} -See our [blog post](https://blog.alignedlayer.com/the-era-of-ai-needs-ethereum-and-zk/) that expands on why we believe ZK and Ethereum will play a major role in the future of AI. -{% endhint %} - -## Identity & verifiable credentials - -Issue/verify privacy-preserving credentials (DID/VC, age/eligibility proofs, reputation). Governments and enterprises can adopt ZK without forcing users to leak data. - -### **How Aligned helps:** - -- Makes credential verification cheap enough for mainstream UX while keeping Ethereum as the root of trust and avoiding the compromise of verifying proofs on a blockchain with lower security. -- Already powering real identity stacks (e.g. [Sovra’s Digital Trust Stack](https://blog.alignedlayer.com/aligned-sovra-partner-to-power-digital-trust-in-latin-america/)). - -### **Choose a mode:** - -- **Verification Layer** for interactive UX (logins, access control). -- **Aggregation Service** for archival or cross-period consolidated attestations. - -## ZK coprocessors & oracles - -Off-chain processes fetch data or perform heavy computations and return a ZK proof that onchain logic can trust. Allows offchain computation to be secured by onchain trust, giving smart contracts greater expressivity. - -### **How Aligned helps:** - -- Lets you run richer computations and affordably verify them onchain. -- A natural way to add computational trust and reduce L1 gas bottlenecks for oracle-like systems. - -### **Choose a mode:** - -- **Verification Layer** for frequent or streaming tasks. -- **Aggregation Service** when the highest security is needed (e.g. if the economic security from the AVS does not meet risk management parameters). - -## Onchain gaming & interactive apps - -Games and interactive dapps that prove game validity, scores/results, or anti-cheat logic with ZK. - -### **How Aligned helps:** - -- Low-latency verification makes regular and frequent proving economical. -- We’ve highlighted early builders in our [hackathon spotlights](https://blog.alignedlayer.com/tag/hackathons/). - -{% hint style="success" %} -_**Coming soon:**_ Our **ZK Arcade** (launching 2025 Q3) will let users verify proofs of game results using Aligned. -{% endhint %} - -## Which mode should I pick? - -**Need the lowest cost and fastest confirmations?** -- Start with the [Proof Verification Layer](https://docs.alignedlayer.com/architecture/1_proof_verification_layer). It’s live on mainnet, secured by 52 restaked operators, and can verify thousands of proofs per second with results readable on Ethereum within blocks (cryptoeconomic security derived from Ethereum). - -**Need full L1 finality in one transaction?** -- Use the [Proof Aggregation Service](https://docs.alignedlayer.com/architecture/2_aggregation_mode). It recursively compresses many proofs into one that’s verified directly on Ethereum, trading minutes of latency for the strongest security (full cryptographic security of Ethereum). - -***You can also combine both:*** use the Verification Layer for UX and fast exits, then periodically post aggregated checkpoints for L1 finality. - -The Proof Aggregation Service is a standalone service, independent from the Proof Verification Layer. Developers submit their ZK proofs directly to the Aggregation Service, where they are aggregated into a single recursive proof that is then verified on Ethereum. By aggregating many proofs into one, the cost of on-chain verification is amortized across the batch. Users can choose either the Verification Layer or the Aggregation Service depending on their latency and security requirements. - -![Comparison between the Proof Verification Layer and Proof Aggregation Service (_August 2025_)](../images/pvl_vs_pas_comp_table.png) - -## Supported proof systems - -Aligned supports multiple verifiers (today: Risc0, SP1, gnark Groth16/Plonk, Circom, with more on the roadmap), so you can pick the right proving stack and still get good economics. - -## Featured projects & posts - -- [Verification Layer vs. Aggregation Service deep-dive](https://blog.alignedlayer.com/proof-verification-layer-vs-aggregation-service/) -- [Aligned RaaS: Based ZK-rollups using Ethrex](https://blog.alignedlayer.com/why-is-aligned-using-ethrex-for-based-zk-rollups/) -- [Mina ↔ Ethereum bridge](https://blog.alignedlayer.com/mina-to-ethereum-bridge/) -- [Why based rollups?](https://blog.alignedlayer.com/aligned-raas-based-rollups-to-build-the-future-of-ethereum/) - -## Future additions - -- Use cases: Aligned RaaS -- Use cases: Meta-proving services -- Use cases: Aligned Wallets-as-a-Service -- Use cases: Aligned Interoperability protocol diff --git a/docs/1_introduction/3_faq.md b/docs/1_introduction/3_faq.md deleted file mode 100644 index 9630dcd6f0..0000000000 --- a/docs/1_introduction/3_faq.md +++ /dev/null @@ -1,159 +0,0 @@ -# FAQ - -### What is Aligned's objective? - -Aligned is creating the foundation for a trustless, verifiable internet. Our vertically integrated stack empowers developers to build applications across finance, AI, and other sectors with one-click solutions for wallets, rollups, and zero-knowledge services on Ethereum. We’re focused on enabling provable execution in a world where institutional trust is increasingly fragile. - -By providing the tools for trust to be integrated into every layer of application infrastructure, we’re enabling developers to create verifiable systems that can be trusted across a wide range of use cases. Aligned is here to enable a future where trust is not assumed, but proven by design. - -### What are the security guarantees and trust assumptions of Aligned's Proof Verification Layer? - -Aligned's Proof Verification Layer 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 EigenLayer to reduce on-chain verification costs. Users can submit their proofs directly to Aligned’s Proof Verification Layer without using the Batcher. The Batcher is fully optional and serves as an optimization to further 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 our Proof Verification Layer 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 depositing only enough funds for a few months of operations. - -### How do I send proofs without a batcher? - -You can see the steps to do it in [this guide](../3_guides/8_submitting_batch_without_batcher.md). - -### How do I run my own batcher? - -To-do - -### 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. - -For further reading on this subject, you can refer to [this Aligned blog post](https://blog.alignedlayer.com/why-ethereum/), which explains why we chose Ethereum. - -### What is the throughput of Aligned’s Proof Verification Layer? - -Aligned’s Proof Verification Layer runs the verifier’s code natively. The verification time depends on the proof system, program run, and public input. Generally, most verifiers can be run in the order of ms on consumer-end hardware. We can optimize the code for speed and leverage parallelization by running it natively. Current testnet can verify more than 2500 proofs per second. - -### How does the throughput of Aligned’s Proof Verification Layer compare with Ethereum? - -Ethereum runs on top of the EVM. Each block is limited to 45,000,000 gas. Since the most efficient proof systems take at least 250,000 gas, Ethereum can verify 180 proofs per block. Aligned's Proof Verification Layer runs the code natively and leverages parallelization, reaching 30,000 proofs in the same period. - -### Why is Aligned buiding its stack? - -Aligned is building its stack to provide the infrastructure for a trustless, verifiable internet. Its vertically integrated stack enables developers to create applications across industries like finance and AI, with one-click solutions for rollups, wallets, and several zero-knowledge (ZK) services. Innovations in proving virtual machines, like Risc0, Jolt, SP1, and Valida, allow users to generate proof of computation integrity using languages like Rust or C. However, Ethereum’s proof verification is costly and slow, limiting innovation. Aligned addresses this with its Proof Verification Layer and Proof Aggregation Service, reducing verification costs and increasing throughput. In addition, Aligned offers a Wallet-as-a-Service infrastructure for simplifying wallet generation, and a Rollup-as-a-Service (RaaS) platform for easy ZK-rollup deployment. Its Interoperability Protocol also supports trust-minimized cross-chain liquidity movement. Together, these innovations aim to build a scalable, secure, and trustless internet. - -### Is Aligned an Ethereum L2? - -No. Aligned is a vertically integrated stack for building applications on a verifiable internet. However, our stack offers one-click solutions for rollups, as well as wallets, and several ZK services. - -### How much it cost to verify proofs using Aligned's Proof Verification Layer? - -The cost ($C$) of proof verification using Aligned's Proof Verification Layer is the cost of task creation ($C_{task}$) plus the cost of verifying an aggregated BLS signature ($C_{verification}$), divided by the number of proofs ($N$) in the batch, plus the the cost of reading the results on-chain ($C_{read}$). - -$$ - C =\frac{C_{task} + C_{verification}}{N} + C_{read} -$$ - -The cost of task creation and signature verification is amortized across $N$ proofs per batch, meaning that our verification layer becomes cheaper to use as more proofs are verified at the same time. - -### What are BLS signatures? - -[Boneh-Lynn-Shacham (BLS)](https://en.wikipedia.org/wiki/BLS_digital_signature) signatures are a cryptographic signature that allows a user to verify that a signer is authentic. It relies on elliptic curve pairings and is used by Ethereum due to its aggregation properties. - -### Why do you have a Proof Verification Layer and a Proof Aggregation Service? - -The Proof Verification Layer is designed to offer very cheap verification costs and low latency. It uses crypto-economic guarantees provided by restaking; costs can be as low as 2100 gas. The Proof Aggregation Service uses recursive proof aggregation, achieving the complete security of Ethereum, but with slightly higher fees and latency. We verify an aggregated BLS signature (around 113,000 gas) in our Proof Verification Layer. We verify an aggregated proof (around 300,000 gas) in our Proof Aggregation Service. Together, these two services form our ZK verification layer which offers developers different options for reducing proof verification costs on Ethereum, depending on their scale and security requirements. - -### What is proof recursion? - -Zero-knowledge proofs let you generate proofs that show the correct execution of programs. If a program is the verification of a proof, then we will be getting a proof that we verified the proof and the result was valid. The validity of the second proof implies the validity of the original proof. This is the idea behind proof recursion, and it can be used with two main goals: - -1. Convert one proof type to another (for example, a STARK proof to a Plonk proof) either to reduce the proof size, have efficient recursion, or because the proof system cannot be verified where we want. -2. Proof aggregation: if we have to verify $N$ proofs on-chain, we can generate a single proof that we verified the $N$ proofs off-chain and just check the single proof on Ethereum. - -Proof recursion is the primary tool used by Aligned’s aggregation mode. - -### What is restaking? - -EigenLayer introduced the concept of Restaking. It allows Ethereum’s validators to impose additional slashing conditions on their staked ETH to participate in Actively Validated Services (AVS) and earn additional rewards. This creates a marketplace where applications can rent Ethereum's trust without competing for blockspace. Aligned's fast mode is an AVS. - -### Is Aligned an aggregation layer? - -Aligned provides proof aggregation as part of its Proof Aggregation Service, a feature shared with all aggregation layers. However, Aligned offers a unique Proof Verification Layer designed to provide cheap and low-latency proof verification, secured by restaked ETH. - -### What proof systems do you support? - -Aligned’s stack is designed to support any proof system. [Currently supported ones](../2_architecture/0_supported_verifiers.md) are Groth16 and Plonk (gnark), SP1, Risc0, and Circom. - -### How does Aligned's Proof Verification Layer work? - -The flow is as follows: - -1. The user uses a provided CLI or SDK to send one proof or many to the batcher, and waits (Alternatively, the user can run a batcher or interact directly with Ethereum) -2. The batcher accumulates proofs of many users for a small number of blocks (typically 1-3). -3. The batcher creates a Merkle Tree with commitments to all the data submitted by users, uploads the proofs to the Data Service, and creates the verification task in the ServiceManager. -4. The operators, using the data in Ethereum, download the proofs from the DataService. They then verify that the Merkle root is equal to the one in Ethereum, and verify all the proofs. -5. If the proofs are valid, they sign the root and send this to the BLS signature aggregator. -6. The signature aggregator accumulates the signed responses until reaching the quorum, then sends the aggregated signature to Ethereum. -7. Ethereum verifies the aggregated signatures and changes the state of the batch to verified. - -### How can I verify proofs using Aligned's stack? - -You can verify proofs with our stack using our CLI or Rust SDK. - -### Can you provide an estimate of Aligned’s savings? - -Proof verification directly on Ethereum (not including the cost of accessing/reading) costs: - -- Groth 16 proofs: >250,000 gas -- Plonk/KZG proofs: >300,000 gas -- STARKs: >1,000,000 gas -- Binius/Jolt: too expensive to run! - -With Aligned's Proof Verification Layer: - -- Just one proof (any!): 350,000 gas -- Batching 1024 proofs: 350 gas + reading cost - -This means verifying proofs using Aligned's Verification Layer can be 99% cheaper than directly on Ethereum. - -### I want to verify just one proof. Can I use your products and services for cheap and fast verification? - -Yes! And all proofs cost the same to verify using our stack. - -### Is Aligned open-source? - -Yes! We are 100% open-source from day one. - -### What’s the role of Aligned in Ethereum? - -Aligned's role is to provide a full stack of vertically integrated infrastructure that simplifies the process of launching, operating, and scaling on the Ethereum network, enabling teams to build applications across finance, AI, and other sectors with one-click solutions for wallets, rollups, and zero-knowledge services. - -### 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 our goal is to help increase its capabilities. - -### What are the use cases for Aligned's stack? - -We believe that there are many things that will be built using Aligned's stack that we have not even imagined yet. For some possible use cases please see [this page](../1_introduction/2_use_cases.md). - -### Why EigenLayer? - -We believe Ethereum is the best settlement layer, and ZK will play a key role in helping it become 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: so how do we build such a decentralized network that will help Ethereum? - -Creating a new L1 doesn’t benefit Ethereum because it will add new trust assumptions to the Ethereum protocols relying on it. EigenLayer enables Aligned to have the following properties: - -1. A decentralized network of verifiers -2. A similar economic security level that can be easily measured in ETH -3. Part of the Ethereum ecosystem -4. Flexible enough to support many current and future proving systems - -### What about TEEs? - -Aligned's stack will also verify remote attestations made by Trusted Execution Environments (TEEs). We believe TEEs provide an alternative to ZK in some applications where ZK is too computationally intensive or as an additional mechanism to provide integrity (_e.g._ in multiproofs). diff --git a/docs/1_introduction/4_why_zk.md b/docs/1_introduction/3_why_zk.md similarity index 84% rename from docs/1_introduction/4_why_zk.md rename to docs/1_introduction/3_why_zk.md index bd6178c499..aff33557c3 100644 --- a/docs/1_introduction/4_why_zk.md +++ b/docs/1_introduction/3_why_zk.md @@ -11,15 +11,14 @@ In blockchains, we need to coordinate between different parties that do not trus With Aligned's stack, you can generate the proof and then use Ethereum as a settlement layer. To do so, Aligned offers a variety of products to reduce your costs and increase throughput. Once you decide to use ZK for your product and Ethereum, Aligned fits perfectly. -- **Proof Verification Layer:** A decentralized network of verifiers that checks the proofs, signs messages stating the correctness of the proof and when a threshold is met, publishes the signature to Ethereum. Once Ethereum checks the signature, the state of the proofs is changed to verified, and you can use the result as always. It has very high throughput, reduces costs significantly (depending on the number of proofs that are sent) and has low latency. -- **Proof Aggregation Service:** Performs recursive proof aggregation of several ZK proofs. The final proof is sent to Ethereum, and if verified, it implied the validity of your proof. It has higher latency and lower throughput than the proof verification layer, but achieves the full security of Ethereum. +- **Proof Aggregation Service:** Performs recursive proof aggregation of several ZK proofs. The final proof is sent to Ethereum, and if verified, it implies the validity of your proof. Because that final proof is checked by an Ethereum smart contract, it achieves the full security of Ethereum, while the cost of the on-chain verification is amortized across every proof in the batch. - **Meta Proving Services**: Offers an easy interface for accessing centralized and decentralized proving from external providers. - **Rollup-as-a-service (RaaS) platform:** Simplifies ZK-rollup deployment, allowing clients to launch L2 chains with just one click, without needing deep blockchain expertise. - **Interoperability protocol:** An intent-based bridge that will be integrated with our RaaS stack. It will leverage based sequencing and enable developers to create native trust-minimized solutions for users and financial institutions to efficiently move liquidity across chains. - **Wallet-as-a-Service infrastructure:** Enable developers to easily generate embedded wallets for users, supporting rollups and mobile integrations. It will leverage the latest account abstraction technology, offering seamless wallet services backed by our robust tech stack. How can you write ZK applications and generate proofs? There are many different technologies and libraries to build ZK applications. Until recently, it was fairly complicated, since you needed some background of math and write circuits (you can think of it as coding in assembly). Luckily, there are several ZK virtual machines (zkVM) that allow you to generate proofs of code written in a higher level language, such as Rust. -You write your code and run it on top of the zkVM, and you get a proof of its correct execution. To simplify things, we have [zkRust](../3_guides/5_using_zkrust.md), where you can run your code and send the proof directly to Aligned! +You write your code and run it on top of the zkVM, and you get a proof of its correct execution. See [Generating proofs for Aligned](../2_proof_aggregation_layer/guides/2_generating_proofs.md) for how to produce a proof that Aligned can aggregate. ## Projects or ideas using ZK diff --git a/docs/2_architecture/0_supported_verifiers.md b/docs/2_architecture/0_supported_verifiers.md deleted file mode 100644 index 729473d3a4..0000000000 --- a/docs/2_architecture/0_supported_verifiers.md +++ /dev/null @@ -1,20 +0,0 @@ -# Supported verifiers - -Aligned's support for multiple proof systems is a significant advantage, as it allows users to choose the most suitable system based on their specific requirements. - -The following is the list of the verifiers currently supported by Aligned: - -- :white_check_mark: gnark - Groth16 (with BN254) [(v0.12.0)](https://github.com/Consensys/gnark/releases/tag/v0.12.0) -- :white_check_mark: gnark - Plonk (with BN254 and BLS12-381) [(v0.12.0)](https://github.com/Consensys/gnark/releases/tag/v0.12.0) -- :white_check_mark: SP1 [(v5.0.0)](https://github.com/succinctlabs/sp1/releases/tag/v5.0.0) -- :white_check_mark: Risc0 [(v3.0.3)](https://github.com/risc0/risc0/releases/tag/v3.0.3). Previous versions are also compatible. -- :white_check_mark: Circom [(v2.2.2)](https://github.com/iden3/circom/releases/tag/v2.2.2) -- :white_check_mark: Mina (Testnet only - Sepolia, Hoodi) -- :white_check_mark: Mina Account (Testnet only - Sepolia, Hoodi) -- 🏗️ Lambdaworks -- 🏗️ Kimchi - -The following are in the roadmap to be added: - -- :black_square_button: Jolt -- :black_square_button: Nexus diff --git a/docs/2_architecture/0b_key_terms.md b/docs/2_architecture/0b_key_terms.md deleted file mode 100644 index fe6db1abe5..0000000000 --- a/docs/2_architecture/0b_key_terms.md +++ /dev/null @@ -1,49 +0,0 @@ -## Key Terms - -### Proof - -A **Proof** is cryptographic data that can attest to the validity of a given computation. The concrete data and size depend on the proof system and program used. - -### Verification - -The **Verification** is an algorithm that takes the proof, and associated public data and verification key/program and outputs whether the proof is valid or not. - -### Proof Batch - -A **Proof batch** is a collection of verification tasks to be carried out by the Operators. - -### User CLI - -The **User CLI** is used to interact with the Verifier Task Batcher. It sends proof and public input data and receives the verification data in Aligned. - -### Verifier Task Batcher - -The **Verifier Task Batcher** receives tasks from users, creates batches of tasks, publishes the proof and public data in the Data service, and sends the batches’ data to Ethereum. This service is permissionless, meaning users have the option to run their own batcher. - -### Service Manager - -The **Service Manager (Ethereum smart contract)** receives the batches’ data and signatures from the BLS signature aggregator. This contract provides information to validators and Light Clients on the batches/tasks. - -### Data Service - -The **Data Service** temporarily stores the data for the proof and public input. - -### Operators - -The **Operators** are responsible for performing the verification of the proofs in each batch and signing messages with the results. - -### BLS Signature Aggregator - -The **BLS Signature Aggregator** receives the signatures from the Operators, checks if a quorum is reached, if so, it performs the aggregation of the signatures. - -### Light Clients - -The **Light Client** samples random tasks from the Service Manager, checks the proofs, and compares against the results posted to Ethereum by Aligned. If there are differences, it can trigger an L1 verification via the proof service. In case of malicious behavior by Aligned’s Operators, this would lead to slashing. - -### Proof Service - -The **Proof Service** receives results from the Light Clients; in case there are differences with the results posted by Aligned, it triggers a re-verification on Ethereum. Note that this re-verification can also be triggered by any user. - -### Proof Aggregator - -The **Proof aggregator**, once tasks have been verified by Aligned’s Operators, performs recursive proof verification to create one proof that will attest to the validity of all proofs contained in the batch. This proof is verified on-chain. diff --git a/docs/2_architecture/2_aggregation_mode.md b/docs/2_architecture/2_aggregation_mode.md deleted file mode 100644 index bf3b501eaf..0000000000 --- a/docs/2_architecture/2_aggregation_mode.md +++ /dev/null @@ -1,9 +0,0 @@ -## Aligned's Proof Aggregation Service in a nutshell - -Aligned's Proof Aggregation Service introduces a scalable solution: compressing multiple proofs into one using recursion, drastically reducing verification costs while maintaining Ethereum-level security. This is our second major product, following the Proof Verification Layer, and is designed to give developers flexible, cost-efficient infrastructure for proving systems. - -The Proof Aggregation Service is a standalone service, independent from the Proof Verification Layer. Developers submit their ZK proofs directly to the Aggregation Service, where they are aggregated in a single recursive proof that attests to the validity of all the proofs. This final proof is then submitted and verified on Ethereum. By aggregating many proofs into one, the cost of on-chain verification is amortized across the batch—developers effectively pay a fraction of the full price, plus a small aggregation fee. - -![Figure 1: Proof Aggregation Service](../images/aligned_proof_aggregation_service.png) - -The system is powered by recursive proving. In simple terms, the aggregation process proves that the verification of multiple proofs was correctly executed. This meta-proof is cryptographically valid and can be verified on Ethereum just like any standard ZK proof. diff --git a/docs/2_proof_aggregation_layer/architecture/1_overview.md b/docs/2_proof_aggregation_layer/architecture/1_overview.md new file mode 100644 index 0000000000..037318c50e --- /dev/null +++ b/docs/2_proof_aggregation_layer/architecture/1_overview.md @@ -0,0 +1,11 @@ +# Overview + +## Aligned's Proof Aggregation Service in a nutshell + +Aligned's Proof Aggregation Service introduces a scalable solution: compressing multiple proofs into one using recursion, drastically reducing verification costs while maintaining Ethereum-level security. It is designed to give developers flexible, cost-efficient infrastructure for proving systems. + +Developers submit their ZK proofs directly to the Aggregation Service, where they are aggregated in a single recursive proof that attests to the validity of all the proofs. This final proof is then submitted and verified on Ethereum. By aggregating many proofs into one, the cost of on-chain verification is amortized across the batch—developers effectively pay a fraction of the full price, plus a small aggregation fee. + +![Figure 1: Proof Aggregation Service](../../images/aligned_proof_aggregation_service.png) + +The system is powered by recursive proving. In simple terms, the aggregation process proves that the verification of multiple proofs was correctly executed. This meta-proof is cryptographically valid and can be verified on Ethereum just like any standard ZK proof. diff --git a/docs/2_architecture/agg_mode_components/1_deep_dive.md b/docs/2_proof_aggregation_layer/architecture/2_deep_dive.md similarity index 100% rename from docs/2_architecture/agg_mode_components/1_deep_dive.md rename to docs/2_proof_aggregation_layer/architecture/2_deep_dive.md diff --git a/docs/2_proof_aggregation_layer/architecture/3_explorer.md b/docs/2_proof_aggregation_layer/architecture/3_explorer.md new file mode 100644 index 0000000000..60b27008b4 --- /dev/null +++ b/docs/2_proof_aggregation_layer/architecture/3_explorer.md @@ -0,0 +1,39 @@ +# Explorer + +{% embed url="https://explorer.alignedlayer.com" %} + +The Explorer tracks the aggregated proofs that the [Proof Aggregator](2_deep_dive.md) settles on Ethereum, so you can see which aggregated proof your submission ended up in and follow it back to the settling transaction. + +Deployments: + +- [Mainnet](https://explorer.alignedlayer.com) +- [Hoodi](https://hoodi.explorer.alignedlayer.com) +- [Sepolia](https://sepolia.explorer.alignedlayer.com) + +## Aggregated proofs list + +The `/aggregated_proofs` page lists aggregated proofs, most recent first. Each row shows: + +- **Merkle root** — the root committed by the aggregated proof, built from the [proof commitments](2_deep_dive.md#proof-commitment) it covers. Links to the detail view. +- **Age** — how long ago the aggregated proof was settled. +- **Block Number** — the Ethereum block the aggregated proof was included in. +- **Blob versioned hash** — the blob carrying the proof commitments, linked to Blobscan. +- **Number of proofs** — how many user proofs were aggregated together. +- **Aggregator** — the aggregation program used, `SP1` or `RISC0`. + +## Aggregated proof details + +Clicking a Merkle root opens `/aggregated_proofs/:id`, which shows: + +- The **Merkle root**, with a copy-to-clipboard button +- The **Aggregator** used +- The **Number of proofs included** +- **Proofs included** — an expandable list of the individual proof commitments in this aggregated proof, each with its own copy button. This is how you confirm your proof made it into a given aggregation. +- **Block Number** and **Transaction Hash** of the settling transaction, linked to Etherscan +- The **Blob versioned hash**, linked to Blobscan + +The blob is the same one described in [Data Availability](2_deep_dive.md#data-availability): it keeps the proof commitments publicly available for 18 days, which is what lets you reconstruct the Merkle proof needed to check your proof's inclusion on-chain. + +{% hint style="info" %} +The Explorer is for inspection. To verify programmatically that your proof was included, use [`agg_mode_cli verify-on-chain`](../guides/3_cli.md#verify-on-chain) or the SDK's [`check_proof_verification`](../guides/4_sdk.md#check_proof_verification). +{% endhint %} diff --git a/docs/2_proof_aggregation_layer/architecture/4_supported_verifiers.md b/docs/2_proof_aggregation_layer/architecture/4_supported_verifiers.md new file mode 100644 index 0000000000..035f1377bf --- /dev/null +++ b/docs/2_proof_aggregation_layer/architecture/4_supported_verifiers.md @@ -0,0 +1,14 @@ +# Supported verifiers + +The following proving systems can be submitted to Aligned's Proof Aggregation Service: + +- :white_check_mark: SP1 [(v5.0.0)](https://github.com/succinctlabs/sp1/releases/tag/v5.0.0) — **compressed** proofs only + +The following are in the roadmap to be added: + +- 🏗️ Risc0 — on-chain proof inclusion checks already accept Risc0 program IDs, but proof submission is not available yet +- :black_square_button: Additional zkVMs + +{% hint style="info" %} +SP1 proofs must be generated in compressed mode. See [Generating proofs for Aligned](../guides/2_generating_proofs.md). +{% endhint %} diff --git a/docs/2_proof_aggregation_layer/architecture/5_key_terms.md b/docs/2_proof_aggregation_layer/architecture/5_key_terms.md new file mode 100644 index 0000000000..2b44dedf0c --- /dev/null +++ b/docs/2_proof_aggregation_layer/architecture/5_key_terms.md @@ -0,0 +1,45 @@ +# Key Terms + +### Proof + +A **Proof** is cryptographic data that can attest to the validity of a given computation. The concrete data and size depend on the proof system and program used. + +### Verification + +The **Verification** is an algorithm that takes the proof, and associated public data and verification key/program and outputs whether the proof is valid or not. + +### Program ID + +The **Program ID** identifies the program a proof was generated for. For SP1 it is the hash of the verifying key; for Risc0 it is the image ID. + +### Proof Commitment + +The **Proof commitment** is a hash that uniquely identifies a submitted proof. It is computed as the keccak of the proof's public inputs concatenated with the program ID. + +### Gateway + +The **Gateway** receives proofs from users, validates them against the sender's quota, and stores them until they are picked up for aggregation. + +### Payment Service + +The **AggregationModePaymentService** is the Ethereum contract users deposit into to fund their proof submission quota. + +### Payments Poller + +The **Payments Poller** watches the payment service contract for deposits and credits the corresponding quota to the user. + +### Proof Aggregator + +The **Proof Aggregator** performs recursive proof verification to create one proof that attests to the validity of all the proofs it received. This aggregated proof is what gets verified on-chain. + +### Aggregation Window + +The **Aggregation window** is how long a submitted proof may wait before being aggregated and settled on Ethereum. It defaults to 24 hours. + +### Merkle Root and Proof Inclusion + +Each aggregated proof commits to a **Merkle root** built from the proof commitments it contains. To show that a specific proof was verified, a user provides a **Merkle proof** against that root, which the `AlignedProofAggregationService` contract checks. + +### Data Availability Blob + +When the aggregated proof is submitted to Ethereum, the proof commitments it covers are published in a **blob**. This makes them publicly available for 18 days so that users can inspect what was aggregated and build their Merkle proofs. diff --git a/docs/2_proof_aggregation_layer/guides/1_quickstart.md b/docs/2_proof_aggregation_layer/guides/1_quickstart.md new file mode 100644 index 0000000000..c6dfa034f2 --- /dev/null +++ b/docs/2_proof_aggregation_layer/guides/1_quickstart.md @@ -0,0 +1,99 @@ +# Quickstart + +In this tutorial you will submit an SP1 proof to Aligned's Proof Aggregation Service and check that it was verified on Ethereum. + +{% hint style="warning" %} +This tutorial uses the Hoodi testnet. The same steps work on Mainnet by passing `--network mainnet` and a Mainnet RPC URL. +{% endhint %} + +## Quickstart + +We will use a previously generated SP1 proof that ships with the repository, submit it for aggregation, and then read the result from Ethereum. + +### 1. Install the Aggregation Mode CLI + +```bash +git clone https://github.com/yetanotherco/aligned_layer.git +cd aligned_layer +make agg_mode_install_cli +``` + +Check the installation: + +```bash +agg_mode_cli --help +``` + +### 2. Create a keystore + +If you do not already have one, create a local keystore with `cast` and import it: + +```bash +cast wallet new-mnemonic +cast wallet import --interactive +``` + +Fund the account with Hoodi ETH from [this faucet](https://cloud.google.com/application/web3/faucet/ethereum/hoodi). You need funds both for gas and for your proof submission quota. + +### 3. Fund your submission quota + +Deposit into the Aggregation Mode payment service: + +```bash +agg_mode_cli deposit \ + --keystore-path \ + --network hoodi \ + --rpc-url https://ethereum-hoodi-rpc.publicnode.com +``` + +Each call deposits a fixed 0.0035 ether. + +### 4. Submit the proof + +From the root of the repository: + +```bash +agg_mode_cli submit sp1 \ + --proof scripts/test_files/sp1/sp1_fibonacci_5_0_0.proof \ + --vk scripts/test_files/sp1/sp1_fibonacci_5_0_0_vk.bin \ + --keystore-path \ + --network hoodi +``` + +On success the CLI prints a task ID: + +``` +INFO Submitting SP1 proof to Hoodi +INFO Proof submitted successfully. Task ID: 3f9a1c4e-... +``` + +### 5. Wait for aggregation + +Your proof is batched with others and aggregated into a single recursive proof, which is then verified on Ethereum. This happens within the aggregation window — **24 hours by default** — so this step is not instant. + +You can follow aggregated proofs as they land in the [Hoodi explorer](https://hoodi.explorer.alignedlayer.com). + +### 6. Check that your proof was verified + +```bash +agg_mode_cli verify-on-chain \ + --network hoodi \ + --rpc-url https://ethereum-hoodi-rpc.publicnode.com \ + --beacon-url https://ethereum-hoodi-beacon-api.publicnode.com \ + --proving-system SP1 \ + --vk-hash scripts/test_files/sp1/sp1_fibonacci_5_0_0.vk \ + --public-inputs scripts/test_files/sp1/sp1_fibonacci_5_0_0.pub +``` + +This reads the result of the aggregated proof verification from Ethereum and checks your proof's inclusion in it. + +{% hint style="info" %} +If your proof is not found, pass an earlier `--from-block` to search further back. The default only looks at roughly the last 25 hours, and the blob carrying the proof commitments expires after 18 days. +{% endhint %} + +## Next steps + +- [Generating proofs for Aligned](2_generating_proofs.md) — produce these files from your own SP1 program +- [Integration example](5_integration_example.md) — a toy L2 built on the Proof Aggregation Layer +- [Aggregation Mode CLI](3_cli.md) and [SDK](4_sdk.md) references +- [Architecture overview](../architecture/1_overview.md) — how aggregation works under the hood diff --git a/docs/2_proof_aggregation_layer/guides/2_generating_proofs.md b/docs/2_proof_aggregation_layer/guides/2_generating_proofs.md new file mode 100644 index 0000000000..1a3b8ef2d6 --- /dev/null +++ b/docs/2_proof_aggregation_layer/guides/2_generating_proofs.md @@ -0,0 +1,101 @@ +# Generating Proofs For Aligned + +Aligned's Proof Aggregation Service currently accepts **SP1 compressed proofs**. This guide shows how to produce the files the [Aggregation Mode CLI](3_cli.md) and [SDK](4_sdk.md) expect. + +## Dependencies + +This guide assumes that: + +- The SP1 prover is installed ([instructions](https://docs.succinct.xyz/docs/sp1/getting-started/install)) +- You have an SP1 project to generate proofs from ([instructions](https://docs.succinct.xyz/docs/sp1/getting-started/quickstart)) +- The Aggregation Mode CLI is installed ([instructions](3_cli.md#installation)) + +## Generating a compressed proof + +{% hint style="warning" %} +Only **compressed** SP1 proofs can be aggregated. In your proving script, the proof must be built with `.compressed()` — a default or Groth16/Plonk proof will be rejected by the aggregator. +{% endhint %} + +In your SP1 script, generate the proof and write out the four files Aligned works with: + +```rust +use sp1_sdk::{include_elf, HashableKey, ProverClient, SP1Stdin}; + +const ELF: &[u8] = include_elf!("your-program"); + +fn main() { + let mut stdin = SP1Stdin::new(); + // ...write your program inputs into `stdin`... + + let client = ProverClient::from_env(); + let (pk, vk) = client.setup(ELF); + + // `.compressed()` is required — Aligned aggregates compressed proofs only. + let proof = client.prove(&pk, &stdin).compressed().run().unwrap(); + client.verify(&proof, &vk).expect("verification failed"); + + // 1. The proof itself — passed to `--proof` when submitting. + proof.save("./my_proof.proof").expect("saving proof failed"); + + // 2. The serialized verifying key — passed to `--vk` when submitting. + std::fs::write("./my_vk.bin", bincode::serialize(&vk).unwrap()).unwrap(); + + // 3. The verifying key hash (32 bytes) — passed to `--vk-hash` when verifying on-chain. + std::fs::write("./my_vk_hash.bin", vk.hash_bytes()).unwrap(); + + // 4. The public values — passed to `--public-inputs` when verifying on-chain. + std::fs::write("./my_public_inputs.bin", proof.public_values.clone()).unwrap(); +} +``` + +Then run it from your script directory: + +```bash +cargo run --release +``` + +A complete working example lives at `scripts/test_files/sp1/fibonacci_proof_generator/`, and the files it produces are checked into `scripts/test_files/sp1/`. + +### Which file goes where + +| File | Produced by | Used for | +|---|---|---| +| `my_proof.proof` | `proof.save(...)` | `agg_mode_cli submit sp1 --proof` | +| `my_vk.bin` | `bincode::serialize(&vk)` | `agg_mode_cli submit sp1 --vk` | +| `my_vk_hash.bin` | `vk.hash_bytes()` | `agg_mode_cli verify-on-chain --vk-hash` | +| `my_public_inputs.bin` | `proof.public_values` | `agg_mode_cli verify-on-chain --public-inputs` | + +## Submitting the proof to Aligned + +Fund your submission quota first, then submit: + +```bash +agg_mode_cli deposit \ + --keystore-path \ + --network hoodi \ + --rpc-url https://ethereum-hoodi-rpc.publicnode.com + +agg_mode_cli submit sp1 \ + --proof ./my_proof.proof \ + --vk ./my_vk.bin \ + --keystore-path \ + --network hoodi +``` + +The command returns a task ID. Your proof is aggregated with others and settled on Ethereum within the aggregation window (24 hours by default). + +## Checking verification + +Once the aggregated proof has been settled, check that yours was included: + +```bash +agg_mode_cli verify-on-chain \ + --network hoodi \ + --rpc-url https://ethereum-hoodi-rpc.publicnode.com \ + --beacon-url https://ethereum-hoodi-beacon-api.publicnode.com \ + --proving-system SP1 \ + --vk-hash ./my_vk_hash.bin \ + --public-inputs ./my_public_inputs.bin +``` + +See the [Aggregation Mode CLI reference](3_cli.md) for every option, and the [integration example](5_integration_example.md) for a full application walkthrough. diff --git a/docs/3_guides/10.1_aggregation_mode_cli.md b/docs/2_proof_aggregation_layer/guides/3_cli.md similarity index 89% rename from docs/3_guides/10.1_aggregation_mode_cli.md rename to docs/2_proof_aggregation_layer/guides/3_cli.md index 0d094905bb..61a58342c6 100644 --- a/docs/3_guides/10.1_aggregation_mode_cli.md +++ b/docs/2_proof_aggregation_layer/guides/3_cli.md @@ -1,11 +1,9 @@ -# Aggregation Mode CLI Documentation +# Aggregation Mode CLI The Aggregation Mode CLI serves as an interface for users to interact with Aligned Aggregation Mode. This document serves as a reference for the commands of the Aggregation Mode CLI. -> **Note:** Aggregation Mode is currently available on the [`staging` branch](https://github.com/yetanotherco/aligned_layer/tree/staging). - ## Installation 1. Clone the Aligned Layer repository: @@ -13,7 +11,6 @@ This document serves as a reference for the commands of the Aggregation Mode CLI ```bash git clone https://github.com/yetanotherco/aligned_layer.git cd aligned_layer - git checkout staging ``` 2. Build and install the Aggregation Mode CLI using the Makefile: @@ -25,7 +22,7 @@ This document serves as a reference for the commands of the Aggregation Mode CLI 3. Verify that the installation was successful: ```bash - agg-mode-cli --version + agg_mode_cli --help ``` > **Note:** A standalone installation script will be available soon for easier installation without cloning the repository. @@ -52,6 +49,8 @@ agg_mode_cli [COMMAND] --help Send ether to the Aggregation Mode payment service to fund your proof submission quota. +The deposit amount is currently fixed at **0.0035 ether** per call; there is no amount option. Run the command more than once to add more quota. + #### Command `deposit [OPTIONS] --rpc-url ` @@ -104,7 +103,7 @@ Submit an SP1 proof to the Aggregation Mode Gateway for verification. ```bash agg_mode_cli submit sp1 \ - --proof ./my_proof.bin \ + --proof ./my_proof.proof \ --vk ./my_vk.bin \ --keystore-path ~/.ethereum/keystore/my-key.json \ --network hoodi @@ -138,13 +137,15 @@ Check whether a proof has been verified on the AlignedProofAggregationService co - Default: Current block minus 7500 blocks (~25 hours) - `--proving-system `: The proving system used. - Possible values: `SP1`, `Risc0` + - Only `SP1` is functional today. `Risc0` is accepted by the argument parser but the check is still performed as SP1, so it will not report correctly. - `--vk-hash `: Path to the file containing the program verification key hash (32 bytes). - `--public-inputs `: Path to the public inputs file. + - Required in practice: the command exits with `Public input file not provided` if omitted. #### Example ```bash -agg-mode-cli verify-on-chain \ +agg_mode_cli verify-on-chain \ --network hoodi \ --rpc-url https://ethereum-hoodi-rpc.publicnode.com \ --beacon-url https://ethereum-hoodi-beacon-api.publicnode.com \ diff --git a/docs/3_guides/1.3_SDK_api_reference_aggregation.md b/docs/2_proof_aggregation_layer/guides/4_sdk.md similarity index 71% rename from docs/3_guides/1.3_SDK_api_reference_aggregation.md rename to docs/2_proof_aggregation_layer/guides/4_sdk.md index bb754881a3..a7c587fed6 100644 --- a/docs/3_guides/1.3_SDK_api_reference_aggregation.md +++ b/docs/2_proof_aggregation_layer/guides/4_sdk.md @@ -1,5 +1,60 @@ # Aggregation Mode SDK +The Aggregation Mode SDK lets you submit proofs to Aligned's Proof Aggregation Service and check their verification on-chain from Rust, without going through the CLI. + +## Installation + +Add the SDK to your `Cargo.toml`: + +```toml +[dependencies] +agg_mode_sdk = { git = "https://github.com/yetanotherco/aligned_layer", branch = "testnet" } + +# Needed to build the arguments the SDK takes: +alloy = { version = "1.1.1", features = ["signer-keystore"] } +sp1-sdk = "5.0.0" +bincode = "1.3.3" +tokio = { version = "1", features = ["macros", "rt-multi-thread"] } +``` + +{% hint style="info" %} +The SDK is not yet part of a tagged release, so the dependency tracks the `testnet` branch. Pin it to a tag once one is published. +{% endhint %} + +## Hello World + +Submitting an SP1 proof takes a signer and the gateway provider: + +```rust +use agg_mode_sdk::{gateway::provider::AggregationModeGatewayProvider, types::Network}; +use alloy::signers::local::PrivateKeySigner; +use sp1_sdk::{SP1ProofWithPublicValues, SP1VerifyingKey}; + +#[tokio::main] +async fn main() { + let proof: SP1ProofWithPublicValues = + bincode::deserialize(&std::fs::read("./my_proof.proof").unwrap()).unwrap(); + let vk: SP1VerifyingKey = + bincode::deserialize(&std::fs::read("./my_vk.bin").unwrap()).unwrap(); + + let signer: PrivateKeySigner = "".parse().unwrap(); + let provider = AggregationModeGatewayProvider::new_with_signer(Network::Hoodi, signer) + .expect("failed to initialize gateway client"); + + let response = provider + .submit_sp1_proof(&proof, &vk) + .await + .expect("failed to submit proof"); + + println!("Proof submitted. Task ID: {}", response.data.task_id); +} +``` + +Your account needs quota before submitting — see the [`deposit` command](3_cli.md#deposit) of the Aggregation Mode CLI. + +Once the proof has been aggregated and settled on L1, check its inclusion with +[`check_proof_verification`](#check_proof_verification). + ## API Reference ### `AggregationModeGatewayProvider` @@ -201,9 +256,17 @@ pub enum AggregationModeVerificationData { vk: [u8; 32], public_inputs: Vec, }, + Risc0 { + image_id: [u8; 32], + public_inputs: Vec, + }, } ``` +{% hint style="info" %} +Proof submission is currently SP1-only: the gateway exposes `submit_sp1_proof` and no Risc0 equivalent. +{% endhint %} + ### `GatewayError` ```rust diff --git a/docs/3_guides/3.1_aggregation_mode.md b/docs/2_proof_aggregation_layer/guides/5_integration_example.md similarity index 82% rename from docs/3_guides/3.1_aggregation_mode.md rename to docs/2_proof_aggregation_layer/guides/5_integration_example.md index 9429e6b34b..18f797cb56 100644 --- a/docs/3_guides/3.1_aggregation_mode.md +++ b/docs/2_proof_aggregation_layer/guides/5_integration_example.md @@ -1,17 +1,4 @@ -# Aggregation Mode - -Aggregation Mode is a standalone service, independent from the Aligned Verification Layer. You no longer need to interact with the verification layer to have your proofs verified—Aggregation Mode handles the entire process. - -> **Note:** Aggregation Mode is currently available on the [`staging` branch](https://github.com/yetanotherco/aligned_layer/tree/staging). - -## Reference Documentation - -- [CLI Reference](10.1_aggregation_mode_cli.md) - Command-line interface for interacting with Aggregation Mode -- [SDK Reference](1.3_SDK_api_reference_aggregation.md) - Rust SDK API reference - ---- - -## Proof Aggregation Service L2 integration example +# Integration example: a toy L2 This guide demonstrates how to build a dummy L2 application that integrates with Aligned's Proof Aggregation Service. The L2 does not post state diffs or any data to Ethereum, only commitments. The prover has to prove that: @@ -28,10 +15,10 @@ The code can be viewed at `examples/l2`. This Layer 2 (L2) system operates in two main steps: -- Off-chain execution and proof generation + verification with Aligned's Proof Verification Layer. -- On-chain state update via proof verification with Aligned's Proof Aggregation Service. +- Off-chain execution and proof generation, then submission to Aligned's Proof Aggregation Service. +- On-chain state update via proof inclusion verification against the aggregated proof. -In Step 1, we execute user transfers and generate a zkVM-based proof of the state transition, which is submitted to Aligned’s verification layer. +In Step 1, we execute user transfers and generate a zkVM-based proof of the state transition, which is submitted to the Aggregation Mode Gateway. In Step 2, once the proof is aggregated (every 24 hours), it is verified on-chain to update the global state. @@ -41,7 +28,7 @@ In Step 2, once the proof is aggregated (every 24 hours), it is verified on-chai 2. Load Transfers: Retrieve or receive the user transfer data for this batch. 3. Execute in zkVM: Run the zkVM with the loaded transfers to compute the new state. 4. Generate Proof: Produce a zk-proof for the executed state transition committing the commitment of the received + the commitment of the new state. -5. Submit Proof to Aligned: Send the proof to Aligned Verification Layer +5. Submit Proof to Aligned: Send the proof to the Aggregation Mode Gateway 6. Save the binary proof locally for later on-chain verification. ### Step 2: Proof Verification + On-Chain State Update @@ -94,7 +81,7 @@ cast wallet import --interactive Then you need to obtain some funds to pay for gas and proof verification. You can do this by using this [faucet](https://cloud.google.com/application/web3/faucet/ethereum/hoodi) -_This same wallet is used to send the proof via aligned, so you'll also need to fund it on aligned. Follow this [guide](https://docs.alignedlayer.com/guides/0_submitting_proofs#id-2.-send-funds-to-aligned)._ +_This same wallet is used to send the proof to Aligned, so you also need to fund your quota on Aligned with the [`deposit` command](3_cli.md#deposit) of the Aggregation Mode CLI._ ### 2. Deploy the contract @@ -144,15 +131,19 @@ Finally [run the l2](#running-the-l2). You can also run this example on a local devnet. To get started, navigate to the root of the Aligned repository -- Start Ethereum package and the Batcher +- Start the Ethereum package and the Aggregation Mode services. Each of these runs in its own terminal: ```shell # This will start the local net make ethereum_package_start -# Start the batcher -make batcher_start_ethereum_package +# Start the gateway that receives proofs +make agg_mode_gateway_start_ethereum_package +# Start the poller that credits deposits to your quota +make agg_mode_payments_poller_start_ethereum_package ``` +See [Running the Proof Aggregation Layer locally](6_local_setup.md) for more detail on each service. + - Navigate back to the example directory: ```shell diff --git a/docs/3_guides/7_setup_aligned_agg_mode.md b/docs/2_proof_aggregation_layer/guides/6_local_setup.md similarity index 87% rename from docs/3_guides/7_setup_aligned_agg_mode.md rename to docs/2_proof_aggregation_layer/guides/6_local_setup.md index 132b115fb3..620f70f53d 100644 --- a/docs/3_guides/7_setup_aligned_agg_mode.md +++ b/docs/2_proof_aggregation_layer/guides/6_local_setup.md @@ -1,4 +1,6 @@ -# Aligned Infrastructure Deployment Guide +# Running the Proof Aggregation Layer locally + +This guide walks through running Aligned's Proof Aggregation Service locally: the Gateway that receives proofs, the Payments Poller that credits deposits, and the Proof Aggregator that aggregates proofs and settles them on-chain. ## Dependencies diff --git a/docs/2_proof_aggregation_layer/guides/7_contract_addresses.md b/docs/2_proof_aggregation_layer/guides/7_contract_addresses.md new file mode 100644 index 0000000000..7b80721af2 --- /dev/null +++ b/docs/2_proof_aggregation_layer/guides/7_contract_addresses.md @@ -0,0 +1,40 @@ +# Aligned contract addresses + +The contracts below back Aligned's Proof Aggregation Service. + +- `AlignedProofAggregationService` — receives aggregated proofs and answers proof inclusion checks. +- `AggregationModePaymentService` — receives deposits that fund your proof submission quota. + +## Mainnet Deployments + +| Contract | Address | +|--------------------------------|-----------------------------------------------------------------------------------------------------------------------| +| AlignedProofAggregationService | [0xD0696d3eEebffcAB2D1b358805efAA005A9A8BC0](https://etherscan.io/address/0xD0696d3eEebffcAB2D1b358805efAA005A9A8BC0) | +| AggregationModePaymentService | [0xc8631Bc1E60c20db40e474F791126212fA8255F4](https://etherscan.io/address/0xc8631Bc1E60c20db40e474F791126212fA8255F4) | + +## Hoodi Deployments + +| Contract | Address | +|--------------------------------|-----------------------------------------------------------------------------------------------------------------------------| +| AlignedProofAggregationService | [0x6B34AAaE780A5EAB4c91AB8F54f2a421E9c2FB59](https://hoodi.etherscan.io/address/0x6B34AAaE780A5EAB4c91AB8F54f2a421E9c2FB59) | +| AggregationModePaymentService | [0xe6C9D0cf87cdaA8B2093c4b3830dde7267843F64](https://hoodi.etherscan.io/address/0xe6C9D0cf87cdaA8B2093c4b3830dde7267843F64) | + +## Sepolia Deployments + +| Contract | Address | +|--------------------------------|-------------------------------------------------------------------------------------------------------------------------------| +| AlignedProofAggregationService | [0xb5D46304c30B1AeB3a8Da6ab599c336f7946C8A4](https://sepolia.etherscan.io/address/0xb5D46304c30B1AeB3a8Da6ab599c336f7946C8A4) | + +{% hint style="warning" %} +The CLI and SDK do not support Sepolia. The `--network` option accepts `devnet`, `hoodi` and `mainnet` only, and there is no Aggregation Mode Gateway deployed for Sepolia. +{% endhint %} + +## Gateway URLs + +Proofs are submitted to the Aggregation Mode Gateway. The CLI and SDK pick the right URL from the `--network` option, so you normally do not need these directly. + +| Network | Gateway URL | +|---------|--------------------------------------------| +| Mainnet | `https://mainnet.gateway.alignedlayer.com` | +| Hoodi | `https://hoodi.gateway.alignedlayer.com` | +| Devnet | `http://127.0.0.1:8089` | diff --git a/docs/3_guides/4_generating_proofs.md b/docs/3_guides/4_generating_proofs.md deleted file mode 100644 index 10ffd69769..0000000000 --- a/docs/3_guides/4_generating_proofs.md +++ /dev/null @@ -1,308 +0,0 @@ -# Generating Proofs For Aligned - -## SP1 - -### Dependencies - -This guide assumes that: - -- sp1 prover installed (instructions [here](https://docs.succinct.xyz/docs/sp1/getting-started/install)) -- sp1 project to generate the proofs - (instructions [here](https://docs.succinct.xyz/docs/sp1/getting-started/quickstart)) -- aligned installed (instructions [here](../1_introduction/1_try_aligned.md#quickstart)) - -### How to generate a proof - -> Aligned only verifies SP1 in a compressed version. -> You can check you are using compressed by opening script/src/main.rs -> and check that the proof is generated with `client.prove_compressed` instead of `client.prove`. - -First, open a terminal and navigate to the script folder in the sp1 project directory - -Then, run the following command to generate a proof: - -```bash -cargo run --release -``` - -### How to get the proof verified by Aligned - -After generating the proof, you will have to find two different files: - -- **proof file**: usually found under `script` directory, with the name `proof.json` or similar -- **elf file**: usually found under `program/elf/` directory - -Then, you can send the proof to the Aligned network by running the following command - -```bash -aligned submit \ ---proving_system SP1 \ ---proof \ ---vm_program \ ---batcher_url wss://batcher.alignedlayer.com \ ---proof_generator_addr \ ---rpc_url https://ethereum-hoodi-rpc.publicnode.com -``` - -Where `proof_path` is the path to the proof file, `vm_program_path` is the path to the ELF file. `proof_generator_addr` is an optional parameter that works as a helper for some applications where you can be frontrunned. - -For more instructions on how to submit proofs, check the [Submitting proofs guide](../3_guides/0_submitting_proofs.md). - -## Gnark - -### Dependencies - -This guide assumes that: - -- Gnark library is installed. If not, install it using the following command inside your Go module: - - ```bash - go get github.com/consensys/gnark@v0.12.0 - ``` - -- Gnark project to generate the proofs' instructions [here](https://docs.gnark.consensys.io/category/how-to) - -### How to generate a proof - -Open a terminal and navigate to the Gnark project directory. Then, run the following command to generate the proof: - - ```bash - go run circuit.go - ``` - -### How to get the proof verified by Aligned - -After generating the proof, you will have to have three different files: - -- proof file -- verification key file -- public input file - -For a detailed guide on how to generate those files, refer to our [detailed guide](3.2_generate_gnark_proof.md). - -Then, you can send the proof to the Aligned network by running the following command - -```bash -aligned submit \ ---proving_system GnarkPlonkBn254 \ ---proof \ ---public_input ---vk \ ---batcher_url wss://batcher.alignedlayer.com \ ---proof_generator_addr \ ---rpc_url https://ethereum-hoodi-rpc.publicnode.com -``` - -Where proof path is the path to the proof file, `public_input_path` is the path to the public input file, -and `verification_key_path` is the path to the verification key file. - -For more instructions on how to submit proofs, check the [Submitting proofs guide](../3_guides/0_submitting_proofs.md). - -## Risc0 - -### Dependencies - -This guide assumes that: - -- Risc0 toolchain installed (instructions [here](https://dev.risczero.com/api/zkvm/quickstart#1-install-the-risc-zero-toolchain)) -- Risc0 project to generate the proofs (instructions [here](https://dev.risczero.com/api/zkvm/quickstart#2-create-a-new-project)) -- Aligned installed (instructions [here](../1_introduction/1_try_aligned.md#quickstart)) - -### How to generate a proof - -First, open the risc0 host file and add the following code to export proof, image id & public input needed by Aligned. - -```rust -fn main() { - // your code here - - // is the path where the proof will be saved - // Note that we serialize receipt.inner to avoid serializing the public inputs along with the proof - let serialized = bincode::serialize(&receipt.inner).expect("Failed to serialize the receipt"); - std::fs::write(" is the method id of the function you want to prove - // is the path where the method id will be saved - std::fs::write("", convert(&)) - .expect("Failed to write method_id file"); - - // is the path where the public input will be saved - std::fs::write("", receipt.journal.bytes) - .expect("Failed to write pub_input file"); -} - - -// Convert u32 array to u8 array for storage -pub fn convert(data: &[u32; 8]) -> [u8; 32] { - let mut res = [0; 32]; - for i in 0..8 { - res[4 * i..4 * (i + 1)].copy_from_slice(&data[i].to_le_bytes()); - } - res -} -``` - -Note that METHOD_ID will be imported from guest, but it will be under a different name. - -Then run the following command to generate the proof: - -```bash -cargo run --release -``` - -### How to get the proof verified by Aligned - -After generating the proof, you will have to find three different files: - -- Proof file -- Image id file -- Public input file - -Then, you can send the proof to the Aligned network by running the following command - -```bash -aligned submit \ - --proving_system Risc0 \ - --proof \ - --vm_program \ - --public_input \ - --batcher_url wss://batcher.alignedlayer.com \ - --proof_generator_addr \ - --rpc_url https://ethereum-hoodi-rpc.publicnode.com \ - --payment_service_addr 0x815aeCA64a974297942D2Bbf034ABEe22a38A003 -``` - -For more instructions on how to submit proofs, check the [Submitting proofs guide](../3_guides/0_submitting_proofs.md). - -## ZkRust - -`zkRust` is a CLI tool maintained by Aligned that aims to simplify the developing applications in Rust using zkVM's such as SP1 or Risc0. - -zkRust can be installed directly by downloading the latest release binaries: - -```sh -curl -L https://raw.githubusercontent.com/yetanotherco/zkRust/main/install_zkrust.sh | bash -``` - -Then, to get started you can create a workspace for your project in zkRust by running: - -```sh -cargo new -``` - -It is that simple. - -## Usage - -To use zkRust, users specify a `fn main()` whose execution is proven within the zkVM. This function must be defined in a `main.rs` file in a directory with the following structure: - -``` -. -└── - ├── Cargo.toml - └── src - └── main.rs -``` - -For using more complex programs you can import a separate lib/ crate into the `PROGRAM_DIRECTORY` - -``` -. -└── - ├── Cargo.toml - ├── lib/ - └── src - └── lib -``` - -### Inputs and Outputs - -The user may also define a `input()` and `output()` functions in addition to `main()`, that define code that runs outside of the zkVM, before and after the VM executes - -- The `input()` function executes before the zkVM code is executed and allows the user to define inputs passed to the vm such as a deserialized Tx or data fetched from an external source at runtime. -- Within the `main()` (guest) function the user may write information from the computation performed in the zkVM to an output buffer to be used after proof generation. -- The `output()` defines code that allows the user to read the information written to that buffer of the and perform post-processing of that data. - -The user may specify inputs into the VM (guest) code using `zk_rust_io::write()` as long on the type of rust object they are writing implements `Serializable`. - -Within the `main()` function (guest) the user may read in the inputs by specifying `zk_rust_io::read()` and output data computed during the execution phase of the code within the VM (guest) program by specifying `zk_rust_io::commit()`. - -To read the output of the output of the VM (guest) program you declare `zk_rust_io::out()`. The `zk_rust_io` crate defines function headers that are not inlined and are purely used as compile time symbols to ensure a user can compile their rust code before running it within one of the zkVMs available in zkRust. - -To use the I/O imports import the `zk_rust_io` crate by adding the following to the `Cargo.toml` in your project directory. - -```sh -zk_rust_io = { git = "https://github.com/yetanotherco/zkRust.git", version = "v0.1.0" } -``` - -## Example - -### input.rs - -```rust -use zk_rust_io; - -pub fn input() { - let pattern = "a+".to_string(); - let target_string = "an era of truth, not trust".to_string(); - - // Write in a simple regex pattern. - zk_rust_io::write(&pattern); - zk_rust_io::write(&target_string); -} -``` - -### main.rs - -```rust -use regex::Regex; -use zk_rust_io; - -pub fn main() { - // Read two inputs from the prover: a regex pattern and a target string. - let pattern: String = zk_rust_io::read(); - let target_string: String = zk_rust_io::read(); - - // Try to compile the regex pattern. If it fails, write `false` as output and return. - let regex = match Regex::new(&pattern) { - Ok(regex) => regex, - Err(_) => { - panic!("Invalid regex pattern"); - } - }; - - // Perform the regex search on the target string. - let result = regex.is_match(&target_string); - - // Write the result (true or false) to the output. - zk_rust_io::commit(&result); -} -``` - -### output.rs - -```rust -use zk_rust_io; - -pub fn output() { - // Read the output. - let res: bool = zk_rust_io::out(); - println!("res: {}", res); -} -``` - -To generate a proof of the execution of your code run the following: - -- **Sp1**: - -```sh - cargo run --release -- prove-sp1 . -``` - -- **Risc0**: - ```sh - cargo run --release -- prove-risc0 . - ``` - Make sure to have [Risc0](https://dev.risczero.com/api/zkvm/quickstart#1-install-the-risc-zero-toolchain) installed with version `v3.0.3`. Running Risc0 on macOS enable [metal](https://developer.apple.com/metal/) acceleration by default and may need to be installed it needed. - -For additional information on using zkRust and using it to submit proofs to Aligned see the [zkRust](https://github.com/yetanotherco/zkRust) Github Repository. diff --git a/docs/2_architecture/3_raas_platform.md b/docs/3_raas/1_raas_platform.md similarity index 92% rename from docs/2_architecture/3_raas_platform.md rename to docs/3_raas/1_raas_platform.md index d2e34a89eb..9bc094c17c 100644 --- a/docs/2_architecture/3_raas_platform.md +++ b/docs/3_raas/1_raas_platform.md @@ -1,10 +1,10 @@ -# Rollup-as-a-Service (RaaS) platform +# Rollup as a Service (RaaS) platform Aligned's RaaS platform integrates RISC-V zkVMs, the new [Ethrex execution client](https://github.com/lambdaclass/ethrex), and our ZK Verification Layer to offer fast, reliable, and secure one-click ZK-rollup deployment — including full support for based rollups — making it as simple as launching a Web2 service. Our RaaS platform will be integrated with our upcoming products to give developers all the tools they need to operate a complete ecosystem: wallet-as-a-service infrastructure for simplified onboarding, meta-proving services that give users access to provers provided by Aligned or other third-party centralized or decentralized proving services, and our interoperability protocol for efficient cross-chain liquidity access. -![Figure 1: Aligned Suite of Products](../images/zk_rollups_and_aligned.png) +![Figure 1: Aligned Suite of Products](../images/aligned_suite_of_products.png) ## What advantages will Aligned's RaaS platform offer for your project? @@ -39,6 +39,6 @@ Based rollups benefit from reduced operating costs as they don’t require opera ## How do ZK-rollups use Aligned’s ZK Verification Layer? -A simplified version of this process can be found in Figure 2. Proofs for batches of rollup transactions (blocks) are sent to Aligned’s ZK Verification Layer (the Proof Aggregation Service, used with or without the Proof Verification Layer), which converts them into one proof that is verified on Aligned's L1 contract. +A simplified version of this process can be found in Figure 2. Proofs for batches of rollup transactions (blocks) are sent to Aligned’s ZK Verification Layer (the Proof Aggregation Service), which converts them into one proof that is verified on Aligned's L1 contract. -![Figure 2: ZK-rollups and the role of Aligned](../images/zkrollups_and_the_role_of_aligned.png) +![Figure 2: ZK-rollups and the role of Aligned](../images/zk_rollups_and_aligned.png) diff --git a/docs/SUMMARY.md b/docs/SUMMARY.md index 70d3dc0eff..e130d8aa63 100644 --- a/docs/SUMMARY.md +++ b/docs/SUMMARY.md @@ -3,69 +3,32 @@ ## Introduction * [About Aligned](1_introduction/0_about_aligned.md) -* [Try Aligned](1_introduction/1_try_aligned.md) -* [Use cases](1_introduction/2_use_cases.md) -* [FAQ](1_introduction/3_faq.md) -* [Why ZK and Aligned?](1_introduction/4_why_zk.md) - -## Architecture - -* [Supported Verifiers](2_architecture/0_supported_verifiers.md) -* [Key Terms](2_architecture/0b_key_terms.md) -* [Proof Verification Layer](2_architecture/1_proof_verification_layer.md) - * [Batcher](./2_architecture/components/1_batcher.md) - * [Payment Service Contract](./2_architecture/components/2_payment_service_contract.md) - * [Service Manager Contract](./2_architecture/components/3_service_manager_contract.md) - * [Operator](./2_architecture/components/4_operator.md) - * [Aggregator](./2_architecture/components/5_aggregator.md) - * [Explorer](./2_architecture/components/6_explorer.md) -* [Proof Aggregation Service](2_architecture/2_aggregation_mode.md) - * [Deep Dive](2_architecture/agg_mode_components/1_deep_dive.md) -* [Rollup-as-a-Service Platform](2_architecture/3_raas_platform.md) - -## Guides - -* [Submitting proofs](3_guides/0_submitting_proofs.md) -* [Build your first Aligned Application](3_guides/2_build_your_first_aligned_application.md) - * [Modify ZkQuiz Questions](3_guides/2.2_modify_zkquiz_questions.md) -* [Validating public input](3_guides/3_validating_public_input.md) -* [Proof Aggregation Service](3_guides/3.1_aggregation_mode.md) -* [SDK Intro](3_guides/1_SDK_how_to.md) -* [Verification Layer SDK](3_guides/1.2_SDK_api_reference.md) -* [Aggregation Mode SDK](3_guides/1.3_SDK_api_reference_aggregation.md) -* [Generating proofs for Aligned](3_guides/4_generating_proofs.md) -* [Generating & submitting proofs of Rust code with ZKRust](3_guides/5_using_zkrust.md) -* [Setup Aligned Infrastructure Locally](3_guides/6_setup_aligned.md) -* [Setup Aligned Agg Mode Infrastructure Locally](3_guides/7_setup_aligned_agg_mode.md) -* [Contract Addresses](3_guides/8_contract_addresses.md) -* [Submitting Batch Without Batcher](3_guides/9_submitting_batch_without_batcher.md) -* [Verification Layer CLI](3_guides/10_aligned_cli.md) -* [Aggregation Mode CLI](3_guides/10.1_aggregation_mode_cli.md) - -## Operators - -* [Running an operator](operator_guides/0_running_an_operator.md) -* [Operator FAQ](operator_guides/1_operator_FAQ.md) -* [Troubleshooting](operator_guides/2_troubleshooting.md) -* Upgrading Guides - * [Upgrading to v0.14.0](operator_guides/upgrading_guides/v0_14_0.md) - * [Upgrading to v0.10.2](operator_guides/upgrading_guides/v0_10_2.md) - * [Upgrading to v0.9.2](operator_guides/upgrading_guides/v0_9_2.md) - -## Useful links - -* [Mainnet Explorer](https://explorer.alignedlayer.com) -* [Sepolia Explorer](https://sepolia.explorer.alignedlayer.com) -* [Hoodi Explorer](https://hoodi.explorer.alignedlayer.com) -* [All the proof aggregation solutions will use RISC-V zkVMs](https://blog.alignedlayer.com/all-the-proof-aggregation-solutions-will-use-risc-v-zkvms/) -* [Manifesto](https://blog.alignedlayer.com/aligned-manifesto/) - -## Socials - -* [Telegram Group](https://t.me/aligned_layer) -* [Twitter/X](https://x.com/alignedlayer) -* [Discord](https://discord.gg/alignedlayer) -* [Blog](https://blog.alignedlayer.com) +* [Use cases](1_introduction/1_use_cases.md) +* [FAQ](1_introduction/2_faq.md) +* [Why ZK and Aligned?](1_introduction/3_why_zk.md) * [Website](https://alignedlayer.com) -* [Github](https://github.com/yetanotherco/aligned_layer) -* [YouTube](https://www.youtube.com/@alignedlayer) + +## Proof Aggregation Layer + +* Architecture + * [Overview](2_proof_aggregation_layer/architecture/1_overview.md) + * [Deep Dive](2_proof_aggregation_layer/architecture/2_deep_dive.md) + * [Explorer](2_proof_aggregation_layer/architecture/3_explorer.md) + * [Supported Verifiers](2_proof_aggregation_layer/architecture/4_supported_verifiers.md) + * [Key Terms](2_proof_aggregation_layer/architecture/5_key_terms.md) +* Guides + * [Quickstart](2_proof_aggregation_layer/guides/1_quickstart.md) + * [Generating proofs](2_proof_aggregation_layer/guides/2_generating_proofs.md) + * [CLI](2_proof_aggregation_layer/guides/3_cli.md) + * [SDK](2_proof_aggregation_layer/guides/4_sdk.md) + * [Integration example](2_proof_aggregation_layer/guides/5_integration_example.md) + * [Running it locally](2_proof_aggregation_layer/guides/6_local_setup.md) + * [Contract Addresses](2_proof_aggregation_layer/guides/7_contract_addresses.md) +* Explorers + * [Mainnet Explorer](https://explorer.alignedlayer.com) + * [Sepolia Explorer](https://sepolia.explorer.alignedlayer.com) + * [Hoodi Explorer](https://hoodi.explorer.alignedlayer.com) + +## Rollup as a Service + +* [RaaS Platform](3_raas/1_raas_platform.md) diff --git a/docs/1_introduction/2_example_quiz_app.md b/docs/archive/1_introduction/2_example_quiz_app.md similarity index 85% rename from docs/1_introduction/2_example_quiz_app.md rename to docs/archive/1_introduction/2_example_quiz_app.md index 1edc29e186..2d231ec026 100644 --- a/docs/1_introduction/2_example_quiz_app.md +++ b/docs/archive/1_introduction/2_example_quiz_app.md @@ -1,5 +1,9 @@ # ZK Quiz +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + ## Introduction This program leverages Aligned's ZK verification infrastructure to run a small quiz. The proof allows any party to check that the quiz was answered right or wrong. If answered correctly, the user receives an NFT. diff --git a/docs/2_architecture/1_proof_verification_layer.md b/docs/archive/2_architecture/1_proof_verification_layer.md similarity index 95% rename from docs/2_architecture/1_proof_verification_layer.md rename to docs/archive/2_architecture/1_proof_verification_layer.md index 2d6c670734..61a986e23c 100644 --- a/docs/2_architecture/1_proof_verification_layer.md +++ b/docs/archive/2_architecture/1_proof_verification_layer.md @@ -1,5 +1,9 @@ ## Aligned's Proof Verification Layer in a nutshell +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + Aligned's Proof Verification Layer works using a subset of Ethereum’s validators via restaking. Validators (also called Operators) receive proofs, verify them using the verification code written in Rust or another higher-level language, and sign messages with BLS signatures. diff --git a/docs/2_architecture/components/1_batcher.md b/docs/archive/2_architecture/components/1_batcher.md similarity index 96% rename from docs/2_architecture/components/1_batcher.md rename to docs/archive/2_architecture/components/1_batcher.md index fbcb24c4bd..21486329d7 100644 --- a/docs/2_architecture/components/1_batcher.md +++ b/docs/archive/2_architecture/components/1_batcher.md @@ -1,5 +1,9 @@ # Batcher +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../../2_proof_aggregation_layer/architecture/1_overview.md). + The Batcher receives proofs from different Users, bundles them in a batch of proofs, builds a Merkle Root from these, uploads the batch to a data service (like an S3 bucket), and submits this information to the [Aligned Service Manager](./3_service_manager_contract.md). To ensure that the User can be certain that their proof was included in a batch, the Batcher will send each User their Merkle Proof (or Merkle Path). With this, the User can rebuild the Merkle Root starting from their proof, thus verifying it was actually included in the batch. @@ -10,7 +14,7 @@ However, each proof has a cost of verification, so each batch must contain some To send the batch of proofs to the [Aligned Service Manager](./3_service_manager_contract.md), the Batcher stores the batch of proofs in an S3 for 1 week, and sends the link to the file to the [Aligned Service Manager](./3_service_manager_contract.md). -To view how to submit your own batch, without the use of this Batcher, you may follow [the following guide](../../3_guides/8_submitting_batch_without_batcher.md) +To view how to submit your own batch, without the use of this Batcher, you may follow [the following guide](../../3_guides/9_submitting_batch_without_batcher.md) ### Max fee priority queue diff --git a/docs/2_architecture/components/2_payment_service_contract.md b/docs/archive/2_architecture/components/2_payment_service_contract.md similarity index 93% rename from docs/2_architecture/components/2_payment_service_contract.md rename to docs/archive/2_architecture/components/2_payment_service_contract.md index c54921dcda..0293e23aff 100644 --- a/docs/2_architecture/components/2_payment_service_contract.md +++ b/docs/archive/2_architecture/components/2_payment_service_contract.md @@ -1,5 +1,9 @@ # Payment Service +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../../2_proof_aggregation_layer/architecture/1_overview.md). + The Payment Service handles users payments to fund the verification of their proofs. To be able to use the batcher, a user must fund its transactions. diff --git a/docs/2_architecture/components/3_service_manager_contract.md b/docs/archive/2_architecture/components/3_service_manager_contract.md similarity index 89% rename from docs/2_architecture/components/3_service_manager_contract.md rename to docs/archive/2_architecture/components/3_service_manager_contract.md index ef4b74e77f..40835ce498 100644 --- a/docs/2_architecture/components/3_service_manager_contract.md +++ b/docs/archive/2_architecture/components/3_service_manager_contract.md @@ -1,5 +1,9 @@ # Aligned Service Manager Contract +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../../2_proof_aggregation_layer/architecture/1_overview.md). + The Aligned Service Manager handles the reception of new batches to Aligned, keeps their status on-chain, and receives their response. It is a smart contract which receives all new batches, with their Merkle Root and a pointer to where the batch is currently stored. When received, this manager will emit an Event for the [Operators](./4_operator.md) to know when there is a new batch to verify. @@ -10,7 +14,7 @@ Once verified, it will emit another Event, for anyone interested (for example, t ## Details of the contract -Besides the base [EigenLayer middleware contracts](https://github.com/Layr-Labs/eigenlayer-middleware/tree/mainnet/src), the core contract for Aligned is [AlignedLayerServiceManager](../../../contracts/src/core/AlignedLayerServiceManager.sol). It is in charge of creating new batch verification tasks, storing batches state and verifying operator responses. +Besides the base [EigenLayer middleware contracts](https://github.com/Layr-Labs/eigenlayer-middleware/tree/mainnet/src), the core contract for Aligned is [AlignedLayerServiceManager](../../../../contracts/src/core/AlignedLayerServiceManager.sol). It is in charge of creating new batch verification tasks, storing batches state and verifying operator responses. ### API diff --git a/docs/2_architecture/components/4_operator.md b/docs/archive/2_architecture/components/4_operator.md similarity index 82% rename from docs/2_architecture/components/4_operator.md rename to docs/archive/2_architecture/components/4_operator.md index 2f3170343d..d046532d5e 100644 --- a/docs/2_architecture/components/4_operator.md +++ b/docs/archive/2_architecture/components/4_operator.md @@ -1,5 +1,9 @@ # Operator +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../../2_proof_aggregation_layer/architecture/1_overview.md). + The Operators verify the ZK Proofs and are the Eigenlayer restakers. They also insert financial security into the system, and leverage Ethereum's security for any AVS they take part in (e.g. Aligned). Operators read [Aligned Service Manager](./3_service_manager_contract.md)'s new batch events. These have the necessary information to verify a batch, its Merkle Root, and its data pointer. diff --git a/docs/2_architecture/components/5_aggregator.md b/docs/archive/2_architecture/components/5_aggregator.md similarity index 50% rename from docs/2_architecture/components/5_aggregator.md rename to docs/archive/2_architecture/components/5_aggregator.md index 0e0c561c66..816ffc6ac5 100644 --- a/docs/2_architecture/components/5_aggregator.md +++ b/docs/archive/2_architecture/components/5_aggregator.md @@ -1,5 +1,9 @@ # Aggregator +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../../2_proof_aggregation_layer/architecture/1_overview.md). + The Aggregator collects [Operator](./4_operator.md)'s BLS Signatures. When the quorum of responses is reached, the Aggregator will submit a Task Response with the aggregated signatures back to the [Aligned Service Manager](./3_service_manager_contract.md). diff --git a/docs/2_architecture/components/6_explorer.md b/docs/archive/2_architecture/components/6_explorer.md similarity index 93% rename from docs/2_architecture/components/6_explorer.md rename to docs/archive/2_architecture/components/6_explorer.md index 41670815b5..e5d35aefdf 100644 --- a/docs/2_architecture/components/6_explorer.md +++ b/docs/archive/2_architecture/components/6_explorer.md @@ -1,5 +1,9 @@ # Explorer +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../../2_proof_aggregation_layer/architecture/1_overview.md). + {% embed url="https://explorer.alignedlayer.com" %} The Explorer keeps track of [Aligned Service Manager](./3_service_manager_contract.md). diff --git a/docs/3_guides/0_submitting_proofs.md b/docs/archive/3_guides/0_submitting_proofs.md similarity index 96% rename from docs/3_guides/0_submitting_proofs.md rename to docs/archive/3_guides/0_submitting_proofs.md index 3d4d5b3dc8..fb0d2d4bb8 100644 --- a/docs/3_guides/0_submitting_proofs.md +++ b/docs/archive/3_guides/0_submitting_proofs.md @@ -1,6 +1,10 @@ # Submitting Proofs -Make sure you have Aligned installed as specified [here](../1_introduction/1_try_aligned.md#quickstart). +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + +Make sure you have Aligned installed as specified [here](../../2_proof_aggregation_layer/guides/1_quickstart.md#quickstart). If you run the examples below, make sure you are in Aligned's repository root. @@ -18,7 +22,7 @@ The following is the list of the verifiers currently supported by Aligned: - :white_check_mark: Mina (Testnet only - Sepolia, Hoodi) - :white_check_mark: Mina Account (Testnet only - Sepolia, Hoodi) -Learn more about future verifiers [here](../2_architecture/0_supported_verifiers.md). +Learn more about future verifiers [here](../../2_proof_aggregation_layer/architecture/4_supported_verifiers.md). ## 1. Import/Create Keystore file diff --git a/docs/3_guides/1.2_SDK_api_reference.md b/docs/archive/3_guides/1.2_SDK_api_reference.md similarity index 98% rename from docs/3_guides/1.2_SDK_api_reference.md rename to docs/archive/3_guides/1.2_SDK_api_reference.md index c6b51ba8f3..a424c44871 100644 --- a/docs/3_guides/1.2_SDK_api_reference.md +++ b/docs/archive/3_guides/1.2_SDK_api_reference.md @@ -1,5 +1,9 @@ # Aligned SDK +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + ## API Reference ### `submit` diff --git a/docs/3_guides/10_aligned_cli.md b/docs/archive/3_guides/10_aligned_cli.md similarity index 98% rename from docs/3_guides/10_aligned_cli.md rename to docs/archive/3_guides/10_aligned_cli.md index c9d14bf2e5..d50aa75fed 100644 --- a/docs/3_guides/10_aligned_cli.md +++ b/docs/archive/3_guides/10_aligned_cli.md @@ -1,5 +1,9 @@ # Aligned CLI Documentation +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + The Aligned CLI serves as an interface for users to interact with Aligned Layer. This document serves as a reference for the commands of the Aligned CLI. diff --git a/docs/3_guides/1_SDK_how_to.md b/docs/archive/3_guides/1_SDK_how_to.md similarity index 90% rename from docs/3_guides/1_SDK_how_to.md rename to docs/archive/3_guides/1_SDK_how_to.md index 7926150938..d3726083da 100644 --- a/docs/3_guides/1_SDK_how_to.md +++ b/docs/archive/3_guides/1_SDK_how_to.md @@ -1,10 +1,14 @@ # Aligned SDK +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + The Aligned SDK aims to help developers interact with Aligned in a simple way. Using the Aligned SDK, you can do things like submitting and verifying proofs through the Aligned Batcher, as well as checking the inclusion of the verified proofs on-chain. This guide provides an overview of the SDK, its installation, usage, and API details. -You can check the list of supported verifiers [here](../2_architecture/0_supported_verifiers.md). +You can check the list of supported verifiers [here](../../2_proof_aggregation_layer/architecture/4_supported_verifiers.md). ## Installation diff --git a/docs/3_guides/2.2_modify_zkquiz_questions.md b/docs/archive/3_guides/2.2_modify_zkquiz_questions.md similarity index 93% rename from docs/3_guides/2.2_modify_zkquiz_questions.md rename to docs/archive/3_guides/2.2_modify_zkquiz_questions.md index 74fd7924a2..94e95466aa 100644 --- a/docs/3_guides/2.2_modify_zkquiz_questions.md +++ b/docs/archive/3_guides/2.2_modify_zkquiz_questions.md @@ -1,5 +1,9 @@ # Modify ZkQuiz Questions +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + In [Build your first Aligned Application](2_build_your_first_aligned_application.md), we show how to build a trivia application, called ZkQuiz. ZKQuiz asks the user three questions, and if answered correctly, generates a ZK Proof of the correct answers, posts the proof on Aligned, and upon verification, mints an NFT via a smart contract. In this guide, we will show you how to replace those questions with your own custom ones. diff --git a/docs/3_guides/2_build_your_first_aligned_application.md b/docs/archive/3_guides/2_build_your_first_aligned_application.md similarity index 94% rename from docs/3_guides/2_build_your_first_aligned_application.md rename to docs/archive/3_guides/2_build_your_first_aligned_application.md index 1c96a13b0a..9c8cc0a27b 100644 --- a/docs/3_guides/2_build_your_first_aligned_application.md +++ b/docs/archive/3_guides/2_build_your_first_aligned_application.md @@ -1,5 +1,9 @@ # Build your first Application +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + In this guide you will learn how to build applications on top of Aligned. It provides a few simple steps to help you verify ZK proofs generated within your system. First we will show you an example of a trivia application, called ZkQuiz. We'll show you the different components and how they interact with each other to be able to submit the proof to aligned and verify that was correctly included in a batch. @@ -81,7 +85,7 @@ This will: ## Deep dive -The ZkQuiz source code is available [here](../../examples/zkquiz). +The ZkQuiz source code is available [here](../../../examples/zkquiz). ZkQuiz has three main components: @@ -92,7 +96,7 @@ ZkQuiz has three main components: The user interacts with ZkQuiz App to solve a trivia challenge answering questions. Then, the App generates a Zk Proof with the Program generated using SP1. {% hint style="info" %} -The ZkQuiz Program is built using SP1 following the [quickstart guide](https://docs.succinct.xyz/docs/sp1/getting-started/quickstart). For your projects, you can user any of the [prooving systems supported by Aligned](../2_architecture/0_supported_verifiers.md). +The ZkQuiz Program is built using SP1 following the [quickstart guide](https://docs.succinct.xyz/docs/sp1/getting-started/quickstart). For your projects, you can user any of the [prooving systems supported by Aligned](../../2_proof_aggregation_layer/architecture/4_supported_verifiers.md). {% endhint %} Once the proof is generated, the App sends the proof to Aligned, and once it is verified, the App calls to the ZkQuiz Verifier Contract to check the proof verification and send an NFT to the user is the proof was verified in Aligned. @@ -300,4 +304,4 @@ claim_nft_with_verified_proof( .expect("Claiming of NFT failed ..."); ``` -You can find the full code of the proof submission and verification in the [ZKQuiz App](../../examples/zkquiz/quiz/script/src/main.rs). +You can find the full code of the proof submission and verification in the [ZKQuiz App](../../../examples/zkquiz/quiz/script/src/main.rs). diff --git a/docs/3_guides/3.2_generate_gnark_proof.md b/docs/archive/3_guides/3.2_generate_gnark_proof.md similarity index 97% rename from docs/3_guides/3.2_generate_gnark_proof.md rename to docs/archive/3_guides/3.2_generate_gnark_proof.md index a92f1e82fe..00ac1c255d 100644 --- a/docs/3_guides/3.2_generate_gnark_proof.md +++ b/docs/archive/3_guides/3.2_generate_gnark_proof.md @@ -1,5 +1,9 @@ # How to create a Gnark Plonk proof +> **Archived.** Gnark proofs cannot be submitted to Aligned's Proof Aggregation +> Service, which currently accepts SP1 compressed proofs only. This page is kept +> for reference. See [Generating proofs for Aligned](../../2_proof_aggregation_layer/guides/2_generating_proofs.md). + ## Step 1: Set up your environment - 1 Install Go: Make sure you have Go installed. You can download it from [here](https://go.dev/doc/install) diff --git a/docs/3_guides/3_validating_public_input.md b/docs/archive/3_guides/3_validating_public_input.md similarity index 97% rename from docs/3_guides/3_validating_public_input.md rename to docs/archive/3_guides/3_validating_public_input.md index 28a1871962..66d7c11f63 100644 --- a/docs/3_guides/3_validating_public_input.md +++ b/docs/archive/3_guides/3_validating_public_input.md @@ -1,5 +1,9 @@ # Validating public input +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + In some applications, it is crucial to ensure that a third party has performed a computation correctly and to make use of the result of that computation. To achieve this, the third party must interact with Aligned, using the Aligned SDK, to obtain the `AlignedVerificationData`, a receipt indicating that the proof of the computation was verified correctly. The application should then receive both the `AlignedVerificationData` and the result of the computation. After confirming that the proof was verified by Aligned, it must check that the posted result matches the one committed in the `AlignedVerificationData`. This guide demonstrates how to validate Risc0 and SP1 proofs using the Aligned SDK. The program in this example is a Fibonacci sequence calculator. It generates a public input that corresponds to the number of fibonacci being calculated and the last two Fibonacci numbers of the sequence, taken modulo 7919. Our goal is to validate, within a smart contract, that the public input commitments match these numbers. @@ -33,7 +37,7 @@ For `SP1`, the Fibonacci program is located in `examples/validating-public-input To submit proofs to **Aligned** and get them verified, you first need to generate those proofs. Every proving system has its own method for generating proofs. -Examples on how to generate proofs can be found in the [generating proofs guide](4_generating_proofs.md). +Examples on how to generate proofs can be found in the [generating proofs guide](../../2_proof_aggregation_layer/guides/2_generating_proofs.md). To generate the proof required for this example, run the following commands: diff --git a/docs/3_guides/5_using_zkrust.md b/docs/archive/3_guides/5_using_zkrust.md similarity index 92% rename from docs/3_guides/5_using_zkrust.md rename to docs/archive/3_guides/5_using_zkrust.md index 9f7c27ca3e..4b05ffe883 100644 --- a/docs/3_guides/5_using_zkrust.md +++ b/docs/archive/3_guides/5_using_zkrust.md @@ -1,5 +1,9 @@ # Generating & submitting proofs to Aligned using zkRust +> **Archived.** This guide submits proofs through the deprecated Aligned +> Verification Layer (`zkrust --submit-to-aligned`). It is kept for reference. +> See [Generating proofs for Aligned](../../2_proof_aggregation_layer/guides/2_generating_proofs.md). + [zkRust](https://github.com/yetanotherco/zkRust) is a CLI tool to generate proofs of your rust code using a RISCV-zkVM's and submit them to Aligned to be verified with only one command. The following provers are supported: diff --git a/docs/3_guides/6_setup_aligned.md b/docs/archive/3_guides/6_setup_aligned.md similarity index 96% rename from docs/3_guides/6_setup_aligned.md rename to docs/archive/3_guides/6_setup_aligned.md index 8c3f822532..a99bf307cb 100644 --- a/docs/3_guides/6_setup_aligned.md +++ b/docs/archive/3_guides/6_setup_aligned.md @@ -1,5 +1,9 @@ # Aligned Infrastructure Deployment Guide +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + ## Dependencies Ensure you have the following installed: diff --git a/docs/3_guides/8_contract_addresses.md b/docs/archive/3_guides/8_contract_addresses.md similarity index 80% rename from docs/3_guides/8_contract_addresses.md rename to docs/archive/3_guides/8_contract_addresses.md index 4cfc4fe9fd..9bb077aa94 100644 --- a/docs/3_guides/8_contract_addresses.md +++ b/docs/archive/3_guides/8_contract_addresses.md @@ -1,4 +1,11 @@ -# Aligned contract addresses +# Verification Layer contract addresses + +> **Deprecated.** The Aligned Verification Layer is no longer active. These +> addresses are kept for historical reference, and for the archived +> [operator guides](../operator_guides/0_running_an_operator.md). +> +> For the Proof Aggregation Service addresses, see +> [Contract Addresses](../../2_proof_aggregation_layer/guides/7_contract_addresses.md). ## Mainnet Deployments @@ -36,20 +43,12 @@ Below is the list of supported strategies available on Aligned Mainnet: For additional details, refer to the [official EigenLayer documentation](https://github.com/Layr-Labs/eigenlayer-contracts). -### Aggregation Mode - -| Contract | Address | -|--------------------------------|-----------------------------------------------------------------------------------------------------------------------| -| AlignedProofAggregationService | [0xD0696d3eEebffcAB2D1b358805efAA005A9A8BC0](https://etherscan.io/address/0xD0696d3eEebffcAB2D1b358805efAA005A9A8BC0) | -| AggregationModePaymentService | [0xc8631Bc1E60c20db40e474F791126212fA8255F4](https://etherscan.io/address/0xc8631Bc1E60c20db40e474F791126212fA8255F4) | - ## Hoodi Deployments ### Verification Layer | Contract | Address | |--------------------------------|-----------------------------------------------------------------------------------------------------------------------------| -| AlignedProofAggregationService | [0xEFeD2fd949995BE1a1C7f61AbFC0A33412c37f95](https://hoodi.etherscan.io/address/0xEFeD2fd949995BE1a1C7f61AbFC0A33412c37f95) | | AlignedLayerServiceManager | [0x87CD431F160e88EC34fA48EC6F6cF7F2C0E8248c](https://hoodi.etherscan.io/address/0x87CD431F160e88EC34fA48EC6F6cF7F2C0E8248c) | | BlsApkRegistry | [0xa7Fc4D0Ad59593fB93B39c3353B4144Ea179f61e](https://hoodi.etherscan.io/address/0xa7Fc4D0Ad59593fB93B39c3353B4144Ea179f61e) | | IndexRegistry | [0x85e972915Ca1FeDF6Ad8361cC1F78211bd3cA6a1](https://hoodi.etherscan.io/address/0x85e972915Ca1FeDF6Ad8361cC1F78211bd3cA6a1) | @@ -68,13 +67,6 @@ Below is the list of supported strategies available on Aligned Hoodi: | [stETH](https://hoodi.eigenlayer.xyz/token/stETH) | [0x19536FAd6Eb831e8211B316177979161BBdb2c2B](https://hoodi.etherscan.io/address/0x19536FAd6Eb831e8211B316177979161BBdb2c2B) | | [WETH](https://hoodi.eigenlayer.xyz/token/WETH) | [0x24579aD4fe83aC53546E5c2D3dF5F85D6383420d](https://hoodi.etherscan.io/address/0x24579aD4fe83aC53546E5c2D3dF5F85D6383420d) | -### Aggregation Mode - -| Contract | Address | -|--------------------------------|-----------------------------------------------------------------------------------------------------------------------------| -| AlignedProofAggregationService | [0x6B34AAaE780A5EAB4c91AB8F54f2a421E9c2FB59](https://hoodi.etherscan.io/address/0x6B34AAaE780A5EAB4c91AB8F54f2a421E9c2FB59) | -| AggregationModePaymentService | [0xe6C9D0cf87cdaA8B2093c4b3830dde7267843F64](https://hoodi.etherscan.io/address/0xe6C9D0cf87cdaA8B2093c4b3830dde7267843F64) | - ## Sepolia Deployments ### Verification Layer @@ -88,9 +80,3 @@ Below is the list of supported strategies available on Aligned Hoodi: | RegistryCoordinator | [0x0Ef1920F089DD02d3A28BF2e34342FD3e74160A3](https://sepolia.etherscan.io/address/0x0Ef1920F089DD02d3A28BF2e34342FD3e74160A3) | | StakeRegistry | [0xe87cB8f9C74264BD446835F899e15c3AE1209C34](https://sepolia.etherscan.io/address/0xe87cB8f9C74264BD446835F899e15c3AE1209C34) | | BatcherPaymentService | [0x403dE630751e148bD71BFFcE762E5667C0825399](https://sepolia.etherscan.io/address/0x403dE630751e148bD71BFFcE762E5667C0825399) | - -### Aggregation Mode - -| Contract | Address | -|--------------------------------|-------------------------------------------------------------------------------------------------------------------------------| -| AlignedProofAggregationService | [0xb5D46304c30B1AeB3a8Da6ab599c336f7946C8A4](https://sepolia.etherscan.io/address/0xb5D46304c30B1AeB3a8Da6ab599c336f7946C8A4) | diff --git a/docs/3_guides/9_submitting_batch_without_batcher.md b/docs/archive/3_guides/9_submitting_batch_without_batcher.md similarity index 92% rename from docs/3_guides/9_submitting_batch_without_batcher.md rename to docs/archive/3_guides/9_submitting_batch_without_batcher.md index 37663f9d17..86649cdc6a 100644 --- a/docs/3_guides/9_submitting_batch_without_batcher.md +++ b/docs/archive/3_guides/9_submitting_batch_without_batcher.md @@ -1,5 +1,9 @@ # Submitting a batch without using the Batcher +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + Aligned's infrastructure contains a key element, the [Batcher](../2_architecture/components/1_batcher.md), which bundles many proofs together to reduce the cost of both submission and verification for each proof. diff --git a/docs/archive/README.md b/docs/archive/README.md new file mode 100644 index 0000000000..5ce269cd48 --- /dev/null +++ b/docs/archive/README.md @@ -0,0 +1,59 @@ +# Archive — Aligned Verification Layer + +> **The Aligned Verification Layer is deprecated.** +> The pages in this folder are kept for historical reference only. They are no +> longer maintained, and the services, contracts and CLI they describe should not +> be used for new integrations. + +Aligned's active ZK verification product is the +[Proof Aggregation Service](../2_proof_aggregation_layer/architecture/1_overview.md). To submit +proofs, see the [Proof Aggregation Service guide](../2_proof_aggregation_layer/guides/5_integration_example.md), +the [Aggregation Mode CLI](../2_proof_aggregation_layer/guides/3_cli.md) and the +[Aggregation Mode SDK](../2_proof_aggregation_layer/guides/4_sdk.md). + +These pages are not listed in `SUMMARY.md`, so they do not appear in the +documentation navigation. + +## Contents + +### Architecture + +- [Proof Verification Layer](2_architecture/1_proof_verification_layer.md) — overall architecture of the deprecated AVS +- [Batcher](2_architecture/components/1_batcher.md) — batched proofs into verification tasks +- [Payment Service Contract](2_architecture/components/2_payment_service_contract.md) — `BatcherPaymentService` +- [Service Manager Contract](2_architecture/components/3_service_manager_contract.md) — `AlignedLayerServiceManager` +- [Operator](2_architecture/components/4_operator.md) — EigenLayer restaker that re-executed proof verification +- [Aggregator](2_architecture/components/5_aggregator.md) — BLS signature aggregator (not proof aggregation) +- [Explorer](2_architecture/components/6_explorer.md) — the batches, operators and restaking views + +### Guides + +- [Submitting proofs](3_guides/0_submitting_proofs.md) +- [SDK intro](3_guides/1_SDK_how_to.md) and [Verification Layer SDK reference](3_guides/1.2_SDK_api_reference.md) +- [Verification Layer CLI](3_guides/10_aligned_cli.md) +- [Build your first Aligned application](3_guides/2_build_your_first_aligned_application.md) and [Modify ZkQuiz questions](3_guides/2.2_modify_zkquiz_questions.md) +- [Validating public input](3_guides/3_validating_public_input.md) +- [Generating a Gnark proof](3_guides/3.2_generate_gnark_proof.md) — Gnark proofs cannot be submitted to the Proof Aggregation Service +- [Using zkRust](3_guides/5_using_zkrust.md) — `--submit-to-aligned` targets the Verification Layer +- [Setup Aligned infrastructure locally](3_guides/6_setup_aligned.md) +- [Submitting a batch without the Batcher](3_guides/9_submitting_batch_without_batcher.md) + +### Operators + +The Verification Layer's operator set is no longer active and is not accepting +new operators. + +- [Running an operator](operator_guides/0_running_an_operator.md) +- [Operator FAQ](operator_guides/1_operator_FAQ.md) +- [Troubleshooting](operator_guides/2_troubleshooting.md) +- Upgrading guides: [v0.14.0](operator_guides/upgrading_guides/v0_14_0.md), [v0.10.2](operator_guides/upgrading_guides/v0_10_2.md), [v0.9.2](operator_guides/upgrading_guides/v0_9_2.md) + +### Introduction + +- [ZkQuiz example app](1_introduction/2_example_quiz_app.md) + +### Superseded pages + +The `about_aligned/` folder holds an earlier version of the introductory +documentation, written when the Verification Layer was called "fast mode". It was +superseded by `1_introduction/` and was already unlisted before being archived. diff --git a/docs/about_aligned/FAQ.md b/docs/archive/about_aligned/FAQ.md similarity index 97% rename from docs/about_aligned/FAQ.md rename to docs/archive/about_aligned/FAQ.md index 7e02f539d4..61835fdee1 100644 --- a/docs/about_aligned/FAQ.md +++ b/docs/archive/about_aligned/FAQ.md @@ -1,5 +1,9 @@ # FAQ +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + ### What is the objective of Aligned? Aligned’s mission is to extend Ethereum’s zero-knowledge capabilities. diff --git a/docs/about_aligned/features.md b/docs/archive/about_aligned/features.md similarity index 93% rename from docs/about_aligned/features.md rename to docs/archive/about_aligned/features.md index 64a2cfab23..a22ac393b6 100644 --- a/docs/about_aligned/features.md +++ b/docs/archive/about_aligned/features.md @@ -1,5 +1,9 @@ # Features +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + ## Expanding capacities With Aligned, we are expanding Ethereum's ZK capabilities to include an interesting variety of proof systems in the Ethereum ecosystem. We want to offer the infrastructure for the future of trustless applications using verifiable computation and Ethereum's security. diff --git a/docs/about_aligned/how_does_aligned_work.md b/docs/archive/about_aligned/how_does_aligned_work.md similarity index 97% rename from docs/about_aligned/how_does_aligned_work.md rename to docs/archive/about_aligned/how_does_aligned_work.md index fc0d3b42da..47883d5220 100644 --- a/docs/about_aligned/how_does_aligned_work.md +++ b/docs/archive/about_aligned/how_does_aligned_work.md @@ -1,5 +1,9 @@ # How does Aligned work? +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + ## Introduction The advancement of proof systems over the last decade has allowed us to prove more complex computations, enabling new applications. The development of general-purpose virtual machines for proving programs written in languages such as Rust makes writing verifiable apps simpler, reducing costs and go-to-market time. However, high verification costs and low throughput remain a challenge that hinders further progress: only projects with enough capital or scale can afford the fees. In Ethereum, verification competes for blockspace with other applications; network congestion can result in higher costs. Most proof systems cost over 250,000 gas in Ethereum, and with the current gas cap set at 30,000,000, the EVM cannot process more than 100 proofs per block. diff --git a/docs/about_aligned/learning_resources.md b/docs/archive/about_aligned/learning_resources.md similarity index 73% rename from docs/about_aligned/learning_resources.md rename to docs/archive/about_aligned/learning_resources.md index 0ffb0171cc..d3bd277ef9 100644 --- a/docs/about_aligned/learning_resources.md +++ b/docs/archive/about_aligned/learning_resources.md @@ -1,5 +1,9 @@ # Learning Resources: +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + ## Aligned blog post: * [Aligned Blog](https://blog.alignedlayer.com) diff --git a/docs/about_aligned/modular_approach.md b/docs/archive/about_aligned/modular_approach.md similarity index 89% rename from docs/about_aligned/modular_approach.md rename to docs/archive/about_aligned/modular_approach.md index 08d5c2e23e..a1e93f886b 100644 --- a/docs/about_aligned/modular_approach.md +++ b/docs/archive/about_aligned/modular_approach.md @@ -1,5 +1,9 @@ # Modular approach +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + As stated in the EigenLayer paper: "Ethereum pioneered the concept of modular blockchains, where distributed applications (DApps) became modules that could be built permissionless on top of the Ethereum trust network". diff --git a/docs/about_aligned/role_of_eigenlayer.md b/docs/archive/about_aligned/role_of_eigenlayer.md similarity index 91% rename from docs/about_aligned/role_of_eigenlayer.md rename to docs/archive/about_aligned/role_of_eigenlayer.md index 56b3ab7d24..d1f9f23763 100644 --- a/docs/about_aligned/role_of_eigenlayer.md +++ b/docs/archive/about_aligned/role_of_eigenlayer.md @@ -1,5 +1,9 @@ # Role of EigenLayer. +> **Deprecated.** This page documents the Aligned Verification Layer, which is no +> longer active. It is kept for historical reference only. Aligned's active +> product is the [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + ## What is EigenLayer? EigenLayer is a set of smart contracts built on Ethereum that introduces restaking, it enables the reuse of ETH on the consensus layer to validate new software modules built on top of the Ethereum ecosystem. In this way, Ethereum stakers can help secure many services by providing pooled security, this occurs when multiple parties combine their resources to offer enhanced security for a system. diff --git a/docs/images/aligned_architecture.png b/docs/archive/images/aligned_architecture.png similarity index 100% rename from docs/images/aligned_architecture.png rename to docs/archive/images/aligned_architecture.png diff --git a/docs/images/batch.png b/docs/archive/images/batch.png similarity index 100% rename from docs/images/batch.png rename to docs/archive/images/batch.png diff --git a/docs/images/diagram.png b/docs/archive/images/diagram.png similarity index 100% rename from docs/images/diagram.png rename to docs/archive/images/diagram.png diff --git a/docs/images/different-approaches.jpg b/docs/archive/images/different-approaches.jpg similarity index 100% rename from docs/images/different-approaches.jpg rename to docs/archive/images/different-approaches.jpg diff --git a/docs/images/entities.png b/docs/archive/images/entities.png similarity index 100% rename from docs/images/entities.png rename to docs/archive/images/entities.png diff --git a/docs/images/explorer-batch-details.png b/docs/archive/images/explorer-batch-details.png similarity index 100% rename from docs/images/explorer-batch-details.png rename to docs/archive/images/explorer-batch-details.png diff --git a/docs/images/explorer-landing-page.png b/docs/archive/images/explorer-landing-page.png similarity index 100% rename from docs/images/explorer-landing-page.png rename to docs/archive/images/explorer-landing-page.png diff --git a/docs/images/explorer-latest-batches.png b/docs/archive/images/explorer-latest-batches.png similarity index 100% rename from docs/images/explorer-latest-batches.png rename to docs/archive/images/explorer-latest-batches.png diff --git a/docs/images/explorer-operator-detail.png b/docs/archive/images/explorer-operator-detail.png similarity index 100% rename from docs/images/explorer-operator-detail.png rename to docs/archive/images/explorer-operator-detail.png diff --git a/docs/images/explorer-operators.png b/docs/archive/images/explorer-operators.png similarity index 100% rename from docs/images/explorer-operators.png rename to docs/archive/images/explorer-operators.png diff --git a/docs/images/explorer-restake-detail.png b/docs/archive/images/explorer-restake-detail.png similarity index 100% rename from docs/images/explorer-restake-detail.png rename to docs/archive/images/explorer-restake-detail.png diff --git a/docs/images/explorer-restake.png b/docs/archive/images/explorer-restake.png similarity index 100% rename from docs/images/explorer-restake.png rename to docs/archive/images/explorer-restake.png diff --git a/docs/images/future-modular.jpg b/docs/archive/images/future-modular.jpg similarity index 100% rename from docs/images/future-modular.jpg rename to docs/archive/images/future-modular.jpg diff --git a/docs/images/payment_service_diagram.png b/docs/archive/images/payment_service_diagram.png similarity index 100% rename from docs/images/payment_service_diagram.png rename to docs/archive/images/payment_service_diagram.png diff --git a/docs/images/prover.png b/docs/archive/images/prover.png similarity index 100% rename from docs/images/prover.png rename to docs/archive/images/prover.png diff --git a/docs/images/pvl_simple_architecture.png b/docs/archive/images/pvl_simple_architecture.png similarity index 100% rename from docs/images/pvl_simple_architecture.png rename to docs/archive/images/pvl_simple_architecture.png diff --git a/docs/images/pvl_vs_pas_comp_table.png b/docs/archive/images/pvl_vs_pas_comp_table.png similarity index 100% rename from docs/images/pvl_vs_pas_comp_table.png rename to docs/archive/images/pvl_vs_pas_comp_table.png diff --git a/docs/images/recursion.png b/docs/archive/images/recursion.png similarity index 100% rename from docs/images/recursion.png rename to docs/archive/images/recursion.png diff --git a/docs/images/scheme-separating-the-slashing-from-the-token-pools.jpg b/docs/archive/images/scheme-separating-the-slashing-from-the-token-pools.jpg similarity index 100% rename from docs/images/scheme-separating-the-slashing-from-the-token-pools.jpg rename to docs/archive/images/scheme-separating-the-slashing-from-the-token-pools.jpg diff --git a/docs/images/the-modularization-of-ethereum.jpg b/docs/archive/images/the-modularization-of-ethereum.jpg similarity index 100% rename from docs/images/the-modularization-of-ethereum.jpg rename to docs/archive/images/the-modularization-of-ethereum.jpg diff --git a/docs/images/zkquiz.png b/docs/archive/images/zkquiz.png similarity index 100% rename from docs/images/zkquiz.png rename to docs/archive/images/zkquiz.png diff --git a/docs/operator_guides/0_running_an_operator.md b/docs/archive/operator_guides/0_running_an_operator.md similarity index 97% rename from docs/operator_guides/0_running_an_operator.md rename to docs/archive/operator_guides/0_running_an_operator.md index 309343d479..549391e662 100644 --- a/docs/operator_guides/0_running_an_operator.md +++ b/docs/archive/operator_guides/0_running_an_operator.md @@ -1,5 +1,10 @@ # Register as an Aligned operator in testnet +> **Deprecated.** The Aligned Verification Layer is no longer active and is not +> accepting new operators. This guide is kept for historical reference only. +> Aligned's active product is the +> [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + > **CURRENT VERSION:** > Aligned Operator [v0.20.0](https://github.com/yetanotherco/aligned_layer/releases/tag/v0.20.0) @@ -23,7 +28,7 @@ Minimum hardware requirements: ## Supported Strategies -The list of supported strategies can be found [here](../3_guides/7_contract_addresses.md). +The list of supported strategies can be found [here](../3_guides/8_contract_addresses.md). ## Step 1 - Clone the repo diff --git a/docs/operator_guides/1_operator_FAQ.md b/docs/archive/operator_guides/1_operator_FAQ.md similarity index 92% rename from docs/operator_guides/1_operator_FAQ.md rename to docs/archive/operator_guides/1_operator_FAQ.md index aeb2dc64bc..b08070c1fa 100644 --- a/docs/operator_guides/1_operator_FAQ.md +++ b/docs/archive/operator_guides/1_operator_FAQ.md @@ -1,5 +1,10 @@ # Operator FAQ +> **Deprecated.** The Aligned Verification Layer is no longer active and is not +> accepting new operators. This guide is kept for historical reference only. +> Aligned's active product is the +> [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + The EigenLayer Operator installation guide is available [here](https://docs.eigencloud.xyz/products/eigenlayer/operators/howto/operator-installation). ### How do I get whitelisted to run an operator? @@ -10,7 +15,7 @@ and wait for the Aligned team to approve your request. ### What Strategies Tokens are supported in Mainnet? -The list of supported strategies can be found [here](../3_guides/7_contract_addresses.md). +The list of supported strategies can be found [here](../3_guides/8_contract_addresses.md). ### What RPC should I use? diff --git a/docs/operator_guides/2_troubleshooting.md b/docs/archive/operator_guides/2_troubleshooting.md similarity index 90% rename from docs/operator_guides/2_troubleshooting.md rename to docs/archive/operator_guides/2_troubleshooting.md index e12cc931dd..7e8189b485 100644 --- a/docs/operator_guides/2_troubleshooting.md +++ b/docs/archive/operator_guides/2_troubleshooting.md @@ -1,5 +1,10 @@ # Troubleshooting +> **Deprecated.** The Aligned Verification Layer is no longer active and is not +> accepting new operators. This guide is kept for historical reference only. +> Aligned's active product is the +> [Proof Aggregation Service](../../2_proof_aggregation_layer/architecture/1_overview.md). + ### How to resolve the error "Error in new task subscription" This error is caused by the operator not being able to subscribe to the task. diff --git a/docs/operator_guides/upgrading_guides/v0_10_2.md b/docs/archive/operator_guides/upgrading_guides/v0_10_2.md similarity index 85% rename from docs/operator_guides/upgrading_guides/v0_10_2.md rename to docs/archive/operator_guides/upgrading_guides/v0_10_2.md index b3ea4c5951..59440bbb12 100644 --- a/docs/operator_guides/upgrading_guides/v0_10_2.md +++ b/docs/archive/operator_guides/upgrading_guides/v0_10_2.md @@ -1,5 +1,10 @@ # Upgrading to v0.10.2 +> **Deprecated.** The Aligned Verification Layer is no longer active and is not +> accepting new operators. This guide is kept for historical reference only. +> Aligned's active product is the +> [Proof Aggregation Service](../../../2_proof_aggregation_layer/architecture/1_overview.md). + This guide will walk you through the process of upgrading your Aligned Operator to v0.10.2. ## Changes diff --git a/docs/operator_guides/upgrading_guides/v0_14_0.md b/docs/archive/operator_guides/upgrading_guides/v0_14_0.md similarity index 91% rename from docs/operator_guides/upgrading_guides/v0_14_0.md rename to docs/archive/operator_guides/upgrading_guides/v0_14_0.md index 301f680bb6..2467836d84 100644 --- a/docs/operator_guides/upgrading_guides/v0_14_0.md +++ b/docs/archive/operator_guides/upgrading_guides/v0_14_0.md @@ -1,5 +1,10 @@ # Upgrading to V0.14.0 +> **Deprecated.** The Aligned Verification Layer is no longer active and is not +> accepting new operators. This guide is kept for historical reference only. +> Aligned's active product is the +> [Proof Aggregation Service](../../../2_proof_aggregation_layer/architecture/1_overview.md). + This guide will walk you through the process of upgrading your Aligned Operator to v0.14.0. Since EigenLayer released Slashing on Holesky Testnet, there are two versions of the [EigenSDK](https://github.com/Layr-Labs/eigensdk-go), one is compatible with Mainnet and the other one is compatible with Holesky Testnet. This guide will help you to upgrade your operator with the correct version of the EigenSDK. diff --git a/docs/operator_guides/upgrading_guides/v0_9_2.md b/docs/archive/operator_guides/upgrading_guides/v0_9_2.md similarity index 84% rename from docs/operator_guides/upgrading_guides/v0_9_2.md rename to docs/archive/operator_guides/upgrading_guides/v0_9_2.md index 6e1bee4996..4fbfa45097 100644 --- a/docs/operator_guides/upgrading_guides/v0_9_2.md +++ b/docs/archive/operator_guides/upgrading_guides/v0_9_2.md @@ -1,5 +1,10 @@ # Upgrading to v0.9.2 +> **Deprecated.** The Aligned Verification Layer is no longer active and is not +> accepting new operators. This guide is kept for historical reference only. +> Aligned's active product is the +> [Proof Aggregation Service](../../../2_proof_aggregation_layer/architecture/1_overview.md). + This guide will walk you through the process of upgrading your Aligned Operator to v0.9.2. ## Changes diff --git a/examples/circom/README.md b/examples/circom/README.md index 60d3728b63..3780cdcee5 100644 --- a/examples/circom/README.md +++ b/examples/circom/README.md @@ -74,7 +74,7 @@ make run ## How to run it locally -Set up all the components of aligned locally following the [aligned setup guide](../../docs/3_guides/6_setup_aligned.md). +Set up all the components of aligned locally following the [aligned setup guide](../../docs/archive/3_guides/6_setup_aligned.md). 1. Generate the trusted setup: diff --git a/examples/l2/README.md b/examples/l2/README.md index 4ee2bdb346..183cd0193b 100644 --- a/examples/l2/README.md +++ b/examples/l2/README.md @@ -13,10 +13,10 @@ Notice a lot of checks that a real L2 should have are missing, since the focus a This Layer 2 (L2) system operates in two main steps: -- Off-chain execution and proof generation + verification with Aligned Verification Layer (a.k.a Fast Mode). -- On-chain state update via proof verification with Aligned Aggregation Mode. +- Off-chain execution and proof generation, then submission to Aligned Aggregation Mode. +- On-chain state update via proof inclusion verification against the aggregated proof. -In Step 1, we execute user transfers and generate a zkVM-based proof of the state transition, which is submitted to Aligned’s verification layer. +In Step 1, we execute user transfers and generate a zkVM-based proof of the state transition, which is submitted to the Aggregation Mode Gateway. In Step 2, once the proof is aggregated (every 24 hours), it is verified on-chain to update the global state. @@ -26,7 +26,7 @@ In Step 2, once the proof is aggregated (every 24 hours), it is verified on-chai 2. Load Transfers: Retrieve or receive the user transfer data for this batch. 3. Execute in zkVM: Run the zkVM with the loaded transfers to compute the new state. 4. Generate Proof: Produce a zk-proof for the executed state transition committing the commitment of the received + the commitment of the new state. -5. Submit Proof to Aligned: Send the proof to Aligned Verification Layer +5. Submit Proof to Aligned: Send the proof to the Aggregation Mode Gateway 6. Save the binary proof locally for later on-chain verification. ### Step 2: Proof Verification + On-Chain State Update @@ -138,7 +138,7 @@ Finally [run the l2](#running-the-l2). You can also run this example on a local devnet. To get started, navigate to the root of the Aligned repository -- Start Ethereum package and the Batcher +- Start the Ethereum package and the Aggregation Mode services ```shell # This will start the local net diff --git a/examples/validating-public-input/README.md b/examples/validating-public-input/README.md index 480ca2bfe4..7054d4f151 100644 --- a/examples/validating-public-input/README.md +++ b/examples/validating-public-input/README.md @@ -2,7 +2,7 @@ ## Testing locally -Set up all the components of aligned locally following the [aligned setup guide](../../docs/3_guides/6_setup_aligned.md). +Set up all the components of aligned locally following the [aligned setup guide](../../docs/archive/3_guides/6_setup_aligned.md). This example is designed to do either with SP1 or risc0 proofs these are the commands to use depending on which verifier want to be used. diff --git a/examples/zkquiz/README.md b/examples/zkquiz/README.md index f4b5731f6f..f90faa8733 100644 --- a/examples/zkquiz/README.md +++ b/examples/zkquiz/README.md @@ -60,7 +60,7 @@ This will: If you want to test the zk quiz on a local network follow these steps: -1. Setup Aligned locally following [this guide](../../docs/3_guides/6_setup_aligned.md) +1. Setup Aligned locally following [this guide](../../docs/archive/3_guides/6_setup_aligned.md) 3. Move into the zkquiz example: ``` diff --git a/infra/aggregation_mode/ansible/README.md b/infra/aggregation_mode/ansible/README.md index e50085a471..898f6eec61 100644 --- a/infra/aggregation_mode/ansible/README.md +++ b/infra/aggregation_mode/ansible/README.md @@ -323,7 +323,7 @@ make gateway_2_deploy ENV=mainnet FORCE_REBUILD=true ``` This will: -1. Pull latest code from the configured branch (staging for hoodi, main for mainnet) +1. Pull latest code from the configured branch (`git_branch` in `playbooks/ini/config-.ini`; currently `staging` for both hoodi and mainnet) 2. Delete existing binaries 3. Rebuild gateway and poller from source