Lunul (LUN) | Technical Whitepaper

A High-Performance, Fee-Only, Zero-Knowledge Privacy Architecture with BFT Finality

Abstract

As blockchain adoption matures globally, the tension between ledger transparency and user confidentiality has reached a critical juncture. While high-throughput layer-1 networks successfully scale transaction execution, they do so by sacrificing user privacy, exposing account balances, transaction graphs, and counterparty relationships. Conversely, legacy privacy coins often compromise throughput, user experience, and programmatic smart contract composability.

Lunul (Null Net) introduces an advanced paradigm: a high-output, parallelized zero-knowledge transaction architecture backed by a Tendermint-style Byzantine Fault Tolerant (BFT) consensus engine. By anchoring state transitions in Pedersen commitments, Groth16 zk-SNARK circuits, and a deterministic spent nullifier database, Lunul achieves complete transactional confidentiality alongside sub-second finality and over 65,000 transactions per second (TPS).

1. Introduction & Background

The modern blockchain landscape is split into two distinct paradigms:

• High-Performance Public Ledgers: Networks optimized for raw throughput (such as Solana or parallelized EVMs) which leave all data visible in plaintext, exposing users to financial surveillance.
• Anonymity-Centric Networks: Blockchains like Monero or Zcash that prioritize privacy but struggle with high-throughput execution, complex smart contract composability, or heavy proof generation times.

Lunul reconciles these divergent goals by embedding zero-knowledge proofs directly into the state transition function. Transactions are private by default, concealing the sender, receiver, and transferred value $v$ via cryptographic commitments, while remaining fully verifiable by decentralized BFT validators.

Core Objectives

• Default Privacy: Obfuscating sender identities, recipient addresses, and transfer amounts using Pedersen commitments and stealth routing.
• Extreme Scalability: Achieving over 65,000 TPS through parallelized execution and optimized zk-SNARK constraint verification.
• Fee-Only Economic Model: Eliminating inflationary block subsidies in favor of direct public fee extraction ($\sum \text{Inputs} = \sum \text{Outputs} + \text{Fee}$).
• Ecosystem Compatibility: Seamless developer onboarding via familiar tooling, libraries, and cross-chain bridging primitives.

2. Core Cryptographic and Privacy Layer

2.1 Pedersen Commitments and Blinding Factors

In Lunul, unspent transaction outputs (UTXOs) are not recorded as raw plaintext amounts. Instead, they are represented as cryptographic commitments on elliptic curves:

$$C = r \cdot G + v \cdot H$$

Where:

• $v$ is the raw transfer value.
• $r$ is a randomly generated 256-bit blinding factor (scalar).
• $G$ and $H$ are independent generators of the elliptic curve group (specifically utilizing the BN254 / alt_bn128 pairing-friendly curve).

Neither validators nor external observers can extract the value $v$ or blinding factor $r$ from $C$ alone, preserving strict confidentiality while permitting homomorphic validation of value conservation.

2.2 Nullifier Double-Spend Barrier

To prevent double-spending without revealing which UTXO is being spent, Lunul utilizes deterministic nullifiers. When a UTXO at index $i$ is consumed, the owner computes a nullifier using their secret spending key ($SK$):

$$\text{Nullifier} = \text{Hash}(SK, \text{UTXO\_Index})$$

The resulting nullifier hash is published to the global Spent Nullifier Set. If a nullifier is submitted a second time, the state machine instantly rejects the transaction, preventing double-spending while preserving recipient and sender anonymity.

2.3 Groth16 ZK-SNARK Prover Pipeline & QAP Mathematics

Client-side wallets execute arithmetic circuit constraints in WebAssembly (WASM) before broadcasting transactions. Lunul employs the Groth16 proving system over pairing-friendly elliptic curves.

Quadratic Arithmetic Programs (QAPs) translate circuit constraints into polynomial relations. Let the witness polynomials satisfy $A(x)B(x) - C(x) = H(x)T(x)$. The pairing equation verified by validators is:

$$e(A, B) = e(\alpha, \beta) \cdot e(L, \gamma) \cdot e(C, \delta)$$

This ensures that the transaction satisfies conservation of value ($\sum \text{Inputs} = \sum \text{Outputs} + \text{Fee}$) without revealing any underlying private parameters.

3. BFT Consensus Engine & Fee-Only Incentive Model

3.1 Tendermint-Style BFT Consensus

Lunul utilizes a robust 4-phase BFT consensus protocol across decentralized validator nodes (Alpha, Beta, Gamma, Delta):

1. Pre-vote: Validators sign proposals and verify cryptographic proofs of incoming batches.
2. Pre-commit: Supermajority threshold signatures ($>2/3$) lock in the block proposal.
3. Commit: The block is appended to the ledger state tree.
4. Execute: State updates (new commitments added, nullifiers marked spent) are finalized.

3.2 Fee-Only Economic Model

Unlike traditional blockchains that rely on inflationary block rewards, Lunul operates on a fee-only economic model. Validators process transactions exclusively for explicit public fees attached to the ZK balance relation:

$$\text{Fee} = \sum \text{Inputs}_{\text{value}} - \sum \text{Outputs}_{\text{value}}$$

This design guarantees long-term economic sustainability without coin dilution.

4. Genesis Block, Tokenomics & Supply

The native utility and governance token of the Lunul ecosystem is LUN.

4.1 Token Supply & Distribution

Total Fixed Supply: 1,000,000,000 (1 Billion) LUN.

4.2 Deflationary Burn Mechanism

To counteract circulation expansion, 10% of all transaction and bridge fees are permanently burned, while dynamic fee adjustments maintain network accessibility.

5. Network Setup and Deployment Guide

5.1 System Requirements for Validators

• CPU: 16+ Cores (optimized for multi-scalar multiplication and pairing checks).
• RAM: 64 GB ECC Memory.
• Storage: 2 TB NVMe SSD (fast I/O for nullifier state tree lookups).
• Network: 1 Gbps symmetrical unmetered connection.

5.2 Initializing a Validator Node

# Clone the official Lunul runtime repository
git clone https://github.com/lunul-network/nullnet-core.git
cd nullnet-core

# Install Rust toolchain and dependencies
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
cargo build --release

# Initialize genesis state and configure validator keys
./target/release/nullnet init --validator-name "Validator-Alpha" --chain-id lunul-mainnet-1

6. Governance Model

Governance over protocol upgrades, fee parameters, and treasury allocation is managed via Quadratic Voting by LUN token holders.

• Proposal Submission: Requires staking a minimum threshold of LUN.
• Voting Period: Active for 14 days with a mandatory 25% quorum participation.
• Quadratic Weighting: Voting power $VP$ is calculated as $VP = \sqrt{\text{Tokens Staked}}$, preventing plutocratic capture while giving voice to smaller community stakeholders.

7. Conclusion

Lunul Null Net successfully bridges the gap between ultra-high performance and uncompromising privacy. By marrying parallelized execution, Groth16 ZK-SNARKs, Pedersen commitments, and a deflationary fee-only BFT model, Lunul provides a robust foundation for the next generation of private decentralized applications, enterprise finance, and cross-chain settlements.