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
5.1.6 Enter the amount (e.g. 5) to bridge and click **Continue**, you will see the **Confirm Bridge** page.
228
+
5.1.6 Enter the amount (e.g. 5) to bridge and click **Continue**, after confirming you understood what you're doing, you will see the **Confirm Bridge** page.
215
229
216
230
5.1.7 Click **Bridge** and approve the transaction on the MetaMask pop-up:
Copy file name to clipboardExpand all lines: docs/zkEVM/architecture/zknode/index.md
-94Lines changed: 0 additions & 94 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -72,97 +72,3 @@ Required services and components:
72
72
73
73
It's recommended that the prover is run on a separate instance, as it has important hardware requirements. On the other hand, all the other components can run on a single instance.
74
74
75
-
76
-
******************* *****************************
77
-
78
-
79
-
80
-
81
-
### (new version) ... zkEVM vs EVM differences
82
-
83
-
This document provides a comprehensive list of differences between the Ethereum Virtual Machine (EVM) and the Polygon Zero-Knowledge Ethereum Virtual Machine (zkEVM). The list includes supported EIPs, opcodes, and additional changes made to build the zkEVM.
84
-
85
-
86
-
87
-
### EVM-equivalence
88
-
89
-
Polygon zkEVM aiming being a Type-2, is designed to be EVM-equivalent rather than being compatible.
90
-
91
-
The difference between EVM-compatibility and EVM-equivalence is that;
92
-
93
-
- Solutions that are compatible, enable most of the existing applications to work, but sometimes with code changes. Additionally, compatibility may lead to the breaking of developer toolings.
94
-
- Polygon zkEVM strives for EVM-equivalence which means most applications, tools, and infrastructure built on Ethereum can immediately port over to Polygon zkEVM, with limited to no changes needed. Things are designed to work 100% on day one.
95
-
96
-
EVM-equivalence is critical to Polygon zkEVM for several reasons, including the following:
97
-
98
-
1. Development teams don't have to make changes to their code, and thus nullifies any chance to introduce security vulnerabilities.
99
-
2. No code changes, means no need for additional audits. This saves time and money.
100
-
3. Polygon zkEVM benefits from the security and decentralization of Ethereum, since transactions are still finalizing on Ethereum.
101
-
4. EVM-equivalence allows Polygon zkEVM to benefit from the already vibrant and active Ethereum community.
102
-
5. It also allows for significant and quick dApp adoption, because applications built on Ethereum are automatically compatible.
103
-
104
-
Ultimately, Polygon zkEVM gives developers an almost identical UX to Ethereum, but with significantly improved scalability.
105
-
106
-
107
-
108
-
!!!info
109
-
No impact on developer experience
110
-
111
-
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.
112
-
113
-
114
-
115
-
Note that the following differences have no impact on the developer experience with the zkEVM as compared to the EVM.
116
-
117
-
- Gas optimization techniques,
118
-
- Interacting with libraries, like Web3.js and Ethers.js,
119
-
- Deploying contracts work seamlessly on the zkEVM without any overhead.
120
-
121
-
122
-
123
-
### Opcodes
124
-
125
-
Below is a list of the changes we have made with Opcodes in zKEVM in comparison to the EVM.
126
-
127
-
-**SELFDESTRUCT**→ removed and replaced by **SENDALL**.
128
-
129
-
-**EXTCODEHASH**→ returns the hash of the contract bytecode from the zkEVM state tree without checking if the account is empty.
130
-
131
-
-**DIFFICULTY**→ returns "0" instead of a random number as in the EVM.
132
-
133
-
-**BLOCKHASH**→ returns all previous block hashes instead of just the last 256 blocks.
134
-
135
-
> **BLOCKHASH** is the state root at the end of a processable transaction and is stored on the system smart contract.
136
-
137
-
-**NUMBER**→ returns the number of processable transactions.
138
-
-**BASEFEE**→ not supported. The zkEVM implements Berlin hardfork, but not the London hardfork.
139
-
140
-
141
-
142
-
### Precompiled contracts
143
-
144
-
Among Ethereum's precompiled contracts, the zkEVM currrently supports: **ecRecover** and **identity**.
145
-
146
-
Other precompiled contracts have no effect on the zkEVM state tree and are treated as a `revert`, returning all gas to the previous context and setting the `success` flag to "0".
147
-
148
-
149
-
150
-
## Additions
151
-
152
-
**zk-counters**→ batch resources are available, linked to state-machine components, as a supplementary addition to gas computation.
153
-
154
-
155
-
156
-
## Other minor differences
157
-
158
-
- zkEVM doesn't clean storage when a contract is deployed at an address due to the zkEVM state tree specification.
159
-
160
-
-**JUMPDEST** opcode is allowed in push bytes to avoid runtime bytecode analysis.
161
-
162
-
- The zkEVM implements [EIP-3541](https://eips.ethereum.org/EIPS/eip-3541) from the [London hardfork](https://ethereum.org/en/history/#london).
163
-
164
-
-[EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) which defines **Typed Transaction Envelope**, is not supported
165
-
-[EIP-2930](https://eips.ethereum.org/EIPS/eip-2930), which defines the **Optional Access Lists** transaction type, is not supported.
Copy file name to clipboardExpand all lines: docs/zkEVM/spec/evm-differences.md
+13-13Lines changed: 13 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,27 +2,27 @@ This document provides a comprehensive list of differences between the EVM and t
2
2
3
3
### EVM-equivalence
4
4
5
-
Polygon zkEVM is designed to be EVM-equivalent rather than just being compatible.
5
+
Polygon zkEVM is designed to be EVM-equivalent rather than just compatible.
6
6
7
7
The difference between EVM-compatibility and EVM-equivalence is that;
8
8
9
-
- Solutions that are compatible, enable most of the existing applications to work, but sometimes with code changes. Additionally, compatibility may lead to the breaking of developer toolings.
9
+
- Solutions that are compatible support most of the existing applications, but sometimes with code changes. Additionally, compatibility may lead to breaking developer tooling.
10
10
11
11
- Polygon zkEVM strives for EVM-equivalence which means most applications, tools, and infrastructure built on Ethereum can immediately port over to Polygon zkEVM, with limited to no changes needed. Things are designed to work 100% on day one.
12
12
13
13
EVM-equivalence is critical to Polygon zkEVM for several reasons, including the following:
14
14
15
-
1. Development teams don't have to make changes to their code, and this eliminates any chance for security vulnerabilities to be introduced.
15
+
1. Development teams don't have to make changes to their code, and this eliminates the possibility of introducing new security vulnerabilities.
16
16
17
-
2. No code changes, means no need for additional audits. This saves time and money.
17
+
2. No code changes means no need for additional audits. This saves time and money.
18
18
19
19
3. Since consolidation of batches and finality of transactions is achieved via smart contracts on Ethereum, Polygon zkEVM benefits from the security of Ethereum.
20
20
21
21
4. EVM-equivalence allows Polygon zkEVM to benefit from the already vibrant and active Ethereum community.
22
22
23
23
5. It also allows for significant and quick dApp adoption, because applications built on Ethereum are automatically compatible.
24
24
25
-
Ultimately, Polygon zkEVM offers developers the exact same UX as on Ethereum, with significantly improved scalability.
25
+
Ultimately, Polygon zkEVM offers developers the same UX as on Ethereum, with significantly improved scalability.
26
26
27
27
28
28
!!!info
@@ -34,16 +34,16 @@ The following differences have no impact on the developer's experience on the zk
34
34
35
35
- Gas optimization techniques.
36
36
- Interacting with libraries, like Web3.js and Ethers.js.
37
-
- Deploying contracts works seamlessly on the zkEVM without any overhead.
37
+
- Deploying contracts seamlessly on the zkEVM without any overhead.
38
38
39
39
40
40
### Opcodes
41
41
42
-
Below is a list of the changes we have made with Opcodes in zkEVM in comparison to the EVM.
42
+
Below is a list of the changes we have made to opcodes in zkEVM in comparison to the EVM.
43
43
44
44
-**SELFDESTRUCT**→ removed and replaced by **SENDALL**.
45
45
46
-
-**EXTCODEHASH**→ returns the hash of the contract bytecode from the zkEVM state tree without checking if the account is empty.
46
+
-`EXTCODEHASH` returns the hash of the contract bytecode from the zkEVM state tree without checking if the account is empty.
47
47
48
48
-**DIFFICULTY**→ returns "0" instead of a random number as in the EVM.
49
49
@@ -56,7 +56,7 @@ Below is a list of the changes we have made with Opcodes in zkEVM in comparison
56
56
57
57
### Precompiled contracts
58
58
59
-
Among Ethereum's precompiled contracts, the zkEVM currrently supports: **ecRecover** and **identity**.
59
+
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).
60
60
61
61
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".
62
62
@@ -70,12 +70,12 @@ Other precompiled contracts have no effect on the zkEVM state tree and are treat
70
70
71
71
- zkEVM doesn't clean storage when a contract is deployed at an address due to the zkEVM state tree specification.
72
72
73
-
-**JUMPDEST** opcode is allowed in push bytes to avoid runtime bytecode analysis.
73
+
-`JUMPDEST` is allowed in push bytes to avoid runtime bytecode analysis.
74
74
75
75
- The zkEVM implements [EIP-3541](https://eips.ethereum.org/EIPS/eip-3541) from the [London hardfork](https://ethereum.org/en/history/#london).
76
76
77
-
-[EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) which defines **Typed Transaction Envelope**, is not supported
77
+
-[EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) which defines the Typed Transaction Envelope, is not supported
78
78
79
-
-[EIP-2930](https://eips.ethereum.org/EIPS/eip-2930), which defines the **Optional Access Lists** transaction type, is not supported.
79
+
-[EIP-2930](https://eips.ethereum.org/EIPS/eip-2930), which defines the Optional Access Lists transaction type, is not supported.
80
80
81
-
-[**BASEFEE**](https://ethereum-org-fork.netlify.app/en/developers/docs/gas#base-fee)opcode is not supported. The zkEVM implements Berlin hardfork, but not the London hardfork.
81
+
-[`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.
0 commit comments