move old resources from protocol toolkit

zero_knowledge/zkEVMs/README.md

@@ -0,0 +1,77 @@
+## 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)**
+

zero_knowledge/zkEVMs/polygon/README.md

@@ -0,0 +1,25 @@
+## polygon zkevm
+
+<br>
+
+### tl; dr
+
+<br>
+
+* compatible at the bytecode-level rather than at the language level.
+
+<br>
+
+<p align="center">
+<img width="500" src="https://user-images.githubusercontent.com/1130416/234144874-e3b04272-8ed7-460d-bbf8-e74a454e4396.png">
+</p>
+
+<br>
+
+---
+
+### cool resources
+
+<br>
+
+* **[polygon zkevm announcement](https://polygon.technology/blog/the-future-is-now-for-ethereum-scaling-introducing-polygon-zkevm)**

zero_knowledge/zkEVMs/scroll/README.md

@@ -0,0 +1,54 @@
+## scroll
+
+<br>
+
+### tl; dr
+
+<br>
+
+* scroll is an evm-equivalent zk-rollup to scale ethereum. 
+* the core piece is the zkevm, used to prove correctness of evm execution in layer 2.
+* architecture:
+  * scroll node: constructs l2 blocks from user txs, commit them to the ethereum base layer, and passes messgaes between l1 and l2.
+  * roller network: generates the zkevm validity proofs to prove that txs are executed correctly.
+  * rollup and bridge contracts: provides da for scroll txs, verifies zkevm validity proofs, and allows users to move assets between ethereum and scroll. 
+
+<br>
+
+<p align="center">
+<img width="600" src="https://user-images.githubusercontent.com/1130416/234146949-a523a484-9b24-43aa-93ac-9817ccf6e51d.png">
+</p>
+
+<br>
+
+* the rollers serve as provers in the network, responsible for generating validity for the rollup.
+  * rollers utilize accelerators such as gpus, fpgas, asics.
+  * a roller first converts the execution trace from the coordinator to circuit witnesses.
+  * then generates proofs for each of the zkevm circuits.
+  * finally, it uses proof aggregation to combine proofs from multiple zkevm circuits into a single block proof.
+
+<br>
+
+<p align="center">
+<img width="600"  src="https://user-images.githubusercontent.com/1130416/234150191-a8e9296b-ae52-4f3a-a3d3-b933418ec10d.png">
+</p>
+
+<br>
+
+* workflow of scroll's rollup:
+
+<br>
+
+<p align="center">
+<img width="610" src="https://user-images.githubusercontent.com/1130416/234150359-d612ac1e-e338-45fa-ab8d-f51fd653b6cd.png">
+</p>
+
+<br>
+
+---
+
+### cool resources
+
+<br>
+
+* **[scroll's publications](https://scroll.mirror.xyz/)**

zero_knowledge/zkEVMs/starkware/README.md

@@ -0,0 +1,11 @@
+## starkware
+
+<br>
+
+### tl; dr
+
+<br>
+
+* layer-2 scaling solution aiming to increase the efficiency and scalability of blockchains (e.g., ethereum, bsc, polkadot).
+* it uses starks. 
+

zero_knowledge/zkEVMs/taiko/README.md

@@ -0,0 +1,11 @@
+## taiko
+
+<br>
+
+### tl; dr
+
+<br>
+
+* "type 1 zkevm", making almost no changes to the ethereum architecture, which includes the hash function, state trees or gas costs.
+* it can reuse the execution client implementations with as few modifications as possible (easy migration).
+

zero_knowledge/zkEVMs/zkSync/README.md

@@ -0,0 +1,39 @@
+## zkSync
+
+<br>
+
+### tl; dr
+
+<br>
+
+* layer-2 scaling solution for ethereum, aiming for scalability. 
+* zkSync 2 is called Era, zkSync 1 is called light.
+* uses "optimistic" transfers, which allow users to send and receive txs without waiting for conformation (reducing tx times, and allowing higher tx throughput).
+* tvl: zkSync era has higher transfers of assets ($125M) than Polygon zkEVM ($2.57M) 
+* sybil addresses: zkSync era has more potential sybil addresses based on the depositing addresses’ wallet age and usage on Ethereum/Layer 2 networks. 
+* tx costs: ~$0.25-$2, high compared to optimistic rollups like arbitrum and Ootimism ($0.13 - $0.45)
+
+<br>
+
+----
+
+### zksync era
+
+* zksync era archtecture:
+  * native account abstraction (any account on era can pay fees in any tokens or even transact with zero fees on protocols willing to subsidize usage)
+  * powerful llvm compiler
+  * data compression (publishing states diffs instead of tx inputs, enabling data compression, more frequent oracle updates, cheap privacy, seamless off-chain sotrage extension)
+  * hyperscalability 
+
+
+<br>
+
+----
+
+### cool resources
+
+<br>
+
+* **[zksync ecosystem](https://ecosystem.zksync.io/)**
+* **[gm zkEVM, by zksync](https://blog.matter-labs.io/gm-zkevm-171b12a26b36)**
+* **[dune board zksync vs. polygon zkEVM](https://dune.com/21shares_research/zkevm-comparison-zksync-era-vs-polygon-hermez)**