Skip to content

Commit 4d85550

Browse files
diegokingstonMauroToscano
diegokingston
and
MauroToscano
authored
add more docs (#488)
Co-authored-by: Mauro Toscano <[email protected]>
1 parent edaf62b commit 4d85550

File tree

7 files changed

+91
-32
lines changed

7 files changed

+91
-32
lines changed

‎docs/SUMMARY.md‎

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -3,9 +3,9 @@
33

44
* [What is Aligned?](introduction/0_what_is_aligned.md)
55
* [Getting started](introduction/1_getting_started.md)
6-
* [FAQ](introduction/2_faq.md)
7-
* Core concepts
8-
* Use cases
6+
* [FAQ](introduction/2_fq.md)
7+
* [Core concepts](introduction/3_core_concepts.md)
8+
* [Use cases](introduction/4_use_cases.md)
99

1010
## Guides
1111

@@ -15,8 +15,8 @@
1515

1616
## Architecture
1717

18-
* Fast mode
19-
* Aggregation mode
18+
* [Fast mode](architecture/fast_mode.md)
19+
* [Aggregation mode](architecture/aggregation_mode.md)
2020

2121
## Useful links
2222

‎docs/architecture/0_fast_mode.md‎

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,18 @@
1+
## Fast mode in an nutshell
2+
3+
### Flow for sending a proof and publishing the result on Ethereum (Fast Mode)
4+
The flow for sending a proof and having the results on Ethereum is as follows:
5+
1. Using our CLI or SDK, the user sends one proof (or many) to the batcher.
6+
2. The batcher answers with a ProofVerificationData for each proof.
7+
3. The user invokes an IsVerified function with this data in Solidity to check that the proof is valid.
8+
4. ( Optional ) The user checks that the commitment to the proven program matches the one it expects.
9+
10+
### Full flow with internals of the proof (Fast Mode)
11+
12+
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)
13+
2. The batcher accumulates proofs of many users for a small number of blocks (typically 1-3).
14+
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.
15+
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 verifies all the proofs.
16+
5. If the proofs are valid, they sign the root and send this to the BLS signature aggregator.
17+
6. The signature aggregator accumulates the signed responses until reaching the quorum, then sends the aggregated signature to Ethereum.
18+
7. Ethereum verifies the aggregated signatures and changes the state of the batch to verified.

‎docs/architecture/1_aggregation_mode.md‎

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
## Aggregation mode in a nutshell
2+
3+
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.
4+
5+
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 2). We can then shrink proof size by recursively proving the verification of proofs, as shown in the tree diagram (see Figure 3).
6+
7+
![Figure 4: Prover](../images/prover.png)
8+
9+
![Figure 5: Recursion tree](../images/recursion.png)

‎docs/guides/0_proving_systems.md‎

Lines changed: 16 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,20 +1,28 @@
1-
# Supported Proving Systems
1+
# Supported verifiers
22

3-
Currently, Aligned supports:
3+
The following is the list of the verifiers currently supported by Aligned:
44

5-
:white_check_mark: Gnark - Groth16 (with BN254)
6-
:white_check_mark: Gnark - Plonk (with BN254 and BLS12-381)
5+
:white_check_mark: gnark - Groth16 (with BN254 and BLS12-381)
6+
:white_check_mark: gnark - Plonk (with BN254 and BLS12-381)
77
:white_check_mark: SP1
8-
:white_check_mark: Halo2 - Plonk/KZG
9-
:white_check_mark: Halo2 - Plonk/IPA
108

11-
The following proving systems are going to be added soon:
9+
The following proof systems are going to be added soon:
1210
:black_square_button: Risc0
1311
:black_square_button: Kimchi
12+
:black_square_button: Halo2 - Plonk/KZG
13+
:black_square_button: Halo2 - Plonk/IPA
1414

1515
## SP1 proof
1616

17-
The SP1 proving system needs the proof file and the vm program file,
17+
These are [STARK proofs](https://eprint.iacr.org/2018/046) that attest to the validity of the execution of a given program over the SP1 virtual machine.
18+
19+
The SP1 proving system needs the proof file and the vm program file.
20+
The arguments for SP1 are
21+
```
22+
--proving_system SP1
23+
--proof <proof_file> \
24+
--vm_program <elf_file> \
25+
```
1826

1927
```bash
2028
rm -rf ./aligned_verification_data/ &&

‎docs/introduction/0_what_is_aligned.md‎

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,24 @@
1+
## What is Aligned?
2+
3+
Aligned is a decentralized network that verifies zero-knowledge/validity proofs and posts the results to Ethereum. It is designed to provide high throughput, cheap proof verification with low latency.
4+
5+
## Mission
6+
7+
Our mission is to accelerate Ethereum's roadmap and the adoption of verifiable computation by enabling fast and economical verification of ZK and validity proofs.
8+
9+
## Why are we building Aligned?
10+
11+
In recent months, we have witnessed the development and enhancement of general proving virtual machines such as Risc0, Valida, Jolt, and SP1. These innovations allow users to write ordinary code in languages like Rust or C and generate proofs demonstrating the integrity of computations. This evolution is poised to transform application development, provided we have verification networks with high throughput and low cost. This is the core vision of Aligned and the reason we are building it: the future belongs to provable applications.
12+
13+
Currently, proof verification in Ethereum is expensive and throughput is limited to around 10 proofs per second. The cost depends on the proof system used, and the availability of precompiles. Groth16 costs around 250,000 gas, STARKs, over 1,000,00, and other proof systems are too expensive to be used in Ethereum.
14+
15+
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.
16+
17+
Aligned provides an alternative to reduce costs and increase throughput significantly. This is achieved by two different modes: the fast mode and the aggregation/slow mode. The fast mode works with 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 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:
18+
19+
- The code can be optimized for speed, not gas consumption.
20+
- We can leverage parallelization to increase throughput.
21+
- Since the gas limit does not constrain us, we can verify proof systems that are too expensive for Ethereum, such as Kimchi or Binius.
22+
- Adding new proof systems is straightforward.
23+
24+
Preliminary numbers show that Aligned can verify more than 1000 proofs per second, over two orders of magnitude than the EVM at nominal capacity. Using effective batching techniques, we can split the task creation and verification cost between thousands of proofs.

‎docs/introduction/3_core_concepts.md‎

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
## Core Concepts
2+
3+
- Proof: cryptographic data that attests to the validity of a given computation. The concrete data and size depend on the proof system and program used.
4+
- Verification: an algorithm that takes the proof, and associated public data and verification key/program and outputs whether the proof is valid or not.
5+
- Proof batch: a collection of verification tasks to be carried out by the operators.
6+
- User CLI: used to interact with the verifier task batcher. Sends proof and public input data and receives the verification data in Aligned.
7+
- 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.
8+
- 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.
9+
- Data service: temporarily stores the data for the proof and public input.
10+
- Operators: responsible for performing the verification of the proofs in each batch and signing messages with the results.
11+
- BLS signature aggregator: receives the signatures from the operators, checks that there is quorum, and performs the aggregation of the signatures.
12+
- 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.
13+
- 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.
14+
- Proof aggregator: Once tasks have been verified by Aligned’s operators, this component 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.

docs/about_aligned/use_cases.md renamed to docs/introduction/4_use_cases.md

Lines changed: 5 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -1,29 +1,15 @@
1-
# Use cases:
2-
3-
Among the possible use cases of Aligned we have:
1+
# Use cases
42

53
- Soft finality for Rollups and Appchains.
6-
74
- Fast bridging.
8-
95
- New settlement layers (use Aligned + EigenDA) for Rollups and Intent based systems.
10-
116
- P2P protocols based on SNARKs such as payment systems and social networks.
12-
137
- Alternative L1s interoperable with Ethereum.
14-
158
- Verifiable Machine Learning.
16-
17-
- Cheap verification and interoperability for Identity Protocols.
18-
9+
- Cheap verification and interoperability for Identity Protocols.
1910
- ZK Oracles.
20-
21-
- New credential protocols such as zkTLS based systems.
22-
23-
- ZK Coprocessor.
24-
11+
- New credential protocols such as zkTLS based systems.
12+
- ZK Coprocessor.
2513
- Encrypted Mempools using SNARKs to show the correctness of the encryption.
26-
27-
- Protocols against misinformation and fake news.
28-
14+
- Protocols against misinformation and fake news.
2915
- On-chain gaming.

0 commit comments

Comments
 (0)