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
This document is a continuation in the series of articles explaining the [Transaction Life Cycle](submit-transaction.md) inside Polygon zkEVM.
3
+
This document is a continuation in the series of articles explaining the [transaction life cycle](submit-transaction.md) inside Polygon zkEVM.
4
4
5
-
The Trusted Aggregator should aggregate the sequences of batches previously committed by the Trusted Sequencer in order to achieve the L2 State final stage, which is the Consolidated State.
5
+
The trusted aggregator should aggregate the sequences of batches previously committed by the trusted sequencer in order to achieve the L2 state final stage, which is the consolidated state.
6
6
7
-
Aggregating a sequence means successfully adding the resulting L2 State root to the `batchNumToStateRoot` mapping in the L1 'PolygonZkEVM.sol' contract. This is a storage structure that contains all of the consolidated L2 State roots, which are keyed by the last batch index of each aggregated sequence of batches.
7
+
Aggregating a sequence means successfully adding the resulting L2 state root to the `batchNumToStateRoot` mapping in the L1 `PolygonZkEVM.sol` contract. This is a storage structure that contains all of the consolidated L2 state roots, which are keyed by the last batch index of each aggregated sequence of batches.
8
8
9
9
```
10
10
// BatchNum --> state root
11
11
mapping (uint64 => bytes32) public batchNumToStateRoot;
12
12
```
13
13
14
-
Furthermore, the aggregation implies the successful verification of the Zero-Knowledge proof of the computational integrity of the transaction batches execution.
14
+
Furthermore, the aggregation implies the successful verification of the zero-knowledge proof of the computational integrity of the transaction batches execution.
15
15
16
-
A SNARK (Succinct Non-interactive Arguments of Knowledge) is the underlying Zero-Knowledge proof verification schema. One of its key characteristics is the proof's conciseness and speed of verification.
16
+
A SNARK (succinct non-interactive arguments of knowledge) is the underlying zero-knowledge proof verification schema. One of its key characteristics is the proof's conciseness and speed of verification.
17
17
18
18
As a result, the integrity of an exhaustive computation can be verified using a fraction of the computational resources required by the original computation. As a result, by employing a SNARK schema, we can provide on-chain security to exhaustive off-chain computations in a gas-efficient manner.
19
19
20
20
21
21
22
22
As shown in the above diagram, the off-chain execution of the batches will suppose an L2 state transition and consequently, a change to a new L2 state root.
23
23
24
-
A computation integrity (CI) proof of the execution is generated by the Aggregator, and its on-chain verification ensures validity of that resulting L2 state root.
24
+
A computation integrity (CI) proof of the execution is generated by the aggregator, and its on-chain verification ensures validity of that resulting L2 state root.
25
25
26
26
## Aggregating a sequence of batches
27
27
28
-
In order to aggregate a sequence of batches, the Trusted Aggregator must call the `trustedVerifyBatches` method:
28
+
In order to aggregate a sequence of batches, the trusted aggregator must call the `trustedVerifyBatches` method:
29
29
30
30
```
31
31
function trustedVerifyBatches (
@@ -42,31 +42,31 @@ function trustedVerifyBatches (
42
42
43
43
where,
44
44
45
-
-`pendingStateNum` is the number of state transitions pending to be consolidated, which is set to 0 for as long as the Trusted Aggregator is in operation. The `pendingState` functions as a security measure to be used when L2 state is consolidated by an independent Aggregator.
45
+
-`pendingStateNum` is the number of state transitions pending to be consolidated, which is set to 0 for as long as the trusted aggregator is in operation. The `pendingState` functions as a security measure to be used when L2 state is consolidated by an independent aggregator.
46
46
-`initNumBatch` is the index of the last batch in the last aggregated sequence.
47
47
-`finalNewBatch` is the index of the last batch in the sequence being aggregated.
48
-
-`newLocalExitRoot` is the root of the Bridge’s L2 Exit Merkle Tree at the end of sequence execution used to compute new Global Exit Root when the sequence is aggregated, and allows bridge claiming transactions to be successfully executed in L1.
49
-
-`newStateRoot` is the L2 StateRoot resulting from the execution of the sequence of batches over an older L2 State.
50
-
-`proof(A,B and C)` is the Zero-Knowledge proof.
48
+
-`newLocalExitRoot` is the root of the Bridge’s L2 exit Merkle tree at the end of sequence execution used to compute new global exit root when the sequence is aggregated, and allows bridge claiming transactions to be successfully executed in L1.
49
+
-`newStateRoot` is the L2 state root resulting from the execution of the sequence of batches over an older L2 state.
50
+
-`proof(A,B and C)` is the zero-knowledge proof.
51
51
52
52
For a sequence of batches to be successfully aggregated, the following conditions must be met:
53
53
54
-
- Aggregation transaction must be sent from the Trusted Aggregator account.
55
-
-`initNumBatch` argument must be the index of an already aggregated batch. That is, it must have an L2 State root in `batchNumToStateRoot` mapping.
54
+
- Aggregation transaction must be sent from the trusted aggregator account.
55
+
-`initNumBatch` argument must be the index of an already aggregated batch. That is, it must have an L2 state root in `batchNumToStateRoot` mapping.
56
56
-`initNumBatch` argument must be less or equal to the last aggregated batch index.
57
57
- The sequence to be aggregated must have at least one batch.
58
58
-`initNumBatch` and `finalNewBatch` arguments have to be sequenced batches, that is, to be present in the `sequencedBatches` mapping.
59
-
- Zero-Knowledge proof of computational integrity must be successfully verified.
59
+
- Zero-knowledge proof of computational integrity must be successfully verified.
60
60
61
-
The Executor and the Prover are services of the Aggregator node that execute batches and generate Zero-Knowledge proofs. We will herein treat them as Ethereum Virtual Machine black box interpreters that can:
61
+
The executor and the prover are services of the aggregator node that execute batches and generate zero-knowledge proofs. We will herein treat them as Ethereum Virtual Machine black box interpreters that can:
62
62
63
63
- execute a sequence of transaction batches on the current L2 state,
64
64
- calculate the resulting L2 state root, and
65
-
- generate a Zero-Knowledge proof of computational integrity for the execution.
65
+
- generate a zero-knowledge proof of computational integrity for the execution.
66
66
67
-
The proving/verification system is designed in such a way that successful proof verification equates to cryptographically proving that executing the given sequence of batches over a Specific L2 State results in an L2 State represented by the `newStateRoot` argument.
67
+
The proving/verification system is designed in such a way that successful proof verification equates to cryptographically proving that executing the given sequence of batches over a specific L2 state results in an L2 state represented by the `newStateRoot` argument.
68
68
69
-
The following code snippet is a part of the [`PolygonZkEVM.sol`](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/contracts/PolygonZkEVM.sol) contract, which shows the Zero-Knowledge proof verification:
69
+
The following code snippet is a part of the [`PolygonZkEVM.sol`](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/contracts/PolygonZkEVM.sol) contract, which shows the zero-knowledge proof verification:
70
70
71
71
```
72
72
// Get snark bytes
@@ -88,35 +88,31 @@ require (
88
88
);
89
89
```
90
90
91
-
### rollupVerifier
91
+
### `RollupVerifier`
92
92
93
93
`rollupVerifier` is an external contract that has a function `verifyProof` that takes a proof (`proofA`, `proofB`, `proofC`) and a value `inputSnark` and returns a boolean value that will be `true` if the proof is valid and `false` if it isn’t.
94
94
95
95
The successful verification of the proof just confirms the integrity of the computation, but not that the correct inputs were used and that they resulted in the correct output values. Public arguments are used to publicly disclose key points of the computation being proved, in order to prove that it was performed using the correct inputs and reveal the outputs.
96
96
97
-
This way, during the proof verification, the L1 smart contract will set the public arguments to ensure that the state transition being proved corresponds to the execution of the batches committed by the Trusted Sequencer.
97
+
This way, during the proof verification, the L1 smart contract will set the public arguments to ensure that the state transition being proved corresponds to the execution of the batches committed by the trusted sequencer.
98
98
99
-
### inputSnark
99
+
### `inputSnark`
100
100
101
-
`inputSnark` is a 256-bits unique cryptographic representative of a specific L2 State transition, which is used as public argument. It is computed as `sha256 mod % _RFIELD` hash of a bytes string called `snarkHashBytes` (modulo operator is needed due to math primitives used in SNARKs).
101
+
`inputSnark` is a 256-bits unique cryptographic representative of a specific L2 state transition, which is used as public argument. It is computed as `sha256 mod % _RFIELD` hash of a bytes string called `snarkHashBytes` (modulo operator is needed due to math primitives used in SNARKs).
102
102
103
103
`snarkHashBytes` array is computed by a smart contract’s function called `getInputSnarkBytes` and it is an ABI-encoded packed string of the following values:
104
104
105
-
-**msg.sender**: Address of Trusted Aggregator.
106
-
-**oldStateRoot**: L2 State Root that represents the L2 State before the state transition
107
-
that wants to be proven.
108
-
-**oldAccInputHash**: Accumulated hash of the last batch aggregated.
109
-
-**initNumBatch**: Index of the last batch aggregated.
110
-
-**chainID**: Unique chain identifier.
111
-
-**newStateRoot**: L2 State Root that represents the L2 State after the state transition
112
-
that is being proved.
113
-
-**newAccInputHash**: Accumulated hash of the last batch in the sequence that is
114
-
being aggregated.
115
-
-**newLocalExitRoot**: Root of the Bridge’s L2 Exit Merkle Tree at the end of
116
-
sequence execution.
117
-
-**finalNewBatch**: Number of the final batch in the execution range.
118
-
119
-
`inputSnark` will represent all the L2 transactions of a specific L2 State transition, executed in a specific order, in a specific L2 (`chainID`), and proved by a specific Trusted Aggregator (`msg.sender`). The `trustedVerifyBatches` function not only verifies the validity of the zero-knowledge proof, but it also checks that the value of `inputSnark` corresponds to an L2 State transition that is pending to be aggregated.
105
+
-`msg.sender`: Address of trusted aggregator.
106
+
-`oldStateRoot`: L2 state root that represents the L2 state before the state transition that wants to be proven.
107
+
-`oldAccInputHash`: Accumulated hash of the last batch aggregated.
108
+
-`initNumBatch`: Index of the last batch aggregated.
109
+
-`chainID`: Unique chain identifier.
110
+
-`newStateRoot`: L2 state root that represents the L2 state after the state transition that is being proved.
111
+
-`newAccInputHash`: Accumulated hash of the last batch in the sequence that is being aggregated.
112
+
-`newLocalExitRoot`: Root of the bridge’s L2 exit Merkle tree at the end of sequence execution.
113
+
-`finalNewBatch`: Number of the final batch in the execution range.
114
+
115
+
`inputSnark` will represent all the L2 transactions of a specific L2 state transition, executed in a specific order, in a specific L2 (`chainID`), and proved by a specific trusted aggregator (`msg.sender`). The `trustedVerifyBatches` function not only verifies the validity of the zero-knowledge proof, but it also checks that the value of `inputSnark` corresponds to an L2 State transition that is pending to be aggregated.
120
116
121
117
If the internal call to `_verifyAndRewardBatches` returns `true`, it will mean that the sequence of batches is verified successfully, and then the `newStateRoot` argument will be added to the `batchNumToStateRoot` mapping. The index of the last batch in the sequence will be used as the key for the entry.
122
118
@@ -130,4 +126,4 @@ event TrustedVerifyBatches (
130
126
);
131
127
```
132
128
133
-
Once the batches have been successfully aggregated in L1, all zkEVM nodes can validate their local L2 state by retrieving and validating consolidated roots directly from the L1 Consensus Contract (`PolygonZkEVM.sol`). As a result, the L2 consolidated State has been reached.
129
+
Once the batches have been successfully aggregated in L1, all zkEVM nodes can validate their local L2 state by retrieving and validating consolidated roots directly from the L1 consensus contract (`PolygonZkEVM.sol`). As a result, the L2 consolidated state has been reached.
0 commit comments