🛹👾

README.md

@@ -0,0 +1,15 @@
+## privacy by math toolkit
+
+<br>
+
+<p align="center">
+<img src="https://github.com/user-attachments/assets/ad115cd1-ee02-4201-ad69-601d0bbd54e3" width="45%" align="center" style="padding:1px;border:1px solid black;"/>
+</p>
+
+
+<br>
+
+* **[zero-knowledge proofs](zkps.md)**
+* **[trusted execution environments](tees.md)**
+* **[multi-party computation](mpc.md)**
+* **[differential privacy](differential.md)**

applications/ml.md

@@ -0,0 +1,59 @@
+## zk proofs applied to ml (zkml)
+
+<br>
+
+
+### tl; dr
+
+
+<br>
+
+<img width="600"  src="https://user-images.githubusercontent.com/1130416/234938321-a0b052b6-e754-4e80-8351-0daa847ebd12.png">
+
+
+<br>
+
+----
+
+### challenges
+
+<br>
+
+* transpile NNs into ZKP circuts (floating-point weigths -> fixed-point arithmetic)
+* model size/depth
+
+<br>
+
+---
+
+<br>
+
+### 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>
+ 
+ ---
+ 
+ ### 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)**

applications/privacy_enhancing_technologies.md

@@ -0,0 +1,7 @@
+## privacy-based technologies
+
+<br>
+
+* [functional encryption](functional.md)
+* [fully-homomorphic encryption (fhe)](fhe.md)
+* [trsuted execution environments (tee)](tee.md)

applications/zkp_projects.md

@@ -0,0 +1,18 @@
+### zkp projects
+
+<br>
+
+* [ethereum foundation applied zkp team](https://appliedzkp.org/)
+* [semaphore, a zk membership proof](https://mirror.xyz/privacy-scaling-explorations.eth/ImQNsJsJuDf_VFDm9EUr4njAuf3unhAGiPu5MzpDIjI):
+  - [unirep, a private reputation system based on zkp](https://github.com/Unirep/Unirep) (zk protocol enabling trustless interactions and enhanced user privacy in applications).
+  - [interep](https://mirror.xyz/privacy-scaling-explorations.eth/FCVVfy-TQ6R7_wavKj1lCr5dd1zqRvwjnDOYRM5NtsE)
+  - [auti.sm]()
+  - [maci (anti-collusion)](https://mirror.xyz/privacy-scaling-explorations.eth/ltCt68hslI5jmMf1AnfkrP2eUwkeZ8_fgkHc_WyD9Nc)
+* [axiom, zk coprocessor for ethereum](https://www.axiom.xyz/)
+  - support for reads for any JSON-RPC query to an archive node, usable on-chain. This includes ZK proofs for states, transactions, and receipts.
+  - support computations too large to be done on-chain.
+* [risc zero, general purpose zk vm](https://www.risczero.com/)
+* [sunccint, with telepathy using zkSNARKS](https://www.succinct.xyz/)
+* [zklend](https://zklend.com/)
+
+

differential.md

@@ -0,0 +1,6 @@
+## differential privacy
+
+<br>
+
+* **[the complexity of differential privacy, by s. vadhan](https://privacytools.seas.harvard.edu/files/privacytools/files/complexityprivacy_1.pdf)**
+* **[the algorithmic foundation of differential privacy, by c. dwork et al.](https://www.cis.upenn.edu/~aaroth/Papers/privacybook.pdf)**

mpc.md

@@ -0,0 +1,6 @@
+## secure multi-party computation
+
+<br>
+
+* **[a pragmatic introduction to secure multi-party computation, by evans et al.](https://securecomputation.org/docs/pragmaticmpc.pdf)**
+* **[cryptographic computing, by aarhus univ](https://users-cs.au.dk/orlandi/crycom/)**

number_theory/README.md

@@ -0,0 +1,15 @@
+## number theory
+
+<br>
+
+
+<br>
+
+---
+
+### external resources
+
+<br>
+
+* **[number theory course by stanford](https://crypto.stanford.edu/pbc/notes/numbertheory/)**
+  

primitives/README.md

@@ -0,0 +1,42 @@
+## cryptographic primitives
+
+<br>
+
+### bls signatures
+
+* used in the beacon chain to verify large numbers of signtures.
+* invented by dan boneh, ben lynn, and hovav shacham.
+* in optimistic rollups such as arbitrum and optimism, each tx must be accompanied by its own signature. these signatures are stored on l1 calldata, a read-only format that's commited as a part of a transaction rather than to (expensive) contract storage.
+* storing txs and signatures as calldata is the cheapst method available for rollups to keep data on l1.
+* the key property of bls signatures is that multiple signatures can be combined into one - so only one aggregate signature needs to be verified and stored on-chain (meaning less gas fees).
+
+<br>
+
+![](https://user-images.githubusercontent.com/1130416/235320176-855998db-d998-45b3-a9cf-e160c4825993.png)
+
+
+<br>
+
+----
+
+### shamir's secret sharing
+
+<br>
+
+* secret sharing algorithm to distribute private information among a group, and the secret cannot be revealed unless a quorum of the groups acts together to pool their knowledge.
+* the secret is matematically divided into parts. if an attacker steals some shares, it's impossible for the attacker to reconstrcut the secret unless they have stolen a quorum number of shares.
+* uses cases: password managers, encrypted emails, and crypto wallets.
+
+<br>
+
+![](https://user-images.githubusercontent.com/1130416/235320099-6ab37a6b-14df-40d4-9c9c-b8142bb6a30b.png)
+
+
+<br>
+
+----
+
+### resources
+
+<br>
+

proofs/README.md

@@ -0,0 +1,80 @@
+## 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.
+
+<br>
+
+<img width="284" src="https://user-images.githubusercontent.com/1130416/234407214-ed3974fd-85cc-471b-a08b-e2edf0efd1a2.png">
+
+<br>
+
+#### comparison of proof systems
+
+<br>
+
+
+<img width="550"  src="https://user-images.githubusercontent.com/1130416/234476377-f7c88f31-919f-4503-8b60-203ca9b0c06d.png">
+
+<br>
+
+<img width="600"  src="https://user-images.githubusercontent.com/1130416/234476566-df847c7f-b1ad-42cf-b5dd-85ba2cf7a997.png">
+
+
+
+<br>
+
+#### common reference strings, structured reference strings, trusted setup, multi-party computation ceremony
+
+<br>
+
+<img width="487" src="https://user-images.githubusercontent.com/1130416/235269418-3cb7b4ca-83b7-4930-a367-586cb8be4fc7.png">
+
+
+<br>
+
+* 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>
+
+----
+
+### in this dir
+
+<br>
+
+* **[zkSNARKS](zkSNARKS.md)**
+* **[zkSTARKS](zkSTARKS.md)**
+* **[PLONK](plonk.md)**
+* **[halo2](halo2.md)**
+* **[semaphore](semaphore.md)**
+* **[DARK](dark.md)**
+* **[nova](nova.md)**
+* **[bulletproofs](bulletproofs.md)**
+* **[FRI](fri.md)**
+* **[Kate](kate.md)**
+
+
+<br>
+
+---
+
+### resources
+
+<br>
+
+* **[how do trusted setups work, by vitalik](https://vitalik.ca/general/2022/03/14/trustedsetup.html)**
+* **[the original paper for sonic, by mary 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)**
+

proofs/bulletproofs.md

@@ -0,0 +1,17 @@
+## bulletproofs
+
+<br>
+
+### tl; dr
+
+<br>
+
+<img width="600" src="https://user-images.githubusercontent.com/1130416/234164194-032fe86c-c0c6-4479-ac14-859759356641.png">
+
+
+
+<br>
+
+---
+
+### resourses

proofs/halo2.md

@@ -0,0 +1,11 @@
+## 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.

proofs/kate.md

@@ -0,0 +1,30 @@
+## 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>
+
+<img width="586" src="https://user-images.githubusercontent.com/1130416/234472661-000ccabb-2bce-4e16-8a51-f599c04b643d.png">
+
+
+<br>
+
+----
+
+### resources
+
+<br>
+
+* **[the original kate paper](https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf)**
+* **[kzg polynomial commitments, by dankrad feist](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html)**
+* **[the kzg ceremony, by carl beekhuizen](https://archive.devcon.org/archive/watch/6/the-kzg-ceremony-or-how-i-learnt-to-stop-worrying-and-love-trusted-setups/?tab=YouTube)**

proofs/nova.md

@@ -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>
+
+---
+
+### resources
+
+<br>
+
+* [nova: recursive snarks without trusted setup, by microsoft](https://github.com/microsoft/Nova)

proofs/plonk.md

@@ -0,0 +1,38 @@
+## PLONK
+
+<br>
+
+### tl; dr
+
+<br>
+
+* **[introduced in 2019](https://eprint.iacr.org/2019/953.pdf)**, plonk stands for **"permutations over lagrange-bases for oecumenical 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>
+
+<img width="593" src="https://user-images.githubusercontent.com/1130416/234398674-d7af7145-e9c8-4dc6-b13a-003745765600.png">
+
+
+
+<br>
+
+----
+
+### resources
+
+<br>
+
+* **[understanding plonk, by vitalik](https://vitalik.ca/general/2019/09/22/plonk.html)**
+* **[plonk original paper, by ariel gabizon et al](https://eprint.iacr.org/2019/953.pdf)**
+* **[plookup original paper, by ariel gabizon et al](https://eprint.iacr.org/2020/315)**

proofs/semaphore.md

@@ -0,0 +1,20 @@
+## semaphore
+
+<br>
+
+### tl; dr
+
+<br>
+
+
+* **[semaphore](https://semaphore.appliedzkp.org/)** allows ethereum users to prove their membership of a group and send signals such as voters or endorsements, without revealing their original identity.
+
+
+
+<br>
+
+---
+
+### resources
+
+<br>

proofs/zkSNARKS.md

@@ -0,0 +1,64 @@
+## 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 halo 2 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>
+
+---
+
+### 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 vitalik](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)**
+
+
+<br>
+
+##### halo2
+
+* **[intro to PLONKish/halo2, by ying tong](https://docs.google.com/presentation/d/1UpMo2Ze5iwzpwICPoKkeT04-xGFRp7ZzVPhgnidr-vs/edit#slide=id.g133c45f1bcd_3_36)**

proofs/zkSTARKS.md

@@ -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>
+
+---
+
+### 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 vitalik](https://vitalik.ca/general/2017/11/09/starks_part_1.html)
+* [starks, part II: thank you goodness it's fri-day, by vitalik ](https://vitalik.ca/general/2017/11/22/starks_part_2.html)
+* [starks, part III: into the weeds, by vitalik](https://vitalik.ca/general/2018/07/21/starks_part_3.html)
+* [stark 101 videos, by starkware](https://www.youtube.com/watch?v=iuNbrTkH2ik)

tees.md

@@ -0,0 +1,43 @@
+## trusted execution environments
+
+<br>
+
+### hardware
+
+#### sgx stuff
+
+* **[intel SGX explained, by costan et al.](https://eprint.iacr.org/2016/086.pdf)**
+* **[linux instalation guides](https://download.01.org/intel-sgx/latest/linux-latest/docs)**
+* **[secure computation in rust: using intel's SGX  with teaclave && fortanix](https://blog.lambdaclass.com/secure-computation-in-rust-using-intels-sgx-instructions-with-teaclave-and-fortanix/)**
+
+<br>
+
+#### cloud providers
+
+* **[nitro enclaves at aws](https://aws.amazon.com/ec2/nitro/nitro-enclaves/)**
+
+<br>
+
+---
+
+### quantum settings
+
+* **[is the security of quantum cryptography guaranteed by the laws of physics?, by bernstein](https://arxiv.org/pdf/1803.04520)**
+* **[the laws of physics and cryptographic security; by rudolph](https://arxiv.org/pdf/quant-ph/0202143)**
+* **[introduction to quantum information, by bt3gl](https://www.astro.sunysb.edu/steinkirch/books/qi.pdf)**
+
+<br>
+
+---
+
+### offensive
+
+* **[using memory errors to attack a virtual machine, by govindavajhala et al.](https://www.cs.princeton.edu/~appel/papers/memerr.pdf)**
+
+<br>
+
+----
+
+### blockchain-specific
+
+* **[demystifying remote attestation by taking it on-chain, by flashbots](https://collective.flashbots.net/t/demystifying-remote-attestation-by-taking-it-on-chain/2629)**

zkEVM/README.md

@@ -0,0 +1,95 @@
+## zk-EVMs
+
+<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](https://github.com/go-outside-labs/blockchains-protocol-design/blob/main/zero_knowledge_proofs/proofs/zkSNARKS.md)** 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.* - vitalik
+
+<br>
+
+---
+
+### design challenges
+
+<br>
+
+* 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
+
+<br>
+
+* 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
+
+<br>
+
+
+* 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>
+
+---
+
+### in this dir
+
+<br>
+
+* **[zk-rollups overview](rollups.md)**
+* **[zkSync](zkSync)**
+* **[starkware](starkware.md)**
+* **[polygon hermez](polygon.md)**
+* **[scroll](scroll.md)**
+* **[taiko](taiko.md)**
+
+<br>
+
+----
+
+### external resources
+
+<br>
+
+* **[l2 beat scaling](https://l2beat.com/scaling/tvl)**
+* **[scroll blog post on zk-evms](https://scroll.io/blog/zkEVM)**
+* **[the different types of zk-evms, by vitalik](https://vitalik.eth.limo/general/2022/08/04/zkevm.html)**
+* **[how will ethereum's multi-client philosophy interact with zk-evms, by vitalik](https://vitalik.ca/general/2023/03/31/zkmulticlient.html)**
+* **[pse series on zkevms](https://mirror.xyz/privacy-scaling-explorations.eth/I5BzurX-T6slFaPbA4i3hVrO7U2VkBR45eO-N3CSnSg)**
+

zkEVM/polygon.md

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

zkEVM/rollups.md

@@ -0,0 +1,21 @@
+## zk rollups overview
+
+<br>
+
+### tl; dr
+
+<br>
+
+* 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>
+
+----
+
+### resources

zkEVM/scroll.md

@@ -0,0 +1,50 @@
+## 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>
+
+<img width="600" src="https://user-images.githubusercontent.com/1130416/234146949-a523a484-9b24-43aa-93ac-9817ccf6e51d.png">
+
+<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>
+
+<img width="600"  src="https://user-images.githubusercontent.com/1130416/234150191-a8e9296b-ae52-4f3a-a3d3-b933418ec10d.png">
+
+<br>
+
+* workflow of scroll's rollup:
+
+<br>
+
+<img width="610" src="https://user-images.githubusercontent.com/1130416/234150359-d612ac1e-e338-45fa-ab8d-f51fd653b6cd.png">
+
+
+<br>
+
+---
+
+### resources
+
+<br>
+
+* [scroll on mirror](https://scroll.mirror.xyz/)

zkEVM/starkware.md

@@ -0,0 +1,16 @@
+## 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 STARKSs. 
+
+<br>
+
+---
+
+### resources

zkEVM/taiko.md

@@ -0,0 +1,16 @@
+## 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).
+
+<br>
+
+----
+
+### resources

zkEVM/zkSync/README.md

@@ -0,0 +1,32 @@
+## 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>
+
+### in this dir
+
+<br>
+
+* [zksync era](era.md)
+
+<br>
+
+----
+
+### resources
+
+<br>
+
+* [dune board zksync vs. polygon zkEVM](https://dune.com/21shares_research/zkevm-comparison-zksync-era-vs-polygon-hermez)

zkEVM/zkSync/era.md

@@ -0,0 +1,26 @@
+## zksync era
+
+<br>
+
+### tl; dr
+
+
+<br>
+
+* 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>
+
+----
+
+### resources
+
+<br>
+
+* [zksync ecosystem](https://ecosystem.zksync.io/)
+* [gm zkEVM, by zksync](https://blog.matter-labs.io/gm-zkevm-171b12a26b36)

zkps.md

@@ -0,0 +1,83 @@
+## ⛓🫱🏻‍🫲🏽 zero-knowledge proofs
+
+<br>
+
+<p align="center">
+<img src="https://user-images.githubusercontent.com/1130416/234397705-090a0c7b-5d96-49f8-8eaa-183297e3fe37.png" width="50%" align="center" style="padding:1px;border:1px solid black;"/>
+
+<br>
+<br>
+
+### tl; dr
+
+<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).
+* **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).
+
+<br>
+
+#### 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).
+
+<br>
+
+#### 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>
+
+---
+
+### in this dir
+
+<br>
+
+* **[zk-EVMs](zkEVM)**
+* **[number theory](number_theory)**
+* **[proof systems](proofs)**
+* **[cryptographic primitives](primitives)**
+* **[machine learning](applications/ml.md)**
+* **[privacy-enhancing technologies](applications/privacy_enhancing_technologies.md)**
+* **[incomplete catalog of zkp projects](applications/zkp_projects.md)**
+
+
+<br>
+
+----
+
+
+### more resources
+
+<br>
+
+* **[zkiap](https://zkiap.com/)**
+* **[zkrepl](https://zkrepl.dev/)**
+* **[zk-learnng](https://zk-learning.org/)**
+* **[pse's mirror](https://mirror.xyz/privacy-scaling-explorations.eth)**
+* **[0xparc on circom](https://learn.0xparc.org/circom/)**
+* **[0xparc on halo2](https://learn.0xparc.org/halo2/)**
+* **[zero knowledge postcast youtube](https://www.youtube.com/@zeroknowledgefm)**
+* **[rollups are not real, by jon charbonneau](https://joncharbonneau.substack.com/p/rollups-arent-real)**
+* **[what are zk proofs, ethereum foundation](https://ethereum.org/en/zero-knowledge-proofs/)**
+* **[the zk-ECDSA landscape, by pse (ethereum foundation)](https://mirror.xyz/privacy-scaling-explorations.eth/djxf2g9VzUcss1e-gWIL2DSRD4stWggtTOcgsv1RlxY)**
+* **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)**
+* **[zero knowledge dapp from 0 to production, by vivian plasencia](https://vivianblog.hashnode.dev/how-to-create-a-zero-knowledge-dapp-from-zero-to-production)**
+* **[an evolution of models for zkps, with sarah meiklejohn](https://youtube.com/watch?v=HO97kVMI3SE&t=2s)**
+* **[an incomplete guide to folding](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](https://vitalik.eth.limo/general/2024/04/29/binius.html)**
+
+