77 lines
3.4 KiB
Markdown
77 lines
3.4 KiB
Markdown
## zkEVMs
|
|
|
|
<br>
|
|
|
|
### tl; dr
|
|
|
|
<br>
|
|
|
|
* with zk proofs, zk-rollup can achieve better scalability, security, and faster finality as a scaling solution for ethereum.
|
|
* zk-evms are a scaling solution compatible with ethereum. other solutions such as zksync lite, loopring, and starknet were not evm-compatible.
|
|
* example: the bundling of txs happening within a certain period and settling the proof of a block of txs on the ethereum network instead of the full list of tx that may congest the network.
|
|
* ***"they use zk-snark technology to make cryptographic proofs of execution of ethereum-like txs, either to make it much easier to verify the Ethereum chain itself or to build ZK-rollups that are (close to) equivalent to what Ethereum provides but are much more scalable."*** - vub
|
|
|
|
<br>
|
|
|
|
##### design challenges
|
|
|
|
* evm has limited support of elliptic curves, hard to do proof recursion since cyclic elliptic curve is not directly supported.
|
|
* evm word size is 256bit, and zkp work over prime fields. mismatch field arithmetic inside a circuit requires range proofs, which adds many constraints per evm step (blowing up the the circuit size).
|
|
* evm has many special opcodes, bringing challenges to circuit design.
|
|
* evm is a stack-based vm. zksync and starkware architectures define their own ir/air in the register-based model (language compatible instead of native evm-compatible).
|
|
* ethereum storage layout carries large overhead, relying on keccak and mpt (both not zk-friendly).
|
|
* machine-based proof has a large overhead (how to complete an evm circuit?).
|
|
|
|
<br>
|
|
|
|
##### recent advancements
|
|
|
|
* usage of polynomial commitment, lifting constraints to any degree with a universal or transparent setup.
|
|
* lookup table arguments and customized gadgets, optimizing zk-unfriendly primitives (bitwise operations).
|
|
* recursive proof is more feasible. this type of proof has a large overhead as it relies on special pairing-friendly cyclic elliptic curves (mnt). halo can avoid the need for a pairing-friendly curve and amortize the cost of recursion using special inner product argument.
|
|
* hardware acceleration, making proving more efficient.
|
|
|
|
<br>
|
|
|
|
##### types
|
|
|
|
* type 1, fully ethereum equivalent. example: taiko and the **[community zkevm by pse](https://github.com/privacy-scaling-explorations/zkevm-specs)**.
|
|
* type 2, fully evm equivalent: might differ on data structure and state trees. example: scroll and polygon hermez.
|
|
* type 2.5, evm-equivalent, except for gas costs (increased).
|
|
* type 3, almost evm-equivalent.
|
|
* type 4, high-level-language equivalent (compatible with smart contract languages). example: zksync.
|
|
|
|
<br>
|
|
|
|
<p align="center">
|
|
<img width="450" src="https://user-images.githubusercontent.com/1130416/234139749-4dbac8ab-d742-45f3-b920-b0b51d8698b5.png">
|
|
</p>
|
|
|
|
<br>
|
|
|
|
---
|
|
|
|
### chapters
|
|
|
|
<br>
|
|
|
|
* **[zkSync](zkSync)**
|
|
* **[starkware](starkware)**
|
|
* **[polygon](polygon)**
|
|
* **[scroll](scroll)**
|
|
* **[taiko](taiko)**
|
|
|
|
<br>
|
|
|
|
----
|
|
|
|
### cool resources
|
|
|
|
<br>
|
|
|
|
* **[l2 beat scaling](https://l2beat.com/scaling/tvl)**
|
|
* **[scroll blog post on zk-evms, by scroll](https://scroll.io/blog/zkEVM)**
|
|
* **[the different types of zk-evms, by eub](https://vitalik.eth.limo/general/2022/08/04/zkevm.html)**
|
|
* **[how will ethereum's multi-client philosophy interact with zk-evms, by vub](https://vitalik.ca/general/2023/03/31/zkmulticlient.html)**
|
|
* **[pse series on zkevms, by pse](https://mirror.xyz/privacy-scaling-explorations.eth/I5BzurX-T6slFaPbA4i3hVrO7U2VkBR45eO-N3CSnSg)**
|
|
|