github/pse.dev
1
1
Fork 0
mirror of https://github.com/privacy-scaling-explorations/pse.dev.git synced 2026-01-10 14:48:13 -05:00
Code Issues Packages Projects Releases Wiki Activity

feat: add blog post feed to project pages #368 (#369)

Browse Source 
- [x] Add blog post feed to project pages #368
- [x] update readme
- [x] fix blog tags
This commit is contained in:
Kalidou Diagne
2025-05-01 14:59:04 +03:00
committed by GitHub
parent fdaecf8a69
commit f022fa21fb
43 changed files with 547 additions and 311 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@@ -21,7 +21,7 @@ Enhancing Ethereum through cryptographic research and collective experimentation
#### For internal, PSE member:
- Suggest to tag: @kalidiagne, @b1gk4t, @AtHeartEngineer for PR review.
- Suggest to tag: @kalidiagne, @psedesign, @AtHeartEngineer for PR review.
- If question, please reach out in discord channel #website-pse
#### For external:

2
app/[lang]/blog/[slug]/page.tsx
View File

@@ -122,7 +122,7 @@ export default function BlogArticle({ params }: any) {
>
Tags:
</span>
<div className="flex gap-2">
<div className="flex flex-wrap gap-2">
{post?.tags?.map((tag) => (
<Link key={tag} href={`/${params.lang}/blog?tag=${tag}`}>
<Button

3
app/[lang]/projects/sections/ProjectContent.tsx
View File

@@ -19,7 +19,7 @@ import { ProjectLinkIconMap } from "@/components/mappings/project-links"
import { WikiSideNavigation } from "@/components/wiki-side-navigation"
import { useTranslation } from "@/app/i18n/client"
import { LocaleTypes } from "@/app/i18n/settings"
import { ProjectBlogArticles } from "@/components/blog/project-blog-articles"
export const ProjectContent = ({
id,
lang = "en",
@@ -261,6 +261,7 @@ export const ProjectContent = ({
</div>
</AppContent>
<ProjectBlogArticles project={project} lang={lang} />
<DiscoverMoreProjects project={project} lang={lang} />
</Divider.Section>
</div>

19
app/api/articles/route.ts Normal file
View File

@@ -0,0 +1,19 @@
import { NextResponse } from "next/server"
import { getArticles } from "@/lib/blog"
export async function GET(request: Request) {
const { searchParams } = new URL(request.url)
const project = searchParams.get("project")
const limit = searchParams.get("limit")
? parseInt(searchParams.get("limit") || "100")
: undefined
const tag = searchParams.get("tag") || undefined
const articles = getArticles({
project: project || undefined,
limit,
tag,
})
return NextResponse.json({ articles })
}

3
articles/README.md
View File

@@ -20,6 +20,7 @@ tldr: "A brief summary of your article" #Short summary
date: "YYYY-MM-DD" # Publication date in ISO format
canonical: "mirror.xyz/my-new-article" # (Optional) The original source URL, this tells search engines the primary version of the content
tags: ["tag1", "tag2"] # (Optional) Add relevant tags as an array of strings to categorize the article
projects: ["project-1"]
---
```
@@ -62,7 +63,7 @@ Before submitting, make sure to:
Open Pull request following the previews step and for any help
- Suggest to tag: @kalidiagne, @b1gk4t, @AtHeartEngineer for PR review.
- Suggest to tag: @kalidiagne, @psedesign, @AtHeartEngineer for PR review.
- If question, please reach out in discord channel #website-pse
## Important Notes

33
articles/a-technical-introduction-to-arbitrums-optimistic-rollup.md
View File

@@ -5,20 +5,21 @@ image: null
tldr: ""
date: "2022-08-29"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/UlHGv9KIk_2MOHr7POfwZAXP01k221hZwQsLCF63cLQ"
projects: []
---
![](https://miro.medium.com/max/1392/1*6CesZrI_Az8ZQ3Zff0y6gw.png)
Originally published on Sep 30, 2021:
Arbitrum is Offchain Labs’ optimistic rollup implementation that aims to greatly increase the throughput of the Ethereum network. This guide is an introduction to how the Arbitrum design works and is meant for anyone looking to get a somewhat technical overview on this layer 2 solution. This article assumes that the reader has some knowledge of Ethereum and optimistic rollups. The following links may be helpful to those who would like more info on optimistic rollups:
Arbitrum is Offchain Labs' optimistic rollup implementation that aims to greatly increase the throughput of the Ethereum network. This guide is an introduction to how the Arbitrum design works and is meant for anyone looking to get a somewhat technical overview on this layer 2 solution. This article assumes that the reader has some knowledge of Ethereum and optimistic rollups. The following links may be helpful to those who would like more info on optimistic rollups:
1. [Optimistic Rollups](https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/optimistic_rollups/)
2. [An Incomplete Guide to Rollups](https://vitalik.ca/general/2021/01/05/rollup.html)
3. [A Rollup-Centric Ethereum Roadmap](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698)
4. [(Almost) Everything you need to know about the Optimistic Rollup](https://research.paradigm.xyz/rollups)
The Arbitrum network is run by two main types of nodes — batchers and validators. Together these nodes interact with Ethereum mainnet (layer 1, L1) in order to maintain a separate chain with its own state, known as layer 2 (L2). Batchers are responsible for taking user L2 transactions and submitting the transaction data onto L1. Validators on the other hand, are responsible for reading the transaction data on L1, processing the transaction and therefore updating the L2 state. Validators will then post the updated L2 state data to L1 so that anyone can verify the validity of this new state. The transaction and state data that is actually stored on L1 is described in more detail in the ‘Transaction and State Data Storage on L1’ section.
The Arbitrum network is run by two main types of nodes — batchers and validators. Together these nodes interact with Ethereum mainnet (layer 1, L1) in order to maintain a separate chain with its own state, known as layer 2 (L2). Batchers are responsible for taking user L2 transactions and submitting the transaction data onto L1. Validators on the other hand, are responsible for reading the transaction data on L1, processing the transaction and therefore updating the L2 state. Validators will then post the updated L2 state data to L1 so that anyone can verify the validity of this new state. The transaction and state data that is actually stored on L1 is described in more detail in the 'Transaction and State Data Storage on L1' section.
**Basic Workflow**
@@ -28,7 +29,7 @@ The Arbitrum network is run by two main types of nodes — batchers and validato
4. Once processed, a new L2 state is generated locally and the validator will post this new state root into an L1 smart contract.
5. Then, all other validators will process the same transactions on their local copies of the L2 state.
6. They will compare their resultant L2 state root with the original one posted to the L1 smart contract.
7. If one of the validators gets a different state root than the one posted to L1, they will begin a challenge on L1 (explained in more detail in the ‘Challenges’ section).
7. If one of the validators gets a different state root than the one posted to L1, they will begin a challenge on L1 (explained in more detail in the 'Challenges' section).
8. The challenge will require the challenger and the validator that posted the original state root to take turns proving what the correct state root should be.
9. Whichever user loses the challenge, gets their initial deposit (stake) slashed. If the original L2 state root posted was invalid, it will be destroyed by future validators and will not be included in the L2 chain.
@@ -38,7 +39,7 @@ The following diagram illustrates this basic workflow for steps 1–6.
## Batcher Nodes and Submitting L2 Transaction Data
There are two different L1 smart contracts that batcher nodes will use to post the transaction data. One is known as the ‘delayed inbox’ while the other is known as the ‘sequencer inbox’. Anyone can send transactions to the delayed inbox, whereas only the sequencer can send transactions to the sequencer inbox. The sequencer inbox pulls in transaction data from the delayed inbox and interweaves it with the other L2 transactions submitted by the sequencer. Therefore, the sequencer inbox is the primary contract where every validator pulls in the latest L2 transaction data.
There are two different L1 smart contracts that batcher nodes will use to post the transaction data. One is known as the 'delayed inbox' while the other is known as the 'sequencer inbox'. Anyone can send transactions to the delayed inbox, whereas only the sequencer can send transactions to the sequencer inbox. The sequencer inbox pulls in transaction data from the delayed inbox and interweaves it with the other L2 transactions submitted by the sequencer. Therefore, the sequencer inbox is the primary contract where every validator pulls in the latest L2 transaction data.
There are 3 types of batcher nodes — forwarders, aggregators, and sequencers. Users can send their L2 transactions to any of these 3 nodes. Forwarder nodes forward any L2 transactions to a designated address of another node. The designated node can be either a sequencer or an aggregator and is referred to as the aggregator address.
@@ -52,7 +53,7 @@ Essentially, batcher nodes are responsible for submitting any L2 transaction dat
## Validator Nodes and Submitting L2 State Data
The set of smart contracts that enable validators to submit and store L2 state data is known as the rollup. The rollup is essentially a chain of blocks, so in other words, the rollup is the L2 chain. Note that the Arbitrum codebase refers to these blocks as ‘nodes’. However, to prevent confusion with the terms ‘validator nodes’ and ‘batcher nodes’, I will continue to refer to these rollup nodes as blocks throughout the article.
The set of smart contracts that enable validators to submit and store L2 state data is known as the rollup. The rollup is essentially a chain of blocks, so in other words, the rollup is the L2 chain. Note that the Arbitrum codebase refers to these blocks as 'nodes'. However, to prevent confusion with the terms 'validator nodes' and 'batcher nodes', I will continue to refer to these rollup nodes as blocks throughout the article.
Each block contains a hash of the L2 state data. So, validators will read and process transactions from the sequencer inbox, and then submit the updated L2 state data hash to the rollup smart contract. The rollup, which stores a chain of blocks, will create a new block with this data and add it as the latest block to the chain. When the validator submits the L2 state data to the rollup smart contract, they also specify which block in the current chain is the parent block to this new block.
@@ -68,16 +69,16 @@ Once a validator becomes a staker, they can then stake on different blocks. Here
A block will be confirmed — permanently accepted in L1 and never reverted — if all of the following are true:
- The 7 day period has passed since the block’s creation
- The 7 day period has passed since the block's creation
- There are no existing challenging blocks
- At least one staker is staked on it
A block can be rejected (destroyed) if all of the following are true:
- It’s parent block is older than the latest confirmed block (the latest confirmed block is on another branch)
- It's parent block is older than the latest confirmed block (the latest confirmed block is on another branch)
- There is a staker staked on a sibling block
- There are no stakers staked on this block
- The 7 day period has passed since the block’s creation
- The 7 day period has passed since the block's creation
Take the following diagram as an example:
@@ -123,15 +124,15 @@ Since the smart contracts only have to store hashes in their storage rather than
**The Arbitrum Virtual Machine**
Since Arbitrum L2 transactions are not executed on L1, they don’t have to follow the same exact rules as the EVM for computation. Therefore, the Arbitrum team built their own virtual machine known as the Arbitrum Virtual Machine (AVM). The AVM is very similar to the EVM because a primary goal was to support compatibility with EVM compiled smart contracts. However, there are a few important differences.
Since Arbitrum L2 transactions are not executed on L1, they don't have to follow the same exact rules as the EVM for computation. Therefore, the Arbitrum team built their own virtual machine known as the Arbitrum Virtual Machine (AVM). The AVM is very similar to the EVM because a primary goal was to support compatibility with EVM compiled smart contracts. However, there are a few important differences.
A major difference between the AVM and EVM is that the AVM must support Arbitrum’s challenges. Challenges, covered in more detail in the next section, require that a step of transaction execution must be provable. Therefore, Arbitrum has introduced the use of CodePoints to their virtual machine. Normally, when code is executed, the instructions are stored in a linear array with a program counter (PC) pointing to the current instruction. Using the program counter to prove which instruction is being executed would take logarithmic time. In order to reduce this time complexity to constant time, the Arbitrum team implemented CodePoints — a pair of the current instruction and the hash of the next codepoint. Every instruction in the array has a codepoint and this allows the AVM to instantly prove which instruction was being executed at that program counter. CodePoints do add some complexity to the AVM, but the Arbitrum system only uses codepoints when it needs to make a proof about transaction execution. Normally, it will use the normal program counter architecture instead.
A major difference between the AVM and EVM is that the AVM must support Arbitrum's challenges. Challenges, covered in more detail in the next section, require that a step of transaction execution must be provable. Therefore, Arbitrum has introduced the use of CodePoints to their virtual machine. Normally, when code is executed, the instructions are stored in a linear array with a program counter (PC) pointing to the current instruction. Using the program counter to prove which instruction is being executed would take logarithmic time. In order to reduce this time complexity to constant time, the Arbitrum team implemented CodePoints — a pair of the current instruction and the hash of the next codepoint. Every instruction in the array has a codepoint and this allows the AVM to instantly prove which instruction was being executed at that program counter. CodePoints do add some complexity to the AVM, but the Arbitrum system only uses codepoints when it needs to make a proof about transaction execution. Normally, it will use the normal program counter architecture instead.
There are quite a few other important differences that are well documented on Arbitrum’s site — [Why AVM Differs from EVM](https://developer.offchainlabs.com/docs/inside_arbitrum#why-avm-differs-from-evm)
There are quite a few other important differences that are well documented on Arbitrum's site — [Why AVM Differs from EVM](https://developer.offchainlabs.com/docs/inside_arbitrum#why-avm-differs-from-evm)
**ArbOS**
ArbOS is Arbitrum’s own operating system. It is responsible for managing and tracking the resources of smart contracts used during execution. So, ArbOS keeps an account table that keeps track of the state for each account. Additionally, it operates the funding model for validators participating in the rollup protocol.
ArbOS is Arbitrum's own operating system. It is responsible for managing and tracking the resources of smart contracts used during execution. So, ArbOS keeps an account table that keeps track of the state for each account. Additionally, it operates the funding model for validators participating in the rollup protocol.
The AVM has built in instructions to aid the execution of ArbOS and its ability to track resources. This support for ArbOS in the AVM allows ArbOS to implement certain rules of execution at layer 2 instead of in the rollup smart contracts on layer 1. Any computation moved from layer 1 to layer 2 saves gas and lowers expenses.
@@ -147,15 +148,15 @@ This process continues until the contested part of execution is only one instruc
## Conclusion
**How does this raise Ethereum’s transaction per second and lower transaction costs?**
**How does this raise Ethereum's transaction per second and lower transaction costs?**
Arbitrum, along with all optimistic rollups, greatly improves the scalability of the Ethereum network and therefore lowers the gas costs (holding throughput constant). In L1 every Ethereum full node in the network will process the transaction, and since the network contains so many nodes, computation becomes very expensive. With Arbitrum, transactions will only be processed by a small set of nodes — the sequencer, aggregators, and validators. So, the computation of each transaction has been moved off of L1 while only the transaction calldata remains on L1. This clears a lot of space on L1 and allows many more transactions to be processed. The greater throughput reduces the gas costs since the competition for getting a transaction added to a block is lower.
**Anything special about Abritrum’s implementation of optimistic rollups?**
**Anything special about Abritrum's implementation of optimistic rollups?**
Arbitrum’s design gives many advantages that other rollup implementations don’t have because of its use of interactive proving. Interactive proving provides a great number of benefits, such as no limits on contract size, that are outlined in good detail on Arbitrum’s site — [Why Interactive Proving is Better](https://developer.offchainlabs.com/docs/inside_arbitrum#why-interactive-proving-is-better). With Arbitrum’s successful mainnet launch (though still early), it’s clear that the project has achieved an incredible feat.
Arbitrum's design gives many advantages that other rollup implementations don't have because of its use of interactive proving. Interactive proving provides a great number of benefits, such as no limits on contract size, that are outlined in good detail on Arbitrum's site — [Why Interactive Proving is Better](https://developer.offchainlabs.com/docs/inside_arbitrum#why-interactive-proving-is-better). With Arbitrum's successful mainnet launch (though still early), it's clear that the project has achieved an incredible feat.
If you’re interested in reading more on Arbitrum’s optimistic rollup, their documentation covers a lot more ground and is easy to read.
If you're interested in reading more on Arbitrum's optimistic rollup, their documentation covers a lot more ground and is easy to read.
- [Arbitrum Doc — Inside Arbitrum](https://developer.offchainlabs.com/docs/inside_arbitrum)
- [Arbitrum Doc — Rollup Protocol](https://developer.offchainlabs.com/docs/rollup_protocol)

39
articles/a-technical-introduction-to-maci-10-privacy-scaling-explorations.md
View File

@@ -5,6 +5,7 @@ image: null
tldr: ""
date: "2022-08-29"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/IlWP_ITvmeZ2-elTJl44SCEGlBiemKt3uxXv2A6Dqy4"
projects: ["maci"]
---
![](https://miro.medium.com/max/1400/0*aWsBozO7zkpxbwpH.png)
@@ -35,26 +36,26 @@ Originally published on Jan 18, 2022:
4. [Conclusion](https://mirror.xyz/privacy-scaling-explorations.eth/IlWP_ITvmeZ2-elTJl44SCEGlBiemKt3uxXv2A6Dqy4#53c9)
MACI, which stands for Minimal Anti-Collusion Infrastructure, is an application that allows users to have an on-chain voting process with greatly increased collusion resistance. A common problem among today’s on-chain voting processes is how easy it is to bribe voters into voting for a particular option. Oftentimes this bribery takes the form of “join our pool (vote our way) and we will give you a cut of the rewards (the bribe)”. Since all transactions on the blockchain are public, without MACI, voters can easily prove to the briber which option they voted for and therefore receive the bribe rewards.
MACI, which stands for Minimal Anti-Collusion Infrastructure, is an application that allows users to have an on-chain voting process with greatly increased collusion resistance. A common problem among today's on-chain voting processes is how easy it is to bribe voters into voting for a particular option. Oftentimes this bribery takes the form of "join our pool (vote our way) and we will give you a cut of the rewards (the bribe)"". Since all transactions on the blockchain are public, without MACI, voters can easily prove to the briber which option they voted for and therefore receive the bribe rewards.
MACI counters this by using zk-SNARKs to essentially hide how each person voted while still revealing the final vote result. User’s cannot prove which option they voted for, and therefore bribers cannot reliably trust that a user voted for their preferred option. For example, a voter can tell a briber that they are voting for option A, but in reality they voted for option B. There is no reliable way to prove which option the voter actually voted for, so the briber does not have the incentive to pay voters to vote their way.
MACI counters this by using zk-SNARKs to essentially hide how each person voted while still revealing the final vote result. User's cannot prove which option they voted for, and therefore bribers cannot reliably trust that a user voted for their preferred option. For example, a voter can tell a briber that they are voting for option A, but in reality they voted for option B. There is no reliable way to prove which option the voter actually voted for, so the briber does not have the incentive to pay voters to vote their way.
## a. Background
For a general overview, the history and the importance of MACI, see [Release Announcement: MACI 1.0](https://medium.com/privacy-scaling-explorations/release-announcement-maci-1-0-c032bddd2157) by Wei Jie, one of the creators. He also created a very helpful [youtube video](https://www.youtube.com/watch?v=sKuNj_IQVYI) on the overview of MACI. To see the origin of the idea of MACI, see Vitalik’s research post on [Minimal Anti-Collusion Infrastructure](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413?u=weijiekoh). Lastly, it is recommended to understand the basic idea behind zk-SNARKs, as these are a core component of MACI. The following articles are great resources:
For a general overview, the history and the importance of MACI, see [Release Announcement: MACI 1.0](https://medium.com/privacy-scaling-explorations/release-announcement-maci-1-0-c032bddd2157) by Wei Jie, one of the creators. He also created a very helpful [youtube video](https://www.youtube.com/watch?v=sKuNj_IQVYI) on the overview of MACI. To see the origin of the idea of MACI, see Vitalik's research post on [Minimal Anti-Collusion Infrastructure](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413?u=weijiekoh). Lastly, it is recommended to understand the basic idea behind zk-SNARKs, as these are a core component of MACI. The following articles are great resources:
- [Introduction to zk-SNARKs](https://consensys.net/blog/developers/introduction-to-zk-snarks/) — Consensys
- [What are zk-SNARKs](https://z.cash/technology/zksnarks/) — Zcash
- [An approximate introduction to how zk-SNARKs are possible](https://vitalik.ca/general/2021/01/26/snarks.html) — Vitalik
- [zkSNARKs in a nutshell](https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell/) — Ethereum.org
This article will go over the general workflow of MACI and how it is capable of providing the following tenets (taken word for word from Wei Jie’s article):
This article will go over the general workflow of MACI and how it is capable of providing the following tenets (taken word for word from Wei Jie's article):
1. **Collusion Resistance**: No one except a trusted coordinator should be certain of the validity of a vote, reducing the effectiveness of bribery
2. **Receipt-freeness**: No voter may prove (besides to the coordinator) which way they voted
3. **Privacy**: No one except a trusted coordinator should be able to decrypt a vote
4. **Uncensorability**: No one (not even the trusted coordinator) should be able to censor a vote
5. **Unforgeability**: Only the owner of a user’s private key may cast a vote tied to its corresponding public key
5. **Unforgeability**: Only the owner of a user's private key may cast a vote tied to its corresponding public key
6. **Non-repudiation**: No one may modify or delete a vote after it is cast, although a user may cast another vote to nullify it
7. **Correct execution**: No one (not even the trusted coordinator) should be able to produce a false tally of votes
@@ -64,9 +65,9 @@ This article will go over the general workflow of MACI and how it is capable of
In the MACI workflow, there are two different roles: users (voters) and a single trusted coordinator. The users vote on the blockchain via MACI smart contracts, and the coordinator tallies up the votes and releases the final results.
The coordinators must use zk-SNARKs to prove that their final tally result is valid without releasing the vote of every individual. Therefore, even if a coordinator is corrupt, they are unable to change a user’s vote or add extra votes themselves. A corrupt coordinator can stop a vote by never publishing the results, but they can’t publish false results.
The coordinators must use zk-SNARKs to prove that their final tally result is valid without releasing the vote of every individual. Therefore, even if a coordinator is corrupt, they are unable to change a user's vote or add extra votes themselves. A corrupt coordinator can stop a vote by never publishing the results, but they can't publish false results.
Before sending their vote on the blockchain, users encrypt their vote using a shared key that only the user and coordinator can know. This key scheme is designed so that every individual user shares a distinct key with the coordinator. This prevents any bribers from simply reading the transaction data to see which option a user voted for. The encrypted vote is now considered a “message” and the user sends this message to a MACI smart contract to be stored on-chain.
Before sending their vote on the blockchain, users encrypt their vote using a shared key that only the user and coordinator can know. This key scheme is designed so that every individual user shares a distinct key with the coordinator. This prevents any bribers from simply reading the transaction data to see which option a user voted for. The encrypted vote is now considered a "message" and the user sends this message to a MACI smart contract to be stored on-chain.
A very simplified illustration of this encryption can be seen below:
@@ -74,11 +75,11 @@ A very simplified illustration of this encryption can be seen below:
## b. Vote Overriding and Public Key Switching
Before a user can cast a vote, they must sign up by sending the public key they wish to use to vote to a MACI smart contract. This public key acts as their identity when voting. They can vote from any address, but their message must contain a signature from that public key. When casting an actual vote after signing up, a user will bundle a few variables — including a public key, their vote option, their vote amount, and a few others — into what is called a “command”. Then, the user signs the command with the public key they originally used to sign up. After that, the user encrypts the signature and command together so that it is now considered a message. This more complex description of how a message is constructed is illustrated below:
Before a user can cast a vote, they must sign up by sending the public key they wish to use to vote to a MACI smart contract. This public key acts as their identity when voting. They can vote from any address, but their message must contain a signature from that public key. When casting an actual vote after signing up, a user will bundle a few variables — including a public key, their vote option, their vote amount, and a few others — into what is called a "command". Then, the user signs the command with the public key they originally used to sign up. After that, the user encrypts the signature and command together so that it is now considered a message. This more complex description of how a message is constructed is illustrated below:
![](https://miro.medium.com/max/1400/0*whHfC8-xxAwSyaaO)
Users are able to override their previous vote as long as they sign their command with the previous public key. If the command is properly signed by the user’s previous public key, then the message is considered valid and the coordinator will count this as the correct vote. So, when a user provides a public key in their vote that is different than their previous public key, they may now submit a new vote signed by this new public key to override their previous vote. If the signature is not from the previous public key, the message will be marked as invalid and not counted toward the tally. Therefore, the public key can be thought of as the user’s voting username, and the signature is the voting password. If they provide the correct signature, they can submit a vote or change their public key — or both.
Users are able to override their previous vote as long as they sign their command with the previous public key. If the command is properly signed by the user's previous public key, then the message is considered valid and the coordinator will count this as the correct vote. So, when a user provides a public key in their vote that is different than their previous public key, they may now submit a new vote signed by this new public key to override their previous vote. If the signature is not from the previous public key, the message will be marked as invalid and not counted toward the tally. Therefore, the public key can be thought of as the user's voting username, and the signature is the voting password. If they provide the correct signature, they can submit a vote or change their public key — or both.
This feature, which I refer to as public key switching, is designed to counter the bribery attack where a user simply shows the briber their message, and then decrypts it for the briber to see which way the user voted. Public key switching allows users to change their public key and create invalid messages in favor of the bribers. The bribers have no way of telling if the user switched their public keys before sending in the vote shown to the bribers.
@@ -88,8 +89,8 @@ This can be quite confusing so here is an example:
2. Bob then creates a command that contains — a vote for option A and public key 2
3. Bob signs this command with public key 1, the key he used to sign up
4. Bob encrypts this command into a message and submits it to the MACI smart contracts
5. The coordinator decrypts this message, and checks to ensure that the command is signed by Bob’s previous key — public key 1. This message is valid.
6. The coordinator then records Bob’s vote for option A and updates his public key to public key 2
5. The coordinator decrypts this message, and checks to ensure that the command is signed by Bob's previous key — public key 1. This message is valid.
6. The coordinator then records Bob's vote for option A and updates his public key to public key 2
![](https://miro.medium.com/max/1400/0*t3CAiLfDniv2fkYI)
@@ -98,12 +99,12 @@ At this point, Bob has successfully voted for option A, and in order to override
1. Bob creates a command that contains — a vote for option B and public key 1
2. Bob signs this command with public key 1, encrypts the message and submits it to the MACI smart contracts
3. Bob shows the briber the decrypted message as proof of his vote for option B
4. The coordinator decrypts Bob’s message and sees that the signature does not match up with public key 2 — Bob’s previous key added in his previous message. Therefore this message is invalid and this vote is not counted in the final tally.
4. The coordinator decrypts Bob's message and sees that the signature does not match up with public key 2 — Bob's previous key added in his previous message. Therefore this message is invalid and this vote is not counted in the final tally.
5. The briber has no way of knowing whether the vote was valid or invalid, and so is not incentivized to offer bribes to other users.
![](https://miro.medium.com/max/1400/0*tqKB8TxOQj27IVS3)
In order to get a good idea of how MACI works, it’s important to know how the zk-SNARKs are able to prove that the coordinator decrypted each message and tallied the votes properly. The next section gives a quick and much oversimplified overview of zk-SNARKs, although the readings listed in the introduction are much more helpful.
In order to get a good idea of how MACI works, it's important to know how the zk-SNARKs are able to prove that the coordinator decrypted each message and tallied the votes properly. The next section gives a quick and much oversimplified overview of zk-SNARKs, although the readings listed in the introduction are much more helpful.
## c. zk-SNARKs
@@ -130,7 +131,7 @@ Here, everyone is able to see the messages on the blockchain and the total tally
1. Encrypt to the messages present on the blockchain
2. Sum to the tally result
Users can then use the SNARK to prove that the tally result is correct, but cannot use it to prove any individual’s vote choices.
Users can then use the SNARK to prove that the tally result is correct, but cannot use it to prove any individual's vote choices.
Now that the core components of MACI have been covered, it is helpful to dive deeper into the MACI workflow and specific smart contracts.
@@ -159,11 +160,11 @@ The sign up process for MACI is handled via the MACI.sol smart contract. Users n
2. Sign Up Gatekeeper Data
3. Initial Voice Credit Proxy Data
The public key is the original public key mentioned in above sections that the user will need to vote. As explained in earlier sections, they can change this public key later once voting starts. The user’s public key used to sign up is shared amongst every poll.
The public key is the original public key mentioned in above sections that the user will need to vote. As explained in earlier sections, they can change this public key later once voting starts. The user's public key used to sign up is shared amongst every poll.
MACI allows the contract creator/owner to set a “signUpGateKeeper”. The sign up gatekeeper is meant to be the address of another smart contract that determines the rules to sign up. So, when a user calls MACI.signUp(), the function will call the sign up gatekeeper to check if this user is valid to sign up.
MACI allows the contract creator/owner to set a "signUpGateKeeper". The sign up gatekeeper is meant to be the address of another smart contract that determines the rules to sign up. So, when a user calls MACI.signUp(), the function will call the sign up gatekeeper to check if this user is valid to sign up.
MACI also allows the contract creator/owner to set an “initialVoiceCreditProxy”. This represents the contract that determines how many votes a given user gets. So, when a user calls MACI.signUp(), the function will call the initial voice credit proxy to check how many votes they can spend. The user’s voice credit balance is reset to this number for every new poll.
MACI also allows the contract creator/owner to set an "initialVoiceCreditProxy". This represents the contract that determines how many votes a given user gets. So, when a user calls MACI.signUp(), the function will call the initial voice credit proxy to check how many votes they can spend. The user's voice credit balance is reset to this number for every new poll.
Once MACI has checked that the user is valid and retrieved how many voice credits they have, MACI stores the following user info into the Sign Up Merkle Tree:
@@ -196,10 +197,10 @@ The PollProcessorAndTallyer contract will send the proof to a separate verifier
Finally, once all messages have been processed, the coordinator tallies the votes of the valid messages. The coordinator creates a zk-SNARK proving that the valid messages in the state tree (proved in Process Messages step) contain votes that sum to the given tally result. Then, they call PollProcessorAndTallyer.tallyVotes() with a hash of the correct tally results and the zk-SNARK proof. Similarly to the processMessages function, the tallyVotes function will send the proof to a verifier contract to ensure that it is valid.
The tallyVotes function is only successful if the verifier contract returns that the proof is valid. Therefore, once the tallyVotes function succeeds, users can trust that the coordinator has correctly tallied all of the valid votes. After this step, anyone can see the final tally results and the proof that these results are a correct result of the messages sent to the Poll contract. The users won’t be able to see how any individual voted, but will be able to trust that these votes were properly processed and counted.
The tallyVotes function is only successful if the verifier contract returns that the proof is valid. Therefore, once the tallyVotes function succeeds, users can trust that the coordinator has correctly tallied all of the valid votes. After this step, anyone can see the final tally results and the proof that these results are a correct result of the messages sent to the Poll contract. The users won't be able to see how any individual voted, but will be able to trust that these votes were properly processed and counted.
![](https://miro.medium.com/max/1400/0*7Le2odbX7e2etpxR)
## 4\. Conclusion
MACI is a huge step forward in preventing collusion for on-chain votes. While it doesn’t prevent all possibilities of collusion, it does make it much harder. MACI can already be [seen](https://twitter.com/vitalikbuterin/status/1329012998585733120) to be in use by the [clr.fund](https://blog.clr.fund/round-4-review/), which has users vote on which projects to receive funding. When the possible funding amount becomes very large, users and organizations have a large incentive to collude to receive parts of these funds. This is where MACI can truly make a difference, to protect the fairness of such important voting processes such as those at clr.fund.
MACI is a huge step forward in preventing collusion for on-chain votes. While it doesn't prevent all possibilities of collusion, it does make it much harder. MACI can already be [seen](https://twitter.com/vitalikbuterin/status/1329012998585733120) to be in use by the [clr.fund](https://blog.clr.fund/round-4-review/), which has users vote on which projects to receive funding. When the possible funding amount becomes very large, users and organizations have a large incentive to collude to receive parts of these funds. This is where MACI can truly make a difference, to protect the fairness of such important voting processes such as those at clr.fund.

15
articles/advancing-anon-aadhaar-whats-new-in-v100.md
View File

@@ -2,13 +2,14 @@
authors: ["Anon Aadhaar Team"]
title: "Advancing Anon Aadhaar: what's new in v1.0.0"
image: "/articles/advancing-anon-aadhaar-whats-new-in-v100/advancing-anon-aadhaar-whats-new-in-v100-cover.webp"
tldr: "This post was written by the Anon Aadhaar team. If you’re new to Anon Aadhaar make sure to read our [initial announcement post](https://mirror.xyz/privacy-scaling-explorations.eth/6R8kACTYp9mF3eIpLZMXs8JAQmTyb6Uy8KnZqzmDFZI)."
tldr: "This post was written by the Anon Aadhaar team. If you're new to Anon Aadhaar make sure to read our [initial announcement post](https://mirror.xyz/privacy-scaling-explorations.eth/6R8kACTYp9mF3eIpLZMXs8JAQmTyb6Uy8KnZqzmDFZI)."
date: "2024-02-14"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/YnqHAxpjoWl4e_K2opKPN4OAy5EU4sIJYYYHFCjkNOE"
tags: ["test"]
projects: ["anon-aadhaar", "zk-email", "bandada"]
---
[Anon Aadhaar](https://github.com/anon-aadhaar/anon-aadhaar) is a protocol that enables [Aadhaar](https://en.wikipedia.org/wiki/Aadhaar) holders to prove their identity anonymously. It works by verifying the Aadhaar card's issuer signature, which is issued by the Indian government in formats like *PDF*, _XML_, and _Secure QR_ code. These digital versions are signed using RSA, involving a pair of keys: a private key for signing data and a public key for verification.
[Anon Aadhaar](https://github.com/anon-aadhaar/anon-aadhaar) is a protocol that enables [Aadhaar](https://en.wikipedia.org/wiki/Aadhaar) holders to prove their identity anonymously. It works by verifying the Aadhaar card's issuer signature, which is issued by the Indian government in formats like _PDF_, _XML_, and _Secure QR_ code. These digital versions are signed using RSA, involving a pair of keys: a private key for signing data and a public key for verification.
Our protocol leverages the [UIDAI's](https://uidai.gov.in/en/about-uidai.html) (government authority) RSA signature, enabling us to verify the documents as anyone could. The novelty of our approach is the use of a SNARK proof in the verification process, which hides sensitive data from the verifier, maintaining the same level of verification while enhancing privacy.
@@ -21,7 +22,7 @@ However, we encountered two major issues:
1. The PDF's size was too large for circuit input
2. A changing timestamp in the document made it impossible to have a consistent identity hash
To overcome these obstacles, we transitioned to use the [Aadhaar secure QR code](https://uidai.gov.in/en/ecosystem/authentication-devices-documents/qr-code-reader.html) for verification purposes.
To overcome these obstacles, we transitioned to use the [Aadhaar secure QR code](https://uidai.gov.in/en/ecosystem/authentication-devices-documents/qr-code-reader.html) for verification purposes.
This method is not only broadly adopted but also readily accessible through the [mAadhaar](https://uidai.gov.in/en/contact-support/have-any-question/285-english-uk/faqs/your-aadhaar/maadhaar-faqs.html) mobile application or via the printed version of the e-Aadhaar PDF. This adjustment enhances the efficiency of verifying signed identity data and streamlines the process of document parsing within our system.
@@ -29,7 +30,7 @@ This method is not only broadly adopted but also readily accessible through the
1. **SHA-256 Hash Verification**: leveraging [zk-email](https://github.com/zkemail) implementation, we've integrated SHA-256 hash verification alongside RSA verification, allowing us to work effectively with the signed data.
2. **Extractor**: with verified data, our new Circom extractor implementation enables selective extraction of identity fields from the document.
3. **Nullifiers**: we're now computing two types of nullifiers:
3. **Nullifiers**: we're now computing two types of nullifiers:
- **userNullifier**: this nullifier serves as a high-entropy, unique identifier for each user, virtually eliminating the possibility of collisions between the identifiers of different individuals. It is generated by hashing the combination of the last four digits of a user's Aadhaar number and their identity photo. The unique byte data of the photo enhances the identifier's uniqueness, ensuring distinctness even in the vast pool of users. This approach is particularly useful for app interactions, where collision avoidance is crucial.
@@ -45,7 +46,7 @@ This method is not only broadly adopted but also readily accessible through the
The dual nullifier system ensures both robust identity verification and the flexibility to accommodate changes in user data, maintaining a seamless user experience while safeguarding against identity collisions and enhancing privacy and security.
4. **Timestamp Check**: our circuit extracts the IST signature timestamp, captured at the moment the QR code is signed, and convert it to UNIX UTC timestamp. This serves as a real-time indicator of document issuance and user access to their UIDAI portal, functioning akin to a Time-based One-Time Password (TOTP) system. It ensures document freshness and validates recent user interaction, requiring proofs to be signed within a specified timeframe (e.g., less than 1 hour ago) for verification purposes.
4. **Timestamp Check**: our circuit extracts the IST signature timestamp, captured at the moment the QR code is signed, and convert it to UNIX UTC timestamp. This serves as a real-time indicator of document issuance and user access to their UIDAI portal, functioning akin to a Time-based One-Time Password (TOTP) system. It ensures document freshness and validates recent user interaction, requiring proofs to be signed within a specified timeframe (e.g., less than 1 hour ago) for verification purposes.
5. **Signal Signing**: this functionality empowers both applications and users to securely sign any data during the proof generation process, a critical component for implementing ERC-4337 standards. It facilitates the creation of Aadhaar-linked transaction hash signatures, offering a robust mechanism to deter front-running in on-chain transactions by anchoring the _msg.sender_ identity within smart contract interactions. This advancement paves the way for the development of Account Abstraction Wallets, enabling users to authenticate and execute transactions directly with their identity, streamlining the user experience while enhancing security.
6. **Improved On-chain Verification Gas Cost**: outputting the issuer's public key hash from the circuit allows us to store this value in the AnonAadhaar smart contract, reducing on-chain verification costs.
@@ -54,10 +55,10 @@ This method is not only broadly adopted but also readily accessible through the
We are incredibly excited to see what developers will build using Anon Aadhaar v1! And invite you to join the [Anon Aadhaar Community](https://t.me/anon_aadhaar) to continue the conversation. To support and inspire your innovative projects, we prepared a variety of resources for you to try:
- **[GitHub Repository](https://github.com/anon-aadhaar/anon-aadhaar)**: dive into the codebase and explore the inner workings of our protocol.
- **[Project ideas to Build with Anon Aadhaar:](https://github.com/anon-aadhaar/anon-aadhaar/discussions/155)** looking for inspiration? Here are some ideas we’ve compiled.
- **[Project ideas to Build with Anon Aadhaar:](https://github.com/anon-aadhaar/anon-aadhaar/discussions/155)** looking for inspiration? Here are some ideas we've compiled.
- **[On-chain voting Example App](https://github.com/anon-aadhaar/boilerplate)**: get hands-on with a practical implementation to see how Anon Aadhaar can be integrated into real-world applications.
- **[Quick Setup Repository](https://github.com/anon-aadhaar/quick-setup)**: for those eager to get started, this repository provides a streamlined Nextjs setup process.
- **[Documentation](https://anon-aadhaar-documentation.vercel.app/)**: comprehensive and detailed, our documentation covers everything from basic setup to advanced features, ensuring you have the information needed at your fingertips.
- **[Roadmap](https://github.com/privacy-scaling-explorations/bandada/discussions/350)**: get an idea about how we’re thinking of evolving the protocol.
- **[Roadmap](https://github.com/privacy-scaling-explorations/bandada/discussions/350)**: get an idea about how we're thinking of evolving the protocol.
We're eager to witness the creative and impactful ways in which the developer community will utilize Anon Aadhaar, pushing the boundaries of privacy and security in digital identity verification. Happy coding!

17
articles/announcing-anon-aadhaar.md
View File

@@ -2,9 +2,10 @@
authors: ["Anon Aadhaar team"]
title: "Announcing Anon Aadhaar"
image: "/articles/announcing-anon-aadhaar/announcing-anon-aadhaar-cover.webp"
tldr: "_This post was written by the Anon Aadhaar team._ /n/n _We’re excited to announce the public release of Anon Aadhaar!_"
tldr: "_This post was written by the Anon Aadhaar team._ /n/n _We're excited to announce the public release of Anon Aadhaar!_"
date: "2023-09-21"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/6R8kACTYp9mF3eIpLZMXs8JAQmTyb6Uy8KnZqzmDFZI"
projects: ["anon-aadhaar", "bandada", "discreetly"]
---
### What is Anon Aadhaar?
@@ -15,11 +16,11 @@ Anon Aadhaar is a protocol that lets users anonymously prove their Aadhaar (Indi
### Why Aadhaar cards?
The [Aadhaar program](https://en.wikipedia.org/wiki/Aadhaar) is among the largest digital identity schemes in the world. There are 1.2 billion people enrolled, accounting for around 90% of India’s population.
The [Aadhaar program](https://en.wikipedia.org/wiki/Aadhaar) is among the largest digital identity schemes in the world. There are 1.2 billion people enrolled, accounting for around 90% of India's population.
Aadhaar cards carry both demographic and biometric data, including the holder’s date of birth and its fingerprint. They are used in a variety of contexts such as loan agreements or housing applications. Bring this onchain in a privacy preserving way opens the possibility for many more applications on Ethereum.
Aadhaar cards carry both demographic and biometric data, including the holder's date of birth and its fingerprint. They are used in a variety of contexts such as loan agreements or housing applications. Bring this onchain in a privacy preserving way opens the possibility for many more applications on Ethereum.
Anon Aadhaar is one instantiation of the broader “Anonymous Credentials" with the goals of “[proof of citizenship](https://discord.com/channels/943612659163602974/1141757600568971304/1141759379578822707)”, “proof of identity”, “proof of passport”, “proof of personhood”, among others. Our approach leverages government identities, in this case Aadhaar Cards, to enhance digital interactions.
Anon Aadhaar is one instantiation of the broader "Anonymous Credentials" with the goals of "[proof of citizenship](https://discord.com/channels/943612659163602974/1141757600568971304/1141759379578822707)", "proof of identity", "proof of passport", "proof of personhood", among others. Our approach leverages government identities, in this case Aadhaar Cards, to enhance digital interactions.
### Importance of Anonymity
@@ -27,7 +28,7 @@ A healthy society enables people to voice their concerns, opinions and ideas wit
**Contextual anonymity is key to build trust** and enhance the value of noise to signal.
In the broader context, Anon Aadhaar supports [proof of personhood](https://vitalik.ca/general/2023/07/24/biometric.html) by adding a convenient privacy layer. We can talk about a “forth column” that leverages existing PKI and public government ID programs to enhance digital interactions.
In the broader context, Anon Aadhaar supports [proof of personhood](https://vitalik.ca/general/2023/07/24/biometric.html) by adding a convenient privacy layer. We can talk about a "forth column" that leverages existing PKI and public government ID programs to enhance digital interactions.
![](/articles/announcing-anon-aadhaar/ZfpBm9HmDYDgP8rTYnA_9.webp)
@@ -55,12 +56,12 @@ Check our [documentation](https://anon-aadhaar-documentation.vercel.app/docs/int
Anonymous protocols are very versatile, so get creating! If you want inspiration here are some ideas:
- **HeyIndia:** a copy of [HeyAnon](https://heyanon.xyz/) app, but need to prove you’re from India in order to post.
- **HeyIndia:** a copy of [HeyAnon](https://heyanon.xyz/) app, but need to prove you're from India in order to post.
- **Aadhaar Wallet:** similar to [Myna](https://ethglobal.com/showcase/myna-uxzdd), create an ERC-4337 compatible wallet that uses your Aadhaar card to approve transactions or social recover with other users.
- **Voting App for Quadratic Voting:** vote if you can prove your citizenship.
- **Telegram private groups:** where you need to prove you’re an Indian citizen in order to join
- **Telegram private groups:** where you need to prove you're an Indian citizen in order to join
- **[Bandada](https://pse.dev/projects/bandada) credential groups**: gatekept by Anon Aadhaar proofs and then integrated to anonymous chats using [Discreetly](https://pse.dev/projects/discreetly).
- **SSO Server:** anonymously login with your “proof of citizenship” in any website. Explore integrations with Sign in with Ethereum
- **SSO Server:** anonymously login with your "proof of citizenship" in any website. Explore integrations with Sign in with Ethereum
- **Payment Channel:** use Anon Aadhaar SDK to create payment channel. Help people can verify another party with zkp. This is only for demo how people can use our SDK.
- **Loan Approval Platform:** create a platform for secure and anonymous loan approvals based on Aadhaar information.
- **Ethereum Wallet Recovery:** design a dApp that helps users recover their Ethereum wallets using their Aadhaar credentials.

11
articles/announcing-maci-v111.md
View File

@@ -5,15 +5,16 @@ image: ""
tldr: "This post was authored by [Alessandro](https://github.com/ctrlc03) and [Chao](https://github.com/chaosma)"
date: "2023-01-18"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/ltCt68hslI5jmMf1AnfkrP2eUwkeZ8_fgkHc_WyD9Nc"
projects: ["maci"]
---
We are pleased to announce the release of an updated version of MACI - Minimal Anti-Collusion Infrastructure v1.1.1.
This new release brings a more secure product, new features, and a much needed documentation refresh. Before we dive into the updates, let’s refresh your memory on what MACI is and what it was created to achieve.
This new release brings a more secure product, new features, and a much needed documentation refresh. Before we dive into the updates, let's refresh your memory on what MACI is and what it was created to achieve.
## Background
MACI is an application that provides collusion resistance for on-chain voting processes. It was originally created after Vitalik’s [post](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413), and has since been revisited and improved.
MACI is an application that provides collusion resistance for on-chain voting processes. It was originally created after Vitalik's [post](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413), and has since been revisited and improved.
MACI revolves around the need for a trusted coordinator. The coordinator is in charge of setting up the system, publishing its public key, and computing the tally of the votes. Below are the main properties of MACI:
@@ -30,7 +31,7 @@ MACI was [audited](https://github.com/privacy-scaling-explorations/maci/blob/v1/
In more details, the audit revealed two high risk issues within the zk-SNARK circuits:
- Incomplete validation when processing messages
- Integer overflow which could have allowed users to affect a coordinator’s effort of calculating the subsidy by either making it incorrect or by intercepting the calculation
- Integer overflow which could have allowed users to affect a coordinator's effort of calculating the subsidy by either making it incorrect or by intercepting the calculation
Another notable security issue was the lack of initialization of the `AccQueue` contract. This contract is used to store messages (votes or topups) for the different polls. Without inserting a zero value hash into the merkle tree contract as the first message during initialization, a malicious user could have performed a denial of service attack on a poll. This could have resulted in the poll results taking a very long time before being tallied by the coordinator.
@@ -38,7 +39,7 @@ All of these issues have been successfully resolved, on top of fixing minor issu
## New Features
The following sections provide a quick introduction to the newest features introduced in MACI’s codebase.
The following sections provide a quick introduction to the newest features introduced in MACI's codebase.
![](/articles/announcing-maci-v111/Gfn-Vu6lKKsJ750LQIXxA.webp)
@@ -68,7 +69,7 @@ Finally, please note that currently it is not possible to generate the `zkeys` f
MACI now includes a sample [coordinator service](https://github.com/privacy-scaling-explorations/maci/tree/v1/server).
There are two roles in the coordinator service: admin (i.e. MACI coordinator) and user (i.e. a voter). The admin’s responsibility is to ensure that the code remains updated and that the backend services are live. The user can then simply send HTTP requests to the backend server to interact with MACI, for instance, by signing up and publishing a message on chain.
There are two roles in the coordinator service: admin (i.e. MACI coordinator) and user (i.e. a voter). The admin's responsibility is to ensure that the code remains updated and that the backend services are live. The user can then simply send HTTP requests to the backend server to interact with MACI, for instance, by signing up and publishing a message on chain.
The coordinator service has been wrapped into two docker instances: one for the backend server to accept user requests; one for the Mongodb service to store all necessary information on the current state such as smart contract addresses, zero knowledge proof keys and so on.

9
articles/announcing-the-pse-grants-program.md Normal file
View File

@@ -0,0 +1,9 @@
---
authors: ["PSE Team"]
title: "Announcing the PSE Grants Program"
image: null
tldr: ""
date: "2022-08-29"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/Oa6yUZVtMKRQFHFpHe3oGVOGPrDMzCUUzJw_xGlBQXM"
projects: []
---

3
articles/anonklub-reflections-on-our-journey-in-privacy-preserving-solutions.md
View File

@@ -5,6 +5,7 @@ image: "/articles/anonklub-reflections-on-our-journey-in-privacy-preserving-solu
tldr: "This post was written by the AnonKlub team."
date: "2024-10-01"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/7VTKFVR4PM75WtNnBzuQSBZW-UYoJOsnzBBQmB9MWbY"
projects: ["anon-klub"]
---
One year and half ago, we embarked on an ambitious journey to explore the potential of zk-ECDSA in bringing enhanced privacy to the Ethereum ecosystem. This research initiative was introduced to the community through a **[blog post detailing the state of zk-ECDSA and its promising applications](https://mirror.xyz/privacy-scaling-explorations.eth/djxf2g9VzUcss1e-gWIL2DSRD4stWggtTOcgsv1RlxY)**.
@@ -56,7 +57,7 @@ Privacy vs Performance Trade-Offs Of Different ZK Frameworks Used
### **PLUME signature/nullifier scheme adoption hurdles**
Nullifying zk ECDSA proofs is hard. The best candidate for robust and secure nullifier for zk proofs of ecdsa signature is [PLUME](https://blog.aayushg.com/nullifier/). PLUME signatures aren’t standard signatures that mainstream wallets can build out of the box: the PLUME signature scheme is a new feature that needs to be implemented into mainstream wallets. As long as mainstream wallets don’t adopt PLUME, users can’t easily generate “deterministic and verifiable nullifiers on ECDSA”. Meaning they can’t use any applications that would make use of ECDSA zk proofs, such as AnonKlub.
Nullifying zk ECDSA proofs is hard. The best candidate for robust and secure nullifier for zk proofs of ecdsa signature is [PLUME](https://blog.aayushg.com/nullifier/). PLUME signatures aren't standard signatures that mainstream wallets can build out of the box: the PLUME signature scheme is a new feature that needs to be implemented into mainstream wallets. As long as mainstream wallets don't adopt PLUME, users can't easily generate "deterministic and verifiable nullifiers on ECDSA". Meaning they can't use any applications that would make use of ECDSA zk proofs, such as AnonKlub.
## Why We're Stopping

13
articles/bandada-is-live.md
View File

@@ -2,9 +2,10 @@
authors: ["Bandada Team"]
title: "Bandada is live!"
image: "/articles/bandada-is-live/bandada-is-live-cover.webp"
tldr: "This post was written by the Bandada team. /n/n We are happy to announce the public release of Bandada V1! Try our [app](https://bandada.pse.dev/) out or run it yourself locally [v1.0.0-alpha](https://github.com/privacy-scaling-explorations/bandada/releases/tag/v1.0.0-alpha)"
tldr: "This post was written by the Bandada team. /n/n We are happy to announce the public release of Bandada V1! Try our [app](https://bandada.pse.dev/) out or run it yourself locally [v1.0.0-alpha](https://github.com/privacy-scaling-explorations/bandada/releases/tag/v1.0.0-alpha)"
date: "2023-08-23"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/p3Mtft28FG1ctgeUARVEKLTK_KexnWC6T4CUHaQark4"
projects: ["bandada", "semaphore"]
---
## **Background**
@@ -19,7 +20,7 @@ Bandada allows you to create groups and establish trust within the participants
## Why _Bandada_?
In Spanish, "Bandada" means "flock" or "group” of birds or animals moving together in a coordinated manner.
In Spanish, "Bandada" means "flock" or "group" of birds or animals moving together in a coordinated manner.
1. **Representation of Anonymous Groups:** Just like a flock of birds or animals moving together, Bandada aims to create privacy-preserving groups where individuals can act collectively without revealing their identities.
2. **Coordinated and Secure Interaction:** Birds in a flock exhibit coordinated movements for navigation, safety, or foraging. Similarly, Bandada enables coordinated and secure interactions among the members of anonymous groups. The infrastructure provided allows for seamless communication and collaboration within these groups without compromising individual identities.
@@ -37,7 +38,7 @@ In Spanish, "Bandada" means "flock" or "group” of birds or animals moving toge
- Group with members who have contributed to a specific GitHub repository
- “Whitelist” a group of GitHub devs who have contributed to top DAOs repositories.
- "Whitelist" a group of GitHub devs who have contributed to top DAOs repositories.
- Group of people with more than X followers on Twitter
@@ -79,13 +80,13 @@ Bandada also provides a preset of credential validators that can be extended wit
Check [here](https://www.notion.so/Bandada-Learning-Resources-Project-Ideas-68803d6da8374a4399824e9a93995ff3?pvs=21) for new and upcoming learning resources like tutorials, videos, and additional documentation and growing project ideas to do with Bandada.
Lastly, keep exploring our [Bandada Notion](https://www.notion.so/Bandada-82d0d9d3c6b64b7bb2a09d4c7647c083?pvs=21) where we’ll keep it updated with the latest news.
Lastly, keep exploring our [Bandada Notion](https://www.notion.so/Bandada-82d0d9d3c6b64b7bb2a09d4c7647c083?pvs=21) where we'll keep it updated with the latest news.
## Bandada Moonrise
Shortly after this announcement, we´re starting Bandada Moonrise, a focused effort, and campaign to showcase Bandada and gather as much feedback as possible from the community to tailor the future roadmap.
If you’re part of a DAO, Web3, or ZK Dev community and want us to give a presentation, please reach us out!
If you're part of a DAO, Web3, or ZK Dev community and want us to give a presentation, please reach us out!
## **What's coming in the future?**
@@ -102,6 +103,6 @@ Want to share ideas? Want to help us build Bandada? Reach us by tagging us with
Also if you contribute to Bandada´s codebase, then you´re eligible to claim a special POAP!
🥳 Check if you´re eligible and get yours here: [https://www.gitpoap.io/eligibility](https://www.gitpoap.io/eligibility)
🥳 Check if you´re eligible and get yours here: [https://www.gitpoap.io/eligibility](https://www.gitpoap.io/eligibility)
Thanks to all contributors and Bandada supporters! In particular @cedoor, @vplasencia, @saleel, @aguzmant103, @rachelaux, @beyondr, @wanseob, @mari, @kat

55
articles/beyond-zero-knowledge-whats-next-in-programmable-cryptography.md
View File

@@ -5,15 +5,16 @@ image: "/articles/beyond-zero-knowledge-whats-next-in-programmable-cryptography/
tldr: "_This post was written by [kichong](https://twitter.com/kichongtran) with helpful feedback and comments from [sinu](https://twitter.com/sinu_eth) and [jmall](https://twitter.com/Janmajaya_mall)._"
date: "2023-11-09"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/xXcRj5QfvA_qhkiZCVg46Gn9uX8P_Ld-DXlqY51roPY"
projects: ["pse-security"]
---
MPC, FHE, iO. If these combinations of letters make little sense to you, then you’re in the right place. This post attempts to review, at a high level, the world of programmable cryptography beyond the borders of zero-knowledge (ZK).
MPC, FHE, iO. If these combinations of letters make little sense to you, then you're in the right place. This post attempts to review, at a high level, the world of programmable cryptography beyond the borders of zero-knowledge (ZK).
The intent is to expose people to the idea that ZK is only one part of a constantly shifting landscape of cryptographic primitives, techniques, and protocols. And what remains is more powerful, more private, and more confusing than the average cryptography-curious person is aware of.
This post makes no claims, conclusions, or predictions. This is no deep dive. At best, it’s an informal skimming of the surface in the quest for the holy grail of cryptography.
This post makes no claims, conclusions, or predictions. This is no deep dive. At best, it's an informal skimming of the surface in the quest for the holy grail of cryptography.
While encryption has been around for thousands of years, programmable cryptography is a modern technology. Described as “[general-purpose cryptography … \[or\] an expressive language for claims”](https://archive.devcon.org/archive/watch/6/zkps-and-programmable-cryptography/?tab=YouTube), it’s the idea that a cryptographic primitive like a ZK proof could be made flexible and adaptive enough that a developer could program nearly any function on top of it. That there can exist an unbroken chain of logic from someone clicking a button on a website to the mathematical proof that guarantees the security of a cryptographic operation.
While encryption has been around for thousands of years, programmable cryptography is a modern technology. Described as "[general-purpose cryptography … \[or\] an expressive language for claims](https://archive.devcon.org/archive/watch/6/zkps-and-programmable-cryptography/?tab=YouTube)", it's the idea that a cryptographic primitive like a ZK proof could be made flexible and adaptive enough that a developer could program nearly any function on top of it. That there can exist an unbroken chain of logic from someone clicking a button on a website to the mathematical proof that guarantees the security of a cryptographic operation.
![https://youtu.be/qAfprVCBhdQ?t=1024](/articles/beyond-zero-knowledge-whats-next-in-programmable-cryptography/6I3pxfsamZF_nsL_X3k6T.webp)
@@ -31,47 +32,47 @@ If you think of programmable cryptography as a type of digital computer, built o
## **Relatively intuitive comparisons**
To better understand the general landscape of programmable cryptography, let’s start by very roughly approximating where MPC, FHE, and IO stand in relation to ZK, and each other. In this section, and really all the sections that come after, we will trade-off nuance, precision, and formality in favor of simplicity and accessibility.
To better understand the general landscape of programmable cryptography, let's start by very roughly approximating where MPC, FHE, and IO stand in relation to ZK, and each other. In this section, and really all the sections that come after, we will trade-off nuance, precision, and formality in favor of simplicity and accessibility.
The simplest way to reason about cryptography is what information is kept hidden or secret. And what the system proves or reveals.
![](/articles/beyond-zero-knowledge-whats-next-in-programmable-cryptography/-AAI15NdLONUuc7SGb9Jt.webp)
You can also think of each of these systems as standing in for an imaginary mutual friend. [Wikipedia calls this friend “Tony”.](https://en.wikipedia.org/wiki/Secure_multi-party_computation#Definition_and_overview) Tony is infallible, incorruptible, and totally trustworthy. Tony’s job is to keep secrets. In the table below, think of the “Private Elements” as what secrets Tony can be trusted to keep, the “Use Cases” as tasks Tony could perform reasonably well, and the “Practicality” as how skillfully Tony could perform these tasks today.
You can also think of each of these systems as standing in for an imaginary mutual friend. [Wikipedia calls this friend "Tony."](https://en.wikipedia.org/wiki/Secure_multi-party_computation#Definition_and_overview) Tony is infallible, incorruptible, and totally trustworthy. Tony's job is to keep secrets. In the table below, think of the "Private Elements" as what secrets Tony can be trusted to keep, the "Use Cases" as tasks Tony could perform reasonably well, and the "Practicality" as how skillfully Tony could perform these tasks today.
![](/articles/beyond-zero-knowledge-whats-next-in-programmable-cryptography/lj84zAzL24ghhq-rWsuW2.webp)
The tables above are intended to give a rough idea for different areas of programmable cryptography. Now, let’s go a bit deeper and review what MPC, FHE, and iO do along with some interesting tidbits about each field.
The tables above are intended to give a rough idea for different areas of programmable cryptography. Now, let's go a bit deeper and review what MPC, FHE, and iO do along with some interesting tidbits about each field.
## **Multi-Party Computation (MPC)**
Multi-Party Computation (MPC) allows many parties to jointly compute some agreed upon function without revealing any data to the other participants. With MPC, the same computation is applied to everyone's data, but each party’s input is kept secret. Intermediate values would also stay secret. Only the output is revealed at the end.
Multi-Party Computation (MPC) allows many parties to jointly compute some agreed upon function without revealing any data to the other participants. With MPC, the same computation is applied to everyone's data, but each party's input is kept secret. Intermediate values would also stay secret. Only the output is revealed at the end.
As opposed to ZK, MPC is collaborative. It allows different parties to collaborate on the same computation, each contributing their own data, to get some mutual result everyone wants.
We can compare ZK and MPC in the context of an AI system to get more context. ZK would be good at authenticating or verifying a piece of data came from a real person or from a person’s phone. MPC is better for training an AI system because different individuals, groups, or organizations could share sensitive data with the AI system but trust that the data won’t be revealed to anyone else.
We can compare ZK and MPC in the context of an AI system to get more context. ZK would be good at authenticating or verifying a piece of data came from a real person or from a person's phone. MPC is better for training an AI system because different individuals, groups, or organizations could share sensitive data with the AI system but trust that the data won't be revealed to anyone else.
## **Millionaire problems**
MPC was thought of in [1982 by Andrew Yao](https://research.cs.wisc.edu/areas/sec/yao1982-ocr.pdf) to solve a thought experiment called the “Millionaire’s Problem” where two millionaire’s want to know who is richer without telling each other how much money they have. The solution was to use [garbled circuits, which according to Vitalik Buterin,](https://vitalik.ca/general/2020/03/21/garbled.html) frequent explainer of cryptographic concepts, is also one of the most basic ways to wrap your head around MPC.
MPC was thought of in [1982 by Andrew Yao](https://research.cs.wisc.edu/areas/sec/yao1982-ocr.pdf) to solve a thought experiment called the "Millionaire's Problem" where two millionaire's want to know who is richer without telling each other how much money they have. The solution was to use [garbled circuits, which according to Vitalik Buterin,](https://vitalik.ca/general/2020/03/21/garbled.html) frequent explainer of cryptographic concepts, is also one of the most basic ways to wrap your head around MPC.
\[Before learning about a garbled circuit, you need to know what a arithmetic circuit is in general. If you’re new to the idea of circuits, there’s a [simple explanation here.](https://mirror.xyz/privacy-scaling-explorations.eth/AW854RXMqS3SU8WCA7Yz-LVnTXCOjpwhmwUq30UNi1Q)\]
\[Before learning about a garbled circuit, you need to know what a arithmetic circuit is in general. If you're new to the idea of circuits, there's a [simple explanation here.](https://mirror.xyz/privacy-scaling-explorations.eth/AW854RXMqS3SU8WCA7Yz-LVnTXCOjpwhmwUq30UNi1Q)\]
MPC is a multi-step, interactive process where millionaire #1 (Alice the Garbler) must first create the circuit, enter her net worth, then transform it into a garbled or encrypted form before passing it along to millionaire #2 (Bob the Evaluator). When Bob gets his hands on the circuit, his job is to add his own net worth, then evaluate or run the circuit to make sure it’s correct. Finally, Bob decrypts the final output and, for example, learns Alice is richer, but never learns that Alice is, in fact, way richer, and he shouldn’t have made assumptions.
MPC is a multi-step, interactive process where millionaire #1 (Alice the Garbler) must first create the circuit, enter her net worth, then transform it into a garbled or encrypted form before passing it along to millionaire #2 (Bob the Evaluator). When Bob gets his hands on the circuit, his job is to add his own net worth, then evaluate or run the circuit to make sure it's correct. Finally, Bob decrypts the final output and, for example, learns Alice is richer, but never learns that Alice is, in fact, way richer, and he shouldn't have made assumptions.
The Millionaire’s Problem and garbled circuits as a solution were crucial to the early development of MPC. But its application was limited. A more complex and nuanced version of the problem, called the [Socialist Millionaire’s Problem](https://en.wikipedia.org/wiki/Socialist_millionaire_problem), checked if the two millionaires were equally rich, instead of revealing which one had more money. This subtle difference significantly extended MPC functionality but required more complex cryptographic solutions and techniques beyond the scope of this article.
The Millionaire's Problem and garbled circuits as a solution were crucial to the early development of MPC. But its application was limited. A more complex and nuanced version of the problem, called the [Socialist Millionaire's Problem](https://en.wikipedia.org/wiki/Socialist_millionaire_problem), checked if the two millionaires were equally rich, instead of revealing which one had more money. This subtle difference significantly extended MPC functionality but required more complex cryptographic solutions and techniques beyond the scope of this article.
## **Fully Homomorphic Encryption (FHE)**
Fully Homomorphic Encryption (FHE) allows computations on encrypted data. It can perform a function on encrypted data just as if it had remained unencrypted. The output of the function is only decrypted by the party with the secret key. If we think of encryption as a black box that hides secrets, then FHE ensures that the data and the computations on that data remain within that black box.
Though there are no famous thought experiments like the Millionaire’s Problem for MPC, FHE does solve a fundamental security weakness: [“the need to decrypt before processing data.”](https://blog.cryptographyengineering.com/2012/01/02/very-casual-introduction-to-fully/)
Though there are no famous thought experiments like the Millionaire's Problem for MPC, FHE does solve a fundamental security weakness: ["the need to decrypt before processing data."](https://blog.cryptographyengineering.com/2012/01/02/very-casual-introduction-to-fully/)
![https://www.zama.ai/post/the-revolution-of-fhe](/articles/beyond-zero-knowledge-whats-next-in-programmable-cryptography/p7FPMhbZ6Hx4lWf-OdWpy.webp)
https://www.zama.ai/post/the-revolution-of-fhe
In an AI context, FHE would keep all the data between the user (secret key holder) and the AI system encrypted. The user interacts with the system as normal, but the user could be confident that the AI never “learned” anything about the data being given. The entire interaction would be encrypted. The AI never learns what you typed or asked, what pictures you sent, or who sent it, but can still respond as if it did know the information.
In an AI context, FHE would keep all the data between the user (secret key holder) and the AI system encrypted. The user interacts with the system as normal, but the user could be confident that the AI never "learned" anything about the data being given. The entire interaction would be encrypted. The AI never learns what you typed or asked, what pictures you sent, or who sent it, but can still respond as if it did know the information.
If it works, FHE will be one of the most powerful privacy-preserving technologies available. And who knows? [In 10 years, we may even have FHE-EVMs](https://youtu.be/ptoKckmRLBw?si=WQDbSStGkqWCx5JM&t=1734).
@@ -79,9 +80,9 @@ If it works, FHE will be one of the most powerful privacy-preserving technologie
Compared to MPC and ZK, FHE is – at the moment – on the more theoretical or less practical end of the spectrum. The technology was only considered to be feasible in [2009 when Craig Gentry](https://www.cs.cmu.edu/~odonnell/hits09/gentry-homomorphic-encryption.pdf) figured out how to deal with noise.
FHE operations are computationally very intensive because “noise” is added during the encryption process to enhance security. Noise in FHE is a small random value added to the plaintext (unencrypted data) before it is turned into ciphertext (encrypted data). Each operation increases noise.  While addition and subtraction operations cause negligible noise growth, multiplication is more computationally expensive, which results in significant noise growth. So as the complexity of a program increases, noise – the space required to accommodate noise and the computational resources needed to process noise – accumulates.
FHE operations are computationally very intensive because "noise" is added during the encryption process to enhance security. Noise in FHE is a small random value added to the plaintext (unencrypted data) before it is turned into ciphertext (encrypted data). Each operation increases noise. While addition and subtraction operations cause negligible noise growth, multiplication is more computationally expensive, which results in significant noise growth. So as the complexity of a program increases, noise – the space required to accommodate noise and the computational resources needed to process noise – accumulates.
Gentry’s breakthrough was a technique called bootstrapping, which could reduce noise and allow for more computation on encrypted data in FHE systems. Bootstrapping takes the ciphertext and decrypts it homomorphically, which means reducing the noise level on an encrypted piece of data without actually revealing what it is. The result is a ciphertext with much lower pre-defined noise, thus allowing us to compute on the ciphertext further. Bootstrapping, in general, allows us to circumvent the need of having higher space for noise growth as complexity of computation increases. We can limit the space to a few operations and repeatedly bootstrap to compute arbitrarily large computations without compromising the original data.
Gentry's breakthrough was a technique called bootstrapping, which could reduce noise and allow for more computation on encrypted data in FHE systems. Bootstrapping takes the ciphertext and decrypts it homomorphically, which means reducing the noise level on an encrypted piece of data without actually revealing what it is. The result is a ciphertext with much lower pre-defined noise, thus allowing us to compute on the ciphertext further. Bootstrapping, in general, allows us to circumvent the need of having higher space for noise growth as complexity of computation increases. We can limit the space to a few operations and repeatedly bootstrap to compute arbitrarily large computations without compromising the original data.
Depending on the FHE scheme, bootstrapping can either take several minutes or milliseconds. If bootstrapping is slower, the computational cost can be spread out by applying it to several ciphertexts at once. If bootstrapping is faster, it usually comes with the trade-off of only working with small pieces of plaintext (usually 8 bits) at a time to stay efficient.
@@ -89,25 +90,25 @@ Depending on the FHE scheme, bootstrapping can either take several minutes or mi
If FHE turns all the elements of the computation into a black box, then iO turns the computation itself into a black box.
Indistinguishability Obfuscation (iO) is considered the most powerful cryptographic system within the realm of theoretic possibility. In [one article](https://www.quantamagazine.org/computer-scientists-achieve-crown-jewel-of-cryptography-20201110/), iO is described as a “master tool from which nearly every other cryptographic protocol could be built” and referred to by cryptography experts as a “crown jewel” and “one cryptographic primitive to rule them all.”
Indistinguishability Obfuscation (iO) is considered the most powerful cryptographic system within the realm of theoretic possibility. In [one article](https://www.quantamagazine.org/computer-scientists-achieve-crown-jewel-of-cryptography-20201110/), iO is described as a "master tool from which nearly every other cryptographic protocol could be built" and referred to by cryptography experts as a "crown jewel" and "one cryptographic primitive to rule them all."
According to Amit Sahai, the professor known for [explaining ZK proofs to kids](https://www.youtube.com/watch?v=fOGdb1CTu5c), and one of the researchers who devised a way [build iO on well-founded assumptions](https://eprint.iacr.org/2020/1003), iO works on a fundamentally different paradigm than previous cryptographic systems. IO assumes the adversary can already read your mind (a metaphor for your computer). Your secrets are already known so can’t be hidden. The only thing you can do is obfuscate what the adversary can already see.
According to Amit Sahai, the professor known for [explaining ZK proofs to kids](https://www.youtube.com/watch?v=fOGdb1CTu5c), and one of the researchers who devised a way [build iO on well-founded assumptions](https://eprint.iacr.org/2020/1003), iO works on a fundamentally different paradigm than previous cryptographic systems. IO assumes the adversary can already read your mind (a metaphor for your computer). Your secrets are already known so can't be hidden. The only thing you can do is obfuscate what the adversary can already see.
![https://youtu.be/v2RR_c5hn1E](/articles/beyond-zero-knowledge-whats-next-in-programmable-cryptography/0JS-dJVwLCjsLtdvd9dOR.webp)
https://youtu.be/v2RR\_c5hn1E
https://youtu.be/v2RR_c5hn1E
The point of iO is to make two functions or computations equally obscure. If you turn two computations into a form that is indistinguishable from each other, then you can hide how the program works. If you can’t tell the difference between two programs, you don’t know which of the two programs is being executed, and no information can be deduced from either one, other than that they both perform the same function. Both programs take the same inputs and produce the same outputs, but iO makes it so no one can figure out how.
The point of iO is to make two functions or computations equally obscure. If you turn two computations into a form that is indistinguishable from each other, then you can hide how the program works. If you can't tell the difference between two programs, you don't know which of the two programs is being executed, and no information can be deduced from either one, other than that they both perform the same function. Both programs take the same inputs and produce the same outputs, but iO makes it so no one can figure out how.
With iO, you can conceal the structure of every type of function including nearly all the functions that make up cryptography. In other words, by obscuring nearly anything, you reach the most general-purpose programmable cryptography on which other primitives can be programmed on top of.
Technically, there is a black box bigger than iO. It’s literally called [black box obfuscation](https://en.wikipedia.org/wiki/Black-box_obfuscation). But that one is still impossible.
Technically, there is a black box bigger than iO. It's literally called [black box obfuscation](https://en.wikipedia.org/wiki/Black-box_obfuscation). But that one is still impossible.
## **Well-founded assumptions**
No one knew how to build iO [until 2013, when multilinear maps were proposed by Garg, Gentry, Halevi, Raykova, Sahai, Waters.](https://eprint.iacr.org/2013/451.pdf) A computer program could be broken up like puzzle pieces then obscured using multilinear maps. The obscured pieces could be reassembled to achieve the same functionality as the original program without revealing its inner workings.
No one knew how to build iO [until 2013, when multilinear maps were proposed by Garg, Gentry, Halevi, Raykova, Sahai, Waters.](https://eprint.iacr.org/2013/451.pdf) A computer program could be broken up like puzzle pieces then obscured using multilinear maps. The obscured pieces could be reassembled to achieve the same functionality as the original program without revealing its inner workings.
Multilinear maps are a generalization of the bilinear maps or pairings used in [Elliptic Curves Cryptography (ECC](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/)). While bilinear maps are foundational to existing cryptographic schemes like [BLS signatures](https://en.wikipedia.org/wiki/BLS_digital_signature), they are not complex or expressive enough for iO. And while multilinear maps could handle iO, this newly developed algebraic structure was easily attackable and wasn’t secure so relying on multilinear maps was generally unsatisfying for cryptographers. The field was stuck again.
Multilinear maps are a generalization of the bilinear maps or pairings used in [Elliptic Curves Cryptography (ECC](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/)). While bilinear maps are foundational to existing cryptographic schemes like [BLS signatures](https://en.wikipedia.org/wiki/BLS_digital_signature), they are not complex or expressive enough for iO. And while multilinear maps could handle iO, this newly developed algebraic structure was easily attackable and wasn't secure so relying on multilinear maps was generally unsatisfying for cryptographers. The field was stuck again.
Then, in 2020, [Jain, Lin, and Sahai proposed](https://eprint.iacr.org/2020/1003) a solution that while unusual and new, was simple enough for cryptographers to reason about, and instead of relying on newly developed assumptions like multilinear maps, this version of iO could be built on more standard and well-founded assumptions that have been studied for decades such as [Learning with Errors (LWE).](https://en.wikipedia.org/wiki/Learning_with_errors) With this latest breakthrough, iO became feasible again. The holy grail was still in reach.
@@ -117,15 +118,15 @@ Each cryptographic system is made of different mathematical assumptions and cryp
![](/articles/beyond-zero-knowledge-whats-next-in-programmable-cryptography/jAMju2X2AJnMDj5mit-AN.webp)
In a presentation on iO, Sahai described the field as being in the “[untamed wilderness](https://youtu.be/v2RR_c5hn1E?t=1317),” where it wasn’t even clear what was not understood and what the right problems to solve were.
In a presentation on iO, Sahai described the field as being in the "[untamed wilderness](https://youtu.be/v2RR_c5hn1E?t=1317),", where it wasn't even clear what was not understood and what the right problems to solve were.
Teams like [PSE](https://www.appliedzkp.org/) primarily work on the practical or applied side of programmable cryptography, focusing on primitives like ZK and MPC with well-founded assumptions that have been battle-tested, relatively optimized, and thought to be secure and effective. Though there are plenty of optimizations left, ZK is now firmly within the realm of practicality. But there was also a time when ZK was confined to the untamed wilderness.
To maximize the number of privacy-preserving, security-guaranteeing, claim-verifying, cryptography-enabled tools the world has access to, we should keep, at least, one eye squinted toward the horizon of what’s to come because no one can predict what will be practical in 10 years.
To maximize the number of privacy-preserving, security-guaranteeing, claim-verifying, cryptography-enabled tools the world has access to, we should keep, at least, one eye squinted toward the horizon of what's to come because no one can predict what will be practical in 10 years.
Sahai’s presentation includes a quote from a [2003 Nature article by Steven Weinberg called Four Golden Lessons](https://www.nature.com/articles/426389a), which highlights another reason to work on the currently impractical.
Sahai's presentation includes a quote from a [2003 Nature article by Steven Weinberg called Four Golden Lessons](https://www.nature.com/articles/426389a), which highlights another reason to work on the currently impractical.
“When I was teaching at the Massachusetts Institute of Technology in the late 1960s, a student told me that he wanted to go into general relativity rather than the area I was working on, elementary particle physics, because the principles of the former were well known, while the latter seemed like a mess to him. It struck me that he had just given a perfectly good reason for doing the opposite… My advice is to go for the messes — that's where the action is.”
"When I was teaching at the Massachusetts Institute of Technology in the late 1960s, a student told me that he wanted to go into general relativity rather than the area I was working on, elementary particle physics, because the principles of the former were well known, while the latter seemed like a mess to him. It struck me that he had just given a perfectly good reason for doing the opposite… My advice is to go for the messes — that's where the action is."
---

9
articles/building-a-zk-proof-of-solvency-for-uniswap-v3-lp-nfts.md Normal file
View File

@@ -0,0 +1,9 @@
---
authors: ["PSE Team"]
title: "Building a ZK Proof of Solvency for Uniswap V3 LP NFTs"
image: null
tldr: ""
date: "2022-08-29"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/YlUuFfEfTB3Ws_nXqe_zg4ak_rPSM0lE2qGdrXPo_Oc"
projects: ["zk-kit"]
---

13
articles/certificate-transparency-using-newtonpir.md
View File

@@ -5,6 +5,7 @@ image: "/articles/certificate-transparency-using-newtonpir/certificate-transpare
tldr: "This post was written by PSE grantee Vishal Kulkarni."
date: "2025-01-28"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/V0PIyv1d_e_WPsAVhBP7zkDvn0XACY63uSvFFxBvjrk"
projects: ["pse-security"]
---
## Introduction
@@ -45,12 +46,12 @@ Signed Certificate Timestamp (SCT) is a cryptographic proof that a digital certi
### 1\. Opt-Out Auditing (Current Chrome Approach)
Rather than client directly interacting with the CT log server Google’s solution involves an SCT auditor which maintains a global set of all valid SCTs for active certificates. Allows clients to check if an SCT is valid without directly revealing which SCT they are verifying.
Rather than client directly interacting with the CT log server Google's solution involves an SCT auditor which maintains a global set of all valid SCTs for active certificates. Allows clients to check if an SCT is valid without directly revealing which SCT they are verifying.
#### How it Works
- Client calculates the hash of the SCT
- Clients reveal the first 20 bits of an SCT’s hash to the auditor.
- Clients reveal the first 20 bits of an SCT's hash to the auditor.
- The auditor provides all matching SCTs (around 1000), achieving k-anonymity (with k=1000).
- Drawback: Partial SCT hash leakage can still compromise privacy.
@@ -123,7 +124,7 @@ The querying process includes the following steps:
- Step 3: Client Decryption
- The client decrypts the server’s response using their secret key to retrieve the certificate at the requested index.
- The client decrypts the server's response using their secret key to retrieve the certificate at the requested index.
### Steps for Integrating NewtonPIR into CT
@@ -149,7 +150,7 @@ The querying process includes the following steps:
- Client Validation:
- The client decrypts the response to retrieve the certificate.
- Optionally, verify the certificate’s SCT and ensure its correctness.
- Optionally, verify the certificate's SCT and ensure its correctness.
## Technical Architecture of PIR-CT
@@ -227,6 +228,6 @@ In this example, I used a simple method with a hashmap, but checking the SCT of
## Conclusion
So, does this enable fully private web search? Not entirely. While it prevents the client’s browser history from being visible to the CT server, the source server can still identify who is accessing the page, and attackers can use metadata or [fingerprinting](https://www.recordedfuture.com/threat-intelligence-101/vulnerability-management-threat-hunting/fingerprinting-in-cybersecurity) to determine the user’s identity.
So, does this enable fully private web search? Not entirely. While it prevents the client's browser history from being visible to the CT server, the source server can still identify who is accessing the page, and attackers can use metadata or [fingerprinting](https://www.recordedfuture.com/threat-intelligence-101/vulnerability-management-threat-hunting/fingerprinting-in-cybersecurity) to determine the user's identity.
This blog provides only a basic overview of how PIR can be applied to CT to address a privacy concern. There may be other PIR schemes that could perform better in this context. I’d love to hear your feedback and suggestions for improvement! Join the conversation [here](https://forum.pse.dev/post/1/21).
This blog provides only a basic overview of how PIR can be applied to CT to address a privacy concern. There may be other PIR schemes that could perform better in this context. I'd love to hear your feedback and suggestions for improvement! Join the conversation [here](https://forum.pse.dev/post/1/21).

1
articles/circom-mpc-tldr-and-retrospective.md
View File

@@ -5,6 +5,7 @@ image: "/articles/circom-mpc-tldr-and-retrospective/circom-mpc-tldr-and-retrospe
tldr: "This post was authored by the Circom MPC research team."
date: "2025-03-06"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/qelA6kAr-CMq-dgmvFUKMMqxf6GoDaP8Cs-5sRWYfO4"
projects: ["circom-mpc"]
---
Circom-MPC is a PSE Research project that enables the use of the Circom language to develop MPC applications. In this project, we envisioned MPC as a [broader paradigm](https://mirror.xyz/privacy-scaling-explorations.eth/qelA6kAr-CMq-dgmvFUKMMqxf6GoDaP8Cs-5sRWYfO4#MPC-as-a-Paradigm), where MPC serves as an umbrella for generic techniques such as Zero-Knowledge Proof, Garbled Circuit, Secret-Sharing, or Fully Homomorphic Encryption.

5
articles/code-optimizations-in-the-landscape-of-post-quantum-cryptography.md
View File

@@ -5,6 +5,7 @@ image: "/articles/code-optimizations-in-the-landscape-of-post-quantum-cryptograp
tldr: "This post was written by PSE researcher Miha Stopar."
date: "2025-04-07"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/BKI3tyauHIiUCYHgma-EHeSRXNTNDtLUQV9VNGQWLUg"
projects: ["post-quantum-cryptography"]
---
There's no doubt that lattice-based cryptography is currently the most promising branch of post-quantum cryptography. Not only is it highly performant and versatile, it also provides the only known technique to achieve fully homomorphic encryption.
@@ -46,7 +47,7 @@ At the core of lattice-based cryptography lies matrix-vector multiplication. For
Matrix multiplication illustration
For performance reasons, lattice-based cryptography relies on polynomial rings rather than ordinary vectors. I won’t go into the details, but let’s consider the following example.
For performance reasons, lattice-based cryptography relies on polynomial rings rather than ordinary vectors. I won't go into the details, but let's consider the following example.
![](/articles/code-optimizations-in-the-landscape-of-post-quantum-cryptography/VEbeKabiB_GT6usoOzVSu.webp)
@@ -122,7 +123,7 @@ Let's have a look at some optimizations used in elliptic curve cryptography:
- Montgomery Reduction: efficiently computes modular reductions without expensive division operations,
- Montgomery Inversion: avoids divisions entirely when used with Montgomery multiplication,
- Using Montgomery or Edwards curves: enables efficient arithmetic,
- Shamir’s Trick: computes $kP+mQ$ simultaneously, reducing the number of operations.
- Shamir's Trick: computes $kP+mQ$ simultaneously, reducing the number of operations.
It is worth noting that some of these optimizations—such as Montgomery reduction and Montgomery multiplication—also apply to lattice-based cryptography.

17
articles/introducing-trinity.md
View File

@@ -5,9 +5,10 @@ image: "/articles/introducing-trinity/trinity.webp"
tldr: "Two-Party Computation for the ZK Era"
date: "2025-04-28"
tags: ["zk", "mpc"]
projects: ["mpz", "mpc-framework", "pse-halo2"]
---
# Introducing Trinity: Two-Party Computation for the ZK Era
### Introducing Trinity: Two-Party Computation for the ZK Era
Trinity is a two-party computation (2PC) protocol designed to minimize interaction rounds, enable input verifiability, and facilitate reusability. It combines three key cryptographic concepts: Extractable Witness Encryption for Laconic Oblivious Transfer (LOT), Garbled Circuits, and PLONK.
@@ -17,13 +18,13 @@ The core mechanism unifying these concepts is the KZG polynomial commitment sche
Trinity redefines the role of ZK credentials, extending their use beyond traditional settings (e.g., authentication) to serve as verified private inputs within secure two-party computations (2PC).
We’ve just added it as a new template in [mpc-hello](https://github.com/voltrevo/mpc-hello/tree/main/trinity), and it’s time to show what it brings to the table.
We've just added it as a new template in [mpc-hello](https://github.com/voltrevo/mpc-hello/tree/main/trinity), and it's time to show what it brings to the table.
To understand Trinity’s novelty, let’s first revisit how traditional secure two-party computation (2PC) works.
To understand Trinity's novelty, let's first revisit how traditional secure two-party computation (2PC) works.
### 🧠 A Classic 2PC Flow
Let’s start with a traditional secure two-party computation (2PC). Say Alice and Bob want to compute `a + b`, without revealing their private inputs `a` and `b` to each other.
Let's start with a traditional secure two-party computation (2PC). Say Alice and Bob want to compute `a + b`, without revealing their private inputs `a` and `b` to each other.
This is typically done using:
@@ -35,9 +36,9 @@ This is typically done using:
In most traditional protocols, OT is built using **public key cryptography**.
Let’s say Alice has an input bit `a ∈ {0,1}`:
Let's say Alice has an input bit `a ∈ {0,1}`:
- Bob (the garbler) prepares two labels for Alice’s input wire: one for 0 and one for 1.
- Bob (the garbler) prepares two labels for Alice's input wire: one for 0 and one for 1.
- Alice runs an OT protocol to retrieve only the label that corresponds to her bit, without revealing it.
- This typically involves public key operations where Bob encrypts both labels, and Alice can only decrypt one.
@@ -57,7 +58,7 @@ Specifically, Trinity leverages:
In short, Trinity lets you garble circuits in the usual way, but with reusable, verifiable inputs — perfect for privacy-preserving apps, on-chain protocols, or even MPC-enabled credentials.
Now let’s see how to build with it.
Now let's see how to build with it.
### Setup
@@ -188,7 +189,7 @@ const resultBytes = currentEvaluator.evaluate(
const result = booleanArrayToInteger(resultBytes)
```
### 🚀 What’s Next?
### 🚀 What's Next?
This is a minimal example — but Trinity supports:

2
articles/reflecting-on-maci-platform.md
View File

@@ -16,8 +16,6 @@ tags:
]
---
# Reflecting on MACI Platform: What We Built, Learned, and What’s Next
Over the past year, we’ve been on a journey to explore how [MACI](https://github.com/privacy-scaling-explorations/maci) could power more democratic, privacy-preserving voting in real-world funding scenarios. The MACI Platform was our experiment in bringing those ideals into practice. Today, we’re sharing what we built, what we learned, and why we’ve decided to sunset the project—along with some parting thoughts on where the opportunity still lies.
---

15
articles/retrospective-trusted-setups-and-p0tion-project.md
View File

@@ -5,23 +5,24 @@ image: "/articles/retrospective-trusted-setups-and-p0tion-project/retrospective-
tldr: "This post was written by the PSE Trusted Setup Team."
date: "2025-01-15"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/Cf9nYvSlATGks8IcFaHQe3H5mgZ_Va767Zk5I8jPYXk"
projects: ["p0tion", "powers-of-tau", "trusted-setups"]
---
## Chronological look back
### **Early Stages and Foundation**
PSE’s Trusted Setups team began two years ago with a focus on understanding and implementing trusted setup ceremonies, which are crucial in generating secure cryptographic keys for production-ready zkSNARKs circuits. The team was formed to continue work on ongoing projects as well as starting to work on new initiatives.
PSE's Trusted Setups team began two years ago with a focus on understanding and implementing trusted setup ceremonies, which are crucial in generating secure cryptographic keys for production-ready zkSNARKs circuits. The team was formed to continue work on ongoing projects as well as starting to work on new initiatives.
In a trusted setup ceremony, multiple participants collaborate to compute the cryptographic parameters for the circuit, each contributing their own entropy - some [secret](https://www.youtube.com/watch?v=I4cDAqeEmpU), [randomly](https://web.archive.org/web/20230501054531/https:/proofof.cat/) [generated](https://web.archive.org/web/20230504180930/https:/hackmd.io/axUX8pFUQD-yCiBzQEDrYQ?view) [value](https://www.vice.com/en/article/power-tau-zcash-radioactive-toxic-waste/) - that is [destroyed](https://x.com/saint_rat/status/1647601259724275713) after the computation is complete. As long as at least one participant runs the computation securely and properly disposes of their “toxic waste”, the setup is secure.
In a trusted setup ceremony, multiple participants collaborate to compute the cryptographic parameters for the circuit, each contributing their own entropy - some [secret](https://www.youtube.com/watch?v=I4cDAqeEmpU), [randomly](https://web.archive.org/web/20230501054531/https:/proofof.cat/) [generated](https://web.archive.org/web/20230504180930/https:/hackmd.io/axUX8pFUQD-yCiBzQEDrYQ?view) [value](https://www.vice.com/en/article/power-tau-zcash-radioactive-toxic-waste/) - that is [destroyed](https://x.com/saint_rat/status/1647601259724275713) after the computation is complete. As long as at least one participant runs the computation securely and properly disposes of their "toxic waste", the setup is secure.
Historically, trusted setups have been difficult and time-consuming, requiring teams to implement infrastructure and coordinate participation for each new zkSNARK, often across two separate phases. The time, resources and technical expertise required to run a trusted setup ceremony placed a big burden on teams working on zero knowledge protocols - [this podcast](https://radiolab.org/podcast/ceremony) famously documents the elaborate precautions taken to secure Zcash’s 2016 trusted setup ceremony.
Historically, trusted setups have been difficult and time-consuming, requiring teams to implement infrastructure and coordinate participation for each new zkSNARK, often across two separate phases. The time, resources and technical expertise required to run a trusted setup ceremony placed a big burden on teams working on zero knowledge protocols - [this podcast](https://radiolab.org/podcast/ceremony) famously documents the elaborate precautions taken to secure Zcash's 2016 trusted setup ceremony.
Our team identified a need for accessible and replicable tools that would help teams run trusted setups with less overhead. We quickly developed expertise in this niche but critical area, laying the groundwork for innovative tools to make trusted setups easier and more efficient.
### **Perpetual Powers of Tau**
In a two-phase trusted setup, the second phase is circuit-specific; but the first phase can be used by any number of projects as long as they trust that it’s secure. Our team took on the challenge of implementing a Phase 1 ceremony that could be trusted by anyone who might want to build on it. Since a setup is secure as long as any one participant has behaved honestly, that meant creating a ceremony that could stay open indefinitely and accept any number of contributions. This way, anyone who wanted to build on the setup but wasn’t confident in its integrity could ensure it was secure for their project by simply making their own contribution.
In a two-phase trusted setup, the second phase is circuit-specific; but the first phase can be used by any number of projects as long as they trust that it's secure. Our team took on the challenge of implementing a Phase 1 ceremony that could be trusted by anyone who might want to build on it. Since a setup is secure as long as any one participant has behaved honestly, that meant creating a ceremony that could stay open indefinitely and accept any number of contributions. This way, anyone who wanted to build on the setup but wasn't confident in its integrity could ensure it was secure for their project by simply making their own contribution.
The result was the [Perpetual Powers of Tau ceremony](https://github.com/privacy-scaling-explorations/perpetualpowersoftau), focusing on producing phase-1 files crucial for all zkSNARKs. This ongoing ceremony has been running since 2019, with 85 contributors to date. Contributing to PPoT involves managing complex 100GB files, which requires contributors to have enough technical knowledge to spin up a server large enough to compute the contribution. It also requires the contributor to know how to install the right tools, download the files and upload the files after they finished their contribution.
@@ -35,7 +36,7 @@ Since Perpetual Powers of Tau began, the team has successfully coordinated, prep
A pivotal moment for the project was the implementation of the [KZG Ceremony](https://blog.ethereum.org/2024/01/23/kzg-wrap), essential for [EIP 4844](https://eips.ethereum.org/EIPS/eip-4844) (Proto-Danksharding). This Ethereum core upgrade aimed to reduce gas prices by creating a separate market for data storage, benefiting layer 2 protocols.
We developed a [user-friendly web application](https://ceremony.ethereum.org/) to invite broad community participation, with a user-friendly process that guided contributors through the ceremony step by step, automating and abstracting away the complex operations of computation and toxic waste disposal. PSE’s design team created a beautiful user interface that made participating in the ceremony feel more like a sacred ritual than collective math.
We developed a [user-friendly web application](https://ceremony.ethereum.org/) to invite broad community participation, with a user-friendly process that guided contributors through the ceremony step by step, automating and abstracting away the complex operations of computation and toxic waste disposal. PSE's design team created a beautiful user interface that made participating in the ceremony feel more like a sacred ritual than collective math.
![ceremony.ethereum.org landing page at the time the ceremony was active](/articles/retrospective-trusted-setups-and-p0tion-project/01yqkaXXNPa8RfDHylN4M.webp)
@@ -92,7 +93,7 @@ The team worked on different projects and solutions. Each one of them presented
Overall we learned the importance of a clear and structured roadmap and project management process. We also learned that it's far more efficient and beneficial to get early feedback on a work-in-progress rather than waiting to present a finished but potentially misguided solution.
**Besides the previous recommendation of implementing a structured project management approach, we recommend encouraging a culture of early code review, even on incomplete work: a discussion on a “half-baked” code is better than no discussion that leads to the development of an off-target solution.**
**Besides the previous recommendation of implementing a structured project management approach, we recommend encouraging a culture of early code review, even on incomplete work: a discussion on a "half-baked" code is better than no discussion that leads to the development of an off-target solution.**
### Technical Considerations
@@ -118,7 +119,7 @@ As we conclude active development, these trusted setup projects are entering a L
- [KZG ceremony](https://github.com/zkparty/trusted-setup-frontend)
- No further development planned
- Website [www.ceremony.ethereum.org](http://www.ceremony.ethereum.org/) will stay up and running for users to check the contributors’ list and the final transcript
- Website [www.ceremony.ethereum.org](http://www.ceremony.ethereum.org/) will stay up and running for users to check the contributors' list and the final transcript
- Codebase will remain public, but developers are generally recommended to use p0tion as a more general tool for all ceremonies
- [p0tion](https://github.com/privacy-scaling-explorations/p0tion)

43
articles/rsa-verification-circuit-in-halo2-and-its-applications.md
View File

@@ -5,6 +5,7 @@ image: null
tldr: "This post was authored by grantee **Sora Suegami** ([Twitter](https://twitter.com/SoraSue77), [Github](https://github.com/SoraSuegami))"
date: "2022-11-14"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/mmkG4uB2PR_peGucULAa7zHag-jz1Y5biZH8W6K2LYM"
projects: ["pse-halo2", "zk-email"]
---
## Introduction
@@ -60,9 +61,9 @@ Notably, if _**e**_ is fixed in the circuit, we can reduce the number of the mod
As an application of the RSA verification circuit, we are considering ZK-Mail, a smart contract that performs email verification using ZKP. Today, digital signatures, especially RSA signatures, are widely used in email protocols such as S/MIME and DKIM to authenticate email senders. Our main idea is that a smart contract can authenticate those emails by verifying the RSA signatures with ZKP. If they pass the authentication, the smart contract can interpret their contents as oracle data provided by the email senders.
The smart contract described above is also useful as a contract wallet. Instead of using the wallet application to make a transaction, the user sends an email to the operator of the contract wallet specifying the transfer amount and the destination in its email message. The operator generates a ZK proof indicating that the received email has been authorized, submitting it to the smart contract. The smart contract verifies the proof and transfers the user’s assets according to the contents of the email. It allows users to manage their assets on Ethereum without modifying current email systems or installing new tools.
The smart contract described above is also useful as a contract wallet. Instead of using the wallet application to make a transaction, the user sends an email to the operator of the contract wallet specifying the transfer amount and the destination in its email message. The operator generates a ZK proof indicating that the received email has been authorized, submitting it to the smart contract. The smart contract verifies the proof and transfers the user's assets according to the contents of the email. It allows users to manage their assets on Ethereum without modifying current email systems or installing new tools.
If the user is different from the administrator of the sending email server, the security of the user’s assets depends on trust in the administrator because the administrator can steal them by forging the user’s emails. However, trust in the operator is not necessary. This is because even if the operator modifies the contents of the received emails, the operator cannot forge the signature corresponding to the email sender. In summary, this is a custodial wallet whose security is guaranteed under trust in the email server administrator, allowing users to manage their assets by simply sending emails using their existing email services.
If the user is different from the administrator of the sending email server, the security of the user's assets depends on trust in the administrator because the administrator can steal them by forging the user's emails. However, trust in the operator is not necessary. This is because even if the operator modifies the contents of the received emails, the operator cannot forge the signature corresponding to the email sender. In summary, this is a custodial wallet whose security is guaranteed under trust in the email server administrator, allowing users to manage their assets by simply sending emails using their existing email services.
In the following, we present two situations where the ZK-Mail can be used.
@@ -71,25 +72,25 @@ In the following, we present two situations where the ZK-Mail can be used.
#### Players and situations
- Alice delivers the latest cryptocurrency prices via email. She attaches her RSA signature to the email following the DKIM protocol.
- Bob subscribes to Alice’s emails and provides them for some DeFi contracts as price oracle data.
- Bob subscribes to Alice's emails and provides them for some DeFi contracts as price oracle data.
#### Assumptions
- A public key corresponding to Alice’s domain name (e.g. [alice.com](http://alice.com/)) is published in DNS and not changed.
- Alice’s public key and email address are registered in the ZK-Mail contract in advance.
- A public key corresponding to Alice's domain name (e.g. [alice.com](http://alice.com/)) is published in DNS and not changed.
- Alice's public key and email address are registered in the ZK-Mail contract in advance.
#### Procedures
1. Bob receives Alice’s latest email.
1. Bob receives Alice's latest email.
2. Bob extracts the cryptocurrency name and price data from the contents of the email.
3. Taking Alice’s RSA signature and the header/contents of the email as private inputs (witnesses), and her public key, her email address, and the cryptocurrency name and price data as public inputs (statements), Bob generates a ZKP proof confirming the following conditions.
3. Taking Alice's RSA signature and the header/contents of the email as private inputs (witnesses), and her public key, her email address, and the cryptocurrency name and price data as public inputs (statements), Bob generates a ZKP proof confirming the following conditions.
- The RSA signature is valid for the header/contents and the public key.
- The From field in the header is equivalent to the provided email address, i.e., Alice’s email address.
- The From field in the header is equivalent to the provided email address, i.e., Alice's email address.
- The contents include the cryptocurrency name and price data.
4. Bob provides the price oracle contract with the cryptocurrency name and price data and the ZKP proof.
5. The contract calls the ZK-Mail contract with the provided data. It verifies the ZKP proof using Alice’s public key and email address registered in advance.
5. The contract calls the ZK-Mail contract with the provided data. It verifies the ZKP proof using Alice's public key and email address registered in advance.
6. If the proof passes the verification, the price oracle contract accepts the provided name and price data.
![](/articles/rsa-verification-circuit-in-halo2-and-its-applications/9Y4bJxpPnxxhdegr0P6LF.webp)
@@ -98,31 +99,31 @@ In the following, we present two situations where the ZK-Mail can be used.
#### Players and situations
- Alice operates an email service. She attaches her RSA signature to her users’ emails following the DKIM protocol. Her domain name is [alice.com](http://alice.com/).
- Bob is a user of Alice’s email service. His email address is [bob@alice.com](http://mailto:bob@alice.com/).
- Alice operates an email service. She attaches her RSA signature to her users' emails following the DKIM protocol. Her domain name is [alice.com](http://alice.com/).
- Bob is a user of Alice's email service. His email address is [bob@alice.com](http://mailto:bob@alice.com/).
- Carol operates a contract wallet service. Her email address is [carol@wallet.com](http://mailto:carol@wallet.com/).
#### Assumptions
- A public key corresponding to Alice’s domain name (e.g. [alice.com](http://alice.com/)) is published in DNS and does not change.
- Alice’s public key is registered in the ZK-Mail contract in advance.
- Bob already registered Carol’s wallet service. His email address is registered in the ZK-Mail contract, and he has 2 ETH in his wallet.
- A public key corresponding to Alice's domain name (e.g. [alice.com](http://alice.com/)) is published in DNS and does not change.
- Alice's public key is registered in the ZK-Mail contract in advance.
- Bob already registered Carol's wallet service. His email address is registered in the ZK-Mail contract, and he has 2 ETH in his wallet.
- **Alice never attaches her RSA signature to forged emails.**
#### Procedures
1. Bob wants to transfer 1 ETH to his friend whose email address is [friend@alice.com](http://mailto:friend@alice.com/).
2. Bob sends an email to [carol@wallet.com](http://mailto:carol@wallet.com/). Its message is “Transfer 1 ETH to [friend@alice.com](http://mailto:friend@alice.com/)”.
3. Alice attaches her RSA signature to the Bob’s email.
2. Bob sends an email to [carol@wallet.com](http://mailto:carol@wallet.com/). Its message is "Transfer 1 ETH to [friend@alice.com](http://mailto:friend@alice.com/)".
3. Alice attaches her RSA signature to the Bob's email.
4. Carol receives the email from Bob. She extracts the transfer amount and the destination (1 ETH and [friend@alice.com](http://mailto:friend@alice.com/) in this case) from the contents of the email.
5. Taking Alice’s RSA signature and the header/contents of the email as private inputs (witnesses), and her public key, sender’s email address, and the transfer amount and the destination as public inputs (statements), Carol generates a ZKP proof confirming the following conditions.
5. Taking Alice's RSA signature and the header/contents of the email as private inputs (witnesses), and her public key, sender's email address, and the transfer amount and the destination as public inputs (statements), Carol generates a ZKP proof confirming the following conditions.
- The RSA signature is valid for the header/contents and the public key.
- The From field in the header is equivalent to the provided email address, i.e., [bob@alice.com](http://mailto:bob@alice.com/).
- The message in the contents is in the form of “Transfer (transfer amount) to (destination)”.
- The message in the contents is in the form of "Transfer (transfer amount) to (destination)".
6. Carol provides her service’s contract with transaction data including the transfer amount and the destination and the ZKP proof.
7. The contract calls the ZK-Mail contract with the provided data. It verifies the ZKP proof using Alice’s public key and Bob’s email address registered in advance.
8. If the proof passes the verification, the contract wallet transfers Bob’s 1 ETH to the wallet corresponding to the email address of [friend@alice.com](http://mailto:friend@alice.com/). (In detail, the contract wallet has storage where the hash of the email address is mapped to the ETH balance. It decreases 1 from the balance of Hash([bob@alice.com](http://mailto:bob@alice.com/)) and increases that of Hash([friend@alice.com](http://mailto:friend@alice.com/)) by the same amount.)
6. Carol provides her service's contract with transaction data including the transfer amount and the destination and the ZKP proof.
7. The contract calls the ZK-Mail contract with the provided data. It verifies the ZKP proof using Alice's public key and Bob's email address registered in advance.
8. If the proof passes the verification, the contract wallet transfers Bob's 1 ETH to the wallet corresponding to the email address of [friend@alice.com](http://mailto:friend@alice.com/). (In detail, the contract wallet has storage where the hash of the email address is mapped to the ETH balance. It decreases 1 from the balance of Hash([bob@alice.com](http://mailto:bob@alice.com/)) and increases that of Hash([friend@alice.com](http://mailto:friend@alice.com/)) by the same amount.)
![](/articles/rsa-verification-circuit-in-halo2-and-its-applications/wqZkchwlp5eKjrHxEQDMp.webp)

28
articles/secure-multi-party-computation.md
View File

@@ -5,6 +5,7 @@ image: "/articles/secure-multi-party-computation/secure-multi-party-computation-
tldr: "This post was written by [Brechy](https://github.com/brech1). Thanks [Nam Ngo](https://github.com/namnc) for the feedback and review!"
date: "2024-08-06"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/v_KNOV_NwQwKV0tb81uBS4m-rbs-qJGvCx7WvwP4sDg"
projects: ["mpz", "tlsn", "mpc-framework"]
---
Secure multi-party computation (MPC) enables a group of participants to collaborate on a specific task that requires their data as input, ensuring the privacy of their inputs and the correctness of the output.
@@ -36,7 +37,7 @@ Specialized protocols are designed and optimized for a specific functionality. T
### Generic Protocols
Generic protocols can compute any function that can be represented as a fixed-size circuit. Yao’s Garbled Circuits protocol is an example of a generic protocol. They can be applied to a wide range of problems.
Generic protocols can compute any function that can be represented as a fixed-size circuit. Yao's Garbled Circuits protocol is an example of a generic protocol. They can be applied to a wide range of problems.
## Secure Protocol Requirements
@@ -64,7 +65,7 @@ Let's explore some real world use cases.
### Privacy Preserving Machine Learning
It's possible to enhance privacy during the machine learning training and inference phases. During training, multiple parties can collaboratively train a model without disclosing their individual datasets. For inference, it can ensure that both the client's input data and the server's model remain confidential. This allows clients to receive model outputs without exposing their data and ensures that the provider’s model remains private.
It's possible to enhance privacy during the machine learning training and inference phases. During training, multiple parties can collaboratively train a model without disclosing their individual datasets. For inference, it can ensure that both the client's input data and the server's model remain confidential. This allows clients to receive model outputs without exposing their data and ensures that the provider's model remains private.
### Threshold Cryptography
@@ -102,9 +103,9 @@ template matrixElementMul (m,n) {
signal input b[m][n];
signal output out[m][n];
for (var i=0; i &lt; m; i++) {
for (var j=0; j &lt; n; j++) {
out[i][j] &lt;== a[i][j] * b[i][j];
for (var i=0; i < m; i++) {
for (var j=0; j < n; j++) {
out[i][j] <== a[i][j] * b[i][j];
}
}
}
@@ -131,7 +132,7 @@ For this example, it might have been quicker to manually construct the gates. Ho
## Oblivious Transfer
Oblivious transfer (OT) is a cryptographic two-party protocol. It allows the receiving party to [obliviously](https://www.oxfordlearnersdictionaries.com/definition/english/obliviously) select one of the sending party’s inputs . The protocol’s privacy guarantees ensure that the sender does not learn the choice of the receiver and the receiver does not learn the non selected inputs.
Oblivious transfer (OT) is a cryptographic two-party protocol. It allows the receiving party to [obliviously](https://www.oxfordlearnersdictionaries.com/definition/english/obliviously) select one of the sending party's inputs . The protocol's privacy guarantees ensure that the sender does not learn the choice of the receiver and the receiver does not learn the non selected inputs.
Let's review a basic example, the **1-out-of-2 oblivious transfer**. In this protocol, the sender has two messages, 𝑚 0 and 𝑚 1 . The receiver wants to learn one of these messages, 𝑚 𝑏 , without the sender knowing which message was chosen.
@@ -195,13 +196,13 @@ Once the evaluator receives the garbled gate, it needs to decrypt exactly one ci
In order to do this, it needs to receive from the garbler $W_{a}^A$ and $W_{b}^B$.
Since the garbler knows 𝑎 , he can send the evaluator $W_{a}^A$. The labels are all random, independent, and identically distributed, so the evaluator won’t learn anything about 𝑎 from $W_{a}^A$
Since the garbler knows 𝑎 , he can send the evaluator $W_{a}^A$. The labels are all random, independent, and identically distributed, so the evaluator won't learn anything about 𝑎 from $W_{a}^A$
However, getting $W_{b}^B$ to the evaluator is harder. The garbler can’t send both $W_{0}^B$ and $W_{1}^B$ to the evaluator because that will allow them to decrypt two ciphertexts in the garbled gate. Similarly, the evaluator can’t simply ask for the one they want because they don’t want the garbler to learn 𝑏 .
However, getting $W_{b}^B$ to the evaluator is harder. The garbler can't send both $W_{0}^B$ and $W_{1}^B$ to the evaluator because that will allow them to decrypt two ciphertexts in the garbled gate. Similarly, the evaluator can't simply ask for the one they want because they don't want the garbler to learn 𝑏 .
So, the garbler and the evaluator use Oblivious Transfer, which allows the evaluator to learn only $W_{b}^B$ without revealing 𝑏 to the garbler.
Note that in order for this to work, the evaluator needs to know when decryption succeeds and when it doesn’t. Otherwise, there’s no way for them to know which ciphertext yields the correct answer.
Note that in order for this to work, the evaluator needs to know when decryption succeeds and when it doesn't. Otherwise, there's no way for them to know which ciphertext yields the correct answer.
### Example Walkthrough
@@ -336,7 +337,7 @@ Therefore, while real-time applications of MPC currently seem unfeasible, use ca
MPC can be integrated with zero-knowledge proofs and fully homomorphic encryption to enhance security and functionality. Consider exploring the following resources on the [PSE Blog](https://mirror.xyz/privacy-scaling-explorations.eth/):
- [Zero to Start: Applied Fully Homomorphic Encryption](https://mirror.xyz/privacy-scaling-explorations.eth/D8UHFW1t48x2liWb5wuP6LDdCRbgUH_8vOFvA0tNDJA)
- [Beyond Zero-Knowledge: What’s Next in Programmable Cryptography?](https://mirror.xyz/privacy-scaling-explorations.eth/xXcRj5QfvA_qhkiZCVg46Gn9uX8P_Ld-DXlqY51roPY)
- [Beyond Zero-Knowledge: What's Next in Programmable Cryptography?](https://mirror.xyz/privacy-scaling-explorations.eth/xXcRj5QfvA_qhkiZCVg46Gn9uX8P_Ld-DXlqY51roPY)
## Conclusion
@@ -347,9 +348,8 @@ Secure multi-party computation is a powerful cryptographic tool that allows mult
These are some MPC projects we're building at [PSE](https://pse.dev/):
- [mpz](https://github.com/privacy-scaling-explorations/mpz): Collection of multi-party computation libraries written in Rust :crab:.
- [tls-notary](https://github.com/tlsnotary/tlsn): Data provenance and privacy with secure multi-party computation.
- [circom-2-arithc](https://github.com/namnc/circom-2-arithc): Circom to Arithmetic Circuit compiler.
- [circom-2-arithc-ts](https://github.com/voltrevo/circom-2-arithc-ts): Circom to Arithmetic Circuit compiler TypeScript library.
- [tlsn](https://github.com/tlsnotary/tlsn): Data provenance and privacy with secure multi-party computation.
- [mpc-framework](https://github.com/voltrevo/circom-2-arithc-ts): Circom to Arithmetic Circuit compiler TypeScript library.
And this is a great list of software libraries and frameworks to start building:
@@ -364,4 +364,4 @@ And this is a great list of software libraries and frameworks to start building:
5. Ishai Yuval, Prabhakaran Manoj, and Sahai Amit. "Founding Cryptography on Oblivious Transfer – Efficiently." [PDF](https://iacr.org/archive/crypto2008/51570574/51570574.pdf), 2008.
6. Lindell Yehuda. "Secure Multiparty Computation (MPC)." [PDF](https://eprint.iacr.org/2020/300.pdf), 2020.
7. Mann Zoltán Ádám, Weinert Christian, Chabal Daphnee, and Bos Joppe W. "Towards Practical Secure Neural Network Inference: The Journey So Far and the Road Ahead." [PDF](https://eprint.iacr.org/2022/1483.pdf), 2022.
8. Yakoubov Sophia. "A Gentle Introduction to Yao’s Garbled Circuits." [PDF](https://web.mit.edu/sonka89/www/papers/2017ygc.pdf), 2017.
8. Yakoubov Sophia. "A Gentle Introduction to Yao's Garbled Circuits." [PDF](https://web.mit.edu/sonka89/www/papers/2017ygc.pdf), 2017.

1
articles/tlsnotary-updates.md
View File

@@ -5,6 +5,7 @@ image: "/articles/tlsnotary-updates/tlsnotary-updates-cover.webp"
tldr: "This post was written by [sinu](https://github.com/sinui0)."
date: "2023-09-19"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/T4MR2PgBzBmN2I3dhDJpILXkQsqZp1Bp8GSm_Oo3Vnw"
projects: ["tlsn"]
---
## Introduction

29
articles/unirep-protocol.md
View File

@@ -5,23 +5,24 @@ image: "/articles/unirep-protocol/cover.webp"
tldr: ""
date: "2023-01-04"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/FCVVfy-TQ6R7_wavKj1lCr5dd1zqRvwjnDOYRM5NtsE"
projects: ["unirep", "semaphore"]
---
Anonymity gives people a clean slate to express themselves, unconnected to an existing identity. Reputation provides context: it reveals an aspect about a person’s history in relation to others. [UniRep protocol](https://github.com/unirep) adds reputation to anonymity, allowing people to provide relational context without revealing specifics of their history.
Anonymity gives people a clean slate to express themselves, unconnected to an existing identity. Reputation provides context: it reveals an aspect about a person's history in relation to others. [UniRep protocol](https://github.com/unirep) adds reputation to anonymity, allowing people to provide relational context without revealing specifics of their history.
UniRep stands for [Universal Reputation](https://mirror.xyz/privacy-scaling-explorations.eth/S04tvQuLbRjf_9ZrzDTE0T2aho9_GoSuok5NEFyHNO4) and serves as a base layer for applying reputation across multiple communities using interoperable smart contracts while preserving user privacy through [zero-knowledge proofs](https://ethereum.org/en/zero-knowledge-proofs/).
## Universal reputation
Reputation is relational: it is built on claims about a person’s behavior or character. It’s also subjective and context-dependent. It can take a qualitative form such as a reference letter from an acquaintance or an Airbnb review, or it can be an upvote or downvote on Reddit, or a positive or negative integer in a database. Many of the apps and services we depend on wouldn’t work without reputation acting as a reference for deciding whether and how to interact with strangers on the internet.
Reputation is relational: it is built on claims about a person's behavior or character. It's also subjective and context-dependent. It can take a qualitative form such as a reference letter from an acquaintance or an Airbnb review, or it can be an upvote or downvote on Reddit, or a positive or negative integer in a database. Many of the apps and services we depend on wouldn't work without reputation acting as a reference for deciding whether and how to interact with strangers on the internet.
UniRep protocol is a standard on which different reputational rules can interoperate. It doesn’t dictate how reputation is used in a given application, but instead functions as a generic and [extensible](https://www.youtube.com/watch?v=jd2Dg9czJzI&list=PLV91V4b0yVqRQ62Mv0nUgWxJhi4E67XSY&index=5) system where platforms such as AirBNB, Uber, Reddit, Medium, Trip Advisor, or Trust Pilot would be [attesters](https://developer.unirep.io/docs/protocol/users-and-attesters): providers of negative or positive reputation.
UniRep protocol is a standard on which different reputational rules can interoperate. It doesn't dictate how reputation is used in a given application, but instead functions as a generic and [extensible](https://www.youtube.com/watch?v=jd2Dg9czJzI&list=PLV91V4b0yVqRQ62Mv0nUgWxJhi4E67XSY&index=5) system where platforms such as AirBNB, Uber, Reddit, Medium, Trip Advisor, or Trust Pilot would be [attesters](https://developer.unirep.io/docs/protocol/users-and-attesters): providers of negative or positive reputation.
Attesters are at the application layer. They are the platforms, businesses, and communities in the ZK social ecosystem. They act as world builders and community managers. Attesters have great flexibility in what to build. They decide how many user identities are used, how users are onboarded, and how users interact with each other. Most importantly, attesters decide why someone receives a positive reputation and why someone receives a negative reputation. In other words, attesters provide accountability.
Attesters use publicly known Ethereum addresses while user identities are always kept private. Users receive reputation from attesters and can create a zero-knowledge proof verifying they have a certain level of reputation from a certain attester.
Attesters use publicly known Ethereum addresses while user identities are always kept private. Users receive reputation from attesters and can create a zero-knowledge proof verifying they have a certain level of reputation from a certain attester.
UniRep users are always in control of how their reputation is used: only they can see how much they’ve accrued and only they have the power to reveal their reputation – and only to who they want.
UniRep users are always in control of how their reputation is used: only they can see how much they've accrued and only they have the power to reveal their reputation – and only to who they want.
## How UniRep works: adding accountability to anonymity
@@ -35,33 +36,33 @@ Reputation is accumulated to users via rotating identities called [epoch keys](h
[Epochs](https://developer.unirep.io/docs/protocol/epoch) represent the ticking of time. Similar to blocks in a blockchain, they can be thought of as cycles in the UniRep system: with each transition, the reputation balances of all users are finalized and carried over into the new epoch. Each attester sets their own epoch length.
Epoch keys are created from an [identity commitment](https://semaphore.appliedzkp.org/docs/guides/identities) generated via [Semaphore](https://semaphore.appliedzkp.org/), a generic privacy layer where users can anonymously send signals from within a group. Inside of a Semaphore group, users’ actions are unconnected to their “outside” identities. Instead of interacting with people as a uniquely identifiable individual, Semaphore identities are expressed simply as a member of the group.
Epoch keys are created from an [identity commitment](https://semaphore.appliedzkp.org/docs/guides/identities) generated via [Semaphore](https://semaphore.appliedzkp.org/), a generic privacy layer where users can anonymously send signals from within a group. Inside of a Semaphore group, users' actions are unconnected to their "outside" identities. Instead of interacting with people as a uniquely identifiable individual, Semaphore identities are expressed simply as a member of the group.
Epoch keys change every epoch, are unique to every user, and look completely random. Only the user knows if they are receiving an attestation or reputation; others would see only an attestation to a random value. Epochs and changing epoch keys help preserve privacy by mixing up where reputation accrues and what identities people use to interact.
## All about the trees
UniRep uses a system of migrating [Merkle tees](https://www.youtube.com/watch?v=YIc6MNfv5iQ) to maintain reputation and privacy at the same time. Merkle trees are data structures capable of efficiently storing and verifying information; reputation and user data are stored as leaves in UniRep’s Merkle trees. Proving a UniRep reputation means generating a proof that a user’s claim (their reputation level) exists in a valid Merkle tree.
UniRep uses a system of migrating [Merkle tees](https://www.youtube.com/watch?v=YIc6MNfv5iQ) to maintain reputation and privacy at the same time. Merkle trees are data structures capable of efficiently storing and verifying information; reputation and user data are stored as leaves in UniRep's Merkle trees. Proving a UniRep reputation means generating a proof that a user's claim (their reputation level) exists in a valid Merkle tree.
When users first sign up, their data is entered into a [State Tree](https://developer.unirep.io/docs/protocol/trees#state-tree). Each attester has their own separate version of a State Tree, which changes every epoch. State Trees can be thought of as the meta reputation tracker for a specific attester: containing relevant UniRep users and their starting reputations at the beginning of an epoch.
Since epoch keys are temporary, the reputations they accumulate must be migrated to a new Merkle tree. When users transition into the new epoch, they receive new epoch keys and the old epoch keys become invalid. In the background, their reputation follows them to the next iteration of an attester’s State Tree via ZK proofs. Moving to the new State Tree means creating a [User State Transition Proof](https://developer.unirep.io/docs/circuits-api/circuits#user-state-transition-proof) verifying the user followed all the rules of the protocol. The proofs show there was no cheating: no omitting negative attestations or adding fraudulent positive attestations.
Since epoch keys are temporary, the reputations they accumulate must be migrated to a new Merkle tree. When users transition into the new epoch, they receive new epoch keys and the old epoch keys become invalid. In the background, their reputation follows them to the next iteration of an attester's State Tree via ZK proofs. Moving to the new State Tree means creating a [User State Transition Proof](https://developer.unirep.io/docs/circuits-api/circuits#user-state-transition-proof) verifying the user followed all the rules of the protocol. The proofs show there was no cheating: no omitting negative attestations or adding fraudulent positive attestations.
![](/articles/unirep-protocol/X1povaSYYwUDI4HdZL_Rw.webp)
The user generates a User State Transition proof containing a new state tree leaf containing the attester ID, the user’s [Semaphore identity nullifier](https://semaphore.appliedzkp.org/docs/guides/identities), sum of the user’s positive and negative reputation from the previous epoch, timestamp and “graffiti” - a value given to the user by the attester. This new leaf is provided to the smart contract, which verifies the proof and inserts it into the new State Tree.
The user generates a User State Transition proof containing a new state tree leaf containing the attester ID, the user's [Semaphore identity nullifier](https://semaphore.appliedzkp.org/docs/guides/identities), sum of the user's positive and negative reputation from the previous epoch, timestamp and "graffiti" - a value given to the user by the attester. This new leaf is provided to the smart contract, which verifies the proof and inserts it into the new State Tree.
Once a user accrues reputation, they can prove how many reputation points they’ve accumulated through a [reputation proof](https://developer.unirep.io/docs/circuits-api/reputation-proof). The reputation proof is a ZK proof that verifies the user exists, has the claimed reputation, and has performed all the necessary transitions or migrations. The reputation proof makes sure the user’s claims are consistent with the data in the State Tree.
Once a user accrues reputation, they can prove how many reputation points they've accumulated through a [reputation proof](https://developer.unirep.io/docs/circuits-api/reputation-proof). The reputation proof is a ZK proof that verifies the user exists, has the claimed reputation, and has performed all the necessary transitions or migrations. The reputation proof makes sure the user's claims are consistent with the data in the State Tree.
There are many parallel efforts to reimagine and rearchitect online social systems to be more decentralized, permissionless, and censorship-resistant. Though different in their approaches, all these initiatives are creating basic building blocks for identity and reputation, then playing with different ways to stack the structure.
Efforts such as [Decentralized Identifiers (DIDs)](https://www.w3.org/TR/2022/REC-did-core-20220719/#abstract), [Decentralized Society (DeSoc)](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4105763), [peer-to-peer networks](https://scuttlebutt.nz/about/) and [Federated universes](https://eric442.substack.com/p/what-is-the-fediverse-0d6) or [networks](https://blueskyweb.xyz/blog/10-18-2022-the-at-protocol) allow anyone to join in, express themselves, and have the freedom to choose how they connect and participate with others. In these systems, users own their accounts, their data and their social graphs; users can choose how they interface with the network; and independent servers or systems are able to talk to each other by default.
When we hear "social applications" we tend to think of social media platforms like Twitter or Reddit – but restaurant reviews, marketplaces, rideshares and homestays are all highly social and highly dependent on reliable reputation systems. ZK social or [ZK identity](https://0xparc.org/blog/zk-id-2) share many of the principles of the decentralized social efforts mentioned previously, but ZK social starts with privacy as the foundational layer to build upon – which is especially important in use cases like homestays that cross into “real life” – and uses zero-knowledge proofs as the primary mechanism to make claims about identities or reputations. UniRep protocol is one building block in the ZK social stack.
When we hear "social applications" we tend to think of social media platforms like Twitter or Reddit – but restaurant reviews, marketplaces, rideshares and homestays are all highly social and highly dependent on reliable reputation systems. ZK social or [ZK identity](https://0xparc.org/blog/zk-id-2) share many of the principles of the decentralized social efforts mentioned previously, but ZK social starts with privacy as the foundational layer to build upon – which is especially important in use cases like homestays that cross into "real life" – and uses zero-knowledge proofs as the primary mechanism to make claims about identities or reputations. UniRep protocol is one building block in the ZK social stack.
Adding on complexity and data to an anonymous system allows people to regain the color that is lost when users can’t be individually identified. Building social primitives from scratch means having to consider and experiment with new ways to layer in constraints, rules, and feedback mechanisms.
Adding on complexity and data to an anonymous system allows people to regain the color that is lost when users can't be individually identified. Building social primitives from scratch means having to consider and experiment with new ways to layer in constraints, rules, and feedback mechanisms.
Eventually, interesting, multi-dimensional, user-owned, privacy-preserving, digital identity and reputation systems – all interoperating – are expected to emerge. But it’s still early days. Protocols such as Semaphore and UniRep are meant to serve as foundational building blocks near the base of the ZK social stack. These primitives can’t decide how this ZK-enabled social future will look or feel; that can only be decided by users, attesters, and builders.
Eventually, interesting, multi-dimensional, user-owned, privacy-preserving, digital identity and reputation systems – all interoperating – are expected to emerge. But it's still early days. Protocols such as Semaphore and UniRep are meant to serve as foundational building blocks near the base of the ZK social stack. These primitives can't decide how this ZK-enabled social future will look or feel; that can only be decided by users, attesters, and builders.
## Next steps
@@ -69,6 +70,6 @@ UniRep is still in the early stages of development, but the team is already work
You can try a [demo app](https://unirep.social/) built with UniRep Protocol, which resembles Reddit but with anonymity and privacy by default.
If you’d like to contribute to helping build the next version of [UniRep Protocol](https://github.com/unirep) or integrating this anonymous reputation layer to your project, check out the [docs](https://developer.unirep.io/docs/welcome) and join the [UniRep Discord here](https://discord.gg/VzMMDJmYc5).
If you'd like to contribute to helping build the next version of [UniRep Protocol](https://github.com/unirep) or integrating this anonymous reputation layer to your project, check out the [docs](https://developer.unirep.io/docs/welcome) and join the [UniRep Discord here](https://discord.gg/VzMMDJmYc5).
UniRep Protocol is possible thanks to the contributions of [Vivian](https://github.com/vivianjeng), [Chance](https://github.com/vimwitch), [Doris](https://github.com/kittybest), [Anthony](https://github.com/AnthonyMadia), [Yuriko](https://github.com/yuriko627), [CJ](https://github.com/CJ-Rose), and [Chiali](https://github.com/ChialiTsai).

3
articles/unleashing-potential-introducing-the-pse-core-program.md
View File

@@ -5,11 +5,12 @@ image: "/articles/unleashing-potential-introducing-the-pse-core-program/unleashi
tldr: "This post was written by the PSE EcoDev Team."
date: "2024-04-24"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/PvNKlzp8Xlaic_DeIFEW20-ai4eN1AqJO26d4YRqWwM"
projects: ["semaphore", "bandada", "tlsn", "zk-email"]
---
Hey there, curious minds! Are you ready to dive into the world of practical skills and open-source project contributions? Well, buckle up because we're about to embark on an exciting journey through the **PSE Core Program**!
In today’s digital landscape, privacy and security are paramount. That’s where Zero Knowledge (ZK) technologies come into play. By allowing parties to verify information without revealing any underlying data, ZK protocols offer a revolutionary solution to protect sensitive information in a world where data breaches and privacy violations are all too common.
In today's digital landscape, privacy and security are paramount. That's where Zero Knowledge (ZK) technologies come into play. By allowing parties to verify information without revealing any underlying data, ZK protocols offer a revolutionary solution to protect sensitive information in a world where data breaches and privacy violations are all too common.
With ZK protocols, individuals can engage in transactions, authenticate identities, and share information without compromising their privacy. It's a game-changer for industries ranging from finance and healthcare to communications and beyond.

1
articles/web2-nullifiers-using-voprf.md
View File

@@ -5,6 +5,7 @@ image: "/articles/web2-nullifiers-using-voprf/web2-nullifiers-using-voprf-cover.
tldr: "This post was written by PSE researcher Rasul Ibragimov. Big thanks to Lev Soukhanov for explaining the majority of this to me - without him, this blog post wouldn't exist."
date: "2025-01-30"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/L4LSAWflNocKolhV6ZVaqt3KDxdSjFPNSv0U5SCc__0"
projects: ["zk-email", "tlsn", "anon-aadhaar", "semaphore"]
---
## Abstract

3
articles/why-we-cant-build-perfectly-secure-multi-party-applications-yet.md
View File

@@ -5,9 +5,10 @@ image: "/articles/why-we-cant-build-perfectly-secure-multi-party-applications-ye
tldr: "This post was written by PSE researcher Enrico Bottazzi. Thanks to Pia Park for discussions and reviews."
date: "2025-01-14"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/nXUhkZ84ckZi_5mYRFCCKgkLVFAmM2ECdEFCQul2jPs"
projects: ["mpc-framework"]
---
In this post, we’ll explore why building secure multi-party applications, which aim to compute a function over inputs from different parties while keeping those inputs private, is impossible today. We use Multi-party Trade Credit Set-off (MTCS) as an example, showing how technologies like multi-party computation and fully homomorphic encryption fall short of perfect security due to a fundamental tradeoff between security and liveness. The current solution involves a delegated security model, but it’s not ideal. Are there any robust patches to this problem, or will we have to wait for indistinguishability obfuscation?
In this post, we'll explore why building secure multi-party applications, which aim to compute a function over inputs from different parties while keeping those inputs private, is impossible today. We use Multi-party Trade Credit Set-off (MTCS) as an example, showing how technologies like multi-party computation and fully homomorphic encryption fall short of perfect security due to a fundamental tradeoff between security and liveness. The current solution involves a delegated security model, but it's not ideal. Are there any robust patches to this problem, or will we have to wait for indistinguishability obfuscation?
### Multilateral Trade Credit Set-off

51
articles/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-1.md
View File

@@ -2,14 +2,15 @@
authors: ["0xZoey"]
title: "Zero to Start: Applied Fully Homomorphic Encryption (FHE) Part 1"
image: "/articles/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-1/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-1-cover.webp"
tldr: "This post was written by [0xZoey](https://twitter.com/0xZoey). Special thanks to [Janmajaya](https://twitter.com/Janmajaya_mall), [Enrico](https://twitter.com/backaes?lang=en), and [Owen](https://twitter.com/omurovec) who generously gave their time and expertise to review this piece. Your valuable contributions and feedback have greatly enhanced the quality and depth of this work. /n/n Find [Part 2: Fundamental Concepts, FHE Development, Applied FHE, Challenges and Open Problems](https://mirror.xyz/privacy-scaling-explorations.eth/wQZqa9acMdGS7LTXmKX-fR05VHfkgFf9Wrjso7XxDzs) here…"
tldr: "This post was written by [0xZoey](https://twitter.com/0xZoey). Special thanks to [Janmajaya](https://twitter.com/Janmajaya_mall), [Enrico](https://twitter.com/backaes?lang=en), and [Owen](https://twitter.com/omurovec) who generously gave their time and expertise to review this piece. Your valuable contributions and feedback have greatly enhanced the quality and depth of this work. /n/n Find [Part 2: Fundamental Concepts, FHE Development, Applied FHE, Challenges and Open Problems](https://mirror.xyz/privacy-scaling-explorations.eth/wQZqa9acMdGS7LTXmKX-fR05VHfkgFf9Wrjso7XxDzs) here…"
date: "2023-12-21"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/D8UHFW1t48x2liWb5wuP6LDdCRbgUH_8vOFvA0tNDJA"
projects: ["mpc-framework", "pse-security"]
---
## **What is FHE?**
Present privacy technology ensures secure communication and storage, encrypting our emails during transit and safeguarding databases in storage. However, accessing data for **processing** requires the data to be first decrypted. What if secure processing could occur without compromising data privacy?
Present privacy technology ensures secure communication and storage, encrypting our emails during transit and safeguarding databases in storage. However, accessing data for **processing** requires the data to be first decrypted. What if secure processing could occur without compromising data privacy?
![FHE allows computation over encrypted data](/articles/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-1/PK_2cdH2q63Dovvnlh777.webp)
@@ -19,7 +20,7 @@ FHE allows computation over encrypted data
This article focuses on the current state of FHE, fundamental concepts, applied FHE, and design challenges ahead. It is meant to help users understand the thought framework around applied FHE without requiring the reader to understand complex math or cryptography.
The idea for FHE was initially proposed in 1978 by Rivest, Adleman, and Dertouzous (the "R" and "A" of [RSA](<https://en.wikipedia.org/wiki/RSA_(cryptosystem)>)). FHE is an extension of public key cryptography; the encryption is "homomorphic" because it works on the principle that for every function performed on unencrypted text (Plaintext), there is an equivalent function for encrypted text (Ciphertext).
The idea for FHE was initially proposed in 1978 by Rivest, Adleman, and Dertouzous (the "R" and "A" of [RSA](<https://en.wikipedia.org/wiki/RSA_(cryptosystem)>)). FHE is an extension of public key cryptography; the encryption is "homomorphic" because it works on the principle that for every function performed on unencrypted text (Plaintext), there is an equivalent function for encrypted text (Ciphertext).
![Homomorphic Encryption](/articles/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-1/PoAkyRxFZ5v2OieE-iRPS.webp)
@@ -36,15 +37,15 @@ There are generally four categories of homomorphic encryption:
![](/articles/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-1/QkcoPW4EGRdD9wBEpqHb4.webp)
In the past, the difficulty in achieving FHE  was due to the "noise" that accumulated with every subsequent operation. The excess overflow in noise eventually makes decryption impossible. Craig Gentry proposed the first FHE scheme in 2009, where he solved this problem with a method called bootstrapping. Bootstrapping is used to recursively evaluate the decryption circuit to reduce and manage noise accumulation.
In the past, the difficulty in achieving FHE was due to the "noise" that accumulated with every subsequent operation. The excess overflow in noise eventually makes decryption impossible. Craig Gentry proposed the first FHE scheme in 2009, where he solved this problem with a method called bootstrapping. Bootstrapping is used to recursively evaluate the decryption circuit to reduce and manage noise accumulation.
## **Why is FHE important?**
Fully Homomorphic Encryption (FHE) signifies a groundbreaking shift in privacy, enabling data-centric systems to preserve privacy with minimal data exposure inherently. FHE, built using lattice-based cryptography, also offers the notable advantage of being post-quantum resistant, ensuring robust security against future potential threats from quantum computing.
Some [general](https://homomorphicencryption.org/wp-content/uploads/2018/10/CCS-HE-Tutorial-Slides.pdf?ref=blog.sunscreen.tech) FHE use cases include:
Some [general](https://homomorphicencryption.org/wp-content/uploads/2018/10/CCS-HE-Tutorial-Slides.pdf?ref=blog.sunscreen.tech) FHE use cases include:
- Private inference & training: FHE could be used to protect the privacy of both the model and data  (likely 3-5 years away).
- Private inference & training: FHE could be used to protect the privacy of both the model and data (likely 3-5 years away).
- Encrypted searches: query an encrypted file and only see the result of your specific query without the entire contents of the database revealed, also known as Private Information Retrieval (PIR).
- Policy Compliance & Identity Management: Secure identity management by enabling the processing of identity-related data without exposure, allowing organizations to comply with regulators' KYC policies.
@@ -52,42 +53,42 @@ Some [general](https://homomorphicencryption.org/wp-content/uploads/2018/10/CCS
General FHE Use Cases
Fully Homomorphic Encryption (FHE) holds immense significance in blockchain technology because it can perform encrypted data computations within a trustless environment. We won't dive into the importance of privacy on the blockchain and how off-chain ZKPs are not the complete solution, but Wei Dai's article [Navigating Privacy on Public Blockchains](https://wdai.us/posts/navigating-privacy/) is a great primer.
Fully Homomorphic Encryption (FHE) holds immense significance in blockchain technology because it can perform encrypted data computations within a trustless environment. We won't dive into the importance of privacy on the blockchain and how off-chain ZKPs are not the complete solution, but Wei Dai's article [Navigating Privacy on Public Blockchains](https://wdai.us/posts/navigating-privacy/) is a great primer.
Here are some theoretical blockchain use cases that FHE could facilitate:
- [Private Transactions](https://eprint.iacr.org/2022/1119.pdf): the processing of confidential transactions by smart contracts, allowing private transactions in dark pools, AMMs, blind auctions, and voting.
- [MEV](https://collective.flashbots.net/t/frp-10-distributed-blockbuilding-networks-via-secure-knapsack-auctions/1955) (Maximal Extractable Value) Mitigation: FHE could potentially allow proposing blocks and ordering transactions while ensuring Pre-execution, failed execution, and post-execution privacy, offering a potential solution to prevent front-running.
- Scaling: [Leveraging](https://www.fhenix.io/fhe-rollups-scaling-confidential-smart-contracts-on-ethereum-and-beyond-whitepaper/) [FHE Rollups](https://www.fhenix.io/wp-content/uploads/2023/11/FHE_Rollups_Whitepaper.pdf) presents a scalable approach to execute private smart contracts utilizing the security derived from Ethereum for state transitions
- [MEV](https://collective.flashbots.net/t/frp-10-distributed-blockbuilding-networks-via-secure-knapsack-auctions/1955) (Maximal Extractable Value) Mitigation: FHE could potentially allow proposing blocks and ordering transactions while ensuring Pre-execution, failed execution, and post-execution privacy, offering a potential solution to prevent front-running.
- Scaling: [Leveraging](https://www.fhenix.io/fhe-rollups-scaling-confidential-smart-contracts-on-ethereum-and-beyond-whitepaper/) [FHE Rollups](https://www.fhenix.io/wp-content/uploads/2023/11/FHE_Rollups_Whitepaper.pdf) presents a scalable approach to execute private smart contracts utilizing the security derived from Ethereum for state transitions
- [Private Blockchains](https://eprint.iacr.org/2022/1119.pdf): encrypted chain states that are programmatically decrypted via consensus using Threshold FHE.
![FHE: Blockchain Use Cases](/articles/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-1/duTnCuiIvMfqdk3ZERSe2.webp)
FHE: Blockchain Use Cases
The applied use cases for FHE are far-reaching, there are non-trivial technical challenges to overcome, and many are still being explored today. At its core, FHE ensures secure **data processing**, which, combined with other cryptographic primitives, can be incredibly powerful. In our exploration of Applied FHE, we dive deeper into real-world applications and use cases.
The applied use cases for FHE are far-reaching, there are non-trivial technical challenges to overcome, and many are still being explored today. At its core, FHE ensures secure **data processing**, which, combined with other cryptographic primitives, can be incredibly powerful. In our exploration of Applied FHE, we dive deeper into real-world applications and use cases.
## **ZKP, MPC, & FHE**
The terms ZKPs, MPC, and FHE have often been misused and interchanged and have been the source of much confusion. The post, [Beyond Zero-Knowledge: What's Next in Programmable Cryptography?](https://mirror.xyz/privacy-scaling-explorations.eth/xXcRj5QfvA_qhkiZCVg46Gn9uX8P_Ld-DXlqY51roPY) provides a succinct overview and comparisons of Zero-Knowledge Proofs (ZKPs), Multi-Party Computation (MPC), Fully Homomorphic Encryption (FHE) and Indistinguishability Obfuscation (iO). All fall under the broader umbrella of programmable cryptography.
The terms ZKPs, MPC, and FHE have often been misused and interchanged and have been the source of much confusion. The post, [Beyond Zero-Knowledge: What's Next in Programmable Cryptography?](https://mirror.xyz/privacy-scaling-explorations.eth/xXcRj5QfvA_qhkiZCVg46Gn9uX8P_Ld-DXlqY51roPY) provides a succinct overview and comparisons of Zero-Knowledge Proofs (ZKPs), Multi-Party Computation (MPC), Fully Homomorphic Encryption (FHE) and Indistinguishability Obfuscation (iO). All fall under the broader umbrella of programmable cryptography.
To briefly summarize how the three concepts are connected:
**[Multi-Party Computation (MPC)](https://www.youtube.com/watch?v=aDL_KScy6hA&t=571s)**: MPC, when described as a **_general function_**, is any setup where mutually distrustful parties can individually provide inputs (private to others) to collaboratively compute a public outcome.  MPC can be used as the term used to describe the **_technology_** itself, where randomized data shares from each individual are delegated for compute across servers.
**[Multi-Party Computation (MPC)](https://www.youtube.com/watch?v=aDL_KScy6hA&t=571s)**: MPC, when described as a **_general function_**, is any setup where mutually distrustful parties can individually provide inputs (private to others) to collaboratively compute a public outcome. MPC can be used as the term used to describe the **_technology_** itself, where randomized data shares from each individual are delegated for compute across servers.
![MPC](/articles/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-1/poh6Brvlh1qyBiYpgPxyP.webp)
MPC
To add to the confusion, it is also often used to describe MPC **_use cases_**, most notably in the context of [Distributed Key Generation](https://en.wikipedia.org/wiki/Distributed_key_generation) (DKG) and [Threshold Signature Schemes](https://link.springer.com/referenceworkentry/10.1007/0-387-23483-7_429#:~:text=Threshold%20signatures%20are%20digital%20signatures,structure%20of%20a%20threshold%20scheme.) (TSS).
To add to the confusion, it is also often used to describe MPC **_use cases_**, most notably in the context of [Distributed Key Generation](https://en.wikipedia.org/wiki/Distributed_key_generation) (DKG) and [Threshold Signature Schemes](https://link.springer.com/referenceworkentry/10.1007/0-387-23483-7_429#:~:text=Threshold%20signatures%20are%20digital%20signatures,structure%20of%20a%20threshold%20scheme.) (TSS).
Three leading technologies form the [building blocks](https://open.spotify.com/episode/4zfrPFbPWZvn6fXwrrEa5f?si=9ab56d47510f4da0) of MPC **_applications_**: [Garbled Circuits (GC)](https://www.youtube.com/watch?v=La6LkUZ4P_s), Linear Secret Sharing Schemes (LSSS), and Fully Homomorphic Encryption (FHE). These can be used both conjunctively or exclusively.
Three leading technologies form the [building blocks](https://open.spotify.com/episode/4zfrPFbPWZvn6fXwrrEa5f?si=9ab56d47510f4da0) of MPC **_applications_**: [Garbled Circuits (GC)](https://www.youtube.com/watch?v=La6LkUZ4P_s), Linear Secret Sharing Schemes (LSSS), and Fully Homomorphic Encryption (FHE). These can be used both conjunctively or exclusively.
![MPC & ZKPs](/articles/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-1/XiqL4MvjssDILJ59mDR5_.webp)
MPC & ZKPs
**Zero-Knowledge Proofs (ZKPs):** A method that allows a single party (prover) to prove to another party (verifier) knowledge about a piece of data without revealing the data itself. Using both public and private inputs, ZKPs enable the prover to present a true or false output to the verifier.
**Zero-Knowledge Proofs (ZKPs):** A method that allows a single party (prover) to prove to another party (verifier) knowledge about a piece of data without revealing the data itself. Using both public and private inputs, ZKPs enable the prover to present a true or false output to the verifier.
![ZKPs](/articles/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-1/8YgbCNa_VDgqwUo3y5qaG.webp)
@@ -97,9 +98,9 @@ In Web 3 applications, the integration of ZKPs alongside FHE becomes crucial for
Note the difference in ZKPs, FHE, and MPCs, where the input element of each primitive is distinct when evaluating the exposure of private data.
- In ZKPs, private data contained in the input is only *visible to the prover*
- In MPC, private data contained in each input is only *visible to the owner*
- In FHE, private data contained in the input is encrypted and is **_never revealed_**
- In ZKPs, private data contained in the input is only _visible to the prover_
- In MPC, private data contained in each input is only _visible to the owner_
- In FHE, private data contained in the input is encrypted and is **_never revealed_**
While MPC is network bound, FHE and ZKPs are compute bound. The three primitives also differ regarding relative computation costs and interactiveness required between parties.
@@ -126,7 +127,7 @@ Early concepts of FHE developed in the 1970s-90s laid the theoretical groundwork
FHE is not possible with Ethereum today due to the size of ciphertexts and the cost of computation on-chain. It is estimated with the current rate of hardware acceleration, we may see applications in production by 2025.
Zama’s implementation of [fhEVM](https://docs.zama.ai/fhevm/) is a fork of Ethereum; they have several [tools](https://docs.zama.ai/homepage/) available:
Zama's implementation of [fhEVM](https://docs.zama.ai/fhevm/) is a fork of Ethereum; they have several [tools](https://docs.zama.ai/homepage/) available:
- **[TFHE-rs](https://docs.zama.ai/tfhe-rs)**: Pure Rust implementation of TFHE for boolean and small integer arithmetics over encrypted data
- **[fhEVM](https://docs.zama.ai/fhevm)**: Private smart contracts on the EVM using homomorphic encryption
@@ -135,16 +136,16 @@ There are some challenges with ZAMA's fhEVM approach that are yet to be improved
Additionally, operations on encrypted integers are much more difficult to perform than on plaintext integers. For example, on an Amazon m6i.metal machine (one of Amazon's top machines costing $2-4k per month to operate):
- adding or subtracting two **encrypted** uint8 values takes around 70ms
- adding **plaintext** uint8 values is essentially free and instant on any modern device
- adding or subtracting two **encrypted** uint8 values takes around 70ms
- adding **plaintext** uint8 values is essentially free and instant on any modern device
There are also limitations to the size of unsigned integers available in the fhEVM context. Encrypted uint32 values are the largest possible in the fhEVM, while uint256 are the largest in the standard EVM and are used frequently by many protocols on Ethereum. Due to the challenge of operating on encrypted values in the fhEVM it is currently unreasonable to run validators at home, which makes this more suitable for networks with a smaller, more trusted validator set.
[Sunscreen](https://docs.sunscreen.tech/) is another project actively working on FHE; they have a Rust-based FHE compiler using the BFV scheme with a [playground](https://playground.sunscreen.tech/). They’ve deployed a [blind auction](https://demo.sunscreen.tech/auctionwithweb3) proof of concept on SepoliaETH.
[Sunscreen](https://docs.sunscreen.tech/) is another project actively working on FHE; they have a Rust-based FHE compiler using the BFV scheme with a [playground](https://playground.sunscreen.tech/). They've deployed a [blind auction](https://demo.sunscreen.tech/auctionwithweb3) proof of concept on SepoliaETH.
[Fhenix](https://docs.fhenix.io/), a team working on a modular “FHE blockchain extension”, plans on launching their testnet in January 2024. They also recently released their [whitepaper on FHE-Rollups](https://www.fhenix.io/fhe-rollups-scaling-confidential-smart-contracts-on-ethereum-and-beyond-whitepaper/).
[Fhenix](https://docs.fhenix.io/), a team working on a modular "FHE blockchain extension", plans on launching their testnet in January 2024. They also recently released their [whitepaper on FHE-Rollups](https://www.fhenix.io/fhe-rollups-scaling-confidential-smart-contracts-on-ethereum-and-beyond-whitepaper/).
In the last five years, significant advancements have been made to make FHE more usable. Shruthi Gorantala's [framework](https://youtu.be/Q3glyMsaWIE?si=TbhlNxGsozbalIHU&t=1278) for thinking about FHE development as a hierarchy of needs is particularly helpful. The performance improvements listed above address deficiency needs and are contained in Layers 1-3 within the FHE tech stack. For FHE to realize its full potential, we also need to address the growth needs listed in Layers 4-5.
In the last five years, significant advancements have been made to make FHE more usable. Shruthi Gorantala's [framework](https://youtu.be/Q3glyMsaWIE?si=TbhlNxGsozbalIHU&t=1278) for thinking about FHE development as a hierarchy of needs is particularly helpful. The performance improvements listed above address deficiency needs and are contained in Layers 1-3 within the FHE tech stack. For FHE to realize its full potential, we also need to address the growth needs listed in Layers 4-5.
![FHE Hierarchy of Needs](/articles/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-1/ZQ48QaY9vXvlwn-4Eh2B9.webp)
@@ -152,4 +153,4 @@ FHE Hierarchy of Needs
A critical aspect of systems integration is figuring out how to combine FHE technology with other privacy-enhancing primitives like ZKPs and MPC in a way that suits each unique trust model and protocol.
Continue to [Part 2: Fundamental Concepts, FHE Development, Applied FHE, Challenges and Open Problems](https://mirror.xyz/privacy-scaling-explorations.eth/wQZqa9acMdGS7LTXmKX-fR05VHfkgFf9Wrjso7XxDzs).
Continue to [Part 2: Fundamental Concepts, FHE Development, Applied FHE, Challenges and Open Problems](https://mirror.xyz/privacy-scaling-explorations.eth/wQZqa9acMdGS7LTXmKX-fR05VHfkgFf9Wrjso7XxDzs).

87
articles/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-2.md
View File

@@ -2,30 +2,31 @@
authors: ["0xZoey"]
title: "Zero to Start: Applied Fully Homomorphic Encryption (FHE) Part 2"
image: "/articles/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-2/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-2-cover-1.webp"
tldr: "This post was written by [0xZoey](https://twitter.com/0xZoey), with contributions from Chance. /n This is an extension of [Part 1: An Introduction to FHE, ZKPs & MPC, and The State of FHE Development](https://mirror.xyz/privacy-scaling-explorations.eth/D8UHFW1t48x2liWb5wuP6LDdCRbgUH_8vOFvA0tNDJA)."
tldr: "This post was written by [0xZoey](https://twitter.com/0xZoey), with contributions from Chance. /n This is an extension of [Part 1: An Introduction to FHE, ZKPs & MPC, and The State of FHE Development](https://mirror.xyz/privacy-scaling-explorations.eth/D8UHFW1t48x2liWb5wuP6LDdCRbgUH_8vOFvA0tNDJA)."
date: "2023-12-21"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/wQZqa9acMdGS7LTXmKX-fR05VHfkgFf9Wrjso7XxDzs"
projects: ["mpc-framework", "pse-security", "post-quantum-cryptography"]
---
## **Fundamental Concepts**
### **Threshold FHE**
Threshold cryptography involves splitting a single cryptographic key into “shares” across multiple parties. You may already be familiar with Threshold Signatures Schemes (TSS), which are most commonly used in MPC wallets. The required threshold of parties to collaborate to gain access to the private key is usually predefined. This is different from a multi-sig scenario where multiple “whole” keys are used.
Threshold cryptography involves splitting a single cryptographic key into "shares" across multiple parties. You may already be familiar with Threshold Signatures Schemes (TSS), which are most commonly used in MPC wallets. The required threshold of parties to collaborate to gain access to the private key is usually predefined. This is different from a multi-sig scenario where multiple "whole" keys are used.
![Threshold Cryptography vs Multi-Sig](/articles/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-2/wfpyPpbJRvjEtiiMA2BSK.webp)
Threshold Cryptography vs Multi-Sig
In [Threshold FHE](https://eprint.iacr.org/2017/257), the concept acts similarly to TSS, but key shares are extended to the decryption process, requiring multiple entities to cooperate to decrypt data. This reinforces security by distributing decryption authority.
In [Threshold FHE](https://eprint.iacr.org/2017/257), the concept acts similarly to TSS, but key shares are extended to the decryption process, requiring multiple entities to cooperate to decrypt data. This reinforces security by distributing decryption authority.
In the [PESCA](https://eprint.iacr.org/2022/1119.pdf) blueprint and [Zama](https://github.com/zama-ai/fhevm/blob/main/fhevm-whitepaper.pdf)’s implementation, an example of threshold FHE  is used to compute over encrypted blockchain states.  The transparent and public nature of blockchain data means that to maintain privacy, we need to be able to decrypt states and allow smart contracts to be composable selectively. The private key shares are distributed to validators, and a certain threshold of private keys is required for decryption. No single validator or group smaller than the threshold is able to decrypt the blockchain state. [Note](https://discord.com/channels/901152454077452399/1126507772524113930/1156317837850329098) that the threshold only applies to privacy and the risk is on confidentiality, not on actual assets.
In the [PESCA](https://eprint.iacr.org/2022/1119.pdf) blueprint and [Zama](https://github.com/zama-ai/fhevm/blob/main/fhevm-whitepaper.pdf)'s implementation, an example of threshold FHE is used to compute over encrypted blockchain states. The transparent and public nature of blockchain data means that to maintain privacy, we need to be able to decrypt states and allow smart contracts to be composable selectively. The private key shares are distributed to validators, and a certain threshold of private keys is required for decryption. No single validator or group smaller than the threshold is able to decrypt the blockchain state. [Note](https://discord.com/channels/901152454077452399/1126507772524113930/1156317837850329098) that the threshold only applies to privacy and the risk is on confidentiality, not on actual assets.
Dynamic Proactive Secret Sharing could theoretically be used to support a consensus set where validator nodes are joining and leaving. There are some caveats to a Threshold FHE setup that requires an honest majority, which we discuss further in the challenges section.
### **FHE & MPC**
With Threshold-FHE, trust is placed with a group of private key holders; in [FHE-MPC,](https://link.springer.com/article/10.1007/s10623-022-01160-x) trust assumptions are minimized to each individual party. A simple example between 2 parties:
With Threshold-FHE, trust is placed with a group of private key holders; in [FHE-MPC,](https://link.springer.com/article/10.1007/s10623-022-01160-x) trust assumptions are minimized to each individual party. A simple example between 2 parties:
- The first party encrypts their input to create a ciphertext
- The ciphertext is passed to the second party
@@ -41,13 +42,13 @@ MPC and FHE can be combined in several ways:
- Multi-Key FHE-based MPC: Multiple FHE key pairs are combined to perform MPC
- Multi-Party FHE-based MPC: Key generation is distributed, and Decryption is also distributed.
The [takeaway](https://eprint.iacr.org/2023/981.pdf) here is the combination of the two technologies allow the key properties of MPC to be combined with FHE. However, managing FHE ciphertext size with the communication complexity between parties in MPC is an important consideration.
The [takeaway](https://eprint.iacr.org/2023/981.pdf) here is the combination of the two technologies allow the key properties of MPC to be combined with FHE. However, managing FHE ciphertext size with the communication complexity between parties in MPC is an important consideration.
### **Lattice-based cryptography**
Lattice-based cryptography provides the mathematical framework that underpins every FHE scheme. It is also used in the three post-quantum computing (PQC) standardization digital signature schemes [selected by NIST](https://csrc.nist.gov/news/2023/additional-pqc-digital-signature-candidates), CRYSTALS-Dilithium, FALCON, and SPHINCS+. The security of lattice-based cryptography comes from the inherent difficulty of solving lattice problems.
Lattice-based cryptography provides the mathematical framework that underpins every FHE scheme. It is also used in the three post-quantum computing (PQC) standardization digital signature schemes [selected by NIST](https://csrc.nist.gov/news/2023/additional-pqc-digital-signature-candidates), CRYSTALS-Dilithium, FALCON, and SPHINCS+. The security of lattice-based cryptography comes from the inherent difficulty of solving lattice problems.
Think of [lattice-based cryptography](https://www.youtube.com/watch?v=K026C5YaB3A) as two vectors forming a pattern over a grid. As we add more vectors across multiple dimensions, this pattern becomes increasingly complex.
Think of [lattice-based cryptography](https://www.youtube.com/watch?v=K026C5YaB3A) as two vectors forming a pattern over a grid. As we add more vectors across multiple dimensions, this pattern becomes increasingly complex.
![Lattice-Based Cryptography](/articles/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-2/1hOeDx2ijeoP2fjQyIWhR.webp)
@@ -57,13 +58,13 @@ Finding the shortest vector to the point of origin of the very first vector beco
### **Learning With Errors (LWE) & Ring-LWE**
[Learning With Errors](https://www.youtube.com/watch?v=K026C5YaB3A) (LWE) is a hard math problem based on the approximate Shortest Vector Problem (SVP). Similar to lattice problems, its hardness makes it a good candidate for use in PQC cryptography.  Ring-LWE is a progression of LWE based on the SVP over ideal lattices. It is significant for FHE because the second generation of FHE schemes utilise LWE and RLWE to reduce ciphertext size and reduce noise, thus increasing performance.
[Learning With Errors](https://www.youtube.com/watch?v=K026C5YaB3A) (LWE) is a hard math problem based on the approximate Shortest Vector Problem (SVP). Similar to lattice problems, its hardness makes it a good candidate for use in PQC cryptography. Ring-LWE is a progression of LWE based on the SVP over ideal lattices. It is significant for FHE because the second generation of FHE schemes utilise LWE and RLWE to reduce ciphertext size and reduce noise, thus increasing performance.
### **Managing Noise**
In FHE, noise refers to the distortion or error accumulating during homomorphic operations on encrypted data. Noise arises due to the mathematical properties of the homomorphic encryption and scale with the operations performed on encrypted values.
The [diagram](https://homomorphicencryption.org/wp-content/uploads/2018/10/CCS-HE-Tutorial-Slides.pdf?ref=blog.sunscreen.tech) below represents fresh encryption, where each component can be expressed as a coefficient in a polynomial or a vector. The height of the element represents the size of the coefficients. Note that in the first step, the initial noise is small.
The [diagram](https://homomorphicencryption.org/wp-content/uploads/2018/10/CCS-HE-Tutorial-Slides.pdf?ref=blog.sunscreen.tech) below represents fresh encryption, where each component can be expressed as a coefficient in a polynomial or a vector. The height of the element represents the size of the coefficients. Note that in the first step, the initial noise is small.
![](/articles/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-2/sB_dnGBjpaiXUWrKLkFnM.webp)
@@ -79,7 +80,7 @@ Noise management techniques in FHE aim to control or reduce the noise level to m
- **Bootstrapping**: this maintains the correctness of computations on encrypted data by reducing the impact of accumulated noise.
- **Modulous Switching**: lightweight noise management without secret-key use, rescaling ciphertexts. It is most effective when applied after each homomorphic multiplication.
- **Batching:** increasing efficiency by packing multiple plaintexts into the same ciphertext so FHE can be conducted on multiple inputs
- **Batching:** increasing efficiency by packing multiple plaintexts into the same ciphertext so FHE can be conducted on multiple inputs
### **Bootstrapping**
@@ -89,7 +90,7 @@ Bootstrapping is the key technique used to manage noise overflow. When bootstrap
Bootstrapping
The ciphertext is re-encrypted recursively, and the noise level is reset to the same level created by the bootstrapping operation itself.  Think of each recursive encryption as layers of wrapping over the original ciphertext, giving you a ciphertext of a ciphertext.
The ciphertext is re-encrypted recursively, and the noise level is reset to the same level created by the bootstrapping operation itself. Think of each recursive encryption as layers of wrapping over the original ciphertext, giving you a ciphertext of a ciphertext.
Using our layers example, each "inner layer" is homomorphically decrypted. As long as your noise reservoir allows room to do one more homomorphic operation (addition or multiplication), you can achieve FHE by running bootstrapping.
@@ -99,7 +100,7 @@ Relinerization is a technique to transform quadratic equations into linear ones,
## **FHE Schemes**
The development of FHE [schemes](https://queue.acm.org/detail.cfm?id=3561800) in the last decade has been rapid, with TFHE and BGV being the most popular blockchain applications. We focus on three main schemes in this article, but [many](https://github.com/jonaschn/awesome-he) others exist. Like any programming language, each comes with its unique properties suited for various use cases.
The development of FHE [schemes](https://queue.acm.org/detail.cfm?id=3561800) in the last decade has been rapid, with TFHE and BGV being the most popular blockchain applications. We focus on three main schemes in this article, but [many](https://github.com/jonaschn/awesome-he) others exist. Like any programming language, each comes with its unique properties suited for various use cases.
![Generations of FHE Schemes](/articles/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-2/BVTrv4k2df5KQNhuQ1yG-.webp)
@@ -107,21 +108,21 @@ Generations of FHE Schemes
### **BGV & BFV**
[Second-generation](https://queue.acm.org/detail.cfm?id=3561800) FHE schemes [BGV](https://eprint.iacr.org/2011/277.pdf) (2011) drastically improved performance and allowed for weaker security assumptions. With BGV, the concept of  [Learning With Errors](https://www.youtube.com/watch?v=K026C5YaB3A&t=28s) (LWE) was introduced, reducing the 30 minutes per bit operation performance time down to seconds. [BFV](https://eprint.iacr.org/2012/144.pdf) (2012) was published very shortly after BGV, where instead of using linear equations with LWE, polynomial rings over finite fields, Ring-LWE, is used.
[Second-generation](https://queue.acm.org/detail.cfm?id=3561800) FHE schemes [BGV](https://eprint.iacr.org/2011/277.pdf) (2011) drastically improved performance and allowed for weaker security assumptions. With BGV, the concept of [Learning With Errors](https://www.youtube.com/watch?v=K026C5YaB3A&t=28s) (LWE) was introduced, reducing the 30 minutes per bit operation performance time down to seconds. [BFV](https://eprint.iacr.org/2012/144.pdf) (2012) was published very shortly after BGV, where instead of using linear equations with LWE, polynomial rings over finite fields, Ring-LWE, is used.
BGV and BFV's computations use modular arithmetic circuits and work well with applications that require large vectors of small integers. These schemes are particularly useful for private information retrieval and database query applications.
### **TFHE**
Fully Homomorphic Encryption over the Torus (TFHE)(2016) is an improved version of [FHEW](https://link.springer.com/chapter/10.1007/978-3-662-46800-5_24) (2014). It was the first scheme to [realize programable bootstrapping](https://www.tfhe.com/evolution-of-homomorphic-encryption-schemes) using a lookup table over a ciphertext with a managed level of noise. It drastically [improved](https://link.springer.com/epdf/10.1007/978-3-662-53887-6_1?sharing_token=YsC3Hu6iPFp104kZQ6tZgPe4RwlQNchNByi7wbcMAY5bBAyAdgprN5xaaLEWgAqi3OyJt9tYY67Qr-JCwidvui2AFZZY23Iilns5cEmIIZMMdU8UUbfVmV_DCtPpkTVuaYBGgF2rZ79A9GuOu_QQi5L1eWufxVcTMf8_0-DEecE%3D) comparison and bootstrapping speeds, reducing times from seconds to milliseconds. TFHE's original implementation only allowed for Boolean circuits, but newer implementations like TFHErs are capable of bootstrapping over integers. It is most suitable for general-purpose computation.
Fully Homomorphic Encryption over the Torus (TFHE)(2016) is an improved version of [FHEW](https://link.springer.com/chapter/10.1007/978-3-662-46800-5_24) (2014). It was the first scheme to [realize programable bootstrapping](https://www.tfhe.com/evolution-of-homomorphic-encryption-schemes) using a lookup table over a ciphertext with a managed level of noise. It drastically [improved](https://link.springer.com/epdf/10.1007/978-3-662-53887-6_1?sharing_token=YsC3Hu6iPFp104kZQ6tZgPe4RwlQNchNByi7wbcMAY5bBAyAdgprN5xaaLEWgAqi3OyJt9tYY67Qr-JCwidvui2AFZZY23Iilns5cEmIIZMMdU8UUbfVmV_DCtPpkTVuaYBGgF2rZ79A9GuOu_QQi5L1eWufxVcTMf8_0-DEecE%3D) comparison and bootstrapping speeds, reducing times from seconds to milliseconds. TFHE's original implementation only allowed for Boolean circuits, but newer implementations like TFHErs are capable of bootstrapping over integers. It is most suitable for general-purpose computation.
### **CKKS**
CKKS (2016) is most appropriate for applications working with real numbers, such as practical machine learning problems, regression training, neural network inference, and statistical computations. CKKS [deals with](https://dualitytech.com/blog/bootstrapping-in-fully-homomorphic-encryption-fhe/) approximate arithmetic and so is not compatible with web3 applications where precise financial data is required. However, we list it here as a particularly efficient scheme and has proven to be a significant advancement in the last few years.
CKKS (2016) is most appropriate for applications working with real numbers, such as practical machine learning problems, regression training, neural network inference, and statistical computations. CKKS [deals with](https://dualitytech.com/blog/bootstrapping-in-fully-homomorphic-encryption-fhe/) approximate arithmetic and so is not compatible with web3 applications where precise financial data is required. However, we list it here as a particularly efficient scheme and has proven to be a significant advancement in the last few years.
## **Scheme Comparisons**
Here is a high-level [comparison](https://www.youtube.com/watch?v=VJZSGM4DdZ0) of the three most relevant FHE schemes:
Here is a high-level [comparison](https://www.youtube.com/watch?v=VJZSGM4DdZ0) of the three most relevant FHE schemes:
![FHE Scheme Comparisons](/articles/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-2/fD4DfgunYv-8mOXw4eWnV.webp)
@@ -129,7 +130,7 @@ FHE Scheme Comparisons
## **Step-by-Step Development**
Now that we have foundational concepts down, we dive into some practical considerations for building with FHE. Development can be broken down into the following [steps](https://homomorphicencryption.org/wp-content/uploads/2018/10/CCS-HE-Tutorial-Slides.pdf?ref=blog.sunscreen.tech):
Now that we have foundational concepts down, we dive into some practical considerations for building with FHE. Development can be broken down into the following [steps](https://homomorphicencryption.org/wp-content/uploads/2018/10/CCS-HE-Tutorial-Slides.pdf?ref=blog.sunscreen.tech):
- Pick a FHE scheme appropriate for your use case
@@ -147,7 +148,7 @@ Now that we have foundational concepts down, we dive into some practical conside
- [Considerations:](https://www.youtube.com/watch?v=VJZSGM4DdZ0)
- What kinds of computation are you looking to do?
- What, if any,  limitations do you have on ciphertext and key sizes?
- What, if any, limitations do you have on ciphertext and key sizes?
- What level of performance are you looking to attain?
- Is relinerization required?
@@ -165,21 +166,21 @@ We outline a few examples of FHE Applications here; despite their diversity, the
1. **Encrypt data**: presented as an encrypted integer (i.e., euint8), which serves as a wrapper over FHE ciphertext.
2. **Perform an Operation**: computation is run on the encrypted data using FHE (i.e, add, sum, diff)
3. **Apply the Condition**: the result of the operation is used to take some action. This is achieved by using an “If…else…” multiplexer operator (i.e., [cmux](https://docs.zama.ai/fhevm/writing-contracts/functions#multiplexer-operator-cmux), where three inputs return one output). Think of this like a railroad switch where two tracks converge to a single destination.
3. **Apply the Condition**: the result of the operation is used to take some action. This is achieved by using an "If…else…" multiplexer operator (i.e., [cmux](https://docs.zama.ai/fhevm/writing-contracts/functions#multiplexer-operator-cmux), where three inputs return one output). Think of this like a railroad switch where two tracks converge to a single destination.
### **Confidential ERC20 Tokens**
In this implementation of a [confidential ERC20](https://www.zama.ai/post/confidential-erc-20-tokens-using-homomorphic-encryption) token contract by Zama, FHE is used to check that the wallet viewing the balance also owns the balance, effectively keeping the balance hidden from everyone else.
In this implementation of a [confidential ERC20](https://www.zama.ai/post/confidential-erc-20-tokens-using-homomorphic-encryption) token contract by Zama, FHE is used to check that the wallet viewing the balance also owns the balance, effectively keeping the balance hidden from everyone else.
1. During a token transfer, the amount sent is encrypted.
2. The sender user balance is checked to make sure that it is greater than the transfer amount to prevent overspending using FHE.
3. The transfer is then executed on-chain, deducting the sender's balance and adding it to the recipient's balance.
Additional measures are also taken with token minting to prevent information about balances from leaking. In a [different implementation](https://docs.fhenix.io/examples/reference-dapps/wrapped-erc20) by Fhenix, a wrapped ERC20 keeps balances and amounts confidential, but the sender and receiver remain public. Note that these implementations are used as an extension of the existing ERC20 standard and not a replacement.
Additional measures are also taken with token minting to prevent information about balances from leaking. In a [different implementation](https://docs.fhenix.io/examples/reference-dapps/wrapped-erc20) by Fhenix, a wrapped ERC20 keeps balances and amounts confidential, but the sender and receiver remain public. Note that these implementations are used as an extension of the existing ERC20 standard and not a replacement.
### **Order matching**
In a privacy-preserving [dark pool](https://www.ifaamas.org/Proceedings/aamas2020/pdfs/p1747.pdf):
In a privacy-preserving [dark pool](https://www.ifaamas.org/Proceedings/aamas2020/pdfs/p1747.pdf):
1. Traders can send their buy and sell orders encrypted to an exchange.
2. The exchange uses FHE to find a match in the order book without knowing the order type, amount, or price.
@@ -189,13 +190,13 @@ In a privacy-preserving [dark pool](https://www.ifaamas.org/Proceedings/aamas20
Dark Pools: Order Matching using FHE
In this use case, traders can place orders without "alerting" the open market of their intentions, potentially giving away high-value alpha. Exchange operators remain neutral and establish trust, as their role here is purely used in order matching and execution. Regulatory authorities can ensure compliance with an additional layer, mitigating conflicts of interest between traders and operators. For an [on-chain darkpool](https://github.com/omurovec/fhe-darkpools/blob/master/src/DarkPool.sol), trades can be encrypted to prevent MEV. Zama has an FHE implementation of a [dark market](https://www.zama.ai/post/dark-market-tfhe-rs), and Sunscreen provides an AMM example [here](https://docs.sunscreen.tech/fhe/fhe_programs/example.html). Note that most of these are partial implementations, and privacy leaks exist.
In this use case, traders can place orders without "alerting" the open market of their intentions, potentially giving away high-value alpha. Exchange operators remain neutral and establish trust, as their role here is purely used in order matching and execution. Regulatory authorities can ensure compliance with an additional layer, mitigating conflicts of interest between traders and operators. For an [on-chain darkpool](https://github.com/omurovec/fhe-darkpools/blob/master/src/DarkPool.sol), trades can be encrypted to prevent MEV. Zama has an FHE implementation of a [dark market](https://www.zama.ai/post/dark-market-tfhe-rs), and Sunscreen provides an AMM example [here](https://docs.sunscreen.tech/fhe/fhe_programs/example.html). Note that most of these are partial implementations, and privacy leaks exist.
### **Private Voting**
Tokens or NFT owners can anonymously vote on proposals for DAO governance. Details such as token circulation amount, voting decisions, and delegation selection can be kept confidential with FHE.
In this specific delegation [example](https://www.zama.ai/post/confidential-dao-voting-using-homomorphic-encryption), an existing Compound contract is used:
In this specific delegation [example](https://www.zama.ai/post/confidential-dao-voting-using-homomorphic-encryption), an existing Compound contract is used:
1. The COMP token contract, including token balances, is first encrypted.
2. Any changes in vote delegation are subsequently run over the encrypted token contract using FHE.
@@ -209,7 +210,7 @@ The Governor contract subsequently manages proposals and votes:
### **Blind Auctions**
In previous blind auctions with ZKP implementations, bid data and compute is off-chain, requiring the trust of a third-party entity for proof creation. FHE allows [blind auctions](https://www.zama.ai/post/on-chain-blind-auctions-using-homomorphic-encryption) to run entirely on-chain, allowing parties to submit an encrypted private bid.  In the bidding process:
In previous blind auctions with ZKP implementations, bid data and compute is off-chain, requiring the trust of a third-party entity for proof creation. FHE allows [blind auctions](https://www.zama.ai/post/on-chain-blind-auctions-using-homomorphic-encryption) to run entirely on-chain, allowing parties to submit an encrypted private bid. In the bidding process:
1. The bid amount by each user is kept encrypted.
2. FHE is used to check if a previous bid has been made and determines the highest bid from all bidders.
@@ -217,7 +218,7 @@ In previous blind auctions with ZKP implementations, bid data and compute is off
### **Other Novel Applications**
Some other fhEVM novel use cases are being explored by the community [here](https://fhevm-explorers.notion.site/fhevm-explorers/fhEVM-Novel-Use-Cases-c1e637b0ca5740afa7fe598407b7266f); they include:
Some other fhEVM novel use cases are being explored by the community [here](https://fhevm-explorers.notion.site/fhevm-explorers/fhEVM-Novel-Use-Cases-c1e637b0ca5740afa7fe598407b7266f); they include:
- Private Surveys: Survey answers are encrypted, and FHE is used to run analytics on the results whilst keeping participants and their answers anonymized
- DIDs: NFTs could contain encrypted metadata; FHE is run on the private metadata to enable entry into gated communities or authentication for access
@@ -233,19 +234,19 @@ Applied FHE Challenges
## **Transciphering/ Hybrid Homomorphic Encryption**
The large size of ciphertexts is one of the greatest barriers to practical implementation due to its associated computation time and bandwidth usage. [Transciphering](https://eprint.iacr.org/2023/1531.pdf), or Hybrid Homomorphic Encryption, is a method of carrying out compression encryption within the FHE setup. Data is first compacted with a scheme like [AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) before creating a ciphertext, which FHE is then run on. There are several [methods of transciphering](https://eprint.iacr.org/2023/980.pdf) being explored at the moment that are compatible with TFHE schemes.
The large size of ciphertexts is one of the greatest barriers to practical implementation due to its associated computation time and bandwidth usage. [Transciphering](https://eprint.iacr.org/2023/1531.pdf), or Hybrid Homomorphic Encryption, is a method of carrying out compression encryption within the FHE setup. Data is first compacted with a scheme like [AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) before creating a ciphertext, which FHE is then run on. There are several [methods of transciphering](https://eprint.iacr.org/2023/980.pdf) being explored at the moment that are compatible with TFHE schemes.
## **Hardware Acceleration**
Whilst bootstrapping reduces ciphertext noise to make FHE practically possible, it still requires a large amount of computation and time. [Hardware acceleration](https://dualitytech.com/blog/hardware-acceleration-of-fully-homomorphic-encryption-making-privacy-preserving-machine-learning-practical/) allows for computing tasks to be offloaded to specialized hardware components. At the moment, there are several teams working on ASICs for TFHE; the speedup with the use of more efficient hardware is likely to hit 1000x by 2025.
Whilst bootstrapping reduces ciphertext noise to make FHE practically possible, it still requires a large amount of computation and time. [Hardware acceleration](https://dualitytech.com/blog/hardware-acceleration-of-fully-homomorphic-encryption-making-privacy-preserving-machine-learning-practical/) allows for computing tasks to be offloaded to specialized hardware components. At the moment, there are several teams working on ASICs for TFHE; the speedup with the use of more efficient hardware is likely to hit 1000x by 2025.
Reducing the complexity of FHE for developers is crucial. Creating user-friendly libraries, tools, and APIs that abstract the cryptography-heavy aspects of FHE while offering easy integration into existing development frameworks can encourage wider adoption. At the moment, there is a lack of standardization when it comes to APIs, schemes, and compilers. Improving [library interoperability](https://homomorphicencryption.org/wp-content/uploads/2018/10/CCS-HE-Tutorial-Slides.pdf?ref=blog.sunscreen.tech) and higher-level automation for developers will make FHE more usable.
Reducing the complexity of FHE for developers is crucial. Creating user-friendly libraries, tools, and APIs that abstract the cryptography-heavy aspects of FHE while offering easy integration into existing development frameworks can encourage wider adoption. At the moment, there is a lack of standardization when it comes to APIs, schemes, and compilers. Improving [library interoperability](https://homomorphicencryption.org/wp-content/uploads/2018/10/CCS-HE-Tutorial-Slides.pdf?ref=blog.sunscreen.tech) and higher-level automation for developers will make FHE more usable.
## **FHE Compilers**
A compiler is a piece of software that converts source code to binary code in one go. Think of it as a translator for human readable languages (programming languages) to machine-readable languages (binary code). The majority of FHE compilers that exist at the moment add a significant amount of time to computation. The most efficient compiler at the time of writing (Sunscreen) has 1.3x overhead when compared to a low-level FHE library.
One of the barriers to wider FHE adoption is the need for developer-friendly compilers. [Sunscreen](https://blog.sunscreen.tech/from-toy-programs-to-real-life-building-an-fhe-compiler/) and [Zama](https://docs.zama.ai/concrete/) are actively building compilers that increase the usability of FHE by automating parameters and key selection. At the moment, both compilers currently only support single-key FHE schemes and are standalone. The compatibility of the two is being worked on so that ZKPs can be used to prove information with FHE ciphertexts.
One of the barriers to wider FHE adoption is the need for developer-friendly compilers. [Sunscreen](https://blog.sunscreen.tech/from-toy-programs-to-real-life-building-an-fhe-compiler/) and [Zama](https://docs.zama.ai/concrete/) are actively building compilers that increase the usability of FHE by automating parameters and key selection. At the moment, both compilers currently only support single-key FHE schemes and are standalone. The compatibility of the two is being worked on so that ZKPs can be used to prove information with FHE ciphertexts.
## **FHE for Blockchain**
@@ -255,11 +256,11 @@ Improving the performance of FHE schemes is essential for responsive Web3 applic
### **Gas Cost**
Gas cost estimations are possible on the blockchain because transaction data is public. In the case of FHE, smart contract execution flow logic will differ depending on the outcome of computation (which may be hidden), making it difficult to accurately estimate gas costs. However, there are currently some [proposed ways](https://github.com/zama-ai/fhevm/blob/main/fhevm-whitepaper.pdf) to navigate this, and more accurate techniques will need to be developed to create a desirable user experience.
Gas cost estimations are possible on the blockchain because transaction data is public. In the case of FHE, smart contract execution flow logic will differ depending on the outcome of computation (which may be hidden), making it difficult to accurately estimate gas costs. However, there are currently some [proposed ways](https://github.com/zama-ai/fhevm/blob/main/fhevm-whitepaper.pdf) to navigate this, and more accurate techniques will need to be developed to create a desirable user experience.
### **Trust assumptions**
The implementation of Threshold FHE for encrypted states on a private blockchain utilizes the security assumptions of a network of decentralized validators. In order to perform the decryption, only 2/3rds of the validators or the number predetermined in the Threshold-FHE setup is required.  Unlike a public blockchain, any form of collusion would be [undetectable](https://hackmd.io/cd7YCyEqQh-n_LJ0kArtQw); malicious activity would, therefore, leave no verifiable trace. Some would argue that a setup requiring stronger trust assumptions, like FHE-MPC, is more prudent.  Decryption nodes and validator notes could also be potentially [separate entities](https://discord.com/channels/901152454077452399/1126507772524113930/1153599900244791397), varying the trust assumptions and threshold of the two operations.
The implementation of Threshold FHE for encrypted states on a private blockchain utilizes the security assumptions of a network of decentralized validators. In order to perform the decryption, only 2/3rds of the validators or the number predetermined in the Threshold-FHE setup is required. Unlike a public blockchain, any form of collusion would be [undetectable](https://hackmd.io/cd7YCyEqQh-n_LJ0kArtQw); malicious activity would, therefore, leave no verifiable trace. Some would argue that a setup requiring stronger trust assumptions, like FHE-MPC, is more prudent. Decryption nodes and validator notes could also be potentially [separate entities](https://discord.com/channels/901152454077452399/1126507772524113930/1153599900244791397), varying the trust assumptions and threshold of the two operations.
### **Privacy Leaks**
@@ -267,17 +268,17 @@ The simple act of the client sending a command to the server running the fhEVM m
## **Conclusion**
FHE opens up new frontiers in secure computation, realizing its full potential demands overcoming challenges such as usability, performance, and integration with other cryptographic primitives. While practical applications of FHE across domains are just emerging, its integration into decentralized systems remains an ongoing narrative.  The technology's potential to reshape data privacy is vast, promising a future where we default to privacy-centric systems.
FHE opens up new frontiers in secure computation, realizing its full potential demands overcoming challenges such as usability, performance, and integration with other cryptographic primitives. While practical applications of FHE across domains are just emerging, its integration into decentralized systems remains an ongoing narrative. The technology's potential to reshape data privacy is vast, promising a future where we default to privacy-centric systems.
The road ahead involves deeper dives into advanced concepts and integration strategies like [Ring-LWE](https://www.mdpi.com/2227-7390/10/5/728), [ZK](https://github.com/emilianobonassi/zkFHE)\-[FHE](https://github.com/enricobottazzi/zk-fhe), [FHE Rollups](https://www.fhenix.io/wp-content/uploads/2023/11/FHE_Rollups_Whitepaper.pdf), [FHE-MPC](https://eprint.iacr.org/2023/981.pdf), and Latticed-based [ZKP](https://eprint.iacr.org/2022/284)s.
The road ahead involves deeper dives into advanced concepts and integration strategies like [Ring-LWE](https://www.mdpi.com/2227-7390/10/5/728), [ZK](https://github.com/emilianobonassi/zkFHE)-[FHE](https://github.com/enricobottazzi/zk-fhe), [FHE Rollups](https://www.fhenix.io/wp-content/uploads/2023/11/FHE_Rollups_Whitepaper.pdf), [FHE-MPC](https://eprint.iacr.org/2023/981.pdf), and Latticed-based [ZKP](https://eprint.iacr.org/2022/284)s.
## **FHE Resources**
Craig Gentry: A Fully Homomorphic Encryption Scheme [https://cdn.sanity.io/files/r000fwn3/production/5496636b7474ef68f79248de4a63dd879db55334.pdf](https://cdn.sanity.io/files/r000fwn3/production/5496636b7474ef68f79248de4a63dd879db55334.pdf)
Craig Gentry: A Fully Homomorphic Encryption Scheme [https://cdn.sanity.io/files/r000fwn3/production/5496636b7474ef68f79248de4a63dd879db55334.pdf](https://cdn.sanity.io/files/r000fwn3/production/5496636b7474ef68f79248de4a63dd879db55334.pdf)
Slides: CSS_HE tutorial slides [https://homomorphicencryption.org/wp-content/uploads/2018/10/CCS-HE-Tutorial-Slides.pdf?ref=blog.sunscreen.tech](https://homomorphicencryption.org/wp-content/uploads/2018/10/CCS-HE-Tutorial-Slides.pdf?ref=blog.sunscreen.tech)
Slides: CSS_HE tutorial slides [https://homomorphicencryption.org/wp-content/uploads/2018/10/CCS-HE-Tutorial-Slides.pdf?ref=blog.sunscreen.tech](https://homomorphicencryption.org/wp-content/uploads/2018/10/CCS-HE-Tutorial-Slides.pdf?ref=blog.sunscreen.tech)
Slides: Computing Arbitrary Functions of Encrypted Data [https://crypto.stanford.edu/craig/easy-fhe.pdf](https://crypto.stanford.edu/craig/easy-fhe.pdf)
Slides: Computing Arbitrary Functions of Encrypted Data [https://crypto.stanford.edu/craig/easy-fhe.pdf](https://crypto.stanford.edu/craig/easy-fhe.pdf)
Fhenix: FHE Rollups
@@ -287,7 +288,7 @@ fhEVM Whitepaper:
**[fhevm/fhevm-whitepaper.pdf at main · zama-ai/fhevm](https://github.com/zama-ai/fhevm/blob/main/fhevm-whitepaper.pdf)**
fhEVM Novel Use cases: [https://fhevm-explorers.notion.site/fhevm-explorers/fhEVM-Novel-Use-Cases-c1e637b0ca5740afa7fe598407b7266f](https://fhevm-explorers.notion.site/fhevm-explorers/fhEVM-Novel-Use-Cases-c1e637b0ca5740afa7fe598407b7266f)
fhEVM Novel Use cases: [https://fhevm-explorers.notion.site/fhevm-explorers/fhEVM-Novel-Use-Cases-c1e637b0ca5740afa7fe598407b7266f](https://fhevm-explorers.notion.site/fhevm-explorers/fhEVM-Novel-Use-Cases-c1e637b0ca5740afa7fe598407b7266f)
FHE-MPC Advanced Grad Course
@@ -297,7 +298,7 @@ Fully Composable Homomorphic Encryption
**[cseweb.ucsd.edu](https://cseweb.ucsd.edu/classes/fa23/cse208-a/cfhe-draft.pdf)**
Video: FHE and MPC by Shruthi Gorantala [https://www.youtube.com/watch?v=Q3glyMsaWIE](https://www.youtube.com/watch?v=Q3glyMsaWIE)
Video: FHE and MPC by Shruthi Gorantala [https://www.youtube.com/watch?v=Q3glyMsaWIE](https://www.youtube.com/watch?v=Q3glyMsaWIE)
Github: FHE awesome list
@@ -317,13 +318,13 @@ Video: Prog Crypto
Sunscreen:
An Intro to FHE: [https://blog.sunscreen.tech/an-intro-to-fully-homomorphic-encryption-for-engineers/](https://blog.sunscreen.tech/an-intro-to-fully-homomorphic-encryption-for-engineers/)
An Intro to FHE: [https://blog.sunscreen.tech/an-intro-to-fully-homomorphic-encryption-for-engineers/](https://blog.sunscreen.tech/an-intro-to-fully-homomorphic-encryption-for-engineers/)
Building Private Dapps:[https://www.youtube.com/watch?v=\_AiEmS8ojvU](https://www.youtube.com/watch?v=_AiEmS8ojvU)
Documentation: [https://docs.sunscreen.tech/](https://docs.sunscreen.tech/)
Documentation: [https://docs.sunscreen.tech/](https://docs.sunscreen.tech/)
ZK9 Building an FHE Compiler: [https://www.youtube.com/watch?v=VJZSGM4DdZ0](https://www.youtube.com/watch?v=VJZSGM4DdZ0)
ZK9 Building an FHE Compiler: [https://www.youtube.com/watch?v=VJZSGM4DdZ0](https://www.youtube.com/watch?v=VJZSGM4DdZ0)
ZK Podcast: Episode 295 The Return to MPC with Nigel Smart

13
articles/zkevm-community-edition-part-1-introduction.md
View File

@@ -5,6 +5,7 @@ image: "/articles/zkevm-community-edition-part-1-introduction/zkevm-community-ed
tldr: ""
date: "2023-05-23"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/I5BzurX-T6slFaPbA4i3hVrO7U2VkBR45eO-N3CSnSg"
projects: ["zkevm-community"]
---
The task of making Ethereum faster, cheaper, and easier to verify is a globally distributed effort with many moving parts. Developing zkEVMs is one piece of the effort with the majority of zkEVM projects being built as Layer 2 scaling solutions. A zkEVM capable of validating L1 blocks is on a long – and often changing – roadmap for scaling Ethereum that has been referenced as part of [“The Splurge”](https://twitter.com/VitalikButerin/status/1466411377107558402), [“ZK-SNARKing everything” on the rollup centric roadmap,](https://www.reddit.com/r/ethereum/comments/j3px5s/a_rollupcentric_ethereum_roadmap_vitalik/) [“enshrined rollups”](https://www.reddit.com/r/ethereum/comments/vrx9xe/comment/if7auu7/), and most recently [“The Verge”](https://twitter.com/VitalikButerin/status/1588669782471368704).
@@ -21,15 +22,15 @@ _[Part 3: Logic and Structure](https://mirror.xyz/privacy-scaling-explorations.e
## World computer
A virtual machine is a simulated computer running as software on a physical computer. In the early days, Ethereum was described as a “[world computer](https://www.youtube.com/watch?v=j23HnORQXvs)” to convey the concept of a shared virtual machine run on a distributed network. Ethereum’s innovation was a virtual machine on top of a blockchain. The virtual machine created an environment for software execution, storage, and state. The blockchain allowed each node or physical computer to reach consensus or agreement on the state of the “world computer.” The result was a common, persistent software environment across a distributed network called the [Ethereum Virtual Machine (EVM)](https://ethereum.org/en/developers/docs/evm/).
A virtual machine is a simulated computer running as software on a physical computer. In the early days, Ethereum was described as a “[world computer](https://www.youtube.com/watch?v=j23HnORQXvs)” to convey the concept of a shared virtual machine run on a distributed network. Ethereum's innovation was a virtual machine on top of a blockchain. The virtual machine created an environment for software execution, storage, and state. The blockchain allowed each node or physical computer to reach consensus or agreement on the state of the "world computer." The result was a common, persistent software environment across a distributed network called the [Ethereum Virtual Machine (EVM)](https://ethereum.org/en/developers/docs/evm/).
To guarantee the same results are achieved across the network, full nodes must receive and re-execute every transaction since the first Ethereum block, which requires substantial computing resources.
The zkEVM takes the EVM and adds [zero-knowledge (ZK) proofs](https://ethereum.org/en/zero-knowledge-proofs/#zk-snarks). ZK proofs can mathematically guarantee [Layer 1 (L1)](https://ethereum.org/en/layer-2/#what-is-layer-1) Ethereum transactions were run correctly. On the standard EVM, nodes run on general-purpose computers, which makes running a node accessible to everyone and allowing the network to have hundreds of thousands of participants. However, proof generation is expensive and resource-intensive. Instead of running this process on all nodes, it must be outsourced to a single specialized node: a powerful computer with specific features that make it suitable for proof generation, such as GPU acceleration or FPGA acceleration. The rest of the nodes – using general purpose computers  – need only verify one proof per block.
The zkEVM takes the EVM and adds [zero-knowledge (ZK) proofs](https://ethereum.org/en/zero-knowledge-proofs/#zk-snarks). ZK proofs can mathematically guarantee [Layer 1 (L1)](https://ethereum.org/en/layer-2/#what-is-layer-1) Ethereum transactions were run correctly. On the standard EVM, nodes run on general-purpose computers, which makes running a node accessible to everyone and allowing the network to have hundreds of thousands of participants. However, proof generation is expensive and resource-intensive. Instead of running this process on all nodes, it must be outsourced to a single specialized node: a powerful computer with specific features that make it suitable for proof generation, such as GPU acceleration or FPGA acceleration. The rest of the nodes – using general purpose computers – need only verify one proof per block.
## Levels of zkEVMs
The EVM has been described as a [“beast of complexity”](https://youtu.be/W2f_GLEtobo?t=448). Many approaches exist for applying ZK proofs to the EVM – all with their own tradeoffs. As a result, building zkEVMs is an ecosystem-wide, multi-polar research and engineering effort with a variety of teams collaborating and competing to scale Ethereum at different levels.
The EVM has been described as a ["beast of complexity"](https://youtu.be/W2f_GLEtobo?t=448). Many approaches exist for applying ZK proofs to the EVM – all with their own tradeoffs. As a result, building zkEVMs is an ecosystem-wide, multi-polar research and engineering effort with a variety of teams collaborating and competing to scale Ethereum at different levels.
A key difference between these approaches is the level of compatibility with the EVM. Different levels of compatibility come with different tradeoffs, from complexity, decentralization and speed of implementation to the familiarity of the user experience and how much of the existing code, infrastructure and tooling can be retained. The range of zkEVMs can be separated into language-level, bytecode level, and consensus-level compatibility.
@@ -39,7 +40,7 @@ A key difference between these approaches is the level of compatibility with the
So far, the majority of zkEVM projects have focused on building bytecode and language compatible ZK rollups on L2.
Vitalik Buterin categorized zkEVMs into different “types”, each with different pros and cons. “Type 1” zkEVMs aim to deliver an experience closest to Ethereum as it is today but face challenges regarding proving time and centralization risk, while “Type 4” have the lowest cost and centralization risks but are less compatible with existing infrastructure.
Vitalik Buterin categorized zkEVMs into different "types", each with different pros and cons. "Type 1" zkEVMs aim to deliver an experience closest to Ethereum as it is today but face challenges regarding proving time and centralization risk, while "Type 4" have the lowest cost and centralization risks but are less compatible with existing infrastructure.
![https://vitalik.ca/general/2022/08/04/zkevm.html](/articles/zkevm-community-edition-part-1-introduction/03QchdJlYoLxWmEbflSoo.webp)
@@ -47,7 +48,7 @@ https://vitalik.ca/general/2022/08/04/zkevm.html
## Consensus-level compatibility
The [zkEVM Community Edition](https://github.com/privacy-scaling-explorations/zkevm-circuits) is a collaborative effort focused on creating a zkEVM capable of verifying Ethereum’s current execution layer. The goal is to be [“fully and uncompromisingly Ethereum-equivalent.”](https://vitalik.ca/general/2022/08/04/zkevm.html) The project is being stewarded by [Privacy & Scaling Explorations (PSE)](https://appliedzkp.org/), a team within the [Ethereum Foundation](https://ethereum.foundation/) specializing in applied zero-knowledge cryptography.
The [zkEVM Community Edition](https://github.com/privacy-scaling-explorations/zkevm-circuits) is a collaborative effort focused on creating a zkEVM capable of verifying Ethereum's current execution layer. The goal is to be ["fully and uncompromisingly Ethereum-equivalent."](https://vitalik.ca/general/2022/08/04/zkevm.html) The project is being stewarded by [Privacy & Scaling Explorations (PSE)](https://appliedzkp.org/), a team within the [Ethereum Foundation](https://ethereum.foundation/) specializing in applied zero-knowledge cryptography.
The work toward completing the zkEVM Community Edition will result in two scalability solutions:
@@ -64,7 +65,7 @@ The more collaboration and communication there is between different zkEVM projec
The zkEVM Community Edition is possible thanks to the contribution of many teams including the [PSE](https://appliedzkp.org/), [Scroll Tech](https://scroll.io/), and [Taiko](https://taiko.xyz/) along with many individual contributors. Teams such as [Zcash](https://electriccoin.co/) have also researched and developed proving systems and libraries that have greatly benefited zkEVM efforts.
The zkEVM Community Edition is an open-source project and can be accessed in the [main repo](https://github.com/privacy-scaling-explorations/zkevm-specs). If you’re interested in helping, you can learn more by visiting the [contribution guidelines](https://github.com/privacy-scaling-explorations/zkevm-circuits/blob/main/CONTRIBUTING.md). The Community Edition is being built in public and its current status can be viewed on the [project board](https://github.com/orgs/privacy-scaling-explorations/projects/3/views/1).
The zkEVM Community Edition is an open-source project and can be accessed in the [main repo](https://github.com/privacy-scaling-explorations/zkevm-specs). If you're interested in helping, you can learn more by visiting the [contribution guidelines](https://github.com/privacy-scaling-explorations/zkevm-circuits/blob/main/CONTRIBUTING.md). The Community Edition is being built in public and its current status can be viewed on the [project board](https://github.com/orgs/privacy-scaling-explorations/projects/3/views/1).
For any general questions, feel free to ask in the [PSE Discord](https://discord.com/invite/sF5CT5rzrR).

19
articles/zkevm-community-edition-part-2-components.md
View File

@@ -5,6 +5,7 @@ image: "/articles/zkevm-community-edition-part-2-components/zkevm-community-edit
tldr: "This series of articles intends to provide an overview of the zkEVM Community Edition in a way that is broadly accessible. Part 2 is a summary of the common components used in most zkEVMs."
date: "2023-05-23"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/AW854RXMqS3SU8WCA7Yz-LVnTXCOjpwhmwUq30UNi1Q"
projects: ["zkevm-community"]
---
_[Part 1: Introduction](https://mirror.xyz/privacy-scaling-explorations.eth/I5BzurX-T6slFaPbA4i3hVrO7U2VkBR45eO-N3CSnSg)_
@@ -13,11 +14,11 @@ _[Part 3: Logic and Structure](https://mirror.xyz/privacy-scaling-explorations.e
Before diving deeper into how the zkEVM Community Edition works, it is necessary to understand some basic concepts that are common among zkEVM projects. The following section is not technically complete and is written as a simplified introduction to zkSNARKs, opcodes, and arithmetic circuits.
At a high level, the EVM state transitions from one block to the next via instructions called opcodes. To prove the EVM transitioned correctly, a ZK proof must be generated for each block and constructing this ZK proof means representing each opcode or change in the EVM as a circuit. Building a zkEVM requires finding optimal ways to efficiently translate opcodes into circuit form. Let’s break down what this all means.
At a high level, the EVM state transitions from one block to the next via instructions called opcodes. To prove the EVM transitioned correctly, a ZK proof must be generated for each block and constructing this ZK proof means representing each opcode or change in the EVM as a circuit. Building a zkEVM requires finding optimal ways to efficiently translate opcodes into circuit form. Let's break down what this all means.
## Zero-knowledge proofs
> “\[Zero knowledge proofs\] deliver *scalability* by exponentially compressing the amount of computation needed to verify the integrity of a large batch of transactions.”            [\- Eli Ben-Sasson](https://nakamoto.com/cambrian-explosion-of-crypto-proofs/)
> "\[Zero knowledge proofs\] deliver _scalability_ by exponentially compressing the amount of computation needed to verify the integrity of a large batch of transactions."            [\- Eli Ben-Sasson](https://nakamoto.com/cambrian-explosion-of-crypto-proofs/)
A ZK proof involves two parties: the prover and the verifier. In a zkEVM, the prover generates the proof of validity. The verifier checks if the proof was done correctly.
@@ -25,7 +26,7 @@ An L1 proof of validity confirms every transaction on Mainnet Ethereum. For a [Z
Zero-knowledge proofs offer the same level of security as re-executing transactions to verify their correctness. However, they require less computation and resources during the verification process. This means that more people can participate in maintaining the network by running nodes and contributing to consensus.
Nodes using specialized hardware will be required to generate proofs of validity, but once the proof is posted on-chain, nearly any node will be able to verify the proof with a low-resource cryptographic operation.
Nodes using specialized hardware will be required to generate proofs of validity, but once the proof is posted on-chain, nearly any node will be able to verify the proof with a low-resource cryptographic operation.
A zkEVM makes it theoretically possible to run an Ethereum [node on your phone](https://youtu.be/hBupNf1igbY?t=590).
@@ -33,7 +34,7 @@ A zkEVM makes it theoretically possible to run an Ethereum [node on your phone](
The zkEVM uses [zkSNARKs](https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell): a type of ZK protocol that is general purpose and capable of turning nearly any computation into a ZK proof. Before zkSNARKs, building ZK proofs was a highly specialized math problem that required a skilled cryptographer to create a unique ZK protocol for every new function. The discovery of zkSNARKs turned the creation of ZK protocols from a specialized math problem to a [generalized programming task](https://archive.devcon.org/archive/watch/6/zkps-and-programmable-cryptography/?tab=YouTube).
[zkSNARKs stand for Zero-Knowledge Succinct Non-interactive ARguments of Knowledge](https://z.cash/technology/zksnarks/). Zero-knowledge refers to the protocol’s capacity to prove a statement is true “without revealing any information beyond the validity of the statement itself.” Though the ZK part tends to get the most attention, it is in fact optional and unnecessary for zkEVMs. The most relevant property is succinctness.
[zkSNARKs stand for Zero-Knowledge Succinct Non-interactive ARguments of Knowledge](https://z.cash/technology/zksnarks/). Zero-knowledge refers to the protocol's capacity to prove a statement is true "without revealing any information beyond the validity of the statement itself." Though the ZK part tends to get the most attention, it is in fact optional and unnecessary for zkEVMs. The most relevant property is succinctness.
![https://www.youtube.com/watch?v=h-94UhJLeck](/articles/zkevm-community-edition-part-2-components/Sd2dQ6Q8Y2nPIgO0cqr9j.webp)
@@ -63,9 +64,9 @@ https://archive.devcon.org/archive/watch/6/eli5-zero-knowledge/?tab=YouTube
To create a SNARK, you must first convert a function to circuit form. Writing a circuit breaks down the function into its simplest arithmetic logic of addition and multiplication. Because addition can express linear computations and multiplication can express exponential computations, these two simple operations become highly expressive when stacked together and applied to polynomials.
![Polynomials are math expressions with “many terms.” ](/articles/zkevm-community-edition-part-2-components/gizYcrA2NKJ4Ow11FlxqJ.webp)
![Polynomials are math expressions with "many terms." ](/articles/zkevm-community-edition-part-2-components/gizYcrA2NKJ4Ow11FlxqJ.webp)
Polynomials are math expressions with “many terms.”
Polynomials are math expressions with "many terms."
In the context of this article, it is only necessary to know that polynomials have two useful properties: they are easy to work with and can efficiently encode a lot of information without needing to reveal all the information it represents. In other words, polynomials can be succinct: they can represent a complex computation yet remain short and fast to verify. For a complete explanation of how zkSNARKs work and why polynomials are used, [this paper](https://arxiv.org/pdf/1906.07221.pdf) is a good resource. For a practical explanation of how polynomial commitments schemes are applied in Ethereum scaling solutions, check out [this blog post](https://scroll.io/blog/kzg).
@@ -88,12 +89,12 @@ Example of a slightly more complex circuit https://nmohnblatt.github.io/zk-jargo
In the image above, the circuit expects:
- Inputs are *x*₀, *x*₁, and *x*₂
- Inputs are *x*₀, *x*₁, and *x*₂
- Output is *y = 5x*₀ *\+ 3(x*₁ *\+ x*₂)
For a prover to demonstrate they know the private inputs without revealing them to the verifier, they must be able to complete the circuit and reach the same output known to both parties. Circuits are designed so that only the correct inputs can go through all the gates and arrive at the same publicly known output. Each step is iterative and must be done in a predetermined order to satisfy the circuit logic. In a sufficiently designed circuit, there should be no feasible way a prover can make it through the circuit without knowing the correct inputs.
In the zkEVM Community Edition, circuits must prove that each transaction, all the opcodes used in the transaction, and the sequence of the operations are correct. As building circuits is a new and rapidly evolving field, there is still no “right way” to define the computation the circuit is trying to verify. To be practical, circuits must also be written efficiently in a way that minimizes the number of steps required while still being capable of satisfying the verifier. The difficulty of building a zkEVM is compounded by the fact that the skills required to build the necessary components are rare.
In the zkEVM Community Edition, circuits must prove that each transaction, all the opcodes used in the transaction, and the sequence of the operations are correct. As building circuits is a new and rapidly evolving field, there is still no "right way" to define the computation the circuit is trying to verify. To be practical, circuits must also be written efficiently in a way that minimizes the number of steps required while still being capable of satisfying the verifier. The difficulty of building a zkEVM is compounded by the fact that the skills required to build the necessary components are rare.
The Community Edition is an attempt to overcome both the technical and organizational challenges of building a consensus-level compatible zkEVM. The goal is to create a public good that serves as a common point of collaboration for the zkEVM community.
@@ -101,7 +102,7 @@ The Community Edition is an attempt to overcome both the technical and organizat
The zkEVM Community Edition is possible thanks to the contribution of many teams including the [PSE](https://appliedzkp.org/), [Scroll Tech](https://scroll.io/), and [Taiko](https://taiko.xyz/) along with many individual contributors. Teams such as [Zcash](https://electriccoin.co/) have also researched and developed proving systems and libraries that have greatly benefited zkEVM efforts.
The zkEVM Community Edition is an open-source project and can be accessed in the [main repo](https://github.com/privacy-scaling-explorations/zkevm-specs). If you’re interested in helping, you can learn more by visiting the [contribution guidelines](https://github.com/privacy-scaling-explorations/zkevm-circuits/blob/main/CONTRIBUTING.md). The Community Edition is being built in public and its current status can be viewed on the [project board](https://github.com/orgs/privacy-scaling-explorations/projects/3/views/1).
The zkEVM Community Edition is an open-source project and can be accessed in the [main repo](https://github.com/privacy-scaling-explorations/zkevm-specs). If you're interested in helping, you can learn more by visiting the [contribution guidelines](https://github.com/privacy-scaling-explorations/zkevm-circuits/blob/main/CONTRIBUTING.md). The Community Edition is being built in public and its current status can be viewed on the [project board](https://github.com/orgs/privacy-scaling-explorations/projects/3/views/1).
For any general questions, feel free to ask in the [PSE Discord.](https://discord.com/invite/sF5CT5rzrR)

13
articles/zkevm-community-edition-part-3-logic-and-structure.md
View File

@@ -5,6 +5,7 @@ image: "/articles/zkevm-community-edition-part-3-logic-and-structure/zkevm-commu
tldr: "This series intends to provide an overview of the zkEVM Community Edition in a way that is broadly accessible. Part 3 reviews the general logic and structure of the zkEVM Community Edition."
date: "2023-05-23"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/shl8eMBiObd6_AUBikXZrjKD4fibI6xUZd7d9Yv5ezE"
projects: ["zkevm-community"]
---
_[Part 1: Introduction](https://mirror.xyz/privacy-scaling-explorations.eth/I5BzurX-T6slFaPbA4i3hVrO7U2VkBR45eO-N3CSnSg)_
@@ -25,7 +26,7 @@ EVM opcodes are unfriendly to SNARKs for two main reasons:
1. 256-bit operations vs prime field operations
The EVM uses different sets of numbers and mathematical operations compared to SNARKs. SNARKs are cheap because they use addition and multiplication over a finite set of numbers called a prime field. In contrast, the EVM uses many arithmetic operations in 256-bit words. Emulating the EVM’s 256-bit operations with the prime field operations used by SNARKs is expensive and requires clever circuit design to be practical.
The EVM uses different sets of numbers and mathematical operations compared to SNARKs. SNARKs are cheap because they use addition and multiplication over a finite set of numbers called a prime field. In contrast, the EVM uses many arithmetic operations in 256-bit words. Emulating the EVM's 256-bit operations with the prime field operations used by SNARKs is expensive and requires clever circuit design to be practical.
2. Variable paths vs fixed paths
@@ -85,7 +86,7 @@ The [EVM Circuit](https://github.com/privacy-scaling-explorations/zkevm-specs/bl
[Bytecode Circuit](https://privacy-scaling-explorations.github.io/zkevm-docs/architecture/bytecode-circuit.html#bytecode-circuit):
- Verifies each bytecode has a valid hash. It also serves as a lookup table for the EVM circuit to access data of any “index of bytecode.”
- Verifies each bytecode has a valid hash. It also serves as a lookup table for the EVM circuit to access data of any "index of bytecode."
[ECDSA Cicruit](https://privacy-scaling-explorations.github.io/zkevm-docs/architecture/ecdsa-circuit.html#ecdsa-cicruit):
@@ -101,11 +102,11 @@ The [EVM Circuit](https://github.com/privacy-scaling-explorations/zkevm-specs/bl
**Copy Circuit:**
- Verifies copies of chunks of bytes. For example, from Memory to Bytecode when deploying a contract, or from Tx to Memory when reading a tx calldata. Used by the EVM Circuit as a lookup table to verify byte array copies
- Verifies copies of chunks of bytes. For example, from Memory to Bytecode when deploying a contract, or from Tx to Memory when reading a tx calldata. Used by the EVM Circuit as a lookup table to verify byte array copies
**Block Circuit:**
- Verifies the block Hash. Used by the EVM Circuit to lookup block fields.
- Verifies the block Hash. Used by the EVM Circuit to lookup block fields.
**Public Input Circuit:**
@@ -121,7 +122,7 @@ Writing optimal circuits means creating a system of polynomial equations with th
However, the zkEVM community aims to be inclusive and supportive of individuals who are interested in learning and contributing. If you have a background in Rust or experience with other zkSNARK tooling like circom, you already have a good foundation for understanding the concepts behind the zkEVM. With a dedicated learning phase of 1-2 months, you should be well-equipped to make valuable contributions.
A consensus level zkEVM that proves the validity of Layer 1 must be a community effort. Not enough skills or resources currently exist for one team to do it alone – and reasonably well. There are many approaches to explore and many gaps in a single team’s capabilities.
A consensus level zkEVM that proves the validity of Layer 1 must be a community effort. Not enough skills or resources currently exist for one team to do it alone – and reasonably well. There are many approaches to explore and many gaps in a single team's capabilities.
Contributing to zkEVMs means entering a world where the tools are limited, the language is nascent, and the skills required are rare, but overcoming the challenge may create the widest practical application of zero-knowledge cryptography to date. If proofs of validity are used to verify every Ethereum block, then every Ethereum user will benefit from zero-knowledge proofs – a benefit that seems worth the effort.
@@ -133,7 +134,7 @@ For those who have found the design of the zkEVM Community Edition interesting o
The zkEVM Community Edition is possible thanks to the contribution of many teams including the [PSE](https://appliedzkp.org/), [Scroll Tech](https://scroll.io/), and [Taiko](https://taiko.xyz/) along with many individual contributors. Teams such as [Zcash](https://electriccoin.co/) have also researched and developed proving systems and libraries that have greatly benefited zkEVM efforts.
The zkEVM Community Edition is an open-source project and can be accessed in the [main repo](https://github.com/privacy-scaling-explorations/zkevm-specs). If you’re interested in helping, you can learn more by visiting the [contribution guidelines](https://github.com/privacy-scaling-explorations/zkevm-circuits/blob/main/CONTRIBUTING.md). The Community Edition is being built in public and its current status can be viewed on the [project board](https://github.com/orgs/privacy-scaling-explorations/projects/3/views/1).
The zkEVM Community Edition is an open-source project and can be accessed in the [main repo](https://github.com/privacy-scaling-explorations/zkevm-specs). If you're interested in helping, you can learn more by visiting the [contribution guidelines](https://github.com/privacy-scaling-explorations/zkevm-circuits/blob/main/CONTRIBUTING.md). The Community Edition is being built in public and its current status can be viewed on the [project board](https://github.com/orgs/privacy-scaling-explorations/projects/3/views/1).
For any general questions, feel free to ask in the [PSE Discord.](https://discord.com/invite/sF5CT5rzrR)

19
articles/zkitter-an-anon-friendly-social-network.md
View File

@@ -5,11 +5,12 @@ image: "/articles/zkitter-an-anon-friendly-social-network/cover.webp"
tldr: ""
date: "2023-01-11"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/P4jDH1gLrVQ-DP5VyIKQrlPAJUTDhtXZkFl2vp8ewSg"
projects: ["zkitter", "semaphore", "interep", "rln"]
---
Zkitter is a decentralized social network where users have the option to interact anonymously. The platform provides familiar social media functions such as posting, chatting, following, and liking, but with a private identity layer under the hood.
Zkitter was created as a public good for more open and honest conversation. With privacy and anonymity enabled by default – and without the fear of damaging or risking one’s personal reputation – the theory is that users will be able to express themselves more freely on Zkitter compared to mainstream platforms.
Zkitter was created as a public good for more open and honest conversation. With privacy and anonymity enabled by default – and without the fear of damaging or risking one's personal reputation – the theory is that users will be able to express themselves more freely on Zkitter compared to mainstream platforms.
Zkitter is a social experiment made possible by decentralized blockchains and privacy-preserving [zero-knowledge proofs](https://ethereum.org/en/zero-knowledge-proofs/), and is currently in [alpha testing.](https://www.zkitter.com/explore/)
@@ -23,25 +24,25 @@ Semaphore allows Ethereum users to prove their membership of a group and send si
**Interep**
Another challenge with anonymity is [Sybil attacks](https://en.wikipedia.org/wiki/Sybil_attack), where a user creates multiple accounts to spam or gain influence.  Zkitter uses Interep to increase Sybil resistance by leveraging existing reputations. Before creating an anonymous account on Zkitter, anonymous users need to prove they also own a reputation on an existing web2 social network such as Twitter or Reddit.
Another challenge with anonymity is [Sybil attacks](https://en.wikipedia.org/wiki/Sybil_attack), where a user creates multiple accounts to spam or gain influence. Zkitter uses Interep to increase Sybil resistance by leveraging existing reputations. Before creating an anonymous account on Zkitter, anonymous users need to prove they also own a reputation on an existing web2 social network such as Twitter or Reddit.
**RLN**
Spam can be a serious problem in anonymous environments. In “real life”, or on social networks where users have persistent identities, the threat of reputational damage or banning prevents most people from openly spamming. On anonymous networks, where a user’s actions can’t be traced to their identity, we can’t know who’s spamming – so we can’t punish or ban them.  [RLN](https://mirror.xyz/privacy-scaling-explorations.eth/aKjLmLVyunELnGObrzPlbhXWu5lZI9QU-P3OuBK8mOY) (Rate Limit Nullifier) requires users to put something at stake, either financial or social, and punishes users who violate the spam rules by either slashing or banning them.
Spam can be a serious problem in anonymous environments. In "real life", or on social networks where users have persistent identities, the threat of reputational damage or banning prevents most people from openly spamming. On anonymous networks, where a user's actions can't be traced to their identity, we can't know who's spamming – so we can't punish or ban them. [RLN](https://mirror.xyz/privacy-scaling-explorations.eth/aKjLmLVyunELnGObrzPlbhXWu5lZI9QU-P3OuBK8mOY) (Rate Limit Nullifier) requires users to put something at stake, either financial or social, and punishes users who violate the spam rules by either slashing or banning them.
**Zkchat**
One of the first use cases for RLN was [“RLN Anonymous Chat”](https://github.com/zkitter/zkitterd/tree/main/lib/zk-chat-server), which later became known as zkchat, a spam resistant instant messaging application for private and anonymous communication. Zkchat powers Zkitter’s chat functionality and the zkchat project is now maintained by Zkitter.
One of the first use cases for RLN was ["RLN Anonymous Chat"](https://github.com/zkitter/zkitterd/tree/main/lib/zk-chat-server), which later became known as zkchat, a spam resistant instant messaging application for private and anonymous communication. Zkchat powers Zkitter's chat functionality and the zkchat project is now maintained by Zkitter.
## Experimenting with anonymity
> “Man is least himself when he talks in his own person.
> "Man is least himself when he talks in his own person.
>
> Give him a mask, and he will tell you the truth.”
> Give him a mask, and he will tell you the truth."
>
> \- Oscar Wilde
Zkitter is a social experiment. Philosophically, it is an experiment in whether the Oscar Wilde quote above is true. Does the option of anonymity, by separating reputation from speech, create a space for more open and honest self-expression? What would happen if the option to be anonymous was available as a default and widely considered to be a “normal” thing to do? How might the conversation change when the content of what’s being said is detached from the reputation of the person saying it?
Zkitter is a social experiment. Philosophically, it is an experiment in whether the Oscar Wilde quote above is true. Does the option of anonymity, by separating reputation from speech, create a space for more open and honest self-expression? What would happen if the option to be anonymous was available as a default and widely considered to be a "normal" thing to do? How might the conversation change when the content of what's being said is detached from the reputation of the person saying it?
As an anon or using a pseudonym, people can say what they really believe, and honest conversation is ultimately the most valuable thing for important topics like governance decisions. Because the stakes are so high, and decisions may potentially last decades or even centuries, debate must be as authentic as possible. Though [DAO](https://ethereum.org/en/dao/) governance may come to mind for most people reading this article; using anonymity, pseudonyms, or aliases to debate controversial topics is not new.
@@ -69,11 +70,11 @@ https://docs.zkitter.com/faqs/how-to-create-an-anonymous-user
Once your reputation is verified, instead of a username, your Zkitter posts will simply show your reputation tier.
When you join Zkitter, you will sign a message to generate a [new ECDSA key pair](https://docs.zkitter.com/developers/identity) and write the public key to a [smart contract](https://arbiscan.io/address/0x6b0a11f9aa5aa275f16e44e1d479a59dd00abe58) on Arbitrum. The ECDSA key pair is used to authenticate messages and recover your Zkitter identity – so you aren’t using your Ethereum account private key to sign for actions on Zkitter.
When you join Zkitter, you will sign a message to generate a [new ECDSA key pair](https://docs.zkitter.com/developers/identity) and write the public key to a [smart contract](https://arbiscan.io/address/0x6b0a11f9aa5aa275f16e44e1d479a59dd00abe58) on Arbitrum. The ECDSA key pair is used to authenticate messages and recover your Zkitter identity – so you aren't using your Ethereum account private key to sign for actions on Zkitter.
**Posting**
Posting to Zkitter will feel pretty familiar, but with some extra options. You can choose whether to post as yourself, or anonymously – even if you don’t have an anonymous account. You can decide who you want to allow replies from, as well as whether the post will appear on the global feed or only on your own. If you’ve connected your Twitter account, you can also mirror your post to Twitter.
Posting to Zkitter will feel pretty familiar, but with some extra options. You can choose whether to post as yourself, or anonymously – even if you don't have an anonymous account. You can decide who you want to allow replies from, as well as whether the post will appear on the global feed or only on your own. If you've connected your Twitter account, you can also mirror your post to Twitter.
**Chat**

11
articles/zkml-bridging-aiml-and-web3-with-zero-knowledge-proofs.md
View File

@@ -5,6 +5,7 @@ image: "/articles/zkml-bridging-aiml-and-web3-with-zero-knowledge-proofs/zkml-br
tldr: "This post was authored by [drCathieSo.eth](https://twitter.com/drCathieSo_eth) and was originally published [here](https://hackmd.io/@cathie/zkml)."
date: "2023-05-02"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/K88lOS4XegJGzMoav9K5bLuT9Zhn3Hz2KkhB3ITq-m8"
projects: ["zkml"]
---
## Introduction
@@ -36,7 +37,7 @@ These challenges have created a demand for solutions that can protect the privac
ZKPs present a promising approach to address the challenges faced by traditional ML bounties. By leveraging the power of ZKPs, ZKML offers a privacy-preserving solution with the following benefits:
1. **Model privacy**: Developers can participate in bounties without disclosing their entire model architecture and weights, protecting their intellectual property.
2. **Transparent verification**: ZKPs enable the verification of model performance without revealing the model’s internals, fostering a transparent and trustless evaluation process.
2. **Transparent verification**: ZKPs enable the verification of model performance without revealing the model's internals, fostering a transparent and trustless evaluation process.
3. **Data privacy**: ZKPs can be used to verify private data with public models or private models with public data, ensuring that sensitive information remains undisclosed.
Integrating ZKPs into the machine learning process provides a secure and privacy-preserving platform that addresses the limitations of traditional ML bounties. This not only promotes the adoption of machine learning in privacy-sensitive industries but also attracts experienced Web2 developers to explore the possibilities within the Web3 ecosystem.
@@ -53,9 +54,9 @@ keras2circom is a Python tool that transpiles TensorFlow Keras models into circo
### ZKaggle: A Decentralized Bounty Platform for Machine Learning
ZKaggle’s first version emerged as [a hackathon submission at ETHGlobal FVM Space Warp Hack](https://ethglobal.com/showcase/zkaggle-70g3b). The platform enabled decentralized computing by allowing users to share their processing power and monetize their proprietary machine learning models. With a browser-based frontend, bounty providers could upload their data to Filecoin and create computing tasks with associated rewards. Bounty hunters could browse available bounties, download data, and perform computations locally. Upon completion, they would submit a proof with hashed results on-chain for the bounty provider to review. Once approved, bounty hunters could claim their rewards by providing the pre-image of the hashed results. ZKPs were used to maintain a succinct proof of computation and enable bounty hunters to monetize private models with credibility.
ZKaggle's first version emerged as [a hackathon submission at ETHGlobal FVM Space Warp Hack](https://ethglobal.com/showcase/zkaggle-70g3b). The platform enabled decentralized computing by allowing users to share their processing power and monetize their proprietary machine learning models. With a browser-based frontend, bounty providers could upload their data to Filecoin and create computing tasks with associated rewards. Bounty hunters could browse available bounties, download data, and perform computations locally. Upon completion, they would submit a proof with hashed results on-chain for the bounty provider to review. Once approved, bounty hunters could claim their rewards by providing the pre-image of the hashed results. ZKPs were used to maintain a succinct proof of computation and enable bounty hunters to monetize private models with credibility.
[ZKaggleV2](https://github.com/socathie/ZKaggleV2) presents an improved version with enhanced features and functionality. In this version, multiple files are aggregated into a single circuit, allowing for more efficient processing. The platform also verifies the accuracy of the computations and incorporates a secure method for transferring model weights from the bounty hunter to the bounty provider using elliptic curve Diffie-Hellman (ECDH) encryption. This added layer of security ensures that only authorized parties can access and utilize the model weights, further solidifying the platform’s commitment to privacy and data protection.
[ZKaggleV2](https://github.com/socathie/ZKaggleV2) presents an improved version with enhanced features and functionality. In this version, multiple files are aggregated into a single circuit, allowing for more efficient processing. The platform also verifies the accuracy of the computations and incorporates a secure method for transferring model weights from the bounty hunter to the bounty provider using elliptic curve Diffie-Hellman (ECDH) encryption. This added layer of security ensures that only authorized parties can access and utilize the model weights, further solidifying the platform's commitment to privacy and data protection.
## Code Highlights
@@ -75,7 +76,7 @@ template Poly (n) {
}
```
**[keras2circom](https://github.com/socathie/keras2circom): Model Weights “Quantization”**
**[keras2circom](https://github.com/socathie/keras2circom): Model Weights "Quantization"**
**[keras2circom/keras2circom/circom.py](https://github.com/socathie/keras2circom/blob/main/keras2circom/circom.py)**
@@ -186,7 +187,7 @@ template encrypt1000() {
...
```
To maintain the integrity of the proof during the bounty claim process, **ZKaggleV2** incorporates a universal model weight encryption circuit. This circuit is precompiled and deployed for use across all bounties and models. The existing implementation supports models with up to 1000 weights, and any model with fewer weights can be zero-padded at the end to conform to the required size. This approach ensures a consistent and secure method of handling model weights
To maintain the integrity of the proof during the bounty claim process, **ZKaggleV2** incorporates a universal model weight encryption circuit. This circuit is precompiled and deployed for use across all bounties and models. The existing implementation supports models with up to 1000 weights, and any model with fewer weights can be zero-padded at the end to conform to the required size. This approach ensures a consistent and secure method of handling model weights
Please visit the respective repositories linked above for full implementation and usage details.

7
articles/zkopru-ceremony-final-call-and-failed-contributions.md
View File

@@ -2,9 +2,10 @@
authors: ["PSE Team"]
title: "Zkopru Ceremony: Final Call and Failed Contributions"
image: null
tldr: "We will end the ceremony on Friday. It was largely a success but we had a few cases of failed contributions. If your first run didn’t succeed you can now head back to our [website](https://zkopru.network/)_ to fix it"
tldr: "We will end the ceremony on Friday. It was largely a success but we had a few cases of failed contributions. If your first run didn't succeed you can now head back to our [website](https://zkopru.network/)_ to fix it"
date: "2022-08-26"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/X7O6_Y33NY-nNfzpV5HZRvups2qimQnQ9ef0OD1U8RY"
projects: ["zkopru"]
---
![](https://miro.medium.com/max/1400/1*_TJxTYbsHsjKY_XJQhxthA.png)
@@ -15,11 +16,11 @@ As mentioned in our [previous post](https://thore-hildebrandt.medium.com/zkopru-
## Reasons for Failed Contributions
We found three causes for failures and enabled affected accounts to do a second run on these circuits. Participants may not be aware that something went wrong in scenario 1&2 so it’s worth heading to our [website](https://zkopru.network/) to see if it allows you a second run.
We found three causes for failures and enabled affected accounts to do a second run on these circuits. Participants may not be aware that something went wrong in scenario 1&2 so it's worth heading to our [website](https://zkopru.network/) to see if it allows you a second run.
Note that the ceremony is secure as long as at least one participant was not malicious. We provide the option for a second run to make sure no one feels censored.
**1\. Conflicting Contributions**We found that most cases occurred during initial periods of high traffic when two or more contributors joined at around the same time. The rate of contribution slowed after that, and we deployed a fix. A contributor may have failures in one or more circuits, but have successful contributions in others. Only the failed contributions have been reset to allow re-run. Each contribution builds on the latest verified contribution, but in this case, both contributors built on the same one. So the contribution looks valid but doesn’t appear in the verification transcript. Similar to an uncle block in Ethereum.
**1\. Conflicting Contributions**We found that most cases occurred during initial periods of high traffic when two or more contributors joined at around the same time. The rate of contribution slowed after that, and we deployed a fix. A contributor may have failures in one or more circuits, but have successful contributions in others. Only the failed contributions have been reset to allow re-run. Each contribution builds on the latest verified contribution, but in this case, both contributors built on the same one. So the contribution looks valid but doesn't appear in the verification transcript. Similar to an uncle block in Ethereum.
**2\. Chaining from 0**In a small number of cases a contributor chained from contribution 0, effectively restarting the chain. These cases have also been identified and reset. The code now has a sanity check to prevent this from occurring.

31
articles/zkopru-on-testnet-privacy-scaling-explorations.md
View File

@@ -5,6 +5,7 @@ image: null
tldr: "Exciting news! ZKOPRU is now live on the Görli testnet. We show you how to use it."
date: "2022-08-26"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/EB0KcMY0k9ucN8iQSBeOYksoupDYRBQ4ZffhRt477FE"
projects: ["zkopru"]
---
Originally published on Nov 30, 2021:
@@ -17,35 +18,35 @@ After many months of hard work we are excited to announce ZKOPRU is live on the
## ZKOPRU tl;dr
We’ll give a very quick overview here, but if you don’t know what ZKOPRU is or need a reminder, we highly recommend reading our previous post [ZKOPRU Wat Y & Wen](https://medium.com/privacy-scaling-explorations/ZKOPRU-wat-y-wen-f5026903cf39) before trying out the wallet.
We'll give a very quick overview here, but if you don't know what ZKOPRU is or need a reminder, we highly recommend reading our previous post [ZKOPRU Wat Y & Wen](https://medium.com/privacy-scaling-explorations/ZKOPRU-wat-y-wen-f5026903cf39) before trying out the wallet.
ZKOPRU is an [optimistic rollup](https://ethereum.org/en/developers/docs/scaling/layer-2-rollups/#optimistic-rollups) that uses zero knowledge proofs to make individual transfers private. Similar to Ethereum’s miners or validators, rollups have coordinators that receive transactions, calculate the new state and submit data to Ethereum.
ZKOPRU is an [optimistic rollup](https://ethereum.org/en/developers/docs/scaling/layer-2-rollups/#optimistic-rollups) that uses zero knowledge proofs to make individual transfers private. Similar to Ethereum's miners or validators, rollups have coordinators that receive transactions, calculate the new state and submit data to Ethereum.
ZKOPRU currently supports deposit, transfer and withdrawal of ETH and ERC-20 tokens (NFTs coming soon™). For the most part these functions work similarly to their layer 1 counterparts, but there are a few key differences from what you might be used to:
- Although the initial deposit to your ZKOPRU wallet will be visible as a transaction on Ethereum, any subsequent transactions will only be visible to you and the recipient.
- Rollups commit only small amounts of data to the main chain, and coordinators can submit transactions in batches, so the price per transaction is drastically lower.
- ZKOPRU allows you to deposit multiple assets (ETH and another token) at the same time.
- ZKOPRU addresses are \*not\* the same as Ethereum addresses. When you need to receive assets to your ZKOPRU account, you’ll use a ZKOPRU address generated from your connected Ethereum address.
- Rollups have a 7 day delay for withdrawals back to the main chain (we’re working on an instant withdrawal mechanism so users can get around this delay).
- ZKOPRU addresses are _not_ the same as Ethereum addresses. When you need to receive assets to your ZKOPRU account, you'll use a ZKOPRU address generated from your connected Ethereum address.
- Rollups have a 7 day delay for withdrawals back to the main chain (we're working on an instant withdrawal mechanism so users can get around this delay).
## How to use ZKOPRU
## Setup
To get started with ZKOPRU, you’ll need the Metamask plugin. Since it’s still on testnet you’ll also need some GörliETH, which you can get from the [Görli Faucet](https://faucet.goerli.mudit.blog/) or the [Paradigm MultiFaucet](https://faucet.paradigm.xyz/).
To get started with ZKOPRU, you'll need the Metamask plugin. Since it's still on testnet you'll also need some GörliETH, which you can get from the [Görli Faucet](https://faucet.goerli.mudit.blog/) or the [Paradigm MultiFaucet](https://faucet.paradigm.xyz/).
> Please note that from here on, when we say ETH we are referring to GörliETH. Don’t send mainnet ETH to your ZKOPRU wallet yet!
> Please note that from here on, when we say ETH we are referring to GörliETH. Don't send mainnet ETH to your ZKOPRU wallet yet!
Once you’ve got your ETH, make sure MetaMask is connected to the Görli testnet and head to the ZKOPRU [wallet](https://zkopru.network/).
Once you've got your ETH, make sure MetaMask is connected to the Görli testnet and head to the ZKOPRU [wallet](https://zkopru.network/).
You’ll need to connect an Ethereum account using MetaMask. Select the account you want to use and click _Next_, then _Connect_. You’ll see a popup asking your permission to sync — the ZKOPRU wallet runs a client in the browser which needs to sync with the ZKOPRU network. MetaMask will prompt you to sign to unlock your ZKOPRU account and start the sync.
You'll need to connect an Ethereum account using MetaMask. Select the account you want to use and click _Next_, then _Connect_. You'll see a popup asking your permission to sync — the ZKOPRU wallet runs a client in the browser which needs to sync with the ZKOPRU network. MetaMask will prompt you to sign to unlock your ZKOPRU account and start the sync.
![](https://miro.medium.com/max/1400/0*TWLX-_TdNK0uWoR-)
Syncing Zkopru
The sync process could take a few minutes. Wait until the bottom left shows \*Fully synced 100%. \*If the site is blurred, double check if Metamask is connected to Görli. If you weren’t connected to Görli you may need to refresh the page in order to start the sync.
The sync process could take a few minutes. Wait until the bottom left shows *Fully synced 100%. *If the site is blurred, double check if Metamask is connected to Görli. If you weren't connected to Görli you may need to refresh the page in order to start the sync.
![](https://miro.medium.com/max/1400/1*bG__U_qysCQ9xBqgrE2FtQ.png)
@@ -53,7 +54,7 @@ ZKOPRU main page
## Deposit
In order to start transacting on ZKOPRU, you’ll need to deposit your ETH from Görli into ZKOPRU On the left side of the main page, click _Deposit_. You’ll see options to deposit ETH, ERC20s or both at the same time. The deposit transaction will require some ETH for the L1 transfer and an additional fee for the coordinator. We recommend you deposit at least 0.01ETH — you’ll also need it to pay coordinator fees for any ZKOPRU transactions. After confirming your transaction in MetaMask, head to the _History_ tab to check the deposit status.
In order to start transacting on ZKOPRU, you'll need to deposit your ETH from Görli into ZKOPRU On the left side of the main page, click _Deposit_. You'll see options to deposit ETH, ERC20s or both at the same time. The deposit transaction will require some ETH for the L1 transfer and an additional fee for the coordinator. We recommend you deposit at least 0.01ETH — you'll also need it to pay coordinator fees for any ZKOPRU transactions. After confirming your transaction in MetaMask, head to the _History_ tab to check the deposit status.
![](https://miro.medium.com/max/1400/1*LY_SezdWuD4vTCsZaOYIkw.png)
@@ -61,7 +62,7 @@ Depositing
## Transfer (Send & Receive)
In order to make a private transfer on ZKOPRU, go to _Send,_ on the main page, enter the recipient address, select the asset and amount you want to send and enter the fee for the coordinator. Remember that the recipient’s ZKOPRU address is different from the Ethereum address — the recipient can generate it by clicking _Receive_ on the ZKOPRU main page, then copy it to send to you.
In order to make a private transfer on ZKOPRU, go to _Send,_ on the main page, enter the recipient address, select the asset and amount you want to send and enter the fee for the coordinator. Remember that the recipient's ZKOPRU address is different from the Ethereum address — the recipient can generate it by clicking _Receive_ on the ZKOPRU main page, then copy it to send to you.
![](https://miro.medium.com/max/1400/0*34CuL1JkOPxxBuYx)
@@ -77,19 +78,19 @@ After the transfer you will see something like this in the _My Wallet_ section:
![](https://miro.medium.com/max/634/0*Vz3tHJi4T7GddChn)
This means that your available balance is currently locked until the transfer succeeds. ZKOPRU, like Bitcoin, uses the UTXO model and you can see your notes’ info by hovering over the “\*i” \*next to your balance.
This means that your available balance is currently locked until the transfer succeeds. ZKOPRU, like Bitcoin, uses the UTXO model and you can see your notes' info by hovering over the "i" next to your balance.
## Withdraw
If you want your assets back on Görli, you’ll need to withdraw them from ZKOPRU. Head to _Withdraw_ on the main page, select the asset you want to withdraw and enter the amount as well as the fee for the coordinator. The withdrawal will be initiated once the coordinator has enough transactions lined up to make submission of the batch economical (this can be a few hours).
If you want your assets back on Görli, you'll need to withdraw them from ZKOPRU. Head to _Withdraw_ on the main page, select the asset you want to withdraw and enter the amount as well as the fee for the coordinator. The withdrawal will be initiated once the coordinator has enough transactions lined up to make submission of the batch economical (this can be a few hours).
Unlike a transfer, you won’t be able to meaningfully speed up the withdrawal via a higher transaction fee. ZKOPRU, like other optimistic rollups, requires a 7 day delay period for withdrawals. So even if you pay enough to incentivize the coordinator to submit the batch a few minutes sooner, you’ll still have to wait 7 days for your assets to be available. This delay serves an important security function, but it’s a UX annoyance — we’re also working on an instant withdrawal mechanism so you’ll have options to get around the withdrawal delay in the future.
Unlike a transfer, you won't be able to meaningfully speed up the withdrawal via a higher transaction fee. ZKOPRU, like other optimistic rollups, requires a 7 day delay period for withdrawals. So even if you pay enough to incentivize the coordinator to submit the batch a few minutes sooner, you'll still have to wait 7 days for your assets to be available. This delay serves an important security function, but it's a UX annoyance — we're also working on an instant withdrawal mechanism so you'll have options to get around the withdrawal delay in the future.
![](https://miro.medium.com/max/1400/0*Jdkh8xVV1w2s3TjF)
## UI Research
Rachel, our awesome designer, has conducted user acceptance testing with users who don’t work in crypto. Users with varying levels of crypto knowledge were asked to complete tasks like adding and withdrawing assets, and describe their experience and impressions. It was especially interesting to hear our users’ first reactions to features we’re excited about, like multi-asset deposits — a good reminder that a new feature is also a new experience for a user, and it’s our job to get them oriented so they can be as excited about it as we are.
Rachel, our awesome designer, has conducted user acceptance testing with users who don't work in crypto. Users with varying levels of crypto knowledge were asked to complete tasks like adding and withdrawing assets, and describe their experience and impressions. It was especially interesting to hear our users' first reactions to features we're excited about, like multi-asset deposits — a good reminder that a new feature is also a new experience for a user, and it's our job to get them oriented so they can be as excited about it as we are.
You can find the report [here](https://github.com/zkopru-network/resources/tree/main/ui-ux/wallet). We hope it will be useful for others working on similar design challenges!

15
articles/zkopru-trusted-setup-ceremony.md
View File

@@ -2,9 +2,10 @@
authors: ["PSE Team"]
title: "Zkopru Trusted Setup Ceremony"
image: null
tldr: "Use this link to participate in the trusted setup (on a desktop, mobile isn’t recommended): [https://mpc.zkopru.network/](https://mpc.zkopru.network/)"
tldr: "Use this link to participate in the trusted setup (on a desktop, mobile isn't recommended): [https://mpc.zkopru.network/](https://mpc.zkopru.network/)"
date: "2022-08-26"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/a2Ut19fwRGNJoCd-IoQadyn3sUMRgGNSfRgHEc4iGhw"
projects: ["zkopru"]
---
_Originally posted on Mar 26, 2021:_
@@ -15,7 +16,7 @@ We are excited to announce that the trusted setup ceremony for Zkopru has been l
![](https://miro.medium.com/max/1400/1*CR-P2g6fjWIFtgmqtUdUvA.png)
Zkopru, pronounced \[zikopru\], is short for zk-optimistic-rollup. It’s a novel layer-2 scaling solution that allows for cheap private transactions. It uses optimistic rollup to scale and zk-SNARKs for privacy. Zkopru supports private transfers and private atomic swaps between ETH, ERC20, ERC721 at low cost. It also provides instant withdrawals via the pay-in-advance feature and compliance compatibility using spending key and viewing keys. See Wanseob [presenting](https://www.youtube.com/watch?v=443EZ0ndaio) the project on zkSummit and check out the Zkopru [website](https://zkopru.network/). You can also dive deeper in the original [ethresear.ch](https://ethresear.ch/t/zkopru-zk-optimistic-rollup-for-private-transactions/7717) post.
Zkopru, pronounced \[zikopru\], is short for zk-optimistic-rollup. It's a novel layer-2 scaling solution that allows for cheap private transactions. It uses optimistic rollup to scale and zk-SNARKs for privacy. Zkopru supports private transfers and private atomic swaps between ETH, ERC20, ERC721 at low cost. It also provides instant withdrawals via the pay-in-advance feature and compliance compatibility using spending key and viewing keys. See Wanseob [presenting](https://www.youtube.com/watch?v=443EZ0ndaio) the project on zkSummit and check out the Zkopru [website](https://zkopru.network/). You can also dive deeper in the original [ethresear.ch](https://ethresear.ch/t/zkopru-zk-optimistic-rollup-for-private-transactions/7717) post.
We have just completed an audit with Least Authority and the next step is to conduct a trusted setup.
@@ -25,7 +26,7 @@ Zkopru relies on a number of different SNARKs and each requires a trusted setup
## How exactly does the setup work?
Our trusted setup is done in 2 steps. The first step is already completed and is called Perpetual Powers of Tau. It’s an ongoing effort led by Wei Jie of the Ethereum Foundation. We are using the output of Iden3’s [selection process](https://blog.hermez.io/hermez-zero-knowledge-proofs/) based on the [54th](https://github.com/weijiekoh/perpetualpowersoftau) Perpetual Powers of Tau contribution.
Our trusted setup is done in 2 steps. The first step is already completed and is called Perpetual Powers of Tau. It's an ongoing effort led by Wei Jie of the Ethereum Foundation. We are using the output of Iden3's [selection process](https://blog.hermez.io/hermez-zero-knowledge-proofs/) based on the [54th](https://github.com/weijiekoh/perpetualpowersoftau) Perpetual Powers of Tau contribution.
The second step is called Phase 2 and is circuit-specific, so it should be done separately for each different SNARK. This is what you participate in here.
@@ -40,7 +41,7 @@ It is very simple!
Click Login
3\. Click on “Launch Ceremony”.
3\. Click on "Launch Ceremony".
![](https://miro.medium.com/max/942/1*gYzc5NI17iFZ1FK3wLIqSQ.png)
@@ -50,7 +51,7 @@ Click Launch Ceremony
![](https://miro.medium.com/max/1352/1*_XiuefrTja0DCjTrz9PhPA.png)
5\. While the ceremony is running please don’t close or refresh the site (you can switch browser tabs) otherwise your contribution will be aborted. The process should take 30–50 mins. Once the ceremony is completed you can tweet about your participation to spread the word and make Zkopru more secure.
5\. While the ceremony is running please don't close or refresh the site (you can switch browser tabs) otherwise your contribution will be aborted. The process should take 30–50 mins. Once the ceremony is completed you can tweet about your participation to spread the word and make Zkopru more secure.
![](https://miro.medium.com/max/1216/1*BDUciwbSPkjDo-LqdLEzNw.png)
@@ -58,7 +59,7 @@ Wait until you see this
## Troubleshooting
If the twitter button doesnt show up in your browser you can try this: Refresh > Menu >Logout, then Login, and launch again. It won’t run any circuits, but it might pick up your hashes and allow you to tweet.
If the twitter button doesnt show up in your browser you can try this: Refresh > Menu >Logout, then Login, and launch again. It won't run any circuits, but it might pick up your hashes and allow you to tweet.
Your browser might go blank, you can just refresh and restart, it will pick up where you left.
@@ -76,7 +77,7 @@ The ceremony will run for at least 2 weeks from now on. Once we have enough cont
## Want to learn more?
Source code for the ceremony is available [here](https://github.com/glamperd/setup-mpc-ui#verifying-the-ceremony-files). Contribution computation is performed in the browser. The computation code is compiled to WASM, based on the repo above, a fork of Kobi Gurkan’s phase 2 computation module which has been [audited](https://research.nccgroup.com/2020/06/24/security-considerations-of-zk-snark-parameter-multi-party-computation/).We made these unaudited changes:
Source code for the ceremony is available [here](https://github.com/glamperd/setup-mpc-ui#verifying-the-ceremony-files). Contribution computation is performed in the browser. The computation code is compiled to WASM, based on the repo above, a fork of Kobi Gurkan's phase 2 computation module which has been [audited](https://research.nccgroup.com/2020/06/24/security-considerations-of-zk-snark-parameter-multi-party-computation/).We made these unaudited changes:
\- For the WASM build, return the result hash to the caller.- Also for the WASM build: Progress is reported by invoking a callback.- Corrected errors in progress report count totals.

3
articles/zkopru-trusted-setup-completed-privacy-scaling-explorations.md
View File

@@ -5,6 +5,7 @@ image: null
tldr: "The public participation part of our ceremony has finished, we provide verification details, stats and announce a random beacon"
date: "2022-08-26"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/dQec_qe4VOcKoVH9OH42Ef9WuSqyAJ6S40jRrZ_Mw7g"
projects: ["zkopru"]
---
Originally published on Apr 21, 2021:
@@ -17,7 +18,7 @@ The public participation part of our ceremony is now complete! It ran for 22 day
## **Statistics**
By some metrics our trusted setup was the largest ever conducted, we had 5147 contributions across the 16 circuits albeit “only” by 369 individuals. A total computation time of 190,5h (7days) went into the ceremony and the average participant spent 36 minutes. We also had quite number of failed contributions and therefore [gave affected participants an additional week](https://thore-hildebrandt.medium.com/zkopru-ceremony-final-call-and-failed-contributions-5a787cb4885e) to do a second run.
By some metrics our trusted setup was the largest ever conducted, we had 5147 contributions across the 16 circuits albeit "only" by 369 individuals. A total computation time of 190,5h (7days) went into the ceremony and the average participant spent 36 minutes. We also had quite number of failed contributions and therefore [gave affected participants an additional week](https://thore-hildebrandt.medium.com/zkopru-ceremony-final-call-and-failed-contributions-5a787cb4885e) to do a second run.
![](https://miro.medium.com/max/916/1*FZtgLoyw52l_fC-YGxyX8g.png)

23
articles/zkopru-wat-y-wen-privacy-scaling-explorations.md
View File

@@ -2,9 +2,10 @@
authors: ["PSE Team"]
title: "Zkopru: Wat, Y & Wen - Privacy & Scaling Explorations"
image: null
tldr: "Zkopru is almost ready, we explain what it is and why it’s awesome. We also announce a date for the testnet."
tldr: "Zkopru is almost ready, we explain what it is and why it's awesome. We also announce a date for the testnet."
date: "2022-08-26"
canonical: "https://mirror.xyz/privacy-scaling-explorations.eth/kfuuBPtGtDjl_J2wBq-jrtyURGLmQpUhZfDTuZChEy8"
projects: ["zkopru"]
---
Originally published on Aug 10, 2021:
@@ -13,19 +14,19 @@ Originally published on Aug 10, 2021:
The Privacy and Scaling Explorations Team works to bridge the gap between cutting-edge research in Zero-Knowledge Proofs (ZKP), and application development on Ethereum.
One of our recent focus areas has been [zkopru](https://zkopru.network/) (zero knowledge optimistic rollup), a new protocol for gas-efficient private transactions. We completed a [trusted setup](https://medium.com/privacy-scaling-explorations/zkopru-trusted-setup-completed-92e614ba44ef) in April and since then have been heads down working on bringing it to completion. We are in the final stages of completing the web wallet and stress testing the system. A second audit is also on its way. With this post we want to give a high level overview of Zkopru’s features and what will be happening in the upcoming weeks as Zkopru moves to public testnet and mainnet.
One of our recent focus areas has been [zkopru](https://zkopru.network/) (zero knowledge optimistic rollup), a new protocol for gas-efficient private transactions. We completed a [trusted setup](https://medium.com/privacy-scaling-explorations/zkopru-trusted-setup-completed-92e614ba44ef) in April and since then have been heads down working on bringing it to completion. We are in the final stages of completing the web wallet and stress testing the system. A second audit is also on its way. With this post we want to give a high level overview of Zkopru's features and what will be happening in the upcoming weeks as Zkopru moves to public testnet and mainnet.
This post assumes that you are generally familiar with Ethereum, layer 2, and the basics of zero knowledge proofs.
![](https://miro.medium.com/max/946/1*R0tVYYlbZEBkWBWeoSb3JQ.png)
Zkopru stands for zk (zero knowledge) opru (optimistic rollup). You might have heard about zero knowledge proofs, zk rollups and optimistic rollups, so what is a zk-optimistic rollup? Let’s start with the basics.
Zkopru stands for zk (zero knowledge) opru (optimistic rollup). You might have heard about zero knowledge proofs, zk rollups and optimistic rollups, so what is a zk-optimistic rollup? Let's start with the basics.
\*\*What is a Zero Knowledge Proof (zkp)?\*\*Zero knowledge proofs such as zkSNARK allow verifying the correctness of computations without having to execute them and without revealing their inputs. Zkps can therefore be used for scaling and privacy. Zkopru uses zkps to make transactions private. [Zcash](https://z.cash/), [AZTEK network](https://aztec.network/) and [tornado.cash](https://tornado.cash/) are other examples where zkps are used for privacy on blockchains.
\*\*What’s an optimistic rollup?\*\*Optimistic rollups sit in parallel to the main Ethereum chain on layer 2. They can offer improvements in scalability because they don’t do any computation on-chain by default. Instead, after a transaction, they propose only a stateroot to mainnet and transaction data is stored as calldata, which doesn’t grow the state and therefore has reduced gas cost. As modifying the state is the slow, expensive part of using Ethereum, optimistic rollups can offer up to 10–100x improvements in scalability depending on the transaction. See [here](https://ethereum.org/en/developers/docs/scaling/layer-2-rollups/) for more information on optimistic rollups. Instead of miners, rollups have coordinators that receive transactions, calculate the new state and submit data to Ethereum.
\*\*What's an optimistic rollup?\*\*Optimistic rollups sit in parallel to the main Ethereum chain on layer 2. They can offer improvements in scalability because they don't do any computation on-chain by default. Instead, after a transaction, they propose only a stateroot to mainnet and transaction data is stored as calldata, which doesn't grow the state and therefore has reduced gas cost. As modifying the state is the slow, expensive part of using Ethereum, optimistic rollups can offer up to 10–100x improvements in scalability depending on the transaction. See [here](https://ethereum.org/en/developers/docs/scaling/layer-2-rollups/) for more information on optimistic rollups. Instead of miners, rollups have coordinators that receive transactions, calculate the new state and submit data to Ethereum.
\*\*What is Zk + opru\*\*Zkopru is an optimistic UTXO based rollup. There is also another type of rollup called zk-rollup, which uses zero-knowledge proofs to verify the correct computation of the next state when new transactions are applied — but Zkopru is _not_ a zk-rollup. Whereas zk-rollups use the “zk” part to create a validity proof for the rollup state transition, Zkopru uses it to make individual transfers private.
\*\*What is Zk + opru\*\*Zkopru is an optimistic UTXO based rollup. There is also another type of rollup called zk-rollup, which uses zero-knowledge proofs to verify the correct computation of the next state when new transactions are applied — but Zkopru is _not_ a zk-rollup. Whereas zk-rollups use the "zk" part to create a validity proof for the rollup state transition, Zkopru uses it to make individual transfers private.
This concept has significant advantages in terms of gas consumption. For zk-transactions directly on the main Ethereum chain, it would be necessary to use a SNARK-friendly hash function to construct a Merkle tree, which is very expensive. Using an optimistic rollup, we can update the SNARK friendly Merkle tree at a low cost off chain. As a result, this protocol consumes about 8,800 gas per private transfer (a normal ETH transfer on Ethereum costs 21,000 Gas) 🎊.
@@ -33,19 +34,19 @@ This concept has significant advantages in terms of gas consumption. For zk-tran
![](https://miro.medium.com/max/1062/1*X17IFo5Z-f-lR_xPSsdxww.png)
Next, let’s look at the most important user facing functionalities of Zkopru. Users will interact with the system via a web wallet to carry out deposits, withdrawals, transfers and swaps on L2. We’ll give an overview of the UX for each of these functions below; for more detailed technical information check out our [documentation](https://docs.zkopru.network/) and [github](https://github.com/wanseob/zkopru) .
Next, let's look at the most important user facing functionalities of Zkopru. Users will interact with the system via a web wallet to carry out deposits, withdrawals, transfers and swaps on L2. We'll give an overview of the UX for each of these functions below; for more detailed technical information check out our [documentation](https://docs.zkopru.network/) and [github](https://github.com/wanseob/zkopru) .
**Deposit:** The user is able to deposit Ether, ERC-20 or NFTs to the Zkopru contracts on L1 (Ethereum) through the Zkopru user interface. After depositing the user will be able to view and transfer their assets on L2, represented behind the scenes as UTXOs. .
**Transfer:** After deposit the assets are still linked to the user’s account but the private transfer feature can be used to break the link. For a transfer, the sender needs the Zkopru address of the recipient. This is not an Ethereum address, but a user can use their Ethereum private key to generate a corresponding address in the Zkopru wallet. The wallet generates a zkp that proves the integrity of the system after the transfer without revealing any details and sends the transaction to the Zkopru coordinator. After the coordinator has included the transaction (for a fee) the funds are considered private.
**Transfer:** After deposit the assets are still linked to the user's account but the private transfer feature can be used to break the link. For a transfer, the sender needs the Zkopru address of the recipient. This is not an Ethereum address, but a user can use their Ethereum private key to generate a corresponding address in the Zkopru wallet. The wallet generates a zkp that proves the integrity of the system after the transfer without revealing any details and sends the transaction to the Zkopru coordinator. After the coordinator has included the transaction (for a fee) the funds are considered private.
**Withdraw:** A user that wants to move their assets back from L2 (Zkopru) to L1 (Ethereum) can use the withdraw function of the wallet. Transaction details will need to be revealed for this action, so the address and amount withdrawn are not private anymore. Like other optimistic rollups, Zkopru requires the user to wait for 7 days for withdrawals to be finalized. Anyone who doesn’t want to wait that long can use the instant withdrawal mechanism.
**Withdraw:** A user that wants to move their assets back from L2 (Zkopru) to L1 (Ethereum) can use the withdraw function of the wallet. Transaction details will need to be revealed for this action, so the address and amount withdrawn are not private anymore. Like other optimistic rollups, Zkopru requires the user to wait for 7 days for withdrawals to be finalized. Anyone who doesn't want to wait that long can use the instant withdrawal mechanism.
\*\*Instant withdraw:\*\*If a user wants to make an instant withdrawal, they can make a request to another user to advance the funds in exchange for a fee. The user who advances the funds keeps the fee but takes on any risk of the transaction being invalidated by a fraud proof.
\*\*Atomic Swap:\*\*Zkopru supports atomic swaps. Two users can ask the coordinator to facilitate the exchange of their two assets, and if the coordinator doesn’t do so they will be slashed. This service will have its own site. At the moment it is difficult to find matching orders efficiently and privately. We’re working on a solution that allows for private order matching.
\*\*Atomic Swap:\*\*Zkopru supports atomic swaps. Two users can ask the coordinator to facilitate the exchange of their two assets, and if the coordinator doesn't do so they will be slashed. This service will have its own site. At the moment it is difficult to find matching orders efficiently and privately. We're working on a solution that allows for private order matching.
\*\*Cost:\*\*Users can deposit and withdraw ETH, ERC20 and NFTs. It’s also possible to combine deposits of NFTs and ERC20s with ETH in the same transaction. The USD values below are the costs incurred on Ethereum assuming a gas price of 25 gwei and an ETH price of USD $2,500.
\*\*Cost:\*\*Users can deposit and withdraw ETH, ERC20 and NFTs. It's also possible to combine deposits of NFTs and ERC20s with ETH in the same transaction. The USD values below are the costs incurred on Ethereum assuming a gas price of 25 gwei and an ETH price of USD $2,500.
![](https://miro.medium.com/max/1400/1*zEx3-wuS2th3H3Al5QjkUw.png)
@@ -59,7 +60,7 @@ On top of the costs listed in the table above, the coordinator has to pay a fina
![](https://miro.medium.com/max/1080/1*wkAXunWTJaW0FOldy4nV1w.png)
In about 2 weeks the Zkopru contracts will be deployed on testnet, the wallet UI will be released and we’ll publish more documentation explaining how to interact with the system. If there are no major issues on testnet for another ~2 weeks we will announce the release of the mainnet contracts. A second audit is also expected to be concluded by that time.
In about 2 weeks the Zkopru contracts will be deployed on testnet, the wallet UI will be released and we'll publish more documentation explaining how to interact with the system. If there are no major issues on testnet for another ~2 weeks we will announce the release of the mainnet contracts. A second audit is also expected to be concluded by that time.
## Conclusion

34
articles_with_projects.txt Normal file
View File

@@ -0,0 +1,34 @@
articles//README.md
articles//a-technical-introduction-to-arbitrums-optimistic-rollup.md
articles//a-technical-introduction-to-maci-10-privacy-scaling-explorations.md
articles//advancing-anon-aadhaar-whats-new-in-v100.md
articles//announcing-anon-aadhaar.md
articles//announcing-maci-v111.md
articles//announcing-the-pse-grants-program.md
articles//anonklub-reflections-on-our-journey-in-privacy-preserving-solutions.md
articles//bandada-is-live.md
articles//beyond-zero-knowledge-whats-next-in-programmable-cryptography.md
articles//building-a-zk-proof-of-solvency-for-uniswap-v3-lp-nfts.md
articles//certificate-transparency-using-newtonpir.md
articles//circom-mpc-tldr-and-retrospective.md
articles//code-optimizations-in-the-landscape-of-post-quantum-cryptography.md
articles//rsa-verification-circuit-in-halo2-and-its-applications.md
articles//secure-multi-party-computation.md
articles//semaphore-v3-announcement.md
articles//tlsnotary-updates.md
articles//unirep-protocol.md
articles//unleashing-potential-introducing-the-pse-core-program.md
articles//web2-nullifiers-using-voprf.md
articles//why-we-cant-build-perfectly-secure-multi-party-applications-yet.md
articles//zero-to-start-applied-fully-homomorphic-encryption-fhe-part-1.md
articles//zero-to-start-applied-fully-homomorphic-encryption-fhe-part-2.md
articles//zkevm-community-edition-part-1-introduction.md
articles//zkevm-community-edition-part-2-components.md
articles//zkevm-community-edition-part-3-logic-and-structure.md
articles//zkitter-an-anon-friendly-social-network.md
articles//zkml-bridging-aiml-and-web3-with-zero-knowledge-proofs.md
articles//zkopru-ceremony-final-call-and-failed-contributions.md
articles//zkopru-on-testnet-privacy-scaling-explorations.md
articles//zkopru-trusted-setup-ceremony.md
articles//zkopru-trusted-setup-completed-privacy-scaling-explorations.md
articles//zkopru-wat-y-wen-privacy-scaling-explorations.md

121
components/blog/project-blog-articles.tsx Normal file
View File

@@ -0,0 +1,121 @@
"use client"
import { LocaleTypes } from "@/app/i18n/settings"
import { ProjectInterface } from "@/lib/types"
import { AppContent } from "../ui/app-content"
import { Article } from "@/lib/blog"
import Link from "next/link"
import { BlogArticleCard } from "./blog-article-card"
import { useEffect, useState } from "react"
async function fetchArticles(project: string) {
const response = await fetch(`/api/articles?project=${project}`)
const data = await response.json()
return data.articles
}
function ArticlesGrid({
articles,
lang,
}: {
articles: Article[]
lang: string
}) {
return (
<div className="grid grid-cols-1 lg:grid-cols-4 gap-8">
{articles.length === 0 && (
<p className="col-span-full text-center text-gray-500">
No articles found for this project.
</p>
)}
{articles.map(
({ id, title, image, tldr = "", date, authors, content }: Article) => {
const url = `/${lang}/blog/${id}`
return (
<div key={id} className="flex h-full">
<Link
className="flex-1 w-full hover:opacity-90 transition-opacity duration-300 rounded-xl overflow-hidden bg-white shadow-sm border border-slate-900/10"
href={url}
rel="noreferrer"
>
<BlogArticleCard
id={id}
image={image}
title={title}
date={date}
authors={authors}
content={content}
/>
</Link>
</div>
)
}
)}
</div>
)
}
export const ProjectBlogArticles = ({
project,
lang,
}: {
project: ProjectInterface
lang: LocaleTypes
}) => {
const [articles, setArticles] = useState<Article[]>([])
const [loading, setLoading] = useState(true)
useEffect(() => {
const getArticles = async () => {
try {
const data = await fetchArticles(project.id)
setArticles(data)
} catch (error) {
console.error("Error fetching articles:", error)
} finally {
setLoading(false)
}
}
getArticles()
}, [project.id])
// Show loading state
if (loading) {
return (
<div className="py-10 lg:py-16 w-full">
<AppContent>
<div className="flex flex-col gap-10">
<h3 className="text-base font-bold font-sans text-center uppercase tracking-[3.36px]">
Related articles
</h3>
<div className="grid grid-cols-1 lg:grid-cols-4 gap-8">
{[1, 2, 3].map((i) => (
<div key={i} className="flex h-full animate-pulse">
<div className="flex-1 w-full rounded-xl overflow-hidden bg-slate-200 h-64"></div>
</div>
))}
</div>
</div>
</AppContent>
</div>
)
}
if (articles.length === 0 && !loading) {
return null
}
return (
<div className="py-10 lg:py-16 w-full">
<AppContent>
<div className="flex flex-col gap-10">
<h3 className="text-base font-bold font-sans text-center uppercase tracking-[3.36px]">
Related articles
</h3>
<ArticlesGrid articles={articles} lang={lang} />
</div>
</AppContent>
</div>
)
}

17
lib/blog.ts
View File

@@ -16,13 +16,18 @@ export interface Article {
hash?: string
canonical?: string
tags?: string[]
projects?: string[]
}
const articlesDirectory = path.join(process.cwd(), "articles")
// Get all articles from /articles
export function getArticles(options?: { limit?: number; tag?: string }) {
const { limit = 1000, tag } = options ?? {}
export function getArticles(options?: {
limit?: number
tag?: string
project?: string
}) {
const { limit = 1000, tag, project } = options ?? {}
// Get file names under /articles
const fileNames = fs.readdirSync(articlesDirectory)
const allArticlesData = fileNames.map((fileName: string) => {
@@ -91,6 +96,14 @@ export function getArticles(options?: { limit?: number; tag?: string }) {
)
}
// Filter by project if provided
if (project) {
filteredArticles = filteredArticles.filter(
(article) =>
Array.isArray(article.projects) && article.projects.includes(project)
)
}
// Sort posts by date
return filteredArticles
.sort((a, b) => {