Merge pull request 0xPolygon#224 from 0xPolygon/empieichO-docs-review

Update zkEVM - Etrog, EVM diffs & Historical data

Author: EmpieichO

docs/zkEVM/architecture/protocol/etrog-upgrade.md

@@ -40,6 +40,42 @@ The below table displays Polygon zkEVM's precompiled status.
 
 ![Figure: etrog-precompiled](../../../img/zkEVM/etrog-precompiled.png)
 
+
+
+
+
+#### 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.[^e1] |
+| EIP-2930 | Berlin   | Not supported. | Defines the Optional Access Lists transaction type.[^e2]     |
+| EIP-3541 | London   | Supported.     | Reject new contract code starting with the 0xEF byte.[^e3]   |
+
+
+#### 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.
@@ -85,3 +121,9 @@ The Etrog upgrade comes with groundbreaking amendments aimed at improving UX and
 - Allowing granularity on the timestamp within a batch.
 
 Attaining the Type-2 status is remarkable.
+
+
+
+[^e1]: https://eips.ethereum.org/EIPS/eip-2718
+[^e2]: https://eips.ethereum.org/EIPS/eip-2930 
+[^e3]: https://eips.ethereum.org/EIPS/eip-3541 

docs/zkEVM/get-started/historical-data.md

@@ -4,18 +4,18 @@ Join discussions or ask questions on Telegram: https://t.me/polygonzkevm_technic
 
 
 
-### 12th Feb, 2024
+### 13th Feb, 2024
 
 **zkEVM mainnet Upgrade: Etrog hardfork**
 
 This upgrade brings the Polygon zkEVM to being almost a type 2 ZK-EVM. See further details [here](../architecture/protocol/etrog-upgrade.md)
 
 |                 |                           Version                            |
 | :-------------: | :----------------------------------------------------------: |
-|      Node       |                            v0.5.6                            |
-|     Prover      |                            v4.0.4                            |
+|      Node       |                            v0.5.8                            |
+|     Prover      |                            v4.0.8                            |
 |     Bridge      |                            v0.4.0                            |
-| Change logs url | https://github.com/0xPolygonHermez/zkevm-node/releases/tag/v0.5.7 |
+| Change logs url | https://github.com/0xPolygonHermez/zkevm-node/releases/tag/v0.5.8 |
 | Supported ForkIDs | Mainnet & Cardona: ForkIDs 4, 5, 6 & 7.  Testnet (Goerli): ForkIDs 1, 2, 3, 4, 5 & 6. |
 
 

docs/zkEVM/spec/evm-differences.md

@@ -1,4 +1,4 @@
-This document provides a comprehensive list of differences between the EVM and the Polygon zkEVM. The list includes supported EIPs, opcodes, and additional changes made when building the Polygon zkEVM.
+This document provides brief remarks on the differences between the EVM and the Polygon zkEVM. Lists of supported and unsupported EIPs, opcodes, and additional changes made when building the Polygon zkEVM, can be found [here](../architecture/protocol/etrog-upgrade.md).
 
 ### EVM-equivalence
 
@@ -24,58 +24,9 @@ EVM-equivalence is critical to Polygon zkEVM for several reasons, including the
 
 Ultimately, Polygon zkEVM offers developers the same UX as on Ethereum, with significantly improved scalability.
 
-
-!!!info
-    No impact on developer experience
-
-    Note that the following differences have no impact on the developer experience with the zkEVM as compared to the EVM. Gas optimization techniques, interacting with libraries like Web3.js and Ethers.js, and deploying contracts work seamlessly on the zkEVM without any overhead.
-
 The following differences have no impact on the developer's experience on the zkEVM compared to the EVM:
 
    - Gas optimization techniques.
    - Interacting with libraries, like Web3.js and Ethers.js.
    - Deploying contracts seamlessly on the zkEVM without any overhead.
 
-
-### Opcodes
-
-Below is a list of the changes we have made to opcodes in zkEVM in comparison to the EVM.
-   
-   - **SELFDESTRUCT** → removed and replaced by **SENDALL**.
-
-   - `EXTCODEHASH` returns the hash of the contract bytecode from the zkEVM state tree without checking if the account is empty.
-
-   - **DIFFICULTY** →  returns "0" instead of a random number as in the EVM.
-
-   - **BLOCKHASH** → returns all previous block hashes instead of just the last 256 blocks.
-
-   > **BLOCKHASH** is the state root at the end of a processable transaction and is stored on the system smart contract.
-
-   - **NUMBER** → returns the number of processable transactions.
-
-
-### Precompiled contracts
-
-Among Ethereum's precompiled contracts, the zkEVM currrently supports: [`ecRecover`](https://www.evm.codes/precompiled?fork=shanghai) and [`identity`](https://www.evm.codes/precompiled?fork=shanghai).
-
-Other precompiled contracts have no effect on the zkEVM state tree and are treated as reverts, returning all gas to the previous context and setting the `success` flag to "0".
-
-
-## Additions
-
-**zk-counters** → batch resources are available, linked to state-machine components, as a supplementary addition to gas computation.
-
-
-## Other minor differences
-   
-   - zkEVM doesn't clean storage when a contract is deployed at an address due to the zkEVM state tree specification.
-
-   - `JUMPDEST` is allowed in push bytes to avoid runtime bytecode analysis.
-
-   - The zkEVM implements [EIP-3541](https://eips.ethereum.org/EIPS/eip-3541) from the [London hardfork](https://ethereum.org/en/history/#london).
-
-   - [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) which defines the Typed Transaction Envelope, is not supported
-
-   - [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930), which defines the Optional Access Lists transaction type, is not supported.
-
-   - [`BASEFEE`](https://ethereum-org-fork.netlify.app/en/developers/docs/gas#base-fee) opcode is not supported. The zkEVM implements the Berlin hardfork, but not the London hardfork.