Contributed by alxkzmn, sinu, 0xvikasrushi Ethereum users are forced to choose between privacy (running their own node) and practicality (using RPC providers), creating a trade-off that undermines Ethereum's principles of decentralization and user sovereignty. This document aims to explore possible ways to narrow this gap. Problem Reconstruction of subject identity (physical or onchain) from Ethereum state requests. Rationale Most users access Ethereum through RPC providers rather than running their own nodes, creating a fundamental privacy vulnerability. While running a personal node would solve this issue, it remains costly and impractical for standard users, especially on resource-constrained devices like smartphones. Local storage of Ethereum's World State is prohibitively expensive for consumer hardware.

Ethereum presents several privacy challenges. One of them is that read operations can expose user data and behavior patterns, potentially leading to deanonymization. In this scenario, users are safe only if they run their own node or host the data locally. Otherwise, all requests go through third parties, such as relayers, providers, and wallets that process IP addresses. Private Information Retrieval provides a solution, enabling users to request information from a server using an obfuscated query, ensuring the server doesn't know which item was retrieved. Recent progress makes PIR an option for practical deployment in some scenarios. Query privacy can be achieved with bandwidth costs on the order of kilobytes and server throughput capable of handling medium-sized databases. Introduction Information in Ethereum and privacy solutions such as Semaphore use Merkle Trees to store its data, since this allows efficient verification with Merkle proofs. Read operations, like checking an account balance or getting sibling nodes to prove group membership, require specifying a target like an account address or a specific identity. This exposes the user's intents to the node or the server hosting the data and any other network observer. Merkle trees can become prohibitively large for local storage, particularly on resource-constrained devices like smartphones. A tree with $2^{20}$ (~1 million) 32-byte leaves is 32 MB, and scales to 1 GB for $2^{25}$ (~33 million) leaves. Having the user download 1 GB every time they need to create a proof (and the tree is updated) is not practical. Being synced with the server for every update would be a high network cost, and not possible in many scenarios.

Ethereum's FOCIL (Fork-choice enforced Inclusion Lists) mechanism aims to enhance censorship resistance by allowing committees of validators to force-include transactions in blocks. However, the current design exposes validator identities, creating potential vulnerabilities to targeted attacks. The zkFOCIL approach proposes using privacy-enhancing cryptography to protect validator identities while maintaining FOCIL functionality. Goal Explore practical approaches for implementing privacy-preserving inclusion lists using zero-knowledge proofs, with a focus on SNARK-based Linkable Ring Signatures. Objectives Core objectives Research SNARK-based approaches for implementing Linkable Ring Signatures in the context of zkFOCIL Prototype and benchmark implementations to evaluate viability Determine performance characteristics across different validator set sizes

Team Brechy (FT) Keewoo (PT) Introduction Semaphore is a zero-knowledge protocol that enables users to prove membership in a group without revealing their identity, allowing for anonymous messaging, voting, and other privacy-preserving applications. However, as group sizes scale to millions of users (such as Worldcoin's 11M+ users), the protocol becomes impractical for client-side implementation due to storage, computation, and bandwidth limitations. The current solution adopted by large-scale implementations like Worldcoin's World ID is to delegate the proving process to servers, which unfortunately compromises user privacy by requiring the disclosure of user identities to these servers. This project aims to develop and evaluate practical solutions that maintain privacy while enabling the Semaphore protocol to scale to millions+ of users. A more in depth review and description of this problem and the justification of the current chosen path can be found here.

banner Thanks to Vivian for answering so many questions. Semaphore is a protocol that allows you to cast a message as a provable group member without revealing your identity. When dealing with large groups it's not possible to run the protocol as it is normally used, mostly on end user's devices to maintain privacy. This introduces storage, computation and bandwidth requirements that make it impractical. Worldcoin World ID (~11M users) currently uses semaphore for their protocol. The solution they found for this issue was to delegate the proving to their servers. The downside of this solution is that users' identities are no longer private, since they need to be disclosed to the server to generate the proofs.

This document can be seen as an appendix for: Scaling Semaphore A proposed solution to scale the Semaphore protocol is to fetch the merkle path leaves using MPC. The merkle path is the set of leaves and hashes involved in the calculation of the zero-knowledge inclusion proof. Semaphore Group Tree (LeanIMT) 

This document provides an overview and status report of the Circom to Arithmetic Circuit Compiler: https://github.com/namnc/circom-2-arithc We will also discuss the challenges currently faced by the project and outline potential next steps for its development. Project Overview The primary aim of this project is to facilitate the creation of arithmetic circuits through the Circom DSL. The motivation behind developing such a tool comes from the desire to construct multi-party computation applications using a programming language, rather than relying on libraries. Traditionally, Circom is utilized for creating R1CS-based zk circuits. However, our project diverges from this path by targeting the generation of generic arithmetic circuits. These circuits are intended to serve as an intermediate representation, enabling the use of Circom for developing MPC or Fully Homomorphic Encryption applications.

Thanks Matan for teaching the topic! idk Roots of unity are the elements in a field that satisfy the equation $$ x^n = 1 $$

The real (unit) circle $C$ is defined algebraically by $$ C = {(x,y) \in \mathbb{R}^2 \mid x^2 + y^2 = 1}. $$ The definition only uses addition and multiplication, so it makes sense over any field. For a field $\mathbb{F}$, we define the $\mathbb{F}$-circle as

If you are not running your own local node, any information you request about Ethereum’s latest state (such as account balances) is handled by someone else’s node. meme This means you rely on a third party for all your queries. Even if you only check a small token balance, the metadata of your requests (IP addresses, location, operating system, etc.) can be gathered. If you keep checking the same address, this data may eventually be used to deanonymize you. A solution would be an Ethereum Incognito Mode, where you can request any on-chain data without revealing what you are asking for, while still receiving accurate answers. These type of private queries can be achieved using Private Information Retrieval (PIR).

Extractable Witness Encryption for KZG Commitments Brief Story  $+$  Screenshot 2024-10-17 at 6.39.34 PM Screenshot 2024-10-17 at 6.42.52 PM

This post provides an overview and implementation of the algorithm presented in: Fast Amortized KZG Proofs This algorithm allows us to compute $n$ opening proofs for a KZG commitment: In $O((n+d) \log (n+d))$ group operations if ${\xi_i}$ are $n$-th roots of unity. In $O(n \log^2 n + d \log d)$ group operations otherwise. We will cover the first scenario.

This document describes the implementation of Oblivious Linear Evaluation (OLE) using Extractable Witness Encryption for KZG Commitments (WE-KZG). Oblivious Linear Evaluation (OLE) OLE is a cryptographic protocol that enables two parties to collaboratively compute a linear function without revealing their private inputs. In OLE: Sender's inputs: coefficients $a$ and $b$ Receiver's input: value $x$ Receiver obtains: $y = a \cdot x + b$ The sender learns nothing about $x$, and the receiver learns nothing about $a$ or $b$.

Resources for the MPC presentation at Aleph -- 08-19-24. Introductory post: MPC intro Pragmatic MPC book: A Pragmatic Introduction to Secure Multi-Party Computation

Resources for the PSE Core Program Industrial Keynote -- 08-15-24. Introductory post: MPC intro Pragmatic MPC book: A Pragmatic Introduction to Secure Multi-Party Computation

Thanks Nam Ngo for the feedback and review! 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. introduction This allows performing operations on private information without disclosing it or involving a trusted third party. The only data each party receives is the function's result. There are several MPC protocols. This post provides an overview of the most general concepts and tools shared by many of them.

The EPF third cohort has come to an end. This is my final update for the project and a general overview of the steps taken. Project Abstract The goal of this project is to enable Helios to retrieve Consensus Layer data directly from the peer-to-peer network, rather than relying on a centralized provider. To achieve this, I began implementing cl-p2p-setup, a minimal Rust-based setup that enables a connection to the consensus layer p2p network. I decided to go in this direction to abstract the feature from the complexity of the helios codebase and only deal with libp2p in an isolated environment. This increased the speed of development for the actual networking aspect, and was easier to check if I was going in the correct direction. However, some code decisions didn’t take into account some of the Helios structure or libraries being used, leading to the need of refactoring some code to achieve compatibility.

My last update was based on the implementation of the Req/Res Protocol module for the Consensus Layer peer-to-peer setup project. Some changes were still pending for this to be fully functional so that will be the main topic of this update Req/Res Protocol The work for this feature took place in this pull request: https://github.com/brech1/cl-p2p-setup/pull/1 I worked on implementing the required responses for each request. This is a code snippet for the match arm of a new RPC event: BehaviourEvent::Rpc(rpc_message) => {

This document details contribution ideas to the current state of the helios consensus layer peer-to-peer networking implementation. Update Helios Networking There should be some work done in the Helios codebase to add a new Networking protocol. Some details of what has been thought can be found in these documents: https://hackmd.io/@brech1/helios-p2p-outline https://hackmd.io/@helios-core/p2p I’d say this is the best thing to take on since it’s completely independent from the other part of the project so far, and it would also be cool to find the best way of how Helios should be supposed to work with a new networking service without being biased of the actual implementation of the service.

In my last update, I discussed the construction of fork data from fork parameters and the implementation of SSZ decoding on GossipSub messages. I also mentioned an issue with bad peer score that caused connection shutdowns due to the lack of Req/Res Protocol implementation. This is the main topic of this update. This is the PR concerning this feature: https://github.com/brech1/cl-p2p-setup/pull/1 Req/Res Protocol This protocol enables consensus layer peers to communicate directly in order to check liveness or request data, such as specific blocks. My implementation was based on the Lighthouse client, however it is not generic across multiple network specifications. pub enum Protocol {