Git-Mirrors/decentralized-cryptography-toolkit
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

move old resources from protocol toolkit

Browse source
This commit is contained in:
bt3gl 2024-11-04 17:30:01 +07:00
parent 88a381fd34
commit 632be7cbf5
31 changed files with 357 additions and 466 deletions
Download patch file Download diff file Expand all files Collapse all files

104
zero_knowledge/README.md Normal file
View file

@ -0,0 +1,104 @@
## zero-knowledge
<br>
### tl; dr
<br>
##### proofs
* **zero-knowledge proofs** represent **programs as circuits**, where a **prover** generates a proof from public and private inputs, and a **verifier** computes the output if the statement is correct (without any information regarding the private input).
* three fundamental characteristics define a zkp:
* completeness (if a statement is true, then an honest verifier can be convinced by an honest prover that they possess knowledge about the correct input).
* soundness (if a statement is false, then no dishonest prover can unilaterally convince an honest verifier that they have knowledge about the correct input).
* zero-knowledge (if the state is true, then the verifier learns nothing more from the prover other than that).
* zk proofs use cases:
* **private transactions**: blockchains such as zcash, with privacy-preserving txs.
* **verifiable computations**: decentralized oracle networks, providing smart contracts with access to off-chain data.
* **highly-scalable and secure l2s**: verifiable computations through methods such as zk-rollups, validiums, and volition by they use l1s as a settlement layer.
* **decentralized identity and authentication**: zkps can underpin identity management systems to enable users to validate their identity.
<br>
<p align="center">
<img src="https://user-images.githubusercontent.com/1130416/234397705-090a0c7b-5d96-49f8-8eaa-183297e3fe37.png" width="60%" align="center" style="padding:1px;border:1px solid black;"/>
<br>
##### zk-rollups
<br>
* **zk-rollups** write transactions to ethereum as calldata, using compression techniques to reduce transaction data. while calldata is not stored as part of the evm's state, it persists on-chain as part of the chain's history logs.
* the zk-rollup's state, which includes l2 accounts and balances, is represented as a merkle tree.
* users in the zk-rollup sign transactions and submit them to l2 operators for processing and inclusion in the next batch. in some cases, the operator is a centralized entity (the sequencer), that executes transactions, aggregates them into batches, and submits to L1.
* the rollup contract won't automatically accept the proposed state commitment until the operator proves the new merkle root resulted from correct updates to the rollup’s state (this comes from validity proofs).
* goals:
* lower gas fees (by tx baches and submitting minimal on-chain data)
* higher throughput (fast tx speeds, reduced confirmation times, up to 100x)
* fastter confirmation time (no need to wait for block confirmations on the base layer, finality on l2)
* privacy (no info about the tx is leaked, concealing tx amounts and recipients)
* proof generation costs can be high (reducing proof generation costs involves using more efficient proof systems or circuit designs or incentivizing provers).
* high circuit complexity can affect zk-rollups' scalability and usability
* compatibility issues (not fully compatible with existing smart contracts or tools)
<br>
----
### chapters
<br>
* **[zkEVMs](zkEVMs)**
* **[proofs](proofs)**
* **[machine learning](machine_learning)**
<br>
----
### cool resources
<br>
#### overview
* **[zk-learning mooc, by d. boneh et al.](https://zk-learning.org/)**
* **[course on modern zero knowledge cryptography](https://zkiap.com/)**
* **[pse's publications](https://mirror.xyz/privacy-scaling-explorations.eth)**
* **[zero knowledge podcast youtube](https://www.youtube.com/@zeroknowledgefm)**
* **[what are zk proofs, by ef](https://ethereum.org/en/zero-knowledge-proofs/)**
* **[the zk-ECDSA landscape, by pse](https://mirror.xyz/privacy-scaling-explorations.eth/djxf2g9VzUcss1e-gWIL2DSRD4stWggtTOcgsv1RlxY)**
* **[zero knowledge dapp from 0 to production, by v. plasencia](https://vivianblog.hashnode.dev/how-to-create-a-zero-knowledge-dapp-from-zero-to-production)**
* **[an evolution of models for zkps, by s. meiklejohn](https://youtube.com/watch?v=HO97kVMI3SE&t=2s)**
* **[an incomplete guide to folding, by taiko](https://taiko.mirror.xyz/tk8LoE-rC2w0MJ4wCWwaJwbq8-Ih8DXnLUf7aJX1FbU)**
* **[a new era: safe deploys on zksync era](https://safe.mirror.xyz/yvnFJxFWrlHTXZFBLfQiKuPyW7zwa2TSurXz5Btl9Jk)**
* **[binius: highly efficient proofs over binary fields, by vub](https://vitalik.eth.limo/general/2024/04/29/binius.html)**
* **[possible futures of the ethereum protocol, part 4: the verge, by vub](https://vitalik.eth.limo/general/2024/10/23/futures4.html)**
* **the state of zk applications in ethereum, by andyguzman.eth: [1](https://mirror.xyz/andyguzman.eth/p4nNk7Rr-2i-uZDO_lTHJEWtNv3nYt2N2z3Cwly8RHc) and [2](https://mirror.xyz/andyguzman.eth/ZZRLBlx2KjlNnQ84v1doMKg_8QO-XRjYxFfT1Fm_ZDw)**
<br>
#### playgrounds
* **[zkrepl](https://zkrepl.dev/)**
<br>
#### coprocessors provers
* **[langrage network](https://www.lagrange.dev/)** (hyper-parallel zk coprocessing)
* **[brevis](https://brevis.network/)** (a smart zk coprocessor for blockchains)
* **[herodotus](https://herodotus.dev/)** (cryptographic integrity verification)
<br>
#### optimistic verifcation provers
* **[uma protocol](https://uma.xyz/)**
* **[accross protocol](https://github.com/across-protocol)**
<br>
#### zk-circuits provers
* **[succinct](https://github.com/succinctlabs/sp1-contract-call)**

45
zero_knowledge/machine_learning/README.md Normal file
View file

@ -0,0 +1,45 @@
## zk proofs applied to ml (zkml)
<br>
### tl; dr
<br>
<p align="center">
<img width="500" src="https://user-images.githubusercontent.com/1130416/234938321-a0b052b6-e754-4e80-8351-0daa847ebd12.png">
</p>
<br>
* **challenges:**
* transpile NNs into ZKP circuts (floating-point weigths -> fixed-point arithmetic)
* model size/depth
* **ideas:**
* model authenticity
- assurance that the ml model is the one that run (e.g. the most accurate one)
- functional commitments allow the prover to establosj that it used a commited model (but no guarantess about the commited model).
* model integrity
- assurance that the same ml algorithm is ran on different data the same way
* attestations
- integrate attestations from external parties
* decentralized inference or traning
- perform ml training in a decentralized way
* proof of personhood
<br>
---
### cool resources
<br>
* **[humanness in the age of ai, by worldcoin](https://worldcoin.org/blog/engineering/humanness-in-the-age-of-ai)**
* **[zk-img: attested images via zk-proofs, d. kang et al.](https://arxiv.org/pdf/2211.04775.pdf)**
* **[checks and balances ml and zk, by a16](https://a16zcrypto.com/content/article/checks-and-balances-machine-learning-and-zero-knowledge-proofs/)**
* **[trustless verification of ml, by d. kang](https://ddkang.github.io/blog/2022/10/18/trustless/)**
* **[tachikoma, neural nets for zk proof systems](https://github.com/zk-ml/tachikoma)**
* **[zkml, framework for constructing proofs of ml model in zksnarks](https://github.com/ddkang/zkml)**
* **[ezkl, deep learning inference in zk-snark](https://github.com/zkonduit/ezkl)**
* **[unraveling zkml, by dr. cathie so](https://www.canva.com/design/DAFgqqAboU0/4HscC5E3YkFRFk3bB64chw/view#1)**

71
zero_knowledge/proofs/README.md Normal file
View file

@ -0,0 +1,71 @@
## zero-knowledge proofs
<br>
### tl; dr
<br>
* suppose that you have a (public) function `f`, a (private) input `x`, and a (public) output `y`.
* you want to prove that you know an `x` such that `f(x) = y`, without revealing what `x` is.
* for the proof to be succinct, you want it to be verifiable much more quickly than computing itself.
* a **trusted setup ceremony** is a procedure that is done to generate a piece of data that must be used every time some cryptographic protocol is run.
* for some proofs to work, such as zk-snarks, it's necessary to create a **common reference string (CRS)**, which provides public parameters for proving and verifying validity proofs.
* the security of the proving system depends on the csr setup and some zk-rollups attempt to solve this problem by using a **multi-party computation ceremony (mpc)** with trusted individuals.
* modern protocols use the **power-of-tau** setup, which has 1-of-N trust model, with N around hundreds.
<br>
<p align="center">
<img width="300" src="https://user-images.githubusercontent.com/1130416/234407214-ed3974fd-85cc-471b-a08b-e2edf0efd1a2.png">
</p>
<br>
#### comparison of proof systems
<p align="center">
<img width="300" src="https://user-images.githubusercontent.com/1130416/234476377-f7c88f31-919f-4503-8b60-203ca9b0c06d.png">
<img width="300" src="https://user-images.githubusercontent.com/1130416/234476566-df847c7f-b1ad-42cf-b5dd-85ba2cf7a997.png">
</p>
<br>
#### common reference strings, structured reference strings, trusted setup, multi-party computation ceremony
<br>
<p align="center">
<img width="250" src="https://user-images.githubusercontent.com/1130416/235269418-3cb7b4ca-83b7-4930-a367-586cb8be4fc7.png">
</p>
<br>
<br>
----
### chapters
<br>
* **[zk-snarks](zk-snarks)**
* **[zk-starks](zk-starks)**
* **[plonk](plonk)**
* **[halo2](halo2)**
* **[nova](nova)**
* **[bulletproofs](bulletproofs)**
* **[kate](kate)**
<br>
---
### cool resources
<br>
* **[how do trusted setups work, by vub](https://vitalik.ca/general/2022/03/14/trustedsetup.html)**
* **[the original paper for sonic, by m. maller et al](https://eprint.iacr.org/2019/099)**
* **[a python script for trusted setup](https://github.com/ethereum/research/blob/master/trusted_setup/trusted_setup.py)**

7
zero_knowledge/proofs/bulletproofs/README.md Normal file
View file

@ -0,0 +1,7 @@
## bulletproofs
<br>
<p align="center">
<img width="600" src="https://user-images.githubusercontent.com/1130416/234164194-032fe86c-c0c6-4479-ac14-859759356641.png">
</p>

22
zero_knowledge/proofs/halo2/README.md Normal file
View file

@ -0,0 +1,22 @@
## halo2
<br>
### tl; dr
<br>
* halo2 us based on ultraplonk and uses several plonkish functions.
* it replaces the kzg polynomial commitment with inner-product argument, which has weaker security assumptions than plonk.
* halo2 does not need setup and implement a powerful recusive proof function. therefore, zkevm can improve the time and efficiency of generating block proof.
<br>
----
### cool resources
<br>
* **[0xparc on halo2](https://learn.0xparc.org/halo2/)**
* **[intro to PLONKish/halo2, by y. tong](https://docs.google.com/presentation/d/1UpMo2Ze5iwzpwICPoKkeT04-xGFRp7ZzVPhgnidr-vs/edit#slide=id.g133c45f1bcd_3_36)**

31
zero_knowledge/proofs/kate/README.md Normal file
View file

@ -0,0 +1,31 @@
## kate polynomial commitment scheme (pronounced kah-tay)
<br>
### tl; dr
<br>
* it allows a prover to compute a commitment to a polynomial, with the properties that this commitment can later be opened at any position.
* the prover shows that the value of the polynomial at a certan position is equal to a claimed value.
* once a **commitment** (an elliptic curve point) is sent to the verifier, the prover cannot change the polynomial they are working with.
* a merkle tree is a "vector commitment": using a merkle tree of depth, you can compute a commitment to a list of elements of fixed length. using merkle proofs, you can provide a proof that an element is a member of this vector at position using hashes.
* in the kate commitment scheme, the element is the commitment to the polynomial: could the prover (without knowing) find another polynomial that has the same commitment.x
<br>
<p align="center">
<img width="586" src="https://user-images.githubusercontent.com/1130416/234472661-000ccabb-2bce-4e16-8a51-f599c04b643d.png">
</p>
<br>
----
### cool resources
<br>
* **[the original kate paper](https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf)**
* **[kzg polynomial commitments, by d. feist](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html)**
* **[the kzg ceremony, by c. beekhuizen](https://archive.devcon.org/archive/watch/6/the-kzg-ceremony-or-how-i-learnt-to-stop-worrying-and-love-trusted-setups/?tab=YouTube)**

20
zero_knowledge/proofs/nova/README.md Normal file
View file

@ -0,0 +1,20 @@
## nova
<br>
### tl; dr
<br>
* nova is the state of the art and high-speed for recursive snarks, using R1CS arithmetization, it can be thought of as a preprocessor for zksnarks.
* nova can shrink the cost (in number of r1cs constraints) of checking N instances of a problem to one instance of the same problem.
<br>
---
### cool resources
<br>
* **[nova: recursive snarks without trusted setup, by microsoft](https://github.com/microsoft/Nova)**

36
zero_knowledge/proofs/plonk/README.md Normal file
View file

@ -0,0 +1,36 @@
## plonk
<br>
### tl; dr
<br>
* **[introduced in 2019](https://eprint.iacr.org/2019/953.pdf)**, plonk stands for **"permutations over lagrange-bases for ecumenical noninteractive arguments of knowledge"**, brining enhancements to the usability of zkps by giving a **universal fully-succinct zk-SNARK with significantly improved prover run time compared to fully-succinct sonic**.
* while plonk still requires a trusted setup procedure similar to snarks, but it's **universal and updateable trusted setup**, meaning:
- instead of there being one separate trusted setup for every program to be proved, there is one single trusted setup for the whole scheme.
- there is a way for multiple parties to participate in the trsuted setup such that it's secure as long as any one of them is honest, and this multi-party procedure is fully sequential (polynomial commitment, in this case, kate).
* there are two types of constraints:
- gate constraints (equations between wires attached to the same gate, e.g., `a1 * b1 = c1`).
- copy constraints (claims about equality of different wires anywhere in the circuit, e.g., `ao = a1`)
* **polynomial commitments** is a short object that represents a polynomial, allowing evaluations verification without needing all the data in the polynomial.
* if someone gives you a commitment representing `c` they can give you a proof that can convince you, for some specific `z`, what the value of `P(z)`.
* a commitment to a degree-d polynomial is made by multiplying each of the first d+1 points in the proving key by the corresponding coefficient in the polynomial, and adding the results together, providing an evaluation of that polynomial at `s` without knowing `s`.
<br>
<p align="center">
<img width="593" src="https://user-images.githubusercontent.com/1130416/234398674-d7af7145-e9c8-4dc6-b13a-003745765600.png">
</p>
<br>
---
### cool resources
<br>
* **[understanding plonk, by vub](https://vitalik.ca/general/2019/09/22/plonk.html)**
* **[plonk original paper, by a. gabizon et al.](https://eprint.iacr.org/2019/953.pdf)**
* **[plookup original paper, by a. gabizon et al.](https://eprint.iacr.org/2020/315)**

61
zero_knowledge/proofs/zk-snarks/README.md Normal file
View file

@ -0,0 +1,61 @@
## zk-snarks
<br>
### tl; dr
<br>
* introduced in 2011, **zk-snarks stands for "zero-knowledge succint non-interactive argument of knowledge"**, and refers to a proof construction where one can prove possession of certain information, without revealing the information nor any interaction between the prover and verifier.
* it made it possible to efficiently scale the nuber of polynomials that can be gated, improving speed and potential complex applications.
* a **"succinct" proof is one where both the size of the proof and the time required to verify it grow much more slowly than the computation to be verified**".
* succint zk proofs can be verified within a few milliseconds, with a proof length of only a few hundred bytes even for large statements.
* this entails enconding the computation into polynomials.
* **a polynomial commitment** is way to hash a polynomial, and the equations between polynomials can be checked by checking equations between hashes.
* **zcash was the first widespread application of zk-snarks** by encoding some of the network’s consensus rules into it.
* in may '22, zcash introduced the orchard shielded payment protocol, which utilizes the halo2 zk proving system (and replace trusted ceremonies).
<br>
#### implementation
* **encoding a polynomial problem**: the program that is to be checked is compiled into a quadractic equation of polynomials, where the equality holds if and only if the program is computed correctly - the prover wants to convince the verifier that this equality holds.
* **succinctness by random sampling**: the verifier chooses a secret evaluation point to reduce the problem from multiplying polynomials and verifying polynomial function equality to simple multiplication and equality check on numbers. - this reduces both the proof size and the verification time.
* **homomorphic enconding/encryption**: an encoding/encryption function E is used that has some homomorphic properties (two operations are homomorphic if you can exchange their order without affecting the resul).
* **zero-knowledge**; verifier can check correct structure without knowing the actual encoded values.
<br>
#### building circuits
1. the first step in turning a tx validity function into a mathematical representation is to break down the logical steps into the smallest possible operations, creating an "arithmetic circuit". this is similar to a boolean circuit where a program is compiled down to discrete AND, OR, NOT.
2. next is to build a **rank 1 constraint system (r1cs)**, to check the values. it's only needed to check that 2 polynomials match at one randoly chosen point in order to verify the proof with high probability. with zk-snarks, techniques such as **homomorphic encryption** and **pairings of elliptic curves** are used to evaluate polynomials blindly.
3. the zero-knowledge part comes from having the prover using "random shifts" of the original polynomials that still satisfy the identity.
<br>
#### zk-snarks applied to create a shielded tx (zcash)
* the sender of a shielded tx constructs a proof to show that, with high probability:
1. the input values sum to the output values for each shielded transfer.
2. the sender proves that they have the private spending keys of the input notes, giving them the authority to spend.
3. the private spending keys of the input notes are linked to a signature over the whole tx, in such a way that the tx cannot be modified by a party that doesn't not have the priv keys.
<br>
---
### cool resources
<br>
* **[what are zk-snarks, by z-cash](https://z.cash/technology/zksnarks/)**
* **[libsnark, C++ lib for zkSNARKS](https://github.com/scipr-lab/libsnark)**
* **[zk-snarks in a nutshell, by ef](https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell)**
* **[bellman, a crate for building zk-SNARK circuits](https://github.com/zkcrypto/bellman)**
* **[an approximate introduction to how zk-snarks are possible, by vub](https://vitalik.ca/general/2021/01/26/snarks.html)**
* **[the crazy security behind the birth of zcash](https://spectrum.ieee.org/the-crazy-security-behind-the-birth-of-zcash)**
* **[bitcoin-monero cross-chain atomic swap](https://eprint.iacr.org/2020/1126.pdf)**
* **[atomic swaps between bitcoin and monero](https://arxiv.org/pdf/2101.12332.pdf)**

26
zero_knowledge/proofs/zk-starks/README.md Normal file
View file

@ -0,0 +1,26 @@
## zk-starks
<br>
### tl; dr
<br>
* the T stands for "transparent", resolving one of the primary weakness of zk-snarks, its reliance on a trusted setup (they can work without the trusted setup of common reference string (crs)). instead, they rely on publicly verifiable randomness to setup parameters for generating and verifying proofs.
* thye also come with much simpler cryptographic assumptions, avoiding the need for elliptic curves, pairings, and knowledge of expoent assumptions - instead relying on hashes and information theory (secure on the quantum standard).
* the size of a proof goes up from 288 bytes to a few hundred kilobytes (making it more expensive to verify on ethereum).
* it provides more scalability because the time needed to prove and verify validity proofs increases quasilinearly in relation to the complexity of the underlying computation.
<br>
---
### cool resources
<br>
* **[risc0, zk platform based on zk-starks and risc-v microarchtecture](https://github.com/risc0/risc0)**
* **[starks, part I: proof with polynomials, by vub](https://vitalik.ca/general/2017/11/09/starks_part_1.html)**
* **[starks, part II: thank you goodness it's fri-day, by vub ](https://vitalik.ca/general/2017/11/22/starks_part_2.html)**
* **[starks, part III: into the weeds, by vub](https://vitalik.ca/general/2018/07/21/starks_part_3.html)**
* **[stark 101 videos, by starkware](https://www.youtube.com/watch?v=iuNbrTkH2ik)**

77
zero_knowledge/zkEVMs/README.md Normal file
View file

@ -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)**

25
zero_knowledge/zkEVMs/polygon/README.md Normal file
View file

@ -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)**

54
zero_knowledge/zkEVMs/scroll/README.md Normal file
View file

@ -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/)**

11
zero_knowledge/zkEVMs/starkware/README.md Normal file
View file

@ -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.

11
zero_knowledge/zkEVMs/taiko/README.md Normal file
View file

@ -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).

39
zero_knowledge/zkEVMs/zkSync/README.md Normal file
View file

@ -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)**