Scaling Confidential Smart Contracts: A Dive into FHE Rollups

Table of Contents

In blockchain technology, the quest for scalability and confidentiality in smart contracts has led to the exploration of innovative solutions. This article dive into the promising world of Fully Homomorphic Encryption (FHE) Rollups—a fusion of Fully Homomorphic Encryption and Rollup scaling techniques. The article is referenced based on the white paper of Fhenix - first blockchain powered by Fully Homomorphic Encryption (FHE)

I. Foundations of FHE

Fully Homomorphic Encryption (FHE) stands as a cornerstone in the architecture of FHE Rollups, enabling computations on encrypted data with results that mirror those performed on plaintext. Originally conceptualized by Gentry , FHE has evolved with various schemes, often rooted in the Learning With Errors (LWE) hardness problem or related algebraic constructs like its ring variant.

Their implementation specifically leverages the TFHE scheme, though, for the purpose of constructing an FHE Rollup, the details of the chosen scheme are secondary. Described in a black-box manner, a generic FHE scheme can be characterized by the tuple of algorithms FHE = (Gen, Enc, Dec, Eval):

- Gen(1 𝜅): With a security parameter 1 𝜅, this algorithm generates a pair of keys (𝑝𝑘, 𝑠𝑘), where 𝑝𝑘 is the public encryption key and 𝑠𝑘 is the secret decryption key. It defines domains P for plaintexts, R for randomness, and C for ciphertexts, along with the set of permissible functions F.

- Enc(𝑝𝑘, 𝑚; 𝑟): Utilizing the public key 𝑝𝑘, a message 𝑚 ∈ P, and randomness 𝑟 ∈ R, this algorithm produces a ciphertext 𝑐 ∈ C such that 𝑐 = Enc𝑝𝑘(𝑚; 𝑟).

- Dec(𝑠𝑘, 𝑐): Using the secret key 𝑠𝑘 and a ciphertext 𝑐, the decryption algorithm retrieves the original plaintext message 𝑚: 𝑚 = Dec𝑠𝑘(𝑐).

- Eval(𝑝𝑘, 𝑓, {𝑐𝑖} 𝑛 𝑖=1): Given the public key 𝑝𝑘, a function 𝑓 ∈ F, and a set of ciphertexts {𝑐𝑖} 𝑛 𝑖=1, this algorithm produces a ciphertext 𝑐 ′ ∈ C such that:

Dec𝑠𝑘(𝑐 ′) = 𝑓 ({Dec𝑠𝑘(𝑐𝑖)}𝑛 𝑖=1)

This signifies that the function 𝑓 operates over encrypted data, and its result is encrypted as 𝑐 ′. The choice of the specific FHE scheme, such as TFHE, becomes a technical detail within the broader context of FHE Rollups.

This foundational encryption capability plays a pivotal role in preserving the confidentiality of computations while engaging with smart contracts within the FHE Rollup ecosystem. It establishes the groundwork for secure and privacy-preserving transactions, as further explored in the subsequent sections.

*Note: Mitigating concerns associated with FHE performance, EIP-4844 and Danksharding aim to address and alleviate these challenges.*

II. Architecture of FHE Rollups

1. Choosing Between Optimistic and ZK-Based Approaches

The architectural foundation of FHE Rollups hinges on a critical decision: whether to adopt an Optimistic Rollup or a Zero-Knowledge (ZK)-based approach. This decision involves a careful consideration of trade-offs between proving-side speed and verification efficiency.

Optimistic Rollups, known for their agility, assume the validity of transactions by default, only engaging in on-chain verification in the presence of disputes. While this approach accelerates transaction processing, it necessitates a robust fraud proof mechanism to address potential discrepancies. On the other hand, ZK Rollups provide heightened privacy by utilizing Zero-Knowledge Proofs, ensuring that transaction details remain confidential while sacrificing some speed on the proving side.

Given the inherent challenges of integrating FHE into the verification process, the draft argues in favor of an optimistic-based approach within the encrypted domain. This strategic choice aligns with the natural characteristics of FHE and acknowledges the current limitations in achieving efficient ZK-based FHE Rollups.

source: fhenix.com

2. Design Overview and Implementation Details

fheOS Library

The heart of the FHE Rollup architecture lies in the fheOS library—a meticulously crafted encrypted computation library designed for smart contracts. This library encapsulates pre-compiled FHE operations, including comparisons, addition, and multiplication. By allowing smart contracts to leverage FHE primitives, fheOS empowers decentralized applications (dApps) to seamlessly integrate encrypted data into their logic.

Designed as an Ethereum Virtual Machine (EVM)-friendly wrapper around Zama's tfhe-rs FHE libraries, fheOS injects itself as an extension into existing EVMs. This modularity ensures compatibility with the EVM, preserving the functionality of existing smart contracts while enhancing developers' capabilities to explore new use cases.

The fheOS library acts as the core engine of the Fhenix node, facilitating encrypted smart contracts. Utilizing fheOS precompiles, smart contracts can perform common FHE operations, while the library manages communication and authentication between the Rollup and the Threshold Services Network (TSN). This communication is vital for decryption and re-encryption requests, with fheOS verifying the legitimacy of these requests during the proving process.

go-tfhe

To extend Ethereum's goethereum (geth) and integrate the capabilities of the tfhe-rs FHE library written in Rust, the go-tfhe module was developed. This module acts as a lightweight, modular, and extendable bridge between tfhe-rs and blockchain applications.

Go-based API: Providing essential interfaces for FHE mathematical operations using Go, this component serves as the primary interaction point for developers familiar with Go programming.

Rust Wrapper for TFHE.rs: A specialized wrapper adapts TFHE.rs library functions for seamless integration with blockchain applications, addressing the language barrier between Rust and Go.

FFI Integration between Go API and Rust Wrapper: To bridge the gap between Go and Rust, the interface employs cgo and extern "C" mechanisms. This integration aligns function calls, types, and naming conventions, ensuring smooth communication between the two languages.

go-tfhe acts as a crucial intermediary, facilitating the adoption of FHE within the blockchain context.

III. Threshold Services Network (TSN)

The Threshold Services Network (TSN) serves as a linchpin within the architecture of FHE Rollups, providing a secure and collaborative environment for critical operations. In this section, we delve into the multifaceted role of the TSN and its various responsibilities, ranging from threshold decryption to ensuring the security of sensitive data.

1. Key Role of TSN

At the core of the FHE Rollup design, the TSN plays a pivotal role by collectively safeguarding the secret-shared network key ([𝑠𝑘]). This network key is a critical asset that enables threshold decryption—a process where a certain number of authorized entities collaboratively decrypt encrypted data. The TSN's responsibility extends beyond individual smart contracts and rollup components, emphasizing the need for a centralized yet secure entity in managing cryptographic operations.

2. Threshold Decryption and Re-encryption

The TSN orchestrates crucial cryptographic operations, such as threshold decryption and re-encryption, ensuring the privacy and security of sensitive information. Consider scenarios where encrypted data, such as voting tallies or private metadata within smart contracts, needs to be revealed or re-encrypted for designated users.

For instance, in a private voting contract deployed on the rollup, users encrypt their votes, and the tally remains encrypted until a specific event triggers the need for decryption. The TSN steps in to decrypt the tally securely and returns the result for storage within the contract's state. This ensures the integrity of the data and the privacy of individual votes.

Similarly, in cases involving private metadata within a non-fungible token (NFT), the TSN facilitates threshold re-encryption. When a user attempts to access their encrypted information, the contract engages the TSN to securely re-encrypt the data, ensuring that only the designated user can decrypt and access the underlying information.

3. Random Beacon

One of the distinctive functionalities introduced by the TSN is the generation of a random beacon. In the realm of smart contracts, randomness is a crucial element for enabling non-deterministic functionalities. Traditional smart contracts are inherently deterministic, lacking the ability to introduce randomness without an external sTheirce.

The TSN addresses this need by providing a sTheirce of randomness through a secure random beacon. This functionality proves vital in applications such as on-chain gaming (e.g., poker, casinos), NFT minting, and any other scenario where the introduction of randomness is essential for the execution of smart contract logic.

4. Secure Shuffle

In various privacy-preserving computation techniques, including those leveraging FHE, an efficient secure shuffle primitive becomes indispensable. The TSN incorporates this functionality, enabling the shuffling of a vector of inputs securely. This capability has wide-ranging applications, with one notable example being in games like poker, where the secure shuffling of the deck is crucial for maintaining fairness and integrity.

Moreover, secure shuffles serve as a critical building block for Oblivious RAM (ORAM)—a scheme ensuring that not only is memory encrypted, but all accesses to it remain private. Integrating an ORAM can pave the way for constructing a more efficient FHE Virtual Machine (fhEVM), allowing the execution of FHE computations over programs directly without the need for unrolling them into circuits.

5. Security

The security of the entire FHE Rollup system is intricately tied to the trust assumptions placed on the TSN. As the custodian of the threshold decryption key and the orchestrator of cryptographic operations, the TSN bears the responsibility of safeguarding sensitive information and ensuring the correct decryption and re-encryption of ciphertexts.

Current protocols, as referenced in the draft, impose constraints on the TSN, requiring a limited number of malicious corruptions for a fast and robust protocol. Ongoing research in this area seeks to address potential improvements and challenges, including actively secure threshold decryption protocols supporting a dishonest majority, cheater identification, scalability to a large number of validators, and mechanisms for share rotation and recovery.

IV. Fraud Proofs in FHE Rollups

1. Key Role of Fraud Proofs

Fraud proofs constitute the backbone of FHE Rollups, ensuring the integrity and validity of transactions in the decentralized ecosystem. Unlike traditional blockchain architectures, where transactions are assumed valid until proven otherwise, FHE Rollups employ a robust fraud proof mechanism to maintain the security of the system.

The key challenge lies in seamlessly integrating fraud proofs into the FHE Rollup architecture, especially given the unique characteristics of Fully Homomorphic Encryption (FHE). The role of fraud proofs becomes particularly crucial in the context of executing smart contracts that involve FHE circuits operating on encrypted data.

2. Compatibility with Optimistic Rollups

Optimistic Rollups rely on the assumption that transactions are valid unless proven otherwise. In the FHE Rollup context, this entails the full transaction data, including the encrypted inputs and outputs, being posted on the Layer 1 (L1) or another data availability service. The essence of optimistic rollups is to allow off-chain verifiers to re-execute transactions and ensure that the encrypted output matches the original transaction. Any discrepancies can then trigger a dispute resolution process.

However, the challenge arises when traditional blockchains, like Ethereum, need to validate FHE computations without inherent support for FHE operations. The solution lies in leveraging Arbitrum's Nitro fraud prover, repurposed to compile FHE logic into WebAssembly (WASM) for on-chain execution on Ethereum.

3. Implementation Details

Arbitrum's Nitro Fraud Prover

Arbitrum's Nitro fraud prover plays a pivotal role in the FHE Rollup ecosystem by facilitating the compilation of FHE logic into WebAssembly. This allows the entire proving round to be executed in a WASM runtime (WAVM) on-chain, aligning with Ethereum's compatibility.

Compiling FHE Logic to WebAssembly

Compiling FHE logic into WebAssembly serves as a bridge between the native Ethereum Virtual Machine (EVM) and the intricacies of FHE operations. This approach ensures that FHE computations can be seamlessly executed on-chain without requiring fundamental changes to the existing Ethereum infrastructure.

4. Performance Considerations

Addressing potential performance concerns, the draft rationalizes that the computational intensity of FHE computations in a dispute scenario is mitigated by the generous dispute window traditionally allocated—approximately seven days. This ample timeframe allows for the resolution of disputes without imposing real-time constraints on the execution speed of FHE computations.

While the theoretical framework is established, empirical validation of performance hypotheses is recognized as an important area for future research. The draft acknowledges that the Arbitrum fraud proof engine, which incorporates software floating points, may introduce some performance overhead, underscoring the need for comprehensive benchmark testing.

Conclusion

In the quest for scaling confidential smart contracts, FHE Rollups emerge as a promising frontier. Balancing security, scalability, and confidentiality, these solutions offer a glimpse into the future of blockchain technology. As the community delves deeper into these concepts, ongoing research and improvements aim to propel FHE Rollups into mainstream adoption.

About Orochi Network

Orochi Network is a cutting-edge zkOS (An operating system based on zero-knowledge proof) designed to tackle the challenges of computation limitation, data correctness, and data availability in the Web3 industry. With the well-rounded solutions for Web3 Applications, Orochi Network omits the current performance-related barriers and makes ways for more comprehensive dApps hence, becoming the backbone of Web3's infrastructure landscape.