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
@@ -31,14 +31,14 @@ Any user can participate in this role, as an RPC node.
31
31
32
32
Required services and components:
33
33
34
-
- JSON RPC: can run in a separated instance, and can have multiple instances
35
-
- Synchronizer: single instance that can run on a separate instance
36
-
- Executor & Merkletree: service that can run on a separate instance
37
-
- State DB: Postgres SQL that can be run in a separate instance
34
+
- JSON RPC: can run on a separated instance, and can have multiple instances.
35
+
- Synchronizer: single instance that can run on a separate instance.
36
+
- Executor & Merkletree: service that can run on a separate instance.
37
+
- State DB: Postgres SQL that can run on a separate instance.
38
38
39
39
There must be only one synchronizer, and it's recommended that it must have exclusive access to an executor instance, though not necessarily.
40
40
41
-
The synchronizer role can be run perfectly in a single instance, but the JSON RPC and executor services can benefit from running in multiple instances, if the performance decreases due to the number of received requests.
41
+
The synchronizer role can run perfectly in a single instance, but the JSON RPC and executor services can benefit from running in multiple instances, if the performance decreases due to the number of received requests.
@@ -49,27 +49,120 @@ This role can only be performed by a single entity. This is enforced in the smar
49
49
50
50
Required services and components:
51
51
52
-
- JSON RPC: can run in a separated instance, and can have multiple instances
53
-
- Sequencer & Synchronizer: single instance that needs to run together
54
-
- Executor & Merkletree: service that can run on a separate instance
55
-
- Pool DB: Postgres SQL that can be run in a separate instance
56
-
- State DB: Postgres SQL that can be run in a separate instance
52
+
- JSON RPC: can run on a separated instance, and can have multiple instances.
53
+
- Sequencer & synchronizer: single instance that needs to run them together.
54
+
- Executor & Merkletree: service that can run on a separate instance.
55
+
- Pool DB: Postgres SQL that can run on a separate instance.
56
+
- State DB: Postgres SQL that can run on a separate instance.
57
57
58
-
Note that the JSON RPC is required to receive transactions. It's recommended that the JSON RPC runs on separated instances, and potentially more than one (depending on the load of the network). It's also recommended that the JSON RPC and the Sequencer don't share the same executor instance, to make sure that the sequencer has exclusive access to an executor
58
+
Note that the JSON RPC is required to receive transactions. It's recommended that the JSON RPC runs on separated instances, and potentially more than one (depending on the load of the network). It's also recommended that the JSON RPC and the sequencer don't share the same executor instance, to make sure that the sequencer has exclusive access to an executor
59
59
60
60
### Aggregator
61
61
62
62
This role can be performed by anyone.
63
63
64
64
Required services and components:
65
65
66
-
- Synchronizer: single instance that can run on a separated instance
67
-
- Executor & Merkletree: service that can run on a separate instance
68
-
- State DB: Postgres SQL that can be run in a separate instance
69
-
- Aggregator: single instance that can run on a separated instance
70
-
- Prover: single instance that can run on a separated instance
71
-
- Executor: single instance that can run on a separated instance
66
+
- Synchronizer: single instance that can run on a separate instance.
67
+
- Executor & Merkletree: service that can run on a separate instance.
68
+
- State DB: Postgres SQL that can be run on a separate instance.
69
+
- Aggregator: single instance that can run on a separate instance.
70
+
- Prover: single instance that can run on a separate instance.
71
+
- Executor: single instance that can run on a separate instance.
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
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.
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.
1
+
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.
2
+
3
+
### EVM-equivalence
4
+
5
+
Polygon zkEVM is designed to be EVM-equivalent rather than just being compatible.
6
+
7
+
The difference between EVM-compatibility and EVM-equivalence is that;
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.
10
+
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
+
13
+
EVM-equivalence is critical to Polygon zkEVM for several reasons, including the following:
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.
16
+
17
+
2. No code changes, means no need for additional audits. This saves time and money.
18
+
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
+
21
+
4. EVM-equivalence allows Polygon zkEVM to benefit from the already vibrant and active Ethereum community.
22
+
23
+
5. It also allows for significant and quick dApp adoption, because applications built on Ethereum are automatically compatible.
24
+
25
+
Ultimately, Polygon zkEVM offers developers the exact same UX as on Ethereum, with significantly improved scalability.
26
+
2
27
3
28
!!!info
4
29
No impact on developer experience
5
30
6
-
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 works seamlessly on the zkEVM without any overhead.
31
+
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.
32
+
33
+
The following differences have no impact on the developer's experience on the zkEVM compared to the EVM:
7
34
8
-
## Opcodes
35
+
- Gas optimization techniques.
36
+
- Interacting with libraries, like Web3.js and Ethers.js.
37
+
- Deploying contracts works seamlessly on the zkEVM without any overhead.
9
38
10
-
This section lists the changes we have done with Opcodes in zKEVM as compared to the EVM.
11
39
12
-
-**SELFDESTRUCT**→ removed and replaced by **SENDALL**.
40
+
### Opcodes
13
41
14
-
-**EXTCODEHASH**→ returns the hash of the contract bytecode from the zkEVM state tree without checking if the account is empty.
42
+
Below is a list of the changes we have made with Opcodes in zkEVM in comparison to the EVM.
43
+
44
+
-**SELFDESTRUCT**→ removed and replaced by **SENDALL**.
15
45
16
-
-**DIFFICULTY**→returns "0" instead of a random number as in the EVM.
46
+
-**EXTCODEHASH**→ returns the hash of the contract bytecode from the zkEVM state tree without checking if the account is empty.
17
47
18
-
-**BLOCKHASH**→ returns all previous block hashes instead of just the last 256 blocks.
48
+
-**DIFFICULTY**→returns "0" instead of a random number as in the EVM.
19
49
20
-
> **BLOCKHASH**is the state root at the end of a processable transaction and is stored on the system smart contract.
50
+
-**BLOCKHASH**→ returns all previous block hashes instead of just the last 256 blocks.
21
51
22
-
-**NUMBER**→ returns the number of processable transactions.
52
+
> **BLOCKHASH**is the state root at the end of a processable transaction and is stored on the system smart contract.
23
53
24
-
## Precompiled contracts
54
+
-**NUMBER**→ returns the number of processable transactions.
25
55
26
-
The following precompiled contracts are supported in the zkEVM:
Among Ethereum's precompiled contracts, the zkEVM currrently supports: **ecRecover** and **identity**.
60
+
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".
30
62
31
-
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".
32
63
33
64
## Additions
34
65
35
66
**zk-counters**→ batch resources are available, linked to state-machine components, as a supplementary addition to gas computation.
36
67
68
+
37
69
## Other minor differences
70
+
71
+
- zkEVM doesn't clean storage when a contract is deployed at an address due to the zkEVM state tree specification.
72
+
73
+
-**JUMPDEST** opcode is allowed in push bytes to avoid runtime bytecode analysis.
38
74
39
-
- zkEVM doesn't clean storage when a contract is deployed at an address due to the zkEVM state tree specification.
75
+
- The zkEVM implements [EIP-3541](https://eips.ethereum.org/EIPS/eip-3541) from the [London hardfork](https://ethereum.org/en/history/#london).
40
76
41
-
-**JUMPDEST** opcode is allowed in push bytes to avoid runtime bytecode analysis.
77
+
-[EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) which defines **Typed Transaction Envelope**, is not supported
42
78
43
-
- The zkEVM implements[EIP-3541](https://eips.ethereum.org/EIPS/eip-3541) from the [London hardfork](https://ethereum.org/en/history/#london).
79
+
-[EIP-2930](https://eips.ethereum.org/EIPS/eip-2930), which defines the **Optional Access Lists** transaction type, is not supported.
44
80
45
-
-[EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) which defines **Typed Transaction Envelope**, is not supported
46
-
-[EIP-2930](https://eips.ethereum.org/EIPS/eip-2930), which defines the **Optional Access Lists** transaction type, is not supported.
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.
0 commit comments