move old resources from protocol toolkit
This commit is contained in:
bt3gl
parent
88a381fd34
commit
632be7cbf5
31 changed files with 357 additions and 466 deletions
17
README.md
17
README.md
|
|
@ -1,15 +1,8 @@
|
|||
## privacy by math toolkit
|
||||
## decentralized cryptography 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)**
|
||||
* ⬛️ **[cryptographic primitives](cryptographic_primitives)**
|
||||
* ⬛️ **[zero-knowledge systems](zero_knowledge)**
|
||||
* ⬛️ **[trusted execution environments](trusted_execution_environments)**
|
||||
* ⬛️ **[multi-party computation](multi_party_computation)**
|
||||
|
|
|
|||
|
|
@ -1,7 +0,0 @@
|
|||
## privacy-based technologies
|
||||
|
||||
<br>
|
||||
|
||||
* [functional encryption](functional.md)
|
||||
* [fully-homomorphic encryption (fhe)](fhe.md)
|
||||
* [trsuted execution environments (tee)](tee.md)
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
### 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/)
|
||||
|
||||
|
||||
|
|
@ -4,17 +4,14 @@
|
|||
|
||||
### bls signatures
|
||||
|
||||
<br>
|
||||
|
||||
* 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>
|
||||
|
||||
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
----
|
||||
|
|
@ -29,14 +26,16 @@
|
|||
|
||||
<br>
|
||||
|
||||
|
||||
---
|
||||
|
||||
### cool resources
|
||||
|
||||
<br>
|
||||
|
||||
----
|
||||
|
||||
### resources
|
||||
|
||||
<br>
|
||||
|
||||
* **[number theory course by stanford](https://crypto.stanford.edu/pbc/notes/numbertheory/)**
|
||||
* **[pairing-friendly elliptic curves of prime order](https://eprint.iacr.org/2005/133.pdf)**
|
||||
* **[intro to differential power analysis](https://link.springer.com/content/pdf/10.1007/s13389-011-0006-y.pdf)**
|
||||
* **[the 12 commandments of synchronization](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.227.3871&rep=rep1&type=pdf)**
|
||||
* **[ring confidential transactions](https://eprint.iacr.org/2015/1098.pdf)**
|
||||
* **[galois fields, part one](https://www.youtube.com/watch?v=yBVqk4YM2VY)**
|
||||
* **[bls multi-signatures with pub-key aggregation](https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html)**
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
## 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)**
|
||||
6
mpc.md
6
mpc.md
|
|
@ -1,6 +0,0 @@
|
|||
## 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/)**
|
||||
32
multi_party_computation/README.md
Normal file
32
multi_party_computation/README.md
Normal file
|
|
@ -0,0 +1,32 @@
|
|||
## secure multi-party computation
|
||||
|
||||
<br>
|
||||
|
||||
### overview
|
||||
|
||||
<br>
|
||||
|
||||
* **[a pragmatic introduction to secure multi-party computation, by evans et al.](https://securecomputation.org/docs/pragmaticmpc.pdf)**: comprehensive book introducting mpc, protocols such as yao's garbled circuits, gmw, bgw, prepocessed multiplication tiples, bmr, information-theoretic garbled circuits, implentation techniques, oblivious data structures, malicious security, and threat models.
|
||||
* **[cryptographic computing, by a. univ](https://users-cs.au.dk/orlandi/crycom/)**
|
||||
* **[secure multiparty computation, by lindell](https://eprint.iacr.org/2020/300.pdf)**: review what MPC is, what problems it solves, and how it is being currently used, including details on shamir secret sharing, honest-majority mpc with secret sharing, output reconstruction, threshold cryptography.
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
|
||||
### on defi
|
||||
|
||||
<br>
|
||||
|
||||
* **[backrunning private transactions using mpc, by annessi](https://writings.flashbots.net/backrunning-private-txs-MPC)**: diagram for a sgx-based solution for backrunning private txs, talk about covert channels, experiments with mp-spdz, show a poc decoding with rlp.
|
||||
* **[exploring cryptographic approaches to enhance privacy in intent solving, by yulia khalniyazova](https://zenodo.org/records/8321167)**
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
|
||||
### open-source projects
|
||||
|
||||
<br>
|
||||
|
||||
* **[mp-spdz, versatile framework for multi-party computation](https://github.com/data61/MP-SPDZ/tree/master?tab=readme-ov-file)** (benchmark several mpc protocols for several security models)
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
## number theory
|
||||
|
||||
<br>
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
|
||||
### external resources
|
||||
|
||||
<br>
|
||||
|
||||
* **[number theory course by stanford](https://crypto.stanford.edu/pbc/notes/numbertheory/)**
|
||||
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
## 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)**
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
## 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>
|
||||
|
|
@ -4,15 +4,17 @@
|
|||
|
||||
### hardware
|
||||
|
||||
#### sgx stuff
|
||||
<br>
|
||||
|
||||
##### 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)**
|
||||
* **[intel SGX explained, by costan et al.](https://eprint.iacr.org/2016/086.pdf)**
|
||||
* **[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
|
||||
##### cloud providers
|
||||
|
||||
* **[nitro enclaves at aws](https://aws.amazon.com/ec2/nitro/nitro-enclaves/)**
|
||||
|
||||
|
|
@ -22,6 +24,8 @@
|
|||
|
||||
### quantum settings
|
||||
|
||||
<br>
|
||||
|
||||
* **[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)**
|
||||
|
|
@ -32,12 +36,16 @@
|
|||
|
||||
### offensive
|
||||
|
||||
<br>
|
||||
|
||||
* **[using memory errors to attack a virtual machine, by govindavajhala et al.](https://www.cs.princeton.edu/~appel/papers/memerr.pdf)**
|
||||
|
||||
<br>
|
||||
|
||||
----
|
||||
|
||||
### blockchain-specific
|
||||
### blockchain specific
|
||||
|
||||
<br>
|
||||
|
||||
* **[demystifying remote attestation by taking it on-chain, by flashbots](https://collective.flashbots.net/t/demystifying-remote-attestation-by-taking-it-on-chain/2629)**
|
||||
104
zero_knowledge/README.md
Normal file
104
zero_knowledge/README.md
Normal 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)**
|
||||
|
|
@ -2,40 +2,26 @@
|
|||
|
||||
<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>
|
||||
|
||||
<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
|
||||
* **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
|
||||
* model integrity
|
||||
- assurance that the same ml algorithm is ran on different data the same way
|
||||
* attestations
|
||||
* attestations
|
||||
- integrate attestations from external parties
|
||||
* decentralized inference or traning
|
||||
- perform ml training in a decentralized way
|
||||
|
|
@ -45,12 +31,12 @@
|
|||
|
||||
---
|
||||
|
||||
### resources
|
||||
### 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)**
|
||||
* **[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)**
|
||||
|
|
@ -9,25 +9,25 @@
|
|||
* 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>
|
||||
|
||||
<img width="284" src="https://user-images.githubusercontent.com/1130416/234407214-ed3974fd-85cc-471b-a08b-e2edf0efd1a2.png">
|
||||
<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
|
||||
|
||||
<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">
|
||||
|
||||
|
||||
<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>
|
||||
|
||||
|
|
@ -35,46 +35,37 @@
|
|||
|
||||
<br>
|
||||
|
||||
<img width="487" src="https://user-images.githubusercontent.com/1130416/235269418-3cb7b4ca-83b7-4930-a367-586cb8be4fc7.png">
|
||||
|
||||
<p align="center">
|
||||
<img width="250" src="https://user-images.githubusercontent.com/1130416/235269418-3cb7b4ca-83b7-4930-a367-586cb8be4fc7.png">
|
||||
</p>
|
||||
|
||||
<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
|
||||
### chapters
|
||||
|
||||
<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)**
|
||||
|
||||
* **[zk-snarks](zk-snarks)**
|
||||
* **[zk-starks](zk-starks)**
|
||||
* **[plonk](plonk)**
|
||||
* **[halo2](halo2)**
|
||||
* **[nova](nova)**
|
||||
* **[bulletproofs](bulletproofs)**
|
||||
* **[kate](kate)**
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
|
||||
### resources
|
||||
### cool 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)**
|
||||
* **[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)**
|
||||
|
||||
|
|
@ -2,16 +2,6 @@
|
|||
|
||||
<br>
|
||||
|
||||
### tl; dr
|
||||
|
||||
<br>
|
||||
|
||||
<p align="center">
|
||||
<img width="600" src="https://user-images.githubusercontent.com/1130416/234164194-032fe86c-c0c6-4479-ac14-859759356641.png">
|
||||
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
|
||||
### resourses
|
||||
</p>
|
||||
|
|
@ -9,3 +9,14 @@
|
|||
* 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)**
|
||||
|
|
@ -14,17 +14,18 @@
|
|||
|
||||
<br>
|
||||
|
||||
<p align="center">
|
||||
<img width="586" src="https://user-images.githubusercontent.com/1130416/234472661-000ccabb-2bce-4e16-8a51-f599c04b643d.png">
|
||||
|
||||
</p>
|
||||
|
||||
<br>
|
||||
|
||||
----
|
||||
|
||||
### resources
|
||||
### cool 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)**
|
||||
* **[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)**
|
||||
|
|
@ -13,8 +13,8 @@
|
|||
|
||||
---
|
||||
|
||||
### resources
|
||||
### cool resources
|
||||
|
||||
<br>
|
||||
|
||||
* [nova: recursive snarks without trusted setup, by microsoft](https://github.com/microsoft/Nova)
|
||||
* **[nova: recursive snarks without trusted setup, by microsoft](https://github.com/microsoft/Nova)**
|
||||
36
zero_knowledge/proofs/plonk/README.md
Normal file
36
zero_knowledge/proofs/plonk/README.md
Normal 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)**
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
## zk-SNARKS
|
||||
## zk-snarks
|
||||
|
||||
<br>
|
||||
|
||||
|
|
@ -6,10 +6,14 @@
|
|||
|
||||
<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).
|
||||
* 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>
|
||||
|
||||
|
|
@ -20,9 +24,6 @@
|
|||
* **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
|
||||
|
|
@ -44,21 +45,17 @@
|
|||
|
||||
---
|
||||
|
||||
### resources
|
||||
### 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 vitalik](https://vitalik.ca/general/2021/01/26/snarks.html)**
|
||||
* **[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)**
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
##### halo2
|
||||
|
||||
* **[intro to PLONKish/halo2, by ying tong](https://docs.google.com/presentation/d/1UpMo2Ze5iwzpwICPoKkeT04-xGFRp7ZzVPhgnidr-vs/edit#slide=id.g133c45f1bcd_3_36)**
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
## zk-STARKS
|
||||
## zk-starks
|
||||
|
||||
<br>
|
||||
|
||||
|
|
@ -15,12 +15,12 @@
|
|||
|
||||
---
|
||||
|
||||
### resources
|
||||
### 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 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)
|
||||
* **[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)**
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
## zk-EVMs
|
||||
## zkEVMs
|
||||
|
||||
<br>
|
||||
|
||||
|
|
@ -7,17 +7,13 @@
|
|||
<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.
|
||||
* 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
|
||||
* ***"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
|
||||
|
||||
<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).
|
||||
|
|
@ -28,27 +24,16 @@
|
|||
|
||||
<br>
|
||||
|
||||
|
||||
---
|
||||
|
||||
### recent advancements
|
||||
|
||||
<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
|
||||
|
||||
<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.
|
||||
|
|
@ -62,34 +47,31 @@
|
|||
<img width="450" src="https://user-images.githubusercontent.com/1130416/234139749-4dbac8ab-d742-45f3-b920-b0b51d8698b5.png">
|
||||
</p>
|
||||
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
|
||||
### in this dir
|
||||
### chapters
|
||||
|
||||
<br>
|
||||
|
||||
* **[zk-rollups overview](rollups.md)**
|
||||
* **[zkSync](zkSync)**
|
||||
* **[starkware](starkware.md)**
|
||||
* **[polygon hermez](polygon.md)**
|
||||
* **[scroll](scroll.md)**
|
||||
* **[taiko](taiko.md)**
|
||||
* **[starkware](starkware)**
|
||||
* **[polygon](polygon)**
|
||||
* **[scroll](scroll)**
|
||||
* **[taiko](taiko)**
|
||||
|
||||
<br>
|
||||
|
||||
----
|
||||
|
||||
### external resources
|
||||
### cool 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)**
|
||||
* **[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)**
|
||||
|
||||
|
|
@ -8,18 +8,18 @@
|
|||
|
||||
* 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>
|
||||
|
||||
---
|
||||
|
||||
### resources
|
||||
### cool resources
|
||||
|
||||
<br>
|
||||
|
||||
* [polygon zkevm announcement](https://polygon.technology/blog/the-future-is-now-for-ethereum-scaling-introducing-polygon-zkevm)
|
||||
* **[polygon zkevm announcement](https://polygon.technology/blog/the-future-is-now-for-ethereum-scaling-introducing-polygon-zkevm)**
|
||||
|
|
@ -15,20 +15,23 @@
|
|||
|
||||
<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
|
||||
* 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>
|
||||
|
||||
|
|
@ -36,15 +39,16 @@
|
|||
|
||||
<br>
|
||||
|
||||
<p align="center">
|
||||
<img width="610" src="https://user-images.githubusercontent.com/1130416/234150359-d612ac1e-e338-45fa-ab8d-f51fd653b6cd.png">
|
||||
|
||||
</p>
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
|
||||
### resources
|
||||
### cool resources
|
||||
|
||||
<br>
|
||||
|
||||
* [scroll on mirror](https://scroll.mirror.xyz/)
|
||||
* **[scroll's publications](https://scroll.mirror.xyz/)**
|
||||
|
|
@ -7,10 +7,5 @@
|
|||
<br>
|
||||
|
||||
* layer-2 scaling solution aiming to increase the efficiency and scalability of blockchains (e.g., ethereum, bsc, polkadot).
|
||||
* it uses STARKSs.
|
||||
* it uses starks.
|
||||
|
||||
<br>
|
||||
|
||||
---
|
||||
|
||||
### resources
|
||||
|
|
@ -9,8 +9,3 @@
|
|||
* "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
|
||||
39
zero_knowledge/zkEVMs/zkSync/README.md
Normal file
39
zero_knowledge/zkEVMs/zkSync/README.md
Normal 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)**
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
## 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
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
## 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)
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
## 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)
|
||||
83
zkps.md
83
zkps.md
|
|
@ -1,83 +0,0 @@
|
|||
## ⛓🫱🏻🫲🏽 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)**
|
||||
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue