The different types of ZK-EVMs
A Thread 🧵
1/n
A Thread 🧵
1/n
There have been many "ZK-EVM" projects making flashy announcements recently.
@0xPolygon open-sourced their ZK-EVM project, @zksync released their plans for ZKSync 2.0,
and the relative newcomer @Scroll_ZKP announced their ZK-EVM recently.
2/
@0xPolygon open-sourced their ZK-EVM project, @zksync released their plans for ZKSync 2.0,
and the relative newcomer @Scroll_ZKP announced their ZK-EVM recently.
2/
The core goal of all of these projects is the same: to use ZK-SNARK technology to make cryptographic proofs of execution of Ethereum-like transactions, or to make it much easier to verify the Ethereum chain itself.
3/
3/
Or to build ZK-rollups that are (close to) equivalent to what Ethereum provides but are much more scalable.
But there are subtle differences between these projects, and what tradeoffs they are making between practicality and speed.
4/
But there are subtle differences between these projects, and what tradeoffs they are making between practicality and speed.
4/
Overview in chart form.
5/
5/
Type 1 (fully Ethereum-equivalent)
Type 1 ZK-EVMs strive to be fully and uncompromisingly Ethereum-equivalent. They do not replace hashes, state trees, transaction trees, precompiles, or any other in-consensus logic, no matter how peripheral.
6/
Type 1 ZK-EVMs strive to be fully and uncompromisingly Ethereum-equivalent. They do not replace hashes, state trees, transaction trees, precompiles, or any other in-consensus logic, no matter how peripheral.
6/
Type 2 (fully EVM-equivalent)
Type 2 strives to be exactly EVM-equivalent, but not quite Ethereum-equivalent. They look exactly like Ethereum "from within", but they have some differences on the outside, particularly in data structures like the block structure and state tree.
7/
Type 2 strives to be exactly EVM-equivalent, but not quite Ethereum-equivalent. They look exactly like Ethereum "from within", but they have some differences on the outside, particularly in data structures like the block structure and state tree.
7/
The goal is to be fully compatible with existing applications, but make some minor modifications to Ethereum to make development easier and to make proof generation faster.
8/
8/
Type 2.5 (EVM-equivalent, except for gas costs)
Type 2.5 ZK-EVMs can modify the EVM only by changing the gas costs and making it faster to generate proofs.
9/
Type 2.5 ZK-EVMs can modify the EVM only by changing the gas costs and making it faster to generate proofs.
9/
Type 3 (almost EVM-equivalent)
Type 3 ZK-EVMs are almost EVM-equivalent, but make a few sacrifices to exact equivalence to further improve prover times and make the EVM easier to develop.
10/
Type 3 ZK-EVMs are almost EVM-equivalent, but make a few sacrifices to exact equivalence to further improve prover times and make the EVM easier to develop.
10/
Type 4 (high-level-language equivalent)
A Type 4 system works by taking smart contract source code written in a high-level language (eg. Solidity, Vyper, etc) and compiling that into some language that is explicitly designed to be ZK-SNARK-friendly.
11/
A Type 4 system works by taking smart contract source code written in a high-level language (eg. Solidity, Vyper, etc) and compiling that into some language that is explicitly designed to be ZK-SNARK-friendly.
11/
Please like and retweet if you find this thread relevant.
Make sure to follow @socllyhq for more informative content.
#soclly #Polygon #MATIC #zksync #EVM #scroll #Web3 #Crypto #CryptocurrencyNews #Ethereum
Make sure to follow @socllyhq for more informative content.
#soclly #Polygon #MATIC #zksync #EVM #scroll #Web3 #Crypto #CryptocurrencyNews #Ethereum
• • •
Missing some Tweet in this thread? You can try to
force a refresh
