Homomorphic Encryption: Math on Locked Boxes

What Problem Does It Solve?

The Challenge:

Blockchain needs to:
  ✓ Verify transactions (amounts valid)
  ✓ Update balances (addition/subtraction)
  ✓ Ensure no double-spending
  
But WITHOUT revealing:
  ✗ Account balances
  ✗ Transaction amounts
  ✗ Any private information

The Solution: Homomorphic Encryption

• ✅ Math happens on encrypted data
• ✅ No decryption ever required
• ✅ Privacy never broken
• ✅ Blockchain can verify without seeing amounts

The Simple Analogy

You have $500 in a locked safe
Someone sends you $100

Normal way:
  1. Open safe (decrypt) → See $500
  2. Add $100 → Now $600
  3. Lock safe again (encrypt)
  
Problem: When safe is open, anyone can see $500
    Privacy: ❌ Broken

For DERO:

• Balance is always encrypted (safe always locked)
• Math happens on the encrypted number
• Safe never opens
• Blockchain never sees actual balance

How It Works

The Encryption Flow

The Setup:

Private key: x (your secret)
Public key:  P = x × G (everyone can see this)
Generator:   G (elliptic curve point - public constant)

Encrypting an Amount

Conceptual flow (actual implementation: CommitElGamal at cryptography/crypto/algebra_elgamal.go:44-50; the numbered steps below are docs annotations, not source comments):

// Encrypt 100 DERO (illustrative):
// 1. Pick random number 'r'    (RandomScalarFixed)
// 2. Calculate Left:  L = 100 × G_value + r × P_recipient
// 3. Calculate Right: R = r × G_randomness
// 4. Ciphertext: E(100) = (L, R)

The Magic: Homomorphic Operations

Addition & Subtraction on Encrypted Data:

The Math:

E(a) = (L₁, R₁)
E(b) = (L₂, R₂)

Addition:
  E(a) + E(b) = (L₁ + L₂, R₁ + R₂) = E(a + b)
  
Subtraction:
  E(a) - E(b) = (L₁ - L₂, R₁ - R₂) = E(a - b)

The encrypted result is STILL encrypted!
No decryption needed at any step!

Transaction Flow: Alice → Bob

Alice sends 100 DERO to Bob:

A common point of confusion: ring size and amount privacy are independent properties. The conservation above holds regardless of how many decoys the ring contains — the cryptographic reason amounts stay hidden has nothing to do with how many ring members there are.

This is why ring size 2 — which removes sender anonymity by design — still leaves the transferred amount fully encrypted. The two privacy properties are decoupled.

What Happens at Each Step

Alice's balance: E(500) = (L_a, R_a)
Bob's balance:   E(200) = (L_b, R_b)
Transfer amount: 100 DERO

Comparison: Traditional vs DERO

Balance Storage

The Difference:

• Bitcoin/Ethereum: Your balance is like your bank statement posted on a billboard
• DERO: Your balance is permanently locked in a safe only you can open

Blockchain Architecture Comparison

DERO = Ethereum's simplicity + Privacy coin encryption 🎯

Real-World Applications

1. Instant Balance Queries

Traditional Privacy Coin:

1. Download entire blockchain
2. Scan all transactions
3. Calculate balance from history
4. Wait minutes to hours

Result: Slow, requires full sync

DERO:

1. Query encrypted balance from node (66 bytes)
2. Decrypt with your private key
3. See balance instantly

Result: Instant, no chain scanning needed

The 66 bytes referenced above are load-bearing — they are literally all a DERO wallet pulls from the network to operate. Captain on the wallet sync model:

This is why DERO wallets open in seconds — to display your current balance the wallet pulls only the 66-byte ciphertext (GetEncryptedBalanceAtTopoHeight) and decrypts locally. Captain's quote above is explicit about the split: blocks and transactions are required to build and maintain history, so when balance changes the wallet binary-searches to the specific blocks where the change happened (walletapi/daemon_communication.go SyncHistory) — but that's bounded by activity, not by chain length. Traditional privacy-coin wallets that linearly scan every block don't have that shortcut.

2. Private Token Systems

How It Works:

Key Points:

Source (verbatim from tests/normal/multi_deposit_test/asset.bas:11-15):

    // Issue Asset after depositing DERO (Convert DERO to TOKENX)
    Function IssueAsset() Uint64
    10  SEND_ASSET_TO_ADDRESS(SIGNER(), DEROVALUE(),SCID())   // send asset without knowing original balance, this is done homomorphically
    20  RETURN 0
    End Function

The SEND_ASSET_TO_ADDRESS DVM function is registered at dvm/dvm_functions.go:80; the BASIC sample above is the canonical example contract in the test suite.

Result in user's wallet:
  User's token balance: E(1000)  ← Encrypted, only user can decrypt
  User's DERO balance:  E(500)   ← Also encrypted

Traditional tokens (ERC-20): Balances public in contract
DERO tokens: Balances encrypted in user wallets, transferable peer-to-peer

3. Private DeFi Operations

Swap Example:

Swap 100 DERO for 500 tokens:

  Your DERO:  E(balance_dero) - E(100)
  Your tokens: E(balance_tokens) + E(500)
  
Public sees:
  ✓ Swap contract called
  ✗ How much swapped
  ✗ Who swapped
  ✗ Resulting balances

Technical Implementation

The C and D Commitments

Every DERO transaction contains encrypted commitments:

C Commitment (per ring member — ElGamal-style, not Pedersen):

// One C[i] per ring slot; pubkey[i] is the slot's public key.
C[i] = ±amount × G + r × pubkey[i]   // sender slot: -amount; receiver slot: +amount; decoys: 0
                                     // (see walletapi/transaction_build.go:152-206)
Where:
  amount     = Transfer amount in atomic units (hidden)
  G          = Pedersen value generator (global_pedersen_values.G)
  r          = Transaction-wide blinding scalar (same r across the ring)
  pubkey[i]  = Ring slot's public key — this is the second generator, NOT a global H
 
Properties:
  • Binding: Cannot change amount after creating C[i] (discrete-log hard)
  • Hiding: Cannot determine amount or which slot is real from C[i] alone
  • Homomorphic on accepted balance: nb.Balance.Add(echanges) at
    blockchain/transaction_execute.go:239 sums an ElGamal change
    ciphertext into the receiver's encrypted balance.

Why this is not Pedersen. Pedersen uses a fixed generator pair (G, H). DERO's per-ring construction reuses each ring member's public key as the second generator (r × pubkey[i]), which is what makes the same encryption serve both as an anonymity-set commitment and as a per-receiver decryption hint. The two families share the homomorphic add property; the security argument differs.

D Commitment (shared across the whole anonymity set, not per recipient):

D = r × G  // single value for the entire payload (one D field on Statement,
           // see cryptography/crypto/protocol_structures.go:38)
 
Purpose:
  • Acts as the public "Right" half of the ElGamal triple
  • Combined with the receiver's secret key to recover the shared secret
  • Same D for all ring members — the receiver-specific shared key is
    derived from D plus the receiver's own secret

Together they enable:

• ✅ Encrypted amounts in transactions
• ✅ Verifiable without revealing amounts
• ✅ Homomorphic balance updates

Source: cryptography/crypto/algebra_elgamal.go — ElGamal encryption implementation. Key entry points: CommitElGamal at algebra_elgamal.go:44 (encryption / commitment construction) and Add at algebra_elgamal.go:69 (homomorphic ciphertext addition).

Technical Specifications

Key Takeaways

What Homomorphic Encryption Provides

What It Enables

• ✅ Private Smart Contracts - Impossible on other chains
• ✅ Instant Balance Lookup - No blockchain scanning
• ✅ Encrypted Token Systems - Private token transfers
• ✅ Private DeFi - Encrypted swap operations
• ✅ Account-Based Privacy - First blockchain to achieve this

Related Pages

Privacy Suite:

• Ring Signatures - Transaction anonymity
• Bulletproofs - Zero-knowledge range proofs
• Transaction Privacy - Complete privacy flow
• Payload Proofs - Prove transfers cryptographically

Technical Implementation:

• DERO Tokens - How tokens use homomorphic encryption
• Private Smart Contracts - Contract encrypted balances

Build with Privacy:

• Token Contract - Private token example
• Wallet RPC API - Send private transactions