Hash Seeding

Given the same initial seed and hash function, the sequence of generated values is perfectly reproducible. This allows all participants to independently verify the results, a cornerstone of provably fair systems like on-chain lotteries and NFT minting. The process is a one-way function, making it impossible to derive the seed from the output.

The security of the system depends on the initial seed's unpredictability. A common pattern is the commit-reveal scheme:

• Commit: The seed provider (e.g., an oracle) publishes a commitment hash (e.g., H(seed + salt)).
• Reveal: After all participant actions are locked, the original seed and salt are revealed.
• Verification: Anyone can hash the revealed data to verify it matches the initial commitment, preventing seed manipulation.

The quality of randomness depends on the entropy (unpredictability) of the seed. Common entropy sources include:

• Block hashes from a future block (e.g., blockhash(blockNumber + 1)).
• Oracle-provided data from verifiable random functions (VRFs).
• Multi-party computation where seeds from several parties are combined. A weak or predictable seed compromises the entire system's security.

A robust hash seeding design prevents precomputation attacks, where an adversary tries to calculate outcomes in advance. Techniques include:

• Using a seed revealed from the future, like a block hash that is unknowable when users submit transactions.
• Incorporating user-provided inputs (e.g., a nonce) into the final hash calculation.
• Batching requests and using a single seed for an entire epoch or batch, making targeted manipulation impractical.

A simple implementation for a winner selection:

1. Commit: Oracle commits H(secretSeed).
2. Participate: Users buy tickets, generating ticket IDs.
3. Reveal & Compute: After the sale, the oracle reveals secretSeed. The contract computes: winnerIndex = uint256(keccak256(abi.encodePacked(secretSeed, ticketId))) % totalTickets.
4. Verify: Anyone can re-run this computation with the public secretSeed and ticketId to confirm the result matches the on-chain outcome.

The most common and secure source for on-chain randomness. Smart contracts use future or past blockhash, timestamp, and difficulty as seeds. This data is deterministic for the network but unpredictable for individual participants before the block is mined.

• Example: uint256 random = uint256(blockhash(block.number - 1));
• Limitation: Miners/validators have a small window of influence, making it unsuitable for high-value applications.

A multi-party protocol where participants first commit to a hidden seed (its hash) and later reveal the original value. The final random number is derived from the combination of all revealed seeds.

• Process: 1) Commit phase: commit = keccak256(seed, secret). 2) Reveal phase: parties disclose seed and secret. 3) Final random number is keccak256(seed_1, seed_2, ...).
• Use Case: Fair random selection in decentralized games or lotteries where all players contribute to the entropy.

RANDAO is a decentralized randomness beacon on Ethereum where validators contribute seeds in a round. The aggregate randomness is the XOR of all revealed contributions.

• Vulnerability: The last contributor can bias the result. This is mitigated by combining RANDAO with a Verifiable Delay Function (VDF).
• VDF Role: A VDF imposes a mandatory time delay on the RANDAO output, making it impossible for the last contributor to compute and bias the final result before the reveal deadline.

Using the preimage (the original input data) of a known hash as a seed. This is common in cryptographic proofs and certain consensus algorithms.

• Mechanism: A party publicly commits to a hash H. To generate a random value, they must reveal the preimage X where keccak256(X) = H. The value X then serves as the seed.
• Application: Found in protocols like Proof of Work, where the nonce is a seed whose hash must meet a target difficulty.

Hash seeding is the core mechanism for mining in Proof-of-Work (PoW) blockchains like Bitcoin. Miners repeatedly hash a block header (seeded with a nonce) to find a result below the network's target difficulty. The first to succeed seeds the next block, securing the chain through computational work.

• Example: Bitcoin's SHA-256 mining algorithm.
• Purpose: Provides Sybil resistance and decentralized security.

Hash functions generate verifiable randomness by seeding them with unpredictable inputs. This is essential for fair lotteries, NFT minting, and gaming outcomes on-chain.

• Process: A seed (e.g., future block hash + user input) is hashed to produce a random number.
• Key Property: The output is deterministic yet unpredictable without the seed.
• Example: Chainlink VRF uses a seed provided by the user combined with an oracle's secret to deliver provably random numbers.

Hash seeding enables commit-reveal protocols, where a user commits to a secret value by publishing its hash. Later, they reveal the original seed to prove commitment without early disclosure.

• Use Case: Sealed-bid auctions, voting systems, and mitigating front-running.
• Mechanism: commit = hash(secret + salt). The salt prevents brute-force guessing of the secret.

Hash seeds form the leaves of a Merkle tree, where parent nodes are hashes of their children. This creates a cryptographic fingerprint of an entire dataset.

• Application: Efficiently verifying that a transaction or piece of data is included in a block without downloading the whole chain (Merkle proofs).
• Example: Light clients verify payment by checking a Merkle path seeded with their transaction hash.

Cryptographic key pairs (public/private keys) are often derived from a seeded hash. A single secret seed, like a mnemonic phrase or random entropy, is hashed to generate a master key, from which a hierarchy of keys can be deterministically derived.

• Standard: BIP-32/39/44 for Hierarchical Deterministic (HD) wallets.
• Benefit: Allows backup and recovery of entire wallets from one seed.

The address of a smart contract deployed via the CREATE opcode is deterministically seeded by the sender's address and their nonce. The formula is keccak256(rlp.encode(sender, nonce))[12:].

• CREATE2: Allows address generation seeded by the sender's address, a custom salt, and the contract's init code, enabling address prediction before deployment.

The core mechanism for preventing precomputation attacks. Participants first commit to a secret value by publishing its hash (the commit phase). After all commitments are locked in, they reveal the original secret (the reveal phase). The final random seed is derived from the combination of all revealed secrets. This ensures no participant can predict or influence the final outcome after seeing others' commitments.

A secure hash seeding protocol must be resistant to bias from any single participant or colluding group. Key threats include:

• Last-revealer advantage: The final participant to reveal can compute the outcome and choose to abort.
• Grinding attacks: Trying multiple secret values to find one that produces a favorable outcome.
• Predictability: If entropy sources are weak (e.g., block hash of a recent, known block), the result can be predicted. Mitigations include using verifiable delay functions (VDFs) or threshold signatures to eliminate last-revealer risk.

The quality of the final seed depends on strong, unpredictable entropy. Common sources include:

• On-chain data: Block hashes, timestamps (vulnerable to miner influence).
• Oracle inputs: External randomness from services like Chainlink VRF.
• Distributed key generation (DKG): Used in protocols like drand, where a committee collectively generates a verifiable random beacon.
• BLS threshold signatures: Produce a single, unbiased signature from a group, used as a random value.

For fairness, the process must be publicly verifiable. Any observer must be able to:

• Verify that each participant's reveal matches their original commitment.
• Independently compute the final seed from all revealed inputs.
• Confirm that no rules of the protocol were violated. This transparency is recorded on-chain, creating an immutable audit trail. Without it, participants cannot trust that the randomness was generated correctly and without manipulation.

Security requirements vary by use case:

• NFT Minting / Lotteries: Focus is on preventing users from grinding for rare outputs. A predictable seed allows sniping desirable assets.
• Validator/Leader Election: In Proof-of-Stake, a biased seed can lead to targeted censorship or repeated selection of a malicious actor.
• Gaming & Gambling dApps: Must ensure the house cannot manipulate odds and players cannot reverse-engineer results. Timelock puzzles or VDFs are often used to add a forced delay between commitment and usability.

Examples of hash seeding in production:

• Ethereum 2.0 (Now Consensus Layer): Uses RANDAO (a commit-reveal scheme) combined with VDFs (planned) for beacon chain randomness.
• Chainlink VRF: Provides cryptographically verifiable randomness to smart contracts, using a commit-reveal model with an oracle network.
• Algorand: Uses a cryptographic sortition based on the seed to select block proposers and committee members in a fair, weighted-by-stake manner.
• drand: A distributed randomness beacon used by Filecoin and others, generating publicly verifiable randomness at regular intervals.