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
While no proof is generated during the pre-execution stage, it ensures that the subsequent proof generation process by the prover can be successfully accomplished. This expedites the overall sequencing of batches.
22
+
While no proof is generated during the pre-execution stage, batch pre-execution ensures that the prover's subsequent proof generation is successful, and expedites batch sequencing overall.
23
23
24
-
A fast executor is employed, which is a _single-computation_ executor, making it capable of executing within blocktime.
24
+
A fast executor is used for batch pre-execution. This is a _single-computation_ executor, capable of executing within blocktime.
25
25
26
-
The sequencer communicates with this executor to perform the pre-execution process swiftly.
26
+
The sequencer communicates with the executor for swift batch pre-execution.
27
27
28
28
Upon determining the transactions that correctly fill a specific batch through successful batch pre-execution, the sequencer records the batch in the node’s StateDB as a _closed batch_.
29
29
30
-
Closure may occur when either one of the following conditions is fulfilled:
30
+
A closed batch means one of the following conditions has been fulfilled:
31
31
32
32
- The maximum number of execution trace rows is reached.
33
33
- The maximum gas limit is attained.
34
34
- The allocated time expires.
35
35
36
-
During batch pre-execution, and for batch closure, the sequencer and the executor update the Merkle tree of the zkEVM with L2 state changes, which is stored in the Prover HashDB. This is illustrated the figure below.
36
+
During batch pre-execution, and for batch closure, the sequencer and the executor update the Merkle tree of the zkEVM with L2 state changes and store them in the prover's hash DB. This is illustrated in the figure below:
The zkEVM's throughput depends highly on the speed at which we are able to close batches, which is directly impacted by the batch pre-execution process.
40
+
The zkEVM's throughput depends on the speed at which we are able to close batches, which is directly impacted by the batch pre-execution process.
41
41
42
-
In fact, most of the performance problems occur here because excessive interaction with the HashDB is inefficient.
42
+
Performance problems can occur here because of excessive and inefficient interaction with the hash DB.
43
43
44
-
Efforts are currently underway to optimize this process:
45
44
46
-
- Reducing the time spent on frequent updates during transaction processing, by accumulating all state changes caused by a transaction, and only update the HashDB at the end of a transaction's pre-execution.
45
+
Optimizing this process may mean reducing the time spent on frequent updates during transaction processing by accumulating all state changes caused by a transaction and only updating the database at the end of a transaction's pre-execution.
47
46
48
47
## Sending batches to L1
49
48
50
49
The next step is to send a call to the smart contract to sequence batches.
51
50
52
-
Once a batch is closed, the sequencer stores the data of the batch in the node’s StateDB.
51
+
Once a batch is closed, the sequencer stores the data of the batch in the node’s state DB.
53
52
54
-
Then, the $\texttt{sequenceSender}$ looks for closed batches and sends them to the [L1 smart contract](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/contracts/PolygonZkEVM.sol) via the $\texttt{EthTxManager}$, who makes sure that the transaction is included in a batch.
53
+
Then, the $\texttt{sequenceSender}$ looks for closed batches and sends them to the [L1 smart contract](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/contracts/PolygonZkEVM.sol) via the $\texttt{EthTxManager}$ which makes sure the transaction is included in a batch.
55
54
56
55
This process is depicted in the figure below.
57
56
58
57
59
58
60
-
In order to sequence a batch, the sequencer calls the $\texttt{sequenceBatches()}$ function in the L1 Smart Contract.
59
+
In order to sequence a batch, the sequencer calls the $\texttt{sequenceBatches()}$ function in the L1 smart contract which can sequence one or multiple batches at once.
61
60
62
-
The name of the function is in plural because it is capable of sequencing several batches at once.
63
61
64
62
This step provides L2 data availability in the L1 execution layer, because we are registering in L1 all the bytes of the L2 transactions.
65
63
66
64
The calldata for the L1 $\texttt{sequenceBatches()}$ function needs to include the following information:
67
65
68
-
- The L2 transactions’ data, which is an array containing data for each batch. It includes all transactions within the batch along with a timestamp indicating its closure time.
66
+
- The L2 transactions data, which is an array containing data for each batch. It includes all transactions within the batch along with a timestamp indicating its closure time.
69
67
- Additionally, the L2 coinbase address, representing the Ethereum address for receiving user fees.
70
68
- Lastly, a timestamp indicating when the L2 transactions were sequenced.
71
69
@@ -75,11 +73,11 @@ The sequencer undertakes the responsibility of paying for data availability in L
75
73
76
74
When the sequencer successfully closes a batch and executes transactions, they receive a reward for their services. This reward, denominated in L2 Ether, is routed to the L2 coinbase address.
77
75
78
-
Crucially, the L2 coinbase address is situated within Layer 2 because users compensate the sequencer with L2 Ether.
76
+
The L2 coinbase address is situated within layer 2 because users compensate the sequencer with L2 Ether.
79
77
80
-
This L2 Ether, representing the reward, is a reflection of the Ether in L1 that users have previously transferred to L2 through transactions via the Bridge.
78
+
This L2 Ether, representing the reward, is a mapping of the Ether in L1 that users have previously transferred to L2 through transactions via the bridge.
81
79
82
-
Importantly, there exists a direct and fixed one-to-one correspondence between L1 ETH and L2 ETH, as we can observe in the figure below.
80
+
There is a direct and fixed one-to-one correspondence between L1 ETH and L2 ETH, as we can observe in the figure below.
83
81
84
82
85
83
@@ -89,7 +87,7 @@ Let's briefly explain how the sequencing operation and the proving process link
89
87
90
88
In particularly, we look at how the prover can match each sequenced batch with its data.
91
89
92
-
When the smart contract receives a call to sequence batches, it initiates creation of cryptographic pointers for each batch.
90
+
When the smart contract receives a transaction for sequencing into batches, it creates a cryptographic pointer for each batch.
93
91
94
92
These pointers play a crucial role in identifying a batch uniquely, specifying its position, and encapsulating its data.
95
93
@@ -99,7 +97,7 @@ The use of cryptographic pointers ensures a robust and unambiguous link between
99
97
100
98
101
99
102
-
These pointers are constructed using a hash that accumulates data, incorporating information from all preceding blocks.
100
+
The pointers are constructed with previous hashes and information from the batches.
103
101
104
102
The procedural steps for this process are illustrated in the figure below:
105
103
@@ -112,8 +110,8 @@ Pointers are generated by executing the KECCAK hash function on:
112
110
- The batch timestamp.
113
111
- The L2 coinbase.
114
112
115
-
Due to the inter-connected nature of their creation, with each pointer encapsulating the previous one in the input of the hash, they are aptly referred to as *accumulated input hash* or $\texttt{accInputHash}$.
113
+
A pointer is referred to as an*accumulated input hash* or $\texttt{accInputHash}$.
116
114
117
115
Such a construction, where previous pointers are linked to the current pointer, guarantees that batch data is proved in the correct and sequential order.
118
116
119
-
Upon completion of the sequencing process, the batch enters a state of being *virtualized*, residing within a _virtual state_.
117
+
When the sequencing process completes, the batch enters a _virtual state_.
0 commit comments