ULedgerNET Cryptographic Foundation

Overview

ULedgerNET implements a comprehensive cryptographic framework supporting multiple signature schemes, hash functions, and zero-knowledge proof systems. This multi-algorithm approach provides flexibility for different security requirements, including post-quantum readiness.

Supported Cryptographic Algorithms

Signature Schemes

Algorithm Comparison

Algorithm	Type	Key Size	Signature Size	Security Level	Quantum Safe
secp256k1	ECDSA	256 bit	64-72 bytes	128-bit	❌
ED25519	EdDSA	256 bit	64 bytes	128-bit	❌
BLS12-377	Pairing	384 bit	96 bytes	128-bit	❌
ML-DSA-87	Lattice	2592 bytes	4627 bytes	256-bit	✅

Signature Schemes in Detail

secp256k1 (Default)

The default signature scheme, widely used in blockchain systems.

Use Cases:

• Standard transactions
• Wallet operations
• Smart contract interactions
• Maximum ecosystem compatibility

ED25519

High-performance EdDSA signatures.

Advantages:

• Faster signature verification
• Deterministic signatures (no random nonce)
• Resistance to side-channel attacks
• Smaller code footprint

Use Cases:

• High-throughput environments
• IoT and embedded systems
• Performance-critical applications

BLS12-377

Pairing-based cryptography enabling advanced features.

Unique Capabilities:

• Signature aggregation (multiple signatures → one)
• Threshold signatures
• ZK-SNARK compatibility
• Efficient multi-party signing

Use Cases:

• Consensus vote aggregation
• Multi-signature wallets
• Privacy-preserving protocols

ML-DSA-87 (Post-Quantum) 🔒

NIST Post-Quantum Standard based on the CRYSTALS-Dilithium algorithm.

Security Properties:

• Based on Module Learning with Errors (MLWE) problem
• NIST Security Level 5 (256-bit equivalent)
• Resistant to both classical and quantum attacks
• Standardized in FIPS 204 (2024)

Trade-offs:

• Larger key and signature sizes
• Suitable for long-term security requirements
• Recommended for high-value or sensitive transactions

Hash Functions

Supported Hash Algorithms

Hash Function Selection

Hash Function	Output Size	Use Case	ZK-Compatible
SHA-256	256 bit	General purpose	❌
SHA3-256	256 bit	Transaction IDs	❌
SHA3-512	512 bit	Block hashing	❌
MiMC-BN254	254 bit	Groth16 proofs	✅
MiMC-BLS24315	315 bit	PLONK proofs	✅
MiMC-BW6-761	761 bit	BLS proofs	✅

Why ZK-Friendly Hashes?

Standard hash functions like SHA-256 are computationally expensive to prove in zero-knowledge circuits. MiMC is designed specifically for efficient ZK computation:

Zero-Knowledge Proof Systems

Proof Systems Overview

Groth16 (Transaction Proofs)

Used for proving transaction validity without revealing private inputs.

Circuit Structure:

Supported Key Types for Groth16:

• secp256k1 (ECDSA circuit)
• BLS12-377 (BLS circuit)

PLONK (Block Proofs)

Used for proving block header integrity and Merkle tree correctness.

What PLONK Proves:

Proof System Comparison

Aspect	Groth16	PLONK
Proof Size	~200 bytes	~500 bytes
Verification Time	~1-2ms	~3-5ms
Setup	Per-circuit	Universal
Use Case	Transactions	Blocks

Key Derivation

Deterministic Key Generation

All key types can be derived from a single seed:

Benefits:

• Single backup for all key types
• Consistent identity across algorithms
• Easy key rotation and recovery

Configuring Cryptography

Blockchain-Level Configuration

{
  "blockchainId": "my-chain",
  "keyType": "secp256k1",
  "hashingStrategy": "HASH_SHA3_256"
}

Available Key Types

Config Value	Algorithm
secp256k1	ECDSA on secp256k1 (default)
ed25519	EdDSA on Curve25519
bls12377	BLS signatures
mldsa87	ML-DSA-87 (post-quantum)

Available Hashing Strategies

Config Value	Algorithm
HASH_SHA256	SHA-256
HASH_SHA3_256	SHA3-256
HASH_SHA3_512	SHA3-512
HASH_MIMC_BN254	MiMC on BN254
HASH_MIMC_BLS24315	MiMC on BLS24-315

Migration Path to Post-Quantum

Recommended Approach

Considerations

Factor	Classical	Post-Quantum
Key Size	Small (33 bytes)	Large (2.5 KB)
Signature Size	Small (64-72 bytes)	Large (4.6 KB)
Verification Speed	Fast	Moderate
Long-term Security	At risk	Assured

---

Next: Network Architecture