Project Abstract: In the world of Ethereum, as envisioned by its co-founder Vitalik Buterin, privacy remains a persistent challenge. The blockchain, while revolutionary, records every transaction in a way that is transparent and permanent. This means that anyone can trace and scrutinize the flow of digital assets from one address to another. This project details a three-fold mission undertaken during the tenure of cohort 4 to enhance the privacy of Ethereum. The initial stride involved fortifying the security of Dual Key Stealth Addresses (DKSAP) through the integration of Fully Homomorphic Encryption (FHE)—a breakthrough allowing computation on ciphered data without revealing the underlying details. Progressing further, the research acknowledged the critical need for regulatory compliance within the blockchain realm. To reconcile the imperative of privacy with the demands of regulation, the study pivoted towards incorporating zero-knowledge proof protocols into the FHE-enriched DKSAP framework. Lastly, the scope of these advancements was expanded to encompass 'abstract accounts' in Ethereum, thereby not only elevating the practicality and adaptability of our scheme but also paving the way for more dynamic and programmable blockchain interactions. 1. Project Overview During the whole journal of cohort 4, I set out on a three-step mission to improve Ethereum's privacy. My first idea was to strengthen the security of dual key stealth addresses (DKSAP) by incorporating fully homomorphic encryption (FHE), a technology that allows computations on encrypted data without exposing the actual information. Moving forward, I recognized that alongside the paramount goal of preserving privacy, the importance of regulation and compliance within the blockchain ecosystem cannot be understated. It was essential to find a harmony between the shield of privacy and the sword of regulatory oversight. To achieve this delicate balance, I turned to the innovation of zero-knowledge proof protocols within the FHE-DKSAP. Last but not least, I aimed to broaden the reach of this technology by applying it to the "abstract accounts" — a concept in Ethereum that allows for more flexible and programmable interactions on blockchain, which makes our scheme more adoptive and practical. Thus, the roadmap can be found as follows. image.png In the following sections, I will break down each of these steps, making the journey towards a more private Ethereum not just a technical pursuit, but a story that reflects the community's shared values and aspirations. 1.1 Starting Point: FHE-DKSAP The journey into enhancing Ethereum's privacy began with cornerstone technology: Fully Homomorphic Encryption - Dual-key Stealth Address Protocol(FHE-DKSAP). This innovative approach was designed to be the bedrock upon which a new level of security and privacy would be constructed.

The details of FHE-DKSAP with AA The technical details of FHE-DKSAP can be found as follows: The details of the "recover" function implementation: The implementation of signing requires two components: the data to be signed and the account executing the signing. The signing process can be achieved using web3.eth.sign(). The specific code is: let msg = web3.sha3('today is 20171026') let signature = web3.eth.sign(address, msg) Here, we used the address account to sign the message 'today is 20171026'. The returned value signature is

Update the solution for AA-based FHE-DKSAP Update the solution for Verifiable FHE-DKSAP Zero-Knowledge Proofs (ZKPs) are cryptographic methods where one party (the prover) can prove to another party (the verifier) that a statement is true without revealing any specific information about the statement itself. In the context of privacy pools and blockchain, ZKPs are used to enhance privacy and scalability. In the context of Ethereum and other smart contract platforms, ZKPs can be used to create private smart contracts where the details of the contract’s execution are hidden but can still be verified. Privacy pools are essentially smart contracts that leverage ZKPs to allow users to deposit, withdraw, and transact privately. Users deposit into the pool and receive private tokens. They can then transact these tokens without the details being public on the blockchain. When they want to exit the pool, they can withdraw, again without revealing specific transaction details. In the interactions of FHE-DKSAP in privacy pool, we both verify the trans- fer ZKP and recive ZKP. When Alice wants to transfer an amount using stealth address and makes a private transaction within the pool, she create a zero- knowledge proof that the transaction is valid (e.g., they have the funds, the transaction does not double-spend, etc.). The pool’s smart contract then veri- fies the proof, and if it’s valid, processes the transaction. However, the specifics of the transaction (like sender, recipient, and amount) remain hidden from the public blockchain. Same for the receiver Bob. When he receives a transaction, he generates the ZK proof based on the transaction. By using this ZKP attach- ments, we can verify the validness of the transaction and reaches the target of reducing the illegal transactions. The overview of ZKP can be found in below figure. At the heart of FHE-DKSAP’s application in Privacy Pools is the following principle: users don’t just use zero-knowledge proofs to verify that their with- drawal corresponds to an earlier deposit. Instead, they prove their membership within a specific association set. This set could encompass all prior deposits, solely the user’s individual deposit, or a combination thereof. The user identifies this set by submitting a Merkle root representing the set as a publicly accessi- ble input. Here, we design a pseudocode in Algorithm 1 to give a conceptual understanding of the process. The above pseudocode offers more details, like cryptographic hashing and zk-SNARK proofs. In our algorithm, we assume SHA-256 for hashing and a simplified zk-SNARK system for zero-knowledge proofs. However, the specific methods for generating a zk-SNARK proof, validating signatures, or even con- structing a Merkle tree can vary based on the exact cryptographic library and requirements.

https://docsend.com/view/pnsnw3zseu7bt7qs

Another iteration of integrating FHE-DKSAP with AA Leveraging the structure of Abstract Accounting (AA), we intend to integrate the FHE-DKSAP within the transaction intent. In this scenario, Alice, the wallet owner, wishes to transfer funds to Bob. Guided by this transaction intent, Alice will utilize her private key, regardless of its format, to craft the transaction intent within the AA framework. She then authenticates this intent using her signature. This process encompasses the creation of a stealth address based on the FHE-DKSAP scheme. The transaction flow is as outlined below: We can conclude our process as follows: Initialization: Initialize the AA framework to be compatible with the cryptographic requirements of FHE-DKSAP. Configure the Ethereum node to understand and verify FHE-DKSAP encrypted transactions.

1. Background In our previous work, we introduced the FHE-DKSAP protocol. This system safeguards the association between a blockchain transaction and the recipient's wallet address, ensuring a heightened level of security. Notably, it offers quantum computing resistance, eliminates key leakage concerns, and enhances efficiency by allowing the reuse of certain public keys. A detailed explanation of the scheme is available in our earlier blog post FHE-DKSAP. However, this scheme is still based on the current regular accounts (EOA) wallets. The EOA is controlled by a private key and can directly send transactions and receive ETH tokens, which is the type of account most familiar to ordinary users. Apart from this EOA address, there is contract accounts (i.e., CA, which stands for Contract Account). Contract accounts are controlled by smart contract codes and do not have a private key. Vitalik foresees a future where users transition from the conventional EOA wallets to those based on smart contracts. If this vision materializes, managing crypto wallets could become as straightforward as handling email accounts. Ethereum account abstraction, also called abstract account (AA, Abstract Account), abstracts regular accounts and contract accounts, allowing them to be seen as the same type of account. In this proposal, we aim to integrate the FHE-DPSAK with AA. This integration offers three significant benefits: While Account Abstraction (AA) necessitates the verification of a user's identity and the proof of wallet ownership, the integration with the stealth address protocol can effectively conceal the identities of smart account holders of the recipient. The usability of the FHE-DKASAP account is enhanced, making this privacy-preserving scheme more versatile within blockchain technology. The SA in AA blog introduced the implementation SA in AA, but in a self-created way. We will extend it to compatibility with ERC-5564.

Security analysis based on FHE-DKSAP In this part, we will conduct a security analysis of FHE-DKSAP. To begin, we will define the security requirements, and subsequently, we will demonstrate how FHE-DKSAP meets these security criteria. Security Requirements: In FHE-DKSAP, confidential data encompasses the secret keys of both Alice and Bob. Furthermore, the generated stealth address must remain unlinkable to the recipient's original address. This scheme relies on the correct execution of encryption and decryption functions based on FHE, leveraging the inherent strengths of FHE to guard against quantum computing attacks. The details of the definitions can be found as follows. Security ProofIn this section, we will furnish formal proof for the security definitions associated with these requirements. Data confidentialityThe security of a public key system lies in the fundamental principle that, given a public key, one cannot feasibly deduce the corresponding secret key. In the case of secp256k1, its security is anchored in the elliptic curve discrete logarithm problem (ECDLP). This problem is deemed computationally intractable for judiciously selected curves coupled with sufficiently large key sizes. With its 256-bit key size, secp256k1 is fortified against known threats, ensuring that secret keys remain confidential.Conversely, in the FHE-DKSAP scheme, public keys serve as the means to encrypt secret keys within the encryption function. Operating under the mechanics of FHE encryption, the retrieval of the original plaintext (in this instance, the secret keys) from its corresponding ciphertext is rendered unfeasible. Unlinkability

In the exciting context of Ethereum Singapore 2023, we are actively engaged, bridging essential components of the blockchain ecosystem. We will seamlessly integrate Metamask and the Linea smart contract with our cutting-edge FHE-DKSAP technology. Before we go into details, we provide the fundamental information of Metamask and Linea Smart contract. Metamask: Metamask is a widely-used cryptocurrency wallet and gateway to decentralized applications (DApps) on the Ethereum blockchain. It serves as a browser extension, allowing users to securely manage their Ethereum-based assets, interact with decentralized platforms, and execute transactions seamlessly. With Metamask, users gain control over their digital identities and assets while navigating the decentralized landscape of the Ethereum network. Linea Smart Contract: The Linea smart contract is a cutting-edge, self-executing digital agreement built on the Ethereum blockchain. Designed to automate and enforce specific contractual conditions without the need for intermediaries, Linea smart contracts ensure trust and transparency in various industries. These contracts operate according to predefined rules and execute actions when predetermined conditions are met, facilitating a wide range of applications, from automated financial services to supply chain management, while eliminating the risk of human error and reducing reliance on centralized authorities. In the following, we provide the integration between Metamask, the Linea smart contract, and FHE-DKSAP. Our integration project leverages the strengths of three powerful components in the blockchain and cryptographic space—Metamask, the Linea smart contract, and Fully Homomorphic Encryption based Dual Key Stealth Address Protocol (FHE-DKSAP). This synergy empowers us to create a secure and efficient ecosystem for decentralized applications and data handling. Implementation Metamask Connectivity: At the heart of our integration is Metamask, a renowned Ethereum wallet and DApp gateway. Users can seamlessly connect their Metamask wallets to our platform, enabling secure access to their digital assets and facilitating frictionless transactions within the Linea smart contract ecosystem.

Q&A from Ethereum research blog https://ethresear.ch/t/fhe-dksap-fully-homomorphic-encryption-based-dual-key-stealth-address-protocol/16213/15 We have disseminated our research findings and results within the Ethereum research community by publishing them on Ethereum Research. After sharing our research and findings on Ethereum Research, we actively gathered valuable insights and feedback from the comments and discussions generated by the community. In this comprehensive compilation, we have meticulously cataloged all the questions raised and thoughtfully presented our meticulously crafted solutions to each of them. The details can be found as follows: Q: Is there a reason why the ciphertext C_2 C2C_2 is publicly shared? A: Good question. it is not necessary to publicly share the C_2 from the algorithm and computation point of view. But to allow any party to be able to calculate the homomorphois addition of C_1 and C_2 reduces the computation cost on Bob client’s side. Q: This is very interesting! I have a few questions:A dumb question as I’m not an expert on cryptography. Does it require FHE? As I see, it only needs additive homomorphism during encryption/decryption? You mentioned the SA can be reused though in step 2 Alice would generate a new key pair for each SA transaction. Can you elaborate more on the SA reuse part? Does reuse mean reusing the same key pair for different SA transactions?

The update from Week 3&4 Our implementation of Fully Homomorphic Encryption Stealth Address comprises two integral components. The first part encompasses the initial implementation of SECP256k1, a widely recognized elliptic curve cryptography algorithm. This foundation forms the basis for secure cryptographic operations in our system. The second component involves the generation of stealth addresses, a crucial technique that enhances the privacy and anonymity of transactions. In order to thoroughly assess the performance and effectiveness of our system, we conducted comprehensive testing of the generated stealth addresses. This testing phase encompassed a variety of scenarios and methodologies to ensure the robustness and reliability of our approach. Specifically, we evaluated the stealth address generation process using three different setups: DK-SAP (Plain), HE-DK-SAP (Pallier), and FHE-DK-SAP. These setups represent distinct encryption methods, each contributing to varying levels of security and computational complexity. The intricate details pertaining to our implementation and the subsequent testing procedures have been meticulously documented. For those seeking an in-depth understanding, we have provided a comprehensive breakdown of our implementation process and testing outcomes in the aspect of time computation. 1. Initial Implementation of SECP256k1 The SECP256k1 elliptic curve is defined with the equation: y^2 = x^3 + 7 (mod p) over the finite field Z(2)(256)(-2)(32)(-977), which means the X and Y coordinates are 256-bit integers modulo a large number. The main functions consist of public key generation based on the secret key

We published an improvement proposal on Ethereum Research: https://ethresear.ch/t/fhe-dksap-fully-homomorphic-encryption-based-dual-key-stealth-address-protocol/16213/3 Any feedback is welcome! Next Steps Improve existing FHE-DKSAP solution Finalize the implementation of FHE-DKSAP Benchmarking FHE-DKSAP Develop use cases to adopt FHE-DKSAP

This week, we have kicked off our research from the Privacy transition of Ethereum, starting from the concept of Stealth Address. In Vitalik's recent "3 transitions" post, he highlighted "As Ethereum transitions from a young experimental technology into a mature tech stack that is capable of actually bringing an open, global and permissionless experience to average users...The privacy transition - making sure privacy-preserving funds transfers are available, and making sure all of the other gadgets that are being developed (social recovery, identity, reputation) are privacy-preserving" He further illustrated the idea of Stealth Address with a more detailed post and ERC-5564 associated with it. However, this is not the first time that Stealth Address was proposed. Let's start from a literature review. A Literature Review Research 17 April 2011; The most basic Stealth Address (SA) technique was invented by user ‘bytecoin’ in bitcoin forum user ‘bytecoin’. Untraceable transactions which can contain a secure message are inevitable. 2011. https://bitcointalk.org/index.php?topic=5965.0

Hello all :wave: I am Mason. My pleasure to be a part of the Ethereum Protocol Fellowship. My expertise and interests are in area of AI and Cryptography to make Web3 a more secure and privacy-preserving place. My Foucs The first week is always the sweetest. I try to list all necessory action items in order to narraw down the research focus for the next 4 months. [x] Draft the reading list to consolidate the basic understanding of Ethereum ecosystem. [x] Kick off the literature reseach in the area I am interested: How to enhance data security and privacy protection on Ethereum [x] Get to know Mentors and other fellows [ ] Set up initial meetings