docs: add components to gitbook (#569)

Co-authored-by: Gian <58370608+glpecile@users.noreply.github.com>
Co-authored-by: Nicolas Rampoldi <58613770+NicolasRampoldi@users.noreply.github.com>
Co-authored-by: Julian Arce <52429267+JuArce@users.noreply.github.com>

Author: 4 people

docs/SUMMARY.md

@@ -11,24 +11,22 @@
 ## Architecture
 
 * [Supported Verifiers](architecture/0_supported_verifiers.md)
-* [Fast mode](architecture/1_fast_mode.md)
 * [Aggregation mode](architecture/2_aggregation_mode.md)
-
-<!-- * Components
-  * [User](./architecture/entities/user.md)
-  * [Operator](./architecture/entities/operator.md)
-  * [Aggregator](./architecture/entities/aggregator.md)
-  * [Batcher](./architecture/entities/batcher.md)
-  * [Payment Service](./architecture/entities/payment_service.md) -->
-
-* [Smart contracts](architecture/3_smart_contracts.md)
+* [Fast mode](architecture/1_fast_mode.md)
+  * [Batcher](./architecture/components/1_batcher.md)
+  * [Payment Service Contract](./architecture/components/2_payment_service_contract.md)
+  * [Service Manager Contract](./architecture/components/3_service_manager_contract.md)
+  * [Operator](./architecture/components/4_operator.md)
+  * [Aggregator](./architecture/components/5_aggregator.md)
+  * [Explorer](./architecture/components/6_explorer.md)
 
 ## Guides
 
 * [Submitting proofs](guides/0_submitting_proofs.md)
 * [SDK](guides/1_SDK.md)
 * [Using Aligned on your app](guides/2_using_aligned_on_your_app.md)
 * [Generating proofs for Aligned](guides/3_generating_proofs.md)
+* [Contract Addresses](architecture/4_contract_addresses.md)
 * [Generating & submitting proofs of Rust code with ZKRust](guides/0_5_using_zkrust.md)
 
 <!-- * [Setup Aligned](developer_guides/2_setup_aligned.md) -->
@@ -39,7 +37,7 @@
 
 ## Useful links
 
-* [All the proof aggregation solutions will use RISC-V zkvms](https://blog.alignedlayer.com/all-the-proof-aggregation-solutions-will-use-risc-v-zkvms/)
+* [All the proof aggregation solutions will use RISC-V zkvms](https://mirror.xyz/0x7794D1c55568270A81D8Bf39e1bcE96BEaC10901/5JfikCrjdHsyqGCpqvbakrA8DZHIgj0d90i9tVOTink)
 * [Manifesto](https://mirror.xyz/0x7794D1c55568270A81D8Bf39e1bcE96BEaC10901/rOya8TwZvj_8kTpjDPVwTuNc1UcS0VLUr1t2nhCxYj8)
 
 ## Contacts

docs/architecture/3_smart_contracts.md

@@ -0,0 +1,10 @@
+# Batcher
+
+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 is sure that their proof was included in a batch, the Batcher will send each User the 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.
+
+Also, to avoid unnecessary proof submissions, the Batcher performs a preliminary verification of the submitted proofs, to minimize the submission of false proofs in a batch.
+
+However, each proof has a cost of verification, so each batch must contain some sort of payment for it to be verified. To handle the payment for each batch, the Batcher submits the batch through its [Batcher Payment Service](./2_payment_service_contract.md).

docs/architecture/components/1_batcher.md

@@ -0,0 +1,52 @@
+# Payment Service
+
+The Payment Service handles User's payments to fund the verification of their proofs. 
+
+To be able to use the batcher, a user must fund its transactions. For this, there is a simple Batcher Payment System.
+
+The Batcher has an associated Batcher Payments smart contract, which is in charge of receiving user's payments, and it guarantees that it can only spend these funds to send users' proofs to Aligned.
+
+Users must first deposit into this contract, via a normal transfer to its address, where the Batcher Payment System will update the User's balance.
+
+Then, users can send proofs to the Batcher, the Batcher will preemptively check if the user has funds for this, and once the whole batch is assembled, the Batcher will call its smart contract with the data it has received from the users.
+
+The smart contract will then discount the corresponding amount of funds from each of the senders' balances, and create a new Batch in [Aligned Service Manager](./3_service_manager_contract.md), sending with it the corresponding amount of tokens for the batch verification to be paid to the [Aggregator](./5_aggregator.md).
+
+Users can then withdraw extra funds deposited to the Batcher Payments smart contract, or leave them to fund future proofs.
+
+This way, the Batcher can only use User funds to pay for the verification of the User's proofs.
+
+## Details of the contract
+
+### API
+
+#### Receive funds
+
+```solidity
+    receive() external payable
+```
+
+This function will be called every time a User transfers funds to the smart contract. It will not only receive the funds, but it will also register internally how much the User deposited, to keep track of each User's funds separately. 
+
+
+#### Create New Task
+
+```solidity
+    function createNewTask(
+        bytes32 batchMerkleRoot,
+        string calldata batchDataPointer,
+        address[] calldata proofSubmitters,
+        uint256 gasForAggregator,
+        uint256 gasPerProof
+    ) external onlyBatcher
+```
+
+This function will be executed only by the Batcher, when it has a batch to post to Aligned. It contains all the information needed to post the batch in [Aligned Service Manager](./3_service_manager_contract.md) (`batchMerkleRoot` and `batchDataPointer`), plus an array containing which are the `proofSubmitters`, so as to discount `gasPerProof` from these, and also the `gasForAggregator`, declaring how much will need to go pay for the response of the batch.
+
+#### Withdraw
+
+```solidity
+    function withdraw(uint256 amount) external
+```
+
+This function can be called by any User, to freely withdraw any amount of their available balance from the contract.

docs/architecture/components/2_payment_service_contract.md

@@ -0,0 +1,64 @@
+# Aligned Service Manager Contract
+
+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.
+
+Then, when receiving a response from the [Aggregator](./5_aggregator.md), with Operator's aggregated BLS signatures, the Aligned Service Manager checks the BLS signature to verify the Operators were in fact those who processed the batch and its responded status.
+
+Once verified, it will emit another Event, for anyone interested (for example, the [Explorer](./6_explorer.md)) to know that the batch was verified by the operators. This batch is now verified and Users can know their proofs inside the batch were proven and verified leveraging Ethereum's security.
+
+## 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.
+
+### API
+
+#### Create new task
+
+```solidity
+function createNewTask(
+    bytes32 batchMerkleRoot,
+    string calldata batchDataPointer
+) external payable
+```
+
+This method is called to create a new batch verification task that will broadcast an event to all operators, signaling that there are new proofs awaiting verification.
+
+* `batchMerkleRoot` is a 256 bit hash corresponding to the Merkle Root of the proofs batch to be verified by operators.
+* `batchDataPointer` is a string representing a link to some specific data storage location. This is used by operators to download the entire batch of proofs.
+
+#### Respond to task
+
+```solidity
+function respondToTask(
+    bytes32 batchMerkleRoot,
+    NonSignerStakesAndSignature memory nonSignerStakesAndSignature
+) external
+```
+
+This method is used by the Aggregator once the quorum for a particular task has been reached. Its main purpose is to verify the aggregated signature of the operators for the given task, and also that the quorum was reached. After verifying, an event is emitted signaling to any consumer that the batch has reached soft finality.
+
+* `batchMerkleRoot` is a 256 bit hash representing the Merkle Root of the batch that has been verified and signed by operators.
+* `nonSignerStakesAndSignature` is a struct provided by EigenLayer middleware with information about operators' signatures, stakes and quorum for the given task.
+
+### Verify batch inclusion
+
+```solidity
+function verifyBatchInclusion(
+    bytes32 proofCommitment,
+    bytes32 pubInputCommitment,
+    bytes32 provingSystemAuxDataCommitment,
+    bytes20 proofGeneratorAddr,
+    bytes32 batchMerkleRoot,
+    bytes memory merkleProof,
+    uint256 verificationDataBatchIndex
+) external view returns (bool)
+```
+
+A method used for consumers to check that their proof was verified in Aligned. It checks if the batch where the proof was included was verified and if the proof was included in the batch when verifying the Merkle path.
+
+* `proofCommitment`, `pubInputCommitment`, `provingSystemAuxDataCommitment`, `proofGeneratorAddr` are the commitments to the verification data sent to the batcher.
+* `batchMerkleRoot` is a 256 bit hash representing the batch Merkle Root the proof was included in.
+* `merkleProof` is the Merkle path from the hashed leaf built from the verification data commitments to the root.
+* `verificationDataBatchIndex` is the index of the proof in the batch where it was included.

docs/architecture/components/3_service_manager_contract.md

@@ -0,0 +1,11 @@
+# Operator
+
+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. 
+
+With the data pointer, they will download the actual proofs they will need to verify. The first thing they do after this, is verify that the downloaded proofs actually compute the expected Merkle Root. If not, they will regard the batch as corrupted and will not verify it. This avoids malicious [Batchers](./1_batcher.md) from uploading proofs that are different from what [Users](0_user.md) uploaded.
+
+After verifying the Merkle Root of the batch, thus verifying that the downloaded batch matches the one intended to be submitted, the Operator must now verify each one of its proofs. This is done by executing the appropriate verification programs integrated with Aligned.
+
+After verifying the whole batch, Operators sign their response (either true or false depending on whether the batch was completely verified or not) with a BLS signature, and send it to the [Aggregator](./5_aggregator.md).

docs/architecture/components/4_operator.md

@@ -0,0 +1,6 @@
+# Aggregator
+
+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).
+

docs/architecture/components/5_aggregator.md

@@ -0,0 +1,32 @@
+# Explorer
+
+{% embed url="https://explorer.alignedlayer.com" %}
+
+The Explorer keeps track of [Aligned Service Manager](./3_service_manager_contract.md).
+
+It has an internal state of previous batches, actively listens for new batches and their responses. The Explorer then displays this information for Users to visualize the submitted batches, their states and more useful information in real time.
+
+In the landing page we can see information such as how many [Operators](./4_operator.md) are currently registered and running, how many Batches and how many total Proofs have been verified.
+
+![](../../images/explorer-landing-page.png)
+
+From here, we can search for a specific batch by its Merkle Root, we can directly jump to any one of the last 5 submitted batches, and we can easily go to the `Latest Batches` page, where we can navigate through the various pages of batches of proofs submitted to aligned, ordered by latest submission, and easily check their on-chain status, timestamp, and block number.
+
+![](../../images/explorer-latest-batches.png)
+
+From there we can also click any individual batch Merkle Root to view its details.
+
+From here we can visualize:
+
+- the whole `Merkle Root`
+- `Amount of Proofs` in the batch
+- Ethereum's `Submission Block Number`, linked to etherscan
+- `Submission Transaction Hash`, linked to etherscan
+- `Submission Timestamp` of the batch
+- `Status`, either `Pending` or `Verified`
+- Ethereum's `Response Block Number`, linked to etherscan
+- `Response Transaction Hash`, linked to etherscan
+- `Response Timestamp` of the batch
+
+![](../../images/explorer-batch-details.png)
+