FHE-DKSAP Final Dev Update

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.

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 Stealth Address (SA) prevents the public association of a blockchain transaction with the recipient’s wallet address. SA effectively conceals the actual destination address of the transaction. It is critical to protect the privacy of recipients and cut off social engineering attacks on transaction flow. Vitalik Buterin et al. proposed EIP-5564 as the first SA design, and developed BasedSAP as an implementation of SA on Ethereum by utilising the Secp256k1 elliptic curve (EC). However, Vitalik also highlighted the current limitations in Open problem: improving stealth addresses to demand a (Fully Homomorphic Encryption) FHE solution. Thus, based on BaseSAP, we contribute further to propose FHE-DKSAP: a SA protocol with Fully Homomorphic Encryption (FHE). FHE-DKSAP has the following primary advantages:

• FHE-DKSAP replaces EC with FHE to improve security level. FHE constructs the lattice cryptographic, and born to equip FHE-DKSAP to prevent quantum computing attacks.
• Therefore, SA in FHE-DKSAP is secured to be reused and there is no need to generate large amounts of SA to reduce the complexity and difficulty of SA adoption.
• Compared to the dual-key design in EIP-5564, our design in FHE-DKSAP, can help the receiver outsource the computation of checking the entire chain for SA containing assets without revealing his view key.

In this foundational stage, the primary output revolved around three critical areas: technical details, experimental implementation, and the provision of security proof.

• Technical Details:
  The focus here was to meticulously chart the architecture of FHE-DKSAP. Each aspect of the protocol was delineated with precision, ensuring that the theoretical underpinnings were sound and that the methodology could be replicated. The protocol’s design was documented with comprehensive technical specifications, outlining the algorithms and cryptographic primitives used, as well as the protocol's workflow and data structures.
• Experimental Implementation:
  A tangible representation of the protocol came to life through its experimental implementation. This involved coding the algorithm, setting up a simulated environment, and running the protocol to observe its behavior in real-world scenarios. The implementation served as a proof of concept, demonstrating the feasibility of FHE-DKSAP and its potential integration into the Ethereum ecosystem. This stage also allowed for the identification and ironing out of any unforeseen kinks or vulnerabilities that could arise in practical applications.
• Security Proof:
  To validate the robustness of FHE-DKSAP against potential threats, a rigorous security proof was necessary. This entailed analyzing the protocol against established security models and potential attack vectors. The goal was to ensure that the protocol could withstand various cryptographic attacks, including those from quantum computing advancements. Proving the security formally provided the assurance needed to proceed with confidence in the protocol’s ability to safeguard user privacy and key management within the Ethereum framework.

This triad of technical details, experimental implementation, and security proof formed the comprehensive output of this stage, setting a solid groundwork for the subsequent phases of the project.

1.2 Exploration Stage: comply with the regulation

While SA offers users a high degree of privacy, it can also be misused for illicit purposes such as money laundering or funding illegal activities. At present, the stealth address operates in a legal gray area as there isn't a comprehensive legal framework or checks specifically tailored for it. The use of stealth addresses brings about a layer of anonymization, which, while advantageous for users seeking privacy, poses significant challenges for regulators. The anonymity makes it difficult to trace and verify transactions, which can hinder efforts to ensure compliance with existing financial and anti-money laundering regulations.

Thus, taking inspiration from the pivotal work "Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium," I embarked on the integration of zero-knowledge proof (ZKP) techniques within the FHE-DKSAP protocol to address regulatory concerns.

In the interactions of FHE-DKSAP in privacy pool, we both verify the transfer ZKP and receive 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 verifies 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 these ZKP attachments, we can verify the validity of the transaction and reach the target of reducing illegal transactions.

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 withdrawal 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 accessible input.

In conclusion, this integration was crafted with a dual purpose: to allow users the confidence to conduct their transactions shielded from public view, while simultaneously providing the means to verify those transactions as legitimate and compliant with regulatory standards. The result was a powerful tool that enabled users to affirm the legitimacy of their activities without the need to disclose the transaction's contents or their personal information.

1.3 Adoption Stage: Conversion into Abstract Account

The final stage in the journey of enhancing Ethereum’s privacy framework through FHE-DKSAP involved a significant leap toward wider applicability: the conversion of the protocol for use with abstract accounts. However, the previous 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. This type of account presents two primary challenges: its inherent single point of failure and associated privacy issues.

• Single Point of Failure: The crux of the vulnerability for an EOA lies in its private key. Should a user misplace or lose this key, they forfeit access to all assets linked to that particular EOA without any means of recovery. Moreover, should this key fall into the wrong hands, it grants the unauthorized individual the ability to transfer assets or engage with smart contracts as if they were the rightful owner.
• Privacy Issues: Transactions stemming from or directed to an EOA are openly accessible on the Ethereum blockchain. This transparency enables anyone to monitor the balance and transaction history of an EOA, laying bare the financial activities of its owner to any observer.

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. To solve this challenge and extend the usability of Ethrerum, the concept of Abstract Accounting(AA) was introduced. 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.

When examining the intricacies of the system, we notice that the Abstract Account (AA) model introduces more roles and actions compared to the simplistic Externally Owned Account (EOA) structure. The remarkable feature about the AA model is its capacity to evolve and add functionalities without tinkering with Ethereum's core and foundational logic. This is achieved by ingeniously sandwiching additional layers both at the initiation and the culmination of the transaction process. The procedures contained within the highlighted blue box adhere to the exact logic of a conventional EOA transaction. This means that the essence of Ethereum remains preserved, even as we integrate the enhancements offered by AA. By maintaining the integrity of the original system and augmenting with AA, we usher in a blend of both security and flexibility, ensuring a seamless transition for users and developers alike. Thus, in this stage, we aim to integrate the FHE-DPSAK with AA. This integration offers three significant benefits:

1. While AA necessitates the verification of a user's identity and the proof of wallet ownership, integration with the stealth address protocol can effectively conceal the identities of smart account holders of the recipient.
2. The usability of the FHE-DKASAP account is enhanced, making this privacy-preserving scheme more versatile within blockchain technology.
3. 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.

1.4 Final scheme with finished task

In the culmination of our efforts, our scheme emerged as an intricate yet coherent synthesis of Zero-Knowledge Proofs (ZKP), Fully Homomorphic Encryption (FHE-DKSAP), and Abstract Accounts (AA). This tripartite framework is not merely a patchwork of advanced concepts but a seamlessly integrated solution, tailored to address the complexities of privacy and compliance in the blockchain domain.

2. Future of the project

2.1 Next steps

There are some points for our next steps with the scheme improvements. It mainly includes the optimization of computational efficiency of FHE operations, enhancing key management, using regulatory compliance tools, expanding zero knowledge proofs and so on.

1. Optimization of Computational Efficiency:
   • Research and implement algorithmic improvements specific to the arithmetic of FHE operations.
   • Explore the use of hardware accelerators, such as Graphics Processing Units (GPUs) or Application-Specific Integrated Circuits (ASICs), to speed up FHE computations.
   • Develop or improve upon existing libraries that are optimized for FHE calculations within the context of blockchain technologies.
2. Enhanced Key Management:
   • Design a user-friendly interface for managing cryptographic keys, with an emphasis on minimizing the risk of human error.
   • Incorporate secure multi-party computation techniques to distribute trust and reduce the single points of failure in key management.
   • Introduce smart contract-based key management solutions that automate the lifecycle of cryptographic keys within the Ethereum ecosystem.
3. Regulatory Compliance Tools:
   • Implement privacy-preserving identity verification methods within the FHE-DKSAP system to meet Know Your Customer (KYC) and Anti-Money Laundering (AML) requirements.
   • Create a protocol layer that can interface with regulatory technologies while maintaining the core privacy-preserving features of FHE-DKSAP.
4. Expanded Zero-Knowledge Proofs:
   • Explore advanced zero-knowledge proof constructions that offer a broader range of privacy guarantees and computational efficiencies.
   • Integrate zero-knowledge proofs that support more complex statements, enabling richer functionalities in smart contracts while preserving privacy.
   • Provide a library of zero-knowledge proof templates that can be customized for various use cases within the FHE-DKSAP framework.
5. Standardization of the FHE-DKSAP Protocol:
   • Develop a comprehensive set of standards for the FHE-DKSAP protocol that can be universally applied across different blockchain architectures. This includes defining clear specifications for encryption, decryption, transaction formats, and data structures that are compatible with multiple blockchain systems.
   • Engage with international standards organizations to establish FHE-DKSAP as a recognized protocol for cross-chain privacy. This would help ensure a consistent implementation across platforms, reducing complexity and enhancing the security of cross-chain interactions.
   • Create an open-source initiative to encourage community-driven development and peer review of the FHE-DKSAP standards, fostering innovation and trust in the protocol.

2.2 Use cases - Building Bridges and Relay Networks:

Our main use case for this scheme lies in interactions with other blockchains, and the main steps include the follows:

• Design and implement secure bridging mechanisms that act as intermediaries to facilitate the safe transfer of encrypted data and digital assets from Ethereum to other blockchains. These bridges would use FHE-DKSAP to ensure that transaction details remain confidential and tamper-proof during transit.
• Establish relay networks that can efficiently verify the integrity and authenticity of transactions crossing between chains without decrypting them. This involves developing protocols that can handle the necessary cryptographic proofs and validations in a decentralized and trustless manner.
• Ensure that these cross-chain transfer systems are resilient to attacks, operational failures, and congestion, which involves rigorous testing and continuous monitoring of the network's performance and security.

Through these expanded efforts, the FHE-DKSAP scheme can become a cornerstone of privacy in the blockchain space, allowing for secure and anonymous transactions not only within Ethereum but also across the myriad of other blockchains that form the decentralized web.

3. Self-evaluation

Through the meticulous interweaving of these technologies, we have accomplished our primary objective: to devise a mechanism that encapsulates the essence of privacy without compromising on the ability to meet regulatory mandates. ZKP provides the assurance that transactional details remain confidential while proving their legitimacy. FHE-DKSAP ensures that encryption and operations on data do not reveal any sensitive information, upholding security throughout the computational processes. Meanwhile, the adoption of Abstract Accounts offers a flexible and forward-thinking approach to managing identities and permissions on blockchain.
Our final architecture represents a significant stride toward realizing a blockchain ecosystem that is both private and compliant. Users can engage with confidence, knowing their transactions are protected, and regulators can uphold the integrity of the system without infringing on individual privacy. We have not only reached our target, but also laid down a foundation for future innovations — a versatile platform that is robust, adaptable, and ready to evolve with the ever-changing landscape of blockchain technology and its governance.

4. Takeaways

• Networking: The cohort has provided opportunities for networking with peers and experts in the field, paving the way for future collaborations and community engagement.
• Skill Development: The program has likely led to the development of specialized skills in smart contract development, cryptographic protocol implementation, and the use of Ethereum-specific tools and platforms.
• Innovation and Problem-Solving: Tackling the complex issues surrounding blockchain privacy has honed the cohort's innovation and problem-solving skills, which are transferable to various aspects of blockchain development and research.
• Preparation for Future Challenges: I am now better prepared to face and address the future challenges of blockchain privacy and security, particularly in the face of evolving technology like quantum computing.

5. Thanks

A big thank you for @JoshD @MarioHavel @EFP_Fellows @vbuterin @Nerolation @EF and many others along the journey! A wonderful and fruitful journey! Highly recommendated for future fellows. Keep in touch! [e-mail]