Cryptography in Hyperscale-rs

Learning Objectives

• Understand why BLS is used for quorum and state certificates
• Compare signature schemes used in blockchain (table)
• Understand how libp2p identity and validator bind (BLS over PeerId) work
• See where BLS and Ed25519 appear in the repo
• Understand QC and StateCertificate aggregation

Cryptographic Topics Around Merkle Trees, State Roots, and QC Certificates

Reference table: where each concept fits and what you need to know for blockchain and Hyperscale-rs.

Category	Concept	What It Is	Where It Appears	What You Need to Know
Cryptographic Hashing	Hash Functions	Deterministic one-way functions producing fixed-size outputs	Everything in blockchains	SHA-256, Keccak, collision resistance, preimage resistance
Authenticated Data Structures	Merkle Trees	Binary tree where leaves hash data and parents hash children	Bitcoin blocks, Ethereum state, rollups	Building trees, generating proofs, verifying proofs
Authenticated Data Structures	Merkle Proofs	Minimal set of hashes proving a leaf belongs to a tree	SPV clients, rollups, state sync	Proof construction, proof verification
Authenticated Data Structures	Merkle Patricia Trees	Trie structure optimized for key-value state	Ethereum state root	Tries, path compression, key hashing
Authenticated Data Structures	Sparse Merkle Trees	Efficient tree for huge key spaces	zk rollups, stateless blockchains	Bit paths, default nodes, proof compression
Authenticated Data Structures	Verkle Trees	Vector commitment trees replacing Merkle trees	Ethereum future roadmap	Polynomial commitments, vector commitments
Blockchain State	State Root	Hash of the entire world state	Ethereum block header	State transitions, trie updates
Blockchain State	Transaction Root	Merkle root of transactions in a block	Bitcoin, Ethereum	Transaction ordering, proof generation
Blockchain State	Receipt Root	Merkle root of execution receipts	Ethereum	Log proofs
Distributed Consensus	Quorum Certificate (QC)	Aggregated signatures proving consensus majority	HotStuff, Aptos, Sui, Diem	BFT consensus, quorum intersection
Distributed Consensus	Block Commit Proof	Evidence a block was agreed upon	Tendermint, HotStuff	Finality proofs
Digital Signatures	Signature Schemes	Cryptographic proof of identity	Validators sign blocks and votes	ECDSA, EdDSA, BLS
Signature Aggregation	BLS Aggregation	Combine many validator signatures into one	Ethereum 2, some BFT chains	Pairing cryptography
Distributed Systems	Byzantine Fault Tolerance	Consensus despite malicious nodes	HotStuff, PBFT	Quorum math, liveness vs safety
Distributed Systems	State Machine Replication	Deterministic execution replicated across nodes	All blockchains	Deterministic execution
Zero Knowledge	Commitment Schemes	Hide data but allow verification later	ZK rollups	Pedersen commitments
Zero Knowledge	Polynomial Commitments	Commit to polynomial evaluations	Verkle trees, SNARKs	KZG commitments
Zero Knowledge	SNARK/STARK Proofs	Succinct proofs verifying computation	zkSync, Starknet	Constraint systems

Why BLS is chosen

The repo doesn’t spell out “we chose BLS because …” in one place, but the usage makes the reason clear: aggregatable signatures for consensus.

• QuorumCertificate holds a single Bls12381G2Signature that is an aggregated signature from 2f+1 validators for the same message (block hash, etc.).
• StateCertificate also uses an aggregated BLS signature from many StateVoteBlocks.

Type definitions: see Suggested crates / files to study.

Flow:

1. Many validators sign the same message (e.g. block hash).
2. Their BLS signatures are combined into one aggregated signature.
3. You store and verify one signature and one aggregated public key, instead of N Ed25519 signatures.

That gives:

• Constant size and cost — QC size and verification cost don’t grow with committee size.
• Compact quorum certificates — One 96-byte BLS G2 signature instead of N×64-byte Ed25519 signatures.
• Same-message aggregation — Matches the “everyone signs this block hash” pattern (as in Ethereum 2, Chia, etc.).

In the types module, the split is summarized as: Ed25519 for “fast signing” and BLS (BLS12-381 G1 pubkey / G2 sig) for “aggregatable signatures”. So BLS is chosen for quorum/state certificates; the keygen binary generates the validator BLS key (from a 32-byte hex seed or at random) used in that aggregation scheme.

Signature schemes: comparison

Different schemes are used for different roles. The table below summarizes pros and cons so you can see why BLS fits consensus certificates and why Ed25519 is used where aggregation isn’t needed.

Scheme	Typical use	Pros	Cons
Ed25519	Tx signing, fast one-off signatures	Fast signing/verify; small keys & sigs; no pairing	No native aggregation; N sigs = N times size/cost
BLS (BLS12-381)	QC, StateCertificate, attestations	Same-message aggregation; constant-size QC; one verify for 2f+1 signers	Slower than Ed25519; pairing-based; need same message for aggregation
ECDSA (e.g. secp256k1)	Bitcoin, Ethereum (legacy) tx signing	Widely used; hardware support; no aggregation needed for single-sig txs	No aggregation; larger sigs than Ed25519; malleability concerns

In Hyperscale-rs: use the table to justify “BLS for QC/StateCertificate, Ed25519 for fast signing” where the design is explained (e.g. in docs or a future general Cryptography module).

Libp2p identity and validator bind

Two keys, one binding. Consensus identity is the BLS public key (votes, QCs, validator set). libp2p uses an Ed25519 keypair for TLS and PeerId. In the current design the libp2p keypair is generated at random (generate_random_keypair() in the network adapter identity module). The runner then signs a validator bind message (the PeerId bytes) with the BLS key, so the network layer can verify that this peer owns the claimed validator identity.

In production: the production runner creates the libp2p adapter with ed25519_keypair (from generate_random_keypair()) and local_bind_signature (BLS signature over validator_bind_message(peer_id)). The validator-bind protocol proves the peer controls the BLS key for the given ValidatorId. Topology holds every validator's BLS public key; the runner passes initial_validator_keys so the network can verify bind signatures. (Legacy note: an older design used LIBP2P_IDENTITY_DOMAIN = b"hyperscale-libp2p-identity-v1:": it is prepended (or otherwise combined) with the pubkey before hashing so that the derived key is bound to this specific use. That way the same BLS pubkey hashed with a different domain would yield a different PeerId, avoiding collisions and tying the derivation to “Hyperscale libp2p identity” only. So anyone who knows a validator’s BLS public key can compute that validator’s PeerId (e.g. compute_peer_id_for_validator(public_key)). The topology already has every validator’s BLS public key, so at startup the runner can fill validator_peers and peer_validators without out-of-band PeerId exchange.) File paths: Suggested crates / files to study.

Why not BLS for libp2p? libp2p’s identity and TLS are built for key types like Ed25519. So: BLS = consensus identity; Ed25519 = Ed25519 = transport key. PeerId is no longer derivable from BLS alone; identity is tied by the BLS signature over PeerId.

Quiz: Cryptography and identity

These questions are designed to be challenging: answers are not obvious and some distractors are plausible. Use the module text and repo links to decide. Pass threshold: 70%.