Why Midnight Chooses ZKPs Over FHE for Scalable Data Protection

Privacy preserving computation in decentralized systems is primarily explored through two cryptographic paradigms: Fully Homomorphic Encryption (FHE) and Zero Knowledge Proof systems (ZKPs). Both enable computation over sensitive data without exposing plaintext, but they differ fundamentally in:

• Where computation occurs
• How state is represented
• What the blockchain is responsible for verifying
• How scalability is achieved

This article compares these architectures and explains why Midnight’s design based on zk-SNARKs and its Kachina execution model prioritizes verifiable computation over encrypted computation.

Jumping straight in, we will focus on the following closely:

1. Computation Model: Encrypted Execution vs Verifiable Execution

1.1 FHE Systems

Fully Homomorphic Encryption enables computation directly on ciphertexts:

Dec( Eval(f, Enc(x)) ) = f(x)

This allows data to remain encrypted during computation. In practice however, FHE blockchain adjacent systems (including designs explored by projects such as Zama) are typically hybrid architectures, not purely on chain execution systems. A realistic decomposition is:
On-chain layer:

• State commitments
• Access control logic

• Coordination of computation requests

  Execution layer (off-chain or specialized network):

• Homomorphic computation over ciphertexts

• Ciphertext transformation pipelines

  Key management layer:

• Threshold decryption or MPC based key control

The key constraint is that FHE is subject to circuit depth and noise growth constraints:

• Leveled FHE supports bounded computation depth
• Bootstrapped FHE removes depth limits but introduces significant computational overhead

Bootstrapping is not a minor optimization step; it is the dominant cost driver in fully homomorphic computation. Thus, FHE performance is fundamentally constrained by:

• ciphertext size
• multiplicative depth
• bootstrapping frequency

1.2 ZKP Systems (Midnight Model)

Midnight is based on Zero knowledge proof systems, specifically zk-SNARK style verifiable computation. The execution model is:

1. Input data remains local (private state)
2. Computation is executed off chain by a prover
3. A proof π is generated attesting correct execution
4. The blockchain verifiesπ

Formally:
∃ x such that f(x) satisfies constraints ⇒ Verify(π, public_inputs) = true

The key property here is is that the blockchain does not execute computation or process encrypted data. It only verifies correctness of a computation that already occurred off chain. This defines a verifiable computation model, not a confidential execution model.

2. State Architecture: Shared Encrypted State vs Commitment Based State

2.1 FHE State Model

FHE systems operate over encrypted shared state, where:

• all state is ciphertext
• multiple parties may interact with the same encrypted values
• correctness depends on secure transformation of ciphertext state

This introduces structural challenges such as:

• synchronization of encrypted state across participants
• secure ordering of encrypted state transitions
• encrypted comparisons for conditional logic
• coordination of decryption via threshold schemes

While FHE preserves confidentiality during computation, it introduces complexity in shared state consistency under encryption.

2.2 Midnight Kachina Model

Midnight uses a dual layer state model called Kachina, consisting of:

a) Public State (on chain)

• deterministic ledger state
• contains commitments and proof outputs
• used for consensus and global validation

b) Private State (off chain)

• stored locally by users or application environments
• never directly written to the ledger

State transition model

A transaction is defined as:
(Private State, Public State) → (New Private State, New Public State)
However, only the:

• public commitments
• zero knowledge proofs are submitted on chain.

As we have seen above the key property here is that Kachina avoids shared encrypted memory entirely. Instead of synchronizing encrypted state across participants, the system enforces correctness of state transitions via proof verification over committed state. This corresponds to a commitment based verifiable state transition system.

3. Performance and Scalability

3.1 FHE Systems

FHE performance is usually constrained by:

• Ciphertext expansion (often orders of magnitude larger than plaintext)
• Homomorphic multiplication cost (significantly higher than plaintext arithmetic)
• Bootstrapping overhead
• Circuit depth limitations (in leveled schemes)

Let:
T = number of homomorphic operations
C = ciphertext size
Then computational cost grows approximately as:
O(T × cost_homomorphic_op(C))

The Key bottleneck in this case it that Bootstrapping is the primary limiting factor in fully homomorphic computation and dominates runtime in deep circuits.

3.2 ZKP Systems (Midnight Model)

ZK systems separate execution cost from verification cost.
Let:
f(x) = computation
π = proof
Then:
Prover cost: O(f(x)) (execution + proof generation)
Verifier cost: O(1) or O(log n) depending on system

Key properties are:

• Proof size remains succinct (small and bounded)
• Verification cost is independent of computation complexity

Critical tradeoff:

• Prover cost is high (compute + memory intensive)
• Proof generation introduces user side latency

This latency ranges from seconds to minutes depending on circuit complexity and hardware availability. Thus:

• FHE shifts cost to the network/execution layer
• ZKPs shift cost to the prover/user layer

4. Concurrency and Shared State Consistency

4.1 FHE Model

FHE systems must support computation over shared encrypted state, which introduces:

• Encrypted condition evaluation (e.g., comparisons over ciphertexts)
• State synchronization across participants
• Ordering of encrypted state transitions
• Multi-user contention over shared encrypted variables

This results in a concurrency model that is tightly coupled to encrypted state consistency and ordering guarantees.

4.2 Midnight Model (Kachina)

Midnight avoids shared mutable encrypted state.
So instead:

• Users operate on private local state
• Interactions are expressed via commitments
• Correctness is enforced through proofs over state transitions

Conflict resolution occurs at the level of:

• proof validity
• Public state ordering
• Commitment consistency

This removes the need for:

• Encrypted shared memory coordination
• Encrypted state comparisons between users

The system enforces validity of transitions and not synchronization of hidden state

5. Developer Model

5.1 FHE Development Model

FHE application development requires reasoning over:

• encrypted arithmetic constraints
• Circuit depth limitations
• Noise growth and bootstrapping thresholds
• Ciphertext compatible data representations

Even with abstractions, developers must reason about the correctness under encryption constraints

5.2 Midnight Compact Model

Midnight introduces Compact, a domain specific language that compiles into zk-SNARK circuits.
Developers define:

• public inputs
• Private witness data
• Constraint logic

The compiler generates:

• arithmetic circuits
• Witness generation logic
• Proof constraints

Abstraction shift to take note of:

• FHE: compute under encryption constraints
• ZKPs: define conditions that must be proven true

6. Compliance and Selective Disclosure

6.1 FHE Model

FHE does not natively define selective disclosure semantics. Auditability typically requires:

• threshold decryption
• MPC based key release
• or external compliance layers

This introduces additional trust assumptions in:

• decryption governance
• key holder integrity

6.2 Midnight Model

Midnight supports selective disclosure via zero knowledge proofs. Users can prove predicates such as:

• Membership conditions
• Range constraints
• Compliance rules
• Non-membership conditions

without revealing underlying private inputs. However, real world compliance systems typically require:

• external identity binding layers
• regulatory integration beyond cryptographic proofs

ZKPs provide cryptographic primitives for compliance, not full regulatory systems.

Conclusion: Architectural Separation of Concerns

FHE and ZKPs represent fundamentally different system architectures:
FHE systems

• Compute over encrypted data
• Preserve confidentiality during execution
• Require coordination over encrypted shared state
• Shift computational burden to execution layer
• Constrained by bootstrapping and ciphertext overhead

ZKP systems (Midnight model)

• execute computation off chain
• prove correctness of execution on chain
• avoid shared encrypted state
• separate public and private state via commitments
• shift computational burden to prover side

Just to sum up Midnight’s architecture reflects a design choice toward:

• Minimal on chain computation
• Explicit state separation
• Succinct verification
• Cryptographic proof based system integrity