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 provides details of the Etrog upgrade, which is Polygon zkEVM's upgrade that succeeds the dragonfruit upgrade.
3
+
This document provides details of the Etrog upgrade, which is Polygon zkEVM's upgrade that succeeds the Dragonfruit upgrade.
4
4
5
5
Although the Dragonfruit upgrade had some advantages over previous zkEVM versions, it has its own pain points. We take a look at what these pain points are, and how the Etrog upgrade resolves them.
6
6
7
7
Before discussing all these, we present the newly launched testnet that coincides with the Etrog upgrade.
8
8
9
-
10
-
11
9
## Cardona testnet
12
10
13
-
In addition to the Goërli testnet, a second testnet is launched on Sepolia and it is dubbed Cardona.
11
+
In addition to the Goërli testnet, we launched a second testnet on Sepolia dubbed Cardona.
14
12
15
13
Due to the looming deprecation of the Goërli testnet, the Polygon team had to put in place a second testnet. This ensures that the zkEVM can continue running even beyond the Goërli's discontinuation.
16
14
17
-
Cardona testnet is ready for developers and users to connect wallets, and begin testing the Etrog upgrade of Polygon zkEVM.
15
+
The Cardona testnet is ready for developers and users to connect wallets, and begin testing the Etrog upgrade of Polygon zkEVM.
18
16
19
17
Use the following details to connect wallets to Cardona:
20
18
@@ -32,9 +30,6 @@ Use the following details to connect wallets to Cardona:
32
30
33
31
We use the same faucet for testnet tokens, here: https://faucet.polygon.technology/
34
32
35
-
36
-
37
-
38
33
## zkEVM is type-2
39
34
40
35
The Etrog upgrade comes with support for most of the EVM's [precompiled contracts](https://www.evm.codes/precompiled?fork=shanghai); ecRecover, SHA-256, identity, modexp, ecAdd, ecMul, and ecPairing. This only leaves out the barely used RIPEMD-160 and blake2f.
Dragonfruit upgrade inherited from its predecessors, the configuration that each block in the zkEVM is equivalent to one L2 transaction.
45
+
Dragonfruit upgrade inherited from its predecessors the configuration that each block in the zkEVM is equivalent to one L2 transaction.
53
46
54
47
The justification for the _one block per transaction_ configuration was that it achieves minimum delay when creating blocks.
55
48
56
49
It however results in a few issues when blocks are processed.
57
50
58
51
The first issue is that it generates a lot of data in the database due to the huge amount of L2 blocks being created.
59
52
60
-
The second being, the approach lacks a way to provide different timestamps for blocks within a batch. So, all blocks in a batch have the same timestamp.
61
-
62
-
However, attaching one timestamp to several blocks causes breaks in dApps that rely on timestamps for proper timing of smart contracts' actions.
53
+
The second being, the approach lacks a way to provide different timestamps for blocks within a batch. So, all blocks in a batch have the same timestamp. However, attaching one timestamp to several blocks causes breaks in dApps that rely on timestamps for proper timing of smart contracts' actions.
63
54
64
55
The crucial alterations made in the Etrog upgrade are therefore on; the _one block per transaction_ approach, and the _one timestamp for many blocks_ problem.
56
+
## Etrog blocks
65
57
66
-
67
-
68
-
## Etrog Blocks
69
-
70
-
Up until the dragonfruit upgrade, each L2 block contains a single transaction. The same approach taken by Optimism.
58
+
Up until the Dragonfruit upgrade, each L2 block contained a single transaction. This is the same approach taken by Optimism.
71
59
72
60
Since a block is formed when the sequencer decides to include a transaction in a batch, prior to the Etrog upgrade, every batch contained as many blocks as transactions. As mentioned above, this resulted in bloated databases.
73
61
74
62
Due to this problem, blocks in the Etrog upgrade have been reconstructed to contain more than one transaction.
75
63
76
64
Blocks with several transactions are achieved by using a small timeout of a few seconds, or a number of milliseconds, when creating the block and waiting for transactions to be added.
77
65
78
-
The below figure displays blocks of the Etrog upgrade vis-à-vis those of the Dragonfruit upgrade.
66
+
The figure below shows the structure of the blocks in Etrog versus those of the Dragonfruit upgrade.
In order to circumvent the above-mentioned issue related to the _one timestamp for many blocks_ problem, each block in the Etrog upgrade's batch receives its own unique timestamp. This is in addition to allowing more than one transaction per block.
87
73
88
-
The solution is achieved by enabling the sequencer to change the timestamp for different blocks within a batch. To do so, a special transaction or marker called `changeL2Block`, is introduced within a batch to mark whenever there is a block change.
74
+
The solution is achieved by enabling the sequencer to change the timestamp for different blocks within a batch. To do so, a special transaction or marker, called `changeL2Block`, is introduced within a batch to mark whenever there is a block change.
89
75
90
-
The below figure shows how `changeL2Block` is used to change the timestamp whenever a new block is formed.
76
+
The figure below shows how `changeL2Block` is used to change the timestamp whenever a new block is formed.
The Etrog upgrade comes with groundbreaking amendments aimed at improving UX and developer experience. The most important additions with this upgrade are the two adjustments that solve the above two issues:
82
+
The Etrog upgrade comes with groundbreaking amendments aimed at improving UX and developer experience. The most important additions with this upgrade are the two adjustments that solve the two issues mentioned-above:
98
83
99
84
- Being able to add multiple transactions to one block.
100
85
- Allowing granularity on the timestamp within a batch.
0 commit comments