Lesson 3 of 3

Lesson 104.3: The Cost of Privacy

SLT: I can evaluate the cost of privacy in a concrete scenario and articulate when the cost is justified.

Type: Exploration


Privacy Is Not Free

You've now built with both contracts. The public version and the private version do the same thing — check an answer. The private version hides the answer. But "hiding" isn't a toggle you flip. It's a set of costs you pay.

This lesson makes those costs concrete.


Cost 1: Time

From the preprod deployment:

Operation

Public Contract

Private Contract

Difference

Circuit execution (local)

< 1s

< 1s

Same

Proof generation

~1.2s

~1.2s

Same for simple circuits

Transaction round-trip

~30-60s

~30-60s

Same

Block confirmation

~6s

~6s

Same

For these simple contracts, the timing is identical. Both generate a ZK proof. Both go through the full transaction lifecycle. The privacy difference is in what the proof contains, not how long it takes to generate.

But this changes with complexity. The proof generation time scales with the number of constraints in the circuit. The private-answer contract has roughly the same number of constraints as the public one — the only difference is one fewer disclose() call, which doesn't add significant computation.

For more complex contracts — the bulletin board with its Merkle tree operations, or a credential system with set membership proofs — proof generation will take longer. Each additional constraint adds to the prover's workload.

Cardano comparison: A Cardano transaction with the same logic (check an answer hash) takes seconds to build and ~20 seconds to confirm. Total: ~25 seconds. The Midnight equivalent: ~45-60 seconds. The premium is proof generation.


Cost 2: Compute

The proof server is a native binary running in Docker. It's CPU-intensive.

Resource

Requirement

CPU

Significant — proof generation is the bottleneck

Memory

Moderate — depends on circuit size

Disk

Minimal — prover/verifier keys are small

Docker

Required — proof server runs as a container

On an Apple Silicon Mac, the proof server completes a simple proof in ~1.2 seconds. On x86 Linux, comparable. On ARM Macs with the platform: linux/amd64 Docker flag (which forces emulation), performance degrades dramatically — this was a scaffolder bug that shipped with create-mn-app.

For developers: Running the proof server locally is fine for development and testing. For production, you need a proof server deployment strategy. Options:

  • Client-side — user runs proof server (maximum privacy, most friction)
  • Server-side — you run proof server for users (less friction, you see pre-proof inputs)
  • WebAssembly — browser-based proving (planned, not yet available)

Each option trades between privacy and convenience. The proof server sees private inputs by design — it needs them to generate the proof.


Cost 3: DUST (Gas)

Every Midnight transaction costs DUST. DUST is generated from staked NIGHT, not purchased.

The deploy script retries up to 8 times with 15-second intervals if DUST is insufficient. A freshly created wallet may not have enough DUST for its first transaction because DUST accumulates over time from staked NIGHT.

Cost structure:

  • Deploying a contract: DUST for deployment proof verification
  • Calling a circuit: DUST for circuit proof verification
  • Each retry after a "Not enough Dust" failure: waiting time (DUST accumulates in blocks)

Unlike Cardano where you pay ADA immediately from your wallet, DUST requires a generation period. For new wallets, this means a cold-start delay — you can't transact until enough DUST has accumulated.

Cardano comparison: On Cardano, transaction fees are ADA, payable immediately from any funded wallet. No generation period. No accumulation. The fee amount is predictable before submission. On Midnight, DUST costs are less predictable because generation rate depends on NIGHT staking and network parameters.


Cost 4: Complexity

The private-answer contract is simpler than the public one — fewer ledger fields, fewer disclose() calls. But the surrounding infrastructure is identical in complexity:

Component

Required for Public

Required for Private

Difference

Compact contract

Yes

Yes

Simpler (fewer fields)

Proof server

Yes

Yes

Same

Wallet (3 types)

Yes

Yes

Same

Providers (6)

Yes

Yes

Same

Deploy pipeline

Yes

Yes

Same

Indexer connection

Yes

Yes

Same

The privacy isn't in the DApp complexity — it's in the disclose() decisions. But the infrastructure that enables privacy (proof server, multi-wallet, ZK compilation) is required for all Midnight contracts, even ones that disclose everything.

You pay the infrastructure cost of privacy whether you use the privacy features or not.


Cost 5: Failure Model

On Cardano, a failed transaction costs nothing. It's rejected entirely. Retry for free.

On Midnight, the guaranteed phase (fee payment) executes even if the fallible phase (your contract logic) fails. If you submit to the private contract and the state has changed since you computed your transcript (Lesson 102.2), you pay DUST and get nothing.

This isn't specific to privacy — it's the Midnight failure model. But it matters more when privacy is involved, because:

  • You can't inspect why someone else's transaction succeeded (it might have changed the state your transaction depends on)
  • Failed transactions don't reveal your private inputs (good for privacy, bad for debugging)
  • Retry requires recomputing the proof (another ~1.2 seconds + round-trip)

When Privacy Is Worth the Cost

The costs above apply to every Midnight transaction. The question is when the privacy benefit justifies them.

Privacy is clearly justified when:

Exposure causes harm. A wrong answer on a public contract is immortalized — embarrassing at best, identity-revealing at worst. A private contract protects learners from the cost of honest attempts. Voting, medical records, financial positions, legal proceedings — exposure has real consequences.

The answer space is valuable. If right answers can be copied from on-chain data, the public contract undermines the assessment. The private contract preserves the value of independent work.

Behavioral patterns leak information. Even if individual transactions are harmless, patterns reveal strategy. On Cardano, a series of transactions from the same wallet tells a story. On Midnight with shielded DUST, fee payments don't link to identity.

Privacy may not be justified when:

Transparency IS the value. A public credential backed by visible evidence is worth more than a private attestation. "Here's what I did — verify it yourself" beats "Trust the math that I qualified." If your application's value comes from public verifiability, Midnight's privacy layer adds cost without adding value.

Latency is critical. Real-time applications — live auctions, gaming, interactive governance — may not tolerate 30-60 second transaction times. Cardano's faster preparation (but slower blocks) might be a better fit.

The ecosystem maturity matters. Midnight is pre-mainnet. SDK versions change. Breaking changes happen between releases. If production reliability matters more than privacy features, Cardano's mature ecosystem is the safer choice today.

The infrastructure overhead isn't justified. If your application would disclose everything anyway (a public registry, a transparent governance record), the proof server, DUST management, and multi-wallet architecture are overhead with no privacy return.


The Decision for This Course's Example

The private-answer contract is a clear case where privacy is justified:

Factor

Assessment

Exposure harm

Wrong answers immortalized, right answers copyable — clear harm

Latency tolerance

Course submission, not real-time — 60 seconds is acceptable

Infrastructure cost

Same as public (proof server required regardless)

DUST cost

Same as public (both generate proofs)

Value of transparency

Low — what matters is whether the answer is correct, not what it was

Verdict

Privacy justified. The private version is strictly better for this use case.

The public contract exists as a teaching tool — to show what happens when you DON'T use privacy. In production, you'd only deploy the private version.


Questions to Consider

  • For the credential comparison from Module 106: an Andamio credential on Cardano publicly shows what someone did. A Midnight credential proves they qualified without showing details. The Cardano credential's value comes from being inspectable. When would you want both — public evidence of work AND private proof of qualification?
  • Proof generation time will decrease as hardware improves and proof systems optimize. At what latency does the privacy cost become negligible? 5 seconds? 1 second? Sub-second?
  • The private contract hides the answer but discloses pass/fail. For a two-option question (yes/no), the result IS the answer. How small can the answer space be before disclose(result) effectively discloses the input?

What's Next

Module 104 is complete. You've built a privacy-preserving app (104.1), compared transaction lifecycles (104.2), and evaluated the cost of privacy (this lesson). Module 105 covers token economics — NIGHT/DUST, sponsored transactions, and application design.


Conversation Starters

You're advising a team building a compliance reporting system. They need to prove that their organization meets regulatory requirements without exposing internal data.

Apply this lesson's cost framework:

  • Time cost: Can the compliance filing tolerate 30-60 second proof generation? (Probably yes — regulatory filings aren't real-time.)
  • Compute cost: Who runs the proof server? The organization? A trusted auditor? What are the trust implications?
  • DUST cost: How frequently are proofs submitted? Daily? Quarterly? Is DUST accumulation sufficient?
  • Complexity cost: Is the team prepared to maintain Midnight infrastructure alongside their existing stack?
  • Failure cost: What happens if a compliance proof fails due to a state conflict? Is there a retry window?

Then: is the privacy worth the cost? What would happen if they submitted compliance data on a public chain instead?