Etrog upgrade

This document provides details of the Etrog upgrade, which is Polygon zkEVM's upgrade that succeeds the Dragonfruit upgrade. Although the Dragonfruit upgrade ha

This document provides details of the Etrog upgrade, which is Polygon zkEVM's upgrade that succeeds the Dragonfruit upgrade.

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.

Before discussing all these, we present the newly launched testnet that coincides with the Etrog upgrade.

Sepolia public testnet: Cardona

In addition to the Goërli testnet, we launched a second testnet on Sepolia dubbed Cardona.

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.

The Cardona testnet is ready for developers and users to connect wallets, and begin testing the Etrog upgrade of Polygon zkEVM.

Use the following details to connect wallets to Cardona:

Network Name: Polygon zkEVM Cardona Testnet
Bridge UI: https://bridge-ui.cardona.zkevm-rpc.com
New RPC URL: https://rpc.cardona.zkevm-rpc.com
Chain ID: 2442
Currency symbol: ETH
Explorer: https://cardona-zkevm.polygonscan.com/

We use the same faucet for testnet tokens, here: https://faucet.polygon.technology/

zkEVM is almost type 2

The Etrog upgrade comes with support for most of the EVM's precompiled contracts; ecRecover, SHA-256, identity, modexp, ecAdd, ecMul, and ecPairing. This only leaves out the barely used RIPEMD-160 and blake2f.

Owing to this fact, the Etrog upgrade therefore helps Polygon zkEVM inch closer to becoming a type 2 ZK-EVM.

The below table displays Polygon zkEVM's precompiled status.

Figure: etrog-precompiled

Supported opcodes

`OPCODE`	Support status	Details
`SELFDESTRUCT`	Not supported	Replaced by SENDALL.
`EXTCODEHASH`	Supported	It returns the hash of the contract bytecode from the zkEVM state tree without checking if the account is empty.
`DIFFICULTY`	Supported	It returns "0" instead of a random number as in the EVM.
`BLOCKHASH`	Supported	It is the state root at the end of a processable transaction and is stored on the system smart contract. It returns all previous block hashes instead of just the last 256 blocks.
`NUMBER`	Supported	It returns the number of processable transactions.
`JUMPDEST`	Supported	It is allowed in PUSH bytes to avoid runtime bytecode analysis.
`BASEFEE`	Not supported	The zkEVM implements the Berlin hardfork, but not the London hardfork.

EIPs support

EIPs	Hardfork	Support status	Description
EIP-2718	Berlin	Not supported.	Defines a new transaction type that is an envelope for future transaction types.¹
EIP-2930	Berlin	Not supported.	Defines the Optional Access Lists transaction type.²
EIP-3541	London	Supported.	Reject new contract code starting with the 0xEF byte.³

Additions

zk-counters indicate batch resources that are available, linked to state-machine components, as a supplementary addition to gas computation.

Dragonfruit issues

Dragonfruit upgrade inherited from its predecessors the configuration that each block in the zkEVM is equivalent to one L2 transaction.

The justification for the one block per transaction configuration was that it achieves minimum delay when creating blocks.

It however results in a few issues when blocks are processed.

The first issue is that it generates a lot of data in the database due to the huge amount of L2 blocks being created.

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.

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.

Etrog blocks

Up until the Dragonfruit upgrade, each L2 block contained a single transaction. This is the same approach taken by Optimism.

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.

Due to this problem, blocks in the Etrog upgrade have been reconstructed to contain more than one transaction.

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.

The figure below shows the structure of the blocks in Etrog versus those of the Dragonfruit upgrade.

Figure: etrog-blocks-vs-dragonfruit

Etrog timestamps

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.

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.

The figure below shows how changeL2Block is used to change the timestamp whenever a new block is formed.

Figure: etrog-changel2block

Conclusion

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:

Being able to add multiple transactions to one block.
Allowing granularity on the timestamp within a batch.

Attaining the Type-2 status is remarkable.

Etrog upgrade

On this page