Threat Model & Cryptography

Umbra's threat model and cryptographic foundations — security guarantees, attack vectors, and defensive mechanisms.

At Umbra, we have taken the utmost care to work in a dishonest majority setting. This page details our threat model, security assumptions, and the cryptographic primitives that protect against various attack scenarios — from threshold MPC security against dishonest majorities, to encryption with Rescue Cipher for balance privacy, to zkSNARK-based proofs that ensure transaction integrity without revealing sensitive information.

1. MPC Threat Model & Threshold Cryptography

At the core of Umbra’s key management lies a Multi-Party Computation (MPC) network that operates under a dishonest majority security model. This means:

We use n/n threshold cryptography, where all MPC nodes must cooperate to reconstruct a decryption key.
If even one node remains honest, your encrypted data cannot be decrypted by an attacker.
This setup assumes the worst case — a majority of nodes could collude or be compromised — and still guarantees data confidentiality as long as one node remains uncompromised.

🔗 References:

Why This Matters

Because we assume an adversarial setting, we encrypt your data before it ever enters the MPC network using the Rescue Cipher. This ensures:

Even a malicious or fully colluding MPC network cannot access plaintext data.
The MPC network can only operate on ciphertext, never leaking secrets.

This combination of encryption + threshold security gives us defense-in-depth, making Umbra resilient against both external and insider attacks.

2. Rescue Cipher: Secure, Efficient Encryption

Umbra uses the Rescue Cipher, an arithmetically optimized block cipher based on the Rescue-Prime hash function.

Key Properties:

Optimized for ZK-Friendly Computation: Rescue is designed to minimize arithmetic constraints, making it ideal for use with zero-knowledge proof systems.
Deterministic & Secure: The cipher guarantees confidentiality while being lightweight for on-chain verification.
Field Operations: The Rescue cipher operates over the prime field on which the Ed25519 curve is created, since the cipher works on field elements.

🔗 References:

Mathematically, encryption follows:

C = E_k(M)

Where:

$( C$ ) is the ciphertext
$( M$ ) is the plaintext message
$( k$ ) is the encryption key
$( E_k$ ) represents Rescue Cipher encryption function

This ensures that even if the MPC system were compromised, your encrypted data $( C$ ) cannot be reverted to $( M$ ) without $( k$ ).

3. Zero-Knowledge Proofs (zkSNARKs)

Umbra leverages zkSNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) to provide privacy-preserving proofs.

Why zkSNARKs?

Succinctness: Proofs are extremely small and fast to verify on-chain.
Non-Interactivity: No back-and-forth communication is needed, making withdrawals efficient.
Soundness & Completeness: You can only generate a valid proof if you actually own a deposit in the Merkle tree — no false claims possible.

Curve Choice

We implement zkSNARKs over the BN254 curve, which is widely used in ZK systems for its performance and security properties.

🔗 References:

Formally, a zkSNARK proof guarantees:

\text{Verify}(pk, \pi, x) = \text{true}

Only if:

\exists w : C(x, w) = 1

Where:

$( pk )$ = proving key
$( \pi )$ = proof
$( x )$ = public input
$( w )$ = private witness
$( C(x, w) )$ = circuit constraint system

This guarantees that the prover knows a valid witness $( w )$ (e.g., a valid Merkle path) without revealing it.

4. Incremental Merkle Tree for Commitments

Umbra uses an incremental Merkle tree to manage commitments efficiently.

Each deposit generates a Poseidon-hashed commitment.
The commitment is inserted into the tree, updating only the necessary branch nodes.
This allows users to later prove inclusion in the tree without revealing which leaf belongs to them.

🔗 References:

Mathematically, the root $( R$ ) of the Merkle tree after inserting a commitment $( C$ ) is:

R = H(H(...H(C, S_1)...), S_h)

Where $( S_i )$ are sibling nodes and $( H )$ is the Poseidon hash function.

5. Concurrent Sparse Merkle Tree for Cost Optimization

To minimize cost and maximize efficiency, Umbra uses a Concurrent Sparse Merkle Tree (CSMT) instead of the naive PDA-based approach.

Naive PDA Approach (And Its Limitations)

For every deposit and claim, a new PDA account would need to be created on-chain.
This incurs storage rent costs (PDA token storage cost) for each deposit/claim.
As the number of users grows, this becomes prohibitively expensive and wastes on-chain space.

Our Approach

By using a CSMT:

We store all commitments within a single, shared tree structure.
No per-user PDA needs to be created for deposits or claims.
Users can still prove ownership of their commitments efficiently using Merkle proofs.
The tree supports concurrent updates, so multiple users can deposit without blocking one another.

This design drastically reduces on-chain storage costs, making Umbra affordable and scalable for mass adoption.

🔗 References:

Summary of Cryptographic Components

Component	Purpose	Implementation	Reference
MPC (n/n)	Key management under dishonest majority	Threshold cryptography	Paper
Rescue Cipher	Encryption before MPC	Rescue-Prime, Ed25519 curve	Spec
zkSNARKs	Privacy-preserving withdrawal proofs	BN254 curve	Explainer
Incremental Merkle Tree	Commitment management	Poseidon hash	Spec
Concurrent Sparse Merkle Tree	Cost-efficient state storage	Shared tree structure, concurrent updates	Research

Cost Advantage:
Unlike the naive PDA approach, Umbra’s use of a CSMT removes the need for per-deposit PDA storage, drastically cutting Solana rent fees and keeping user transaction costs minimal — even at scale.

This combination of cryptographic primitives ensures Umbra is secure, privacy-preserving, and cost-effective for users on Solana.

Threat Model & Cryptography

On this page