Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
30 commits
Select commit Hold shift + click to select a range
ef46f11
Add files via upload
cliraa Jul 22, 2025
3b5fff7
Update 0_about_aligned.md
cliraa Jul 22, 2025
d3cf2aa
Update 3_faq.md
cliraa Jul 22, 2025
7881e4e
Update 4_why_zk.md
cliraa Jul 22, 2025
ec7a885
Update 2_use_cases.md
cliraa Jul 22, 2025
82da82d
Update SUMMARY.md
cliraa Jul 22, 2025
f222623
Update 4_why_zk.md
cliraa Jul 22, 2025
ade4680
Update and rename 1_fast_mode.md to 1_proof_verification_layer.md
cliraa Jul 22, 2025
0bdd3af
Update SUMMARY.md
cliraa Jul 22, 2025
33c758c
Update 4_why_zk.md
cliraa Jul 22, 2025
e88b429
Update 0_about_aligned.md
cliraa Jul 23, 2025
379b484
Update 2_use_cases.md
cliraa Jul 25, 2025
c9b1e1b
Update 1_operator_FAQ.md
cliraa Jul 25, 2025
f5eb683
Update 2_use_cases.md
cliraa Jul 26, 2025
9f64a55
Update 1_operator_FAQ.md
cliraa Jul 26, 2025
f514ef9
Add files via upload
cliraa Jul 28, 2025
2966aa4
Update 2_aggregation_mode.md
cliraa Jul 28, 2025
2146090
Update 1_deep_dive.md
cliraa Jul 28, 2025
7be79d1
Create 3_raas_platform.md
cliraa Jul 28, 2025
76b2f63
Update SUMMARY.md
cliraa Jul 28, 2025
44b7471
Update SUMMARY.md
cliraa Jul 28, 2025
0a8b137
Update SUMMARY.md
cliraa Jul 28, 2025
fb0db0e
Update SUMMARY.md
cliraa Jul 28, 2025
d1873c7
Update SUMMARY.md
cliraa Jul 28, 2025
f2d3c52
Update 3.1_aggregation_mode.md
cliraa Jul 28, 2025
bd1304d
Update docs/1_introduction/0_about_aligned.md
cliraa Jul 29, 2025
0c8efa6
Update 3_faq.md
cliraa Jul 29, 2025
1cc0f53
Update 3_faq.md
cliraa Jul 29, 2025
033bd93
Update 3_faq.md
cliraa Jul 29, 2025
02babb6
Update docs/1_introduction/3_faq.md
cliraa Jul 29, 2025
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
91 changes: 48 additions & 43 deletions docs/1_introduction/0_about_aligned.md

Large diffs are not rendered by default.

2 changes: 1 addition & 1 deletion docs/1_introduction/2_use_cases.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@
- New settlement layers (use Aligned + EigenDA) for Rollups and Intent based systems.
- P2P protocols based on SNARKs such as payment systems and social networks.
- Alternative L1s interoperable with Ethereum: similar to fast bridging.
- Verifiable Machine Learning (ML): with general-purpose zkvms we can prove code written in Rust, solving part of the problem of using ML. However, most zkVMs use STARK-based proof systems, which leads to high on-chain costs or expensive wrapping. With Aligned, you can directly verify your proof from the zkVM for much less than Ethereum.
- Verifiable Machine Learning (ML): with general-purpose zkVMs we can prove code written in Rust, solving part of the problem of using ML. However, most zkVMs use STARK-based proof systems, which leads to high on-chain costs or expensive wrapping. With Aligned, you can directly verify your proof from the zkVM for much less than Ethereum.
- Cheap verification and interoperability for Identity Protocols.
- ZK Oracles: With ZK oracles we can show that we have a piece of information off-chain and produce a ZK proof doing some computation with that data. Aligned reduces the cost of using those oracles. For more background, see the [following post](https://minaprotocol.com/blog/what-are-zkoracles).
- New credential protocols such as zkTLS based systems: you can create proofs of data shown on your web browser and have the result verified in Ethereum. See the following thread for an [ELI5 on TLS](https://x.com/dabit3/status/1830022029195501799)
Expand Down
139 changes: 48 additions & 91 deletions docs/1_introduction/3_faq.md

Large diffs are not rendered by default.

29 changes: 12 additions & 17 deletions docs/1_introduction/4_why_zk.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,37 +7,32 @@ The following is an introduction to zero-knowledge/validity proofs to understand

The two terms are sometimes grouped under ZK, though depending on the use case, you may need it to be zero-knowledge or not. Validity proofs are widely used by ZK-rollups (though not rigorously zero-knowledge), while Schnorr signatures are an example of the second (basically, they let you show to others that you have a secret key, without leaking it).

In blockchains, we need to coordinate between different parties that do not trust each other. How can we agree on whether something has happened? The logical construction involves independently re-executing transactions and reaching consensus. However, the number of transactions we can process is limited by the weakest devices in the network, acting as bottlenecks. Moreover, adding more hardware does not make the system faster (as in web2), only more robust. ZK allows the situation to scale, allowing the system to process more transactions with the same guarantees. ZK proofs allow you to verify a computation much faster than re-execution: we can use more powerful machines to run the transactions and generate the cryptographic proof, and the rest of the network verifies the proof. If the proof is valid, it is the same as if all the nodes had re-executed the transactions, but with less computational effort. More concretely, a ZK-rollup can generate a proof that it processed 10,000 transactions correctly, and submit to Ethereum the proof with the state diff (or other information necessary to update the state), and Ethereum can check very quickly that all those transactions were correct! ZK is also useful whenever you need to show the integrity of some computation, for example, that an image you published in the newspaper is the result of enlarging an image from a real camera. You can generate the proof and then use Ethereum as a settlement layer, in charge of performing the verification of your proofs, though there is a problem: it can be expensive, and you have limited throughput. This is where Aligned comes in.
In blockchains, we need to coordinate between different parties that do not trust each other. How can we agree on whether something has happened? The logical construction involves independently re-executing transactions and reaching consensus. However, the number of transactions we can process is limited by the weakest devices in the network, acting as bottlenecks. Moreover, adding more hardware does not make the system faster (as in web2), only more robust. ZK allows the situation to scale, allowing the system to process more transactions with the same guarantees. ZK proofs allow you to verify a computation much faster than re-execution: we can use more powerful machines to run the transactions and generate the cryptographic proof, and the rest of the network verifies the proof. If the proof is valid, it is the same as if all the nodes had re-executed the transactions, but with less computational effort. More concretely, a ZK-rollup can generate a proof that it processed 10,000 transactions correctly, and submit to Ethereum the proof with the state diff (or other information necessary to update the state), and Ethereum can check very quickly that all those transactions were correct! ZK is also useful whenever you need to show the integrity of some computation, for example, that an image you published in the newspaper is the result of enlarging an image from a real camera. This is where Aligned's stack comes in.

Aligned offers you two different products to reduce your costs and increase throughput: fast mode and the proof aggregation service. Once you know that you want to use ZK for your product and Ethereum, Aligned fits perfectly. Whether to use fast mode or proof aggregation depends on your needs:
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.

- Fast mode: 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 fast mode, but achieves the full security of Ethereum.
- **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.
- **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!
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!

## Projects or ideas using ZK

The list below contains examples or projects using ZK. It is meant to illustrate some use cases, but it is not meant to be exhaustive.

- Rollups
- On-chain gaming
- ZK Machine Learning (zKML)
- ZK Machine Learning (zkML)
- ZK-TLS
- Bridges
- Oracles
- Data processors
- Voting
- ZK-Email
- Identity protocols
- IoT
- IoT
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
## Fast mode in a nutshell
## Aligned's Proof Verification Layer in a nutshell

The fast mode works using a subset of Ethereum’s validators via restaking.
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.
If a two-thirds majority agrees, the results are posted to Ethereum.
Expand All @@ -9,7 +9,7 @@ If a two-thirds majority agrees, the results are posted to Ethereum.

The proof submission can be simplified as follows:

![Figure 1: Simplified Architecture.png](../images/simplified_architecture.png)
![Figure 1: Simplified Architecture](../images/simplified_architecture.png)

1. The users submit proofs to the batcher through the CLI or SDK.
2. The batcher accumulates proofs, and then sends the batch to some Data Service and posts the merkle root and data to
Expand All @@ -23,7 +23,7 @@ The proof submission can be simplified as follows:

Aligned’s architecture is shown in the figure below:

![Figure 2: Architecture fast mode](../images/aligned_architecture.png)
![Figure 2: Proof Verification Layer Architecture](../images/aligned_architecture.png)

The validators/AVS operators are the ones responsible for proof verification.
They fetch the proof data from the data service and verify it using the different proving systems supported by Aligned.
Expand Down
10 changes: 5 additions & 5 deletions docs/2_architecture/2_aggregation_mode.md
Original file line number Diff line number Diff line change
@@ -1,9 +1,9 @@
## Aggregation mode in a nutshell
## Aligned's Proof Aggregation Service in a nutshell

General Prover/Verifier: Every several days, takes the proofs from the DA layer and generates a proof of the verification of all the proofs. The general prover can be based on the SP1, Risc0 or Nexus virtual machine, which is a virtual machine able to prove general Rust code. The proof of the verification of the proofs is done using the corresponding verifier codes in Rust. The verification can be done using a tree structure.
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.

To aggregate all the proofs, in the first step, all proofs are transformed into proofs of execution of the virtual machine, achieving proof uniformity (see Figure 1). We can then shrink proof size by recursively proving the verification of proofs, as shown in the tree diagram (see Figure 2).
Aggregation Service allows developers to submit individual ZK proofs to Aligned’s Verification Layer; the ones that can be aggregated are then batched and passed to the Aggregation Service. The service generates a single recursive proof that attests to the validity of these 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: Prover](../images/prover.png)
![Figure 1: Proof Aggregation Service](../images/aligned_proof_aggregation_service.png)

![Figure 2: Recursion tree](../images/recursion.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.
44 changes: 44 additions & 0 deletions docs/2_architecture/3_raas_platform.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
# 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/aligned_suite_of_products.png)

## What advantages will Aligned's RaaS platform offer for your project?

Aligned's RaaS platform will offer significant benefits, starting with substantial time and cost savings, enabling teams to deploy rollups faster and more affordably. This accessibility unlocks new use cases that would otherwise be economically unfeasible. A key advantage is customizability and modularity. Our platform will enable easy mixing and matching of different rollup components, helping build the ideal solution for specific needs. From initial deployment to long-term maintenance, we handle upgrades, performance optimization, and assist you in integrating new capabilities as they emerge.

## Why is Aligned using Ethrex for Based ZK-rollups?

Aligned chose Ethrex as the rollup stack for our RaaS platform due to its stable, minimalist, and modular design and its support for the latest features like based rollups. This aligns with our commitment to reliability and performance, and ensures that we can continue to offer our users the best technology to access Ethereum.

Ethrex operates in two modes:

- Ethrex L1: a streamlined Ethereum execution client
- Ethrex L2: a ZK-rollup client supporting multiple proving systems (RISC-V zkVMs like SP1 or R0VM, and Trusted Execution Environments (TEEs))

Ethrex's design principles emphasize minimalism, clarity, and simplicity, resulting in a codebase that is both fast and resilient. This approach enables rapid iteration and the early adoption of next-generation features, which is crucial for staying ahead in the rapidly evolving blockchain landscape. Additionally, Ethrex's vertical integration and minimal dependencies ensure efficient operation and ease of maintenance, enabling low overhead and providing a robust foundation for our services.

By leveraging Ethrex, Aligned can offer a streamlined, high-performance RaaS platform that simplifies the deployment of Layer 2 chains, empowering developers to build scalable applications with greater efficiency and control.

## What are Based rollups?

Based rollups are rollups that use Ethereum L1 proposers and builders for sequencing (ordering its transactions and forming blocks), as opposed to a separate (typically centralized) sequencer.

Based sequencing is “based on the L1”, meaning that rollups using this design give Ethereum’s validators the power to sequence rollup transactions. This simplifies what a rollup needs to do and lets it take advantage of the extensive, battle-tested infrastructure that makes up Ethereum’s block building market. The result is a rollup architecture that offers greater feature parity with the L1 and many other benefits that are important to customers looking to launch their own rollup.

## The benefits of Based Rollups

Based rollups provide a range of benefits that address many of the shortcomings rollups currently face. Because non-based rollups are not synchronously composable with Ethereum their proliferation has resulted in liquidity fragmentation and the majority of DeFi volume taking place on the L1, which has higher fees. Based rollups enable atomic synchronous composability and full access to Ethereum’s liquidity, ultimately resulting in improved interoperability between apps and smart contracts and greatly improved UX.

By eliminating the need for a dedicated sequencer, based rollups are inherently more decentralized, have stronger liveness guarantees, are more censorship-resistant, and more credibly neutral than non-based rollups. These are core features of Ethereum that make it the best decentralized smart contract platform for high-value, global transactions—features which non-based rollups fail to replicate.

Based rollups benefit from reduced operating costs as they don’t require operators to run a dedicated sequencer, but also make use of the L1s existing block building pipeline. This means based rollups do not need to attract sophisticated actors to provide these services, further reducing costs and improving efficiency.

## 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.

![Figure 2: ZK-rollups and the role of Aligned](../images/zkrollups_and_the_role_of_aligned.png)
6 changes: 3 additions & 3 deletions docs/2_architecture/agg_mode_components/1_deep_dive.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Aggregation Mode Deep Dive
# Proof Aggregation Service Deep Dive

The Aggregation Mode runs **once every 24 hours** and performs the following steps:
The Proof Aggregation Service runs **once every 24 hours** and performs the following steps:

1. **Fetch Proofs from the Verification Layer**
Queries `NewBatchV3` events from the `AlignedLayerServiceManager` and downloads the batches from `S3`, starting from the last processed block of the previous run.
Expand All @@ -18,7 +18,7 @@ The Aggregation Mode runs **once every 24 hours** and performs the following ste
The final aggregated proof and its blob are sent to the `AlignedProofAggregationService` contract for verification.

> [Note]
> Currently if you want your proof to be verified in the `AggregationMode` you need to submit it via the `VerificationLayer`. In the future, users will be able to decide if they want to use any of the modes in particular or both of them
> Currently if you want your proof to be verified in the `AggregationMode` you need to submit it via the `VerificationLayer`. In the future, users will have the option to choose whether they want to continue using this method or switch to using only the Aggregation service.

## Aggregators and Supported Proof Types

Expand Down
Loading