You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Aligned’s architecture is shown in the figure below:
5
6
6
7
7
8
8
-
Here, 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.
9
+
Here, the validators/AVS operators are the ones responsible for proof verification.
10
+
They fetch the proof data from the data service and verify it using the different proving systems supported by Aligned.
11
+
12
+
### What happens when sending a proof and publishing the result on Ethereum?
9
13
10
-
### Flow for sending a proof and publishing the result on Ethereum
11
14
The flow for sending a proof and having the results on Ethereum is as follows:
12
-
1. The user uses a provided CLI or SDK to send one proof or many to the batcher, and waits.
13
-
2. The batcher answers with a BatchInclusionData for each proof.
14
-
3. The user invokes the VerifyBatchInclusion function in the ServiceManager contract with this data to check that the proof has been verified in Aligned and is included in the batch.
15
-
4. Then, it is checked that the commitment of the proven program matches the expected one.
15
+
16
+
1. The user uses a provided CLI or SDK to send one or many proofs to the batcher, and waits.
17
+
2. The batcher answers with a ValidityResponse for each proof (if proof, nonce and signature are valid).
18
+
3. The batcher answers with a BatchInclusionData for each proof.
19
+
4. The user invokes the VerifyBatchInclusion function in the ServiceManager contract with this data to check that the
20
+
proof has been verified in Aligned and is included in the batch.
21
+
5. Then, it is checked that the commitment of the proven program matches the expected one.
16
22
17
23
### Full flow with internals of the proof
18
24
19
-
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).
20
-
2. The batcher accumulates proofs of many users for a small number of blocks (typically 1-3).
21
-
3. The batcher creates a Merkle Tree with commitments of all the data submitted by users, uploads the proofs to the Data Service, and creates the verification task in the ServiceManager.
22
-
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.
23
-
5. If the proofs are valid, they sign the root and send this to the BLS signature aggregator.
24
-
6. The signature aggregator accumulates the signed responses until reaching the quorum, then sends the aggregated signature to Ethereum.
25
-
7. Ethereum verifies the aggregated signatures and changes the state of the batch to verified.
25
+
1. The user uses a provided CLI or SDK to send one or more proofs to the batcher, and waits (Alternatively, the user can
26
+
run a batcher or interact directly with Ethereum).
27
+
2. The batcher accumulates proofs of many users for a small number of blocks (typically 1–3).
28
+
3. The batcher creates a Merkle Tree with commitments of all the data submitted by users, uploads the proofs to the Data
29
+
Service,
30
+
and submits it to the [Batcher Payment Service](./components/2_payment_service_contract.md)
31
+
4. The Batcher Payment Service rebuilds the merkle tree, and then verifies user signatures and nonce's.
32
+
5. The Batcher Payment Service sends the batch to
33
+
the [Aligned Service Manager](./components/3_service_manager_contract.md).
34
+
6. The operators, using the data in Ethereum, download the proofs from the DataService.
35
+
They then verify that the Merkle root is equal to the one in Ethereum, and verifies all the proofs.
36
+
7. If the proofs are valid, they sign the root and send this to the BLS signature aggregator.
37
+
8. The signature aggregator accumulates the signed responses until reaching the quorum, then sends the aggregated
38
+
signature to Ethereum.
39
+
9. Ethereum verifies the aggregated signatures and changes the state of the batch from pending to verified.
The Payment Service handles User's payments to fund the verification of their proofs.
3
+
The Payment Service handles User's payments to fund the verification of their proofs.
4
4
5
-
To be able to use the batcher, a user must fund its transactions. For this, there is a simple Batcher Payment System.
5
+
To be able to use the batcher, a user must fund its transactions.
6
+
For this, there is a simple Batcher Payment System.
6
7
7
-
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.
8
+
The Batcher has an associated Batcher Payments smart contract,
9
+
which is in charge of receiving user's payments,
10
+
and it guarantees that it can only spend these funds to send users' proofs to Aligned.
8
11
9
-
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.
12
+
Users must first deposit into this contract, via a normal transfer to its address,
13
+
where the Batcher Payment System will update the User's balance.
10
14
11
-
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.
15
+
Users send proofs to the Batcher, which checks for sufficient funds.
16
+
Once a batch is complete, the Batcher calls its smart contract with the collected user data
12
17
13
-
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).
18
+
The smart contract deducts funds from senders' balances and creates a new Batch in
19
+
the [Aligned Service Manager](./3_service_manager_contract.md),
20
+
including tokens for batch verification payment to the [Aggregator](./5_aggregator.md).
14
21
15
-
Users can then withdraw extra funds deposited to the Batcher Payments smart contract, or leave them to fund future proofs.
22
+
Users can then withdraw extra funds deposited to the Batcher Payments smart contract,
23
+
or leave them to fund future proofs.
16
24
17
25
This way, the Batcher can only use User funds to pay for the verification of the User's proofs.
18
26
27
+
The Batcher Payment Service guarantees that the Batcher
28
+
will not be able to spend the user funds for anything other than submitting the user's proofs to Aligned.
29
+
30
+
The way it does is:
31
+
32
+
- When the batcher calls the smart contract to create a new batch,
33
+
it gets the batch merkle tree leaves, with each leaf, signed by the user.
34
+
- The contract then rebuilds the merkle tree to check the
35
+
batch merkle root and verifies the user signatures.
36
+
- Each signature also contains a nonce that can only be used once per user,
37
+
to avoid the batcher being able to reuse the same signature.
38
+
- Only if the merkle root and the signatures are valid, the contract will
39
+
discount the corresponding funds from the user's balance and
40
+
create a new batch in the [Aligned Service Manager](./3_service_manager_contract.md).
41
+
19
42
## Details of the contract
20
43
21
44
### API
@@ -26,27 +49,53 @@ This way, the Batcher can only use User funds to pay for the verification of the
26
49
receive() external payable
27
50
```
28
51
29
-
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.
30
-
52
+
This function will be called every time a User transfers funds to the smart contract.
53
+
It will not only receive the funds, but it will also register internally how much the User deposited,
54
+
to keep track of each User's funds separately.
31
55
32
56
#### Create New Task
33
57
34
58
```solidity
35
59
function createNewTask(
36
60
bytes32 batchMerkleRoot,
37
61
string calldata batchDataPointer,
38
-
address[] calldata proofSubmitters,
62
+
bytes32[] calldata leaves, // padded to the next power of 2
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.
69
+
This function will be executed only by the Batcher when it has a batch to post to Aligned.
70
+
It contains all the information needed to post the batch
71
+
in [Aligned Service Manager](./3_service_manager_contract.md) (`batchMerkleRoot`
72
+
and `batchDataPointer`), plus an array containing which are the `proofSubmitters`, to discount `gasPerProof` from
73
+
these, and also the `gasForAggregator`, declaring how much will need to go pay for the response of the batch.
74
+
75
+
#### Unlock
76
+
77
+
```solidity
78
+
function unlock() external
79
+
```
80
+
81
+
Any user can call this function to unlock its funds for withdrawal after 100 blocks.
82
+
83
+
Note that if the user funds are unlocked, the batcher will reject any new proofs from this user until the funds are
84
+
locked again.
85
+
86
+
#### Lock
87
+
88
+
```solidity
89
+
function lock() external
90
+
```
91
+
92
+
Any user can call this function to lock its funds again after unlocking.
45
93
46
94
#### Withdraw
47
95
48
96
```solidity
49
97
function withdraw(uint256 amount) external
50
98
```
51
99
52
-
This function can be called by any User, to freely withdraw any amount of their available balance from the contract.
100
+
Any User can call this function to withdraw any amount of their available balance from the contract,
0 commit comments