Random Numbers

​

How NEAR Random Seed Works

​

Deterministic and Verifiable

• It comes from the validator that produced the block
• The validator signs the previous block-hash with their private key
• The signature becomes the random seed for the current block
• Anyone can verify the seed, but only the validator knows it in advance.

​

Security Properties

​

1. Only Validator Can Predict

• Only the validator mining the transaction can predict which random number will be generated
• No one else can predict it because nobody knows the validator’s private key (except the validator)
• This provides some security, but creates a centralization risk.

​

2. Validator Cannot Interfere

• The validator cannot interfere with the random number being created
• They must sign the previous block-hash, over which they (with high probability) had no control
• The previous block was likely produced by a different validator.

​

Attack Type 1: Gaming the Input

​

The Vulnerability

• Contract asks user to choose a number between 1-100
• If user’s number matches the random seed, they win a prize
• Validator knows the random seed before the block is mined
• Validator creates a transaction with the winning number
• Validator includes their transaction in the block
• Validator wins the prize

// ❌ VULNERABILITY: Gaming the input - validator can predict and win
// User provides input and random seed is generated in same block
pub fn guess_number(&mut self, guess: u8) {
    let account_id = env::signer_account_id();

    // Store user's guess
    self.bets.insert(account_id.clone(), guess.to_string());

    // Generate random number in SAME block - validator knows it!
    let random_seed = env::random_seed();
    let random_number = (random_seed[0] % 100) as u8;

    // Validator can see user's guess and create winning transaction
    if guess == random_number {
        let reward = NearToken::from_near(1);
        let previous_user_reward = self.rewards.get(&account_id).unwrap_or(&NearToken::ZERO);
        let user_reward = previous_user_reward.saturating_add(reward);
        self.rewards.insert(account_id, user_reward);
    }
}

​

Why This Works

1. Calculate the winning input
2. Create a transaction with that input
3. Include their transaction in the block
4. Win every time

​

Attack Type 2: Refusing to Mine the Block

​

The Two-Stage Solution

1. Bet Stage: User sends their input/choice (e.g., “heads” or “tails”)
2. Resolve Stage: Contract generates random number and determines winner (in a later block)

• User’s choice is locked in the first block
• Random seed is generated in a different (later) block
• Validator cannot know the random seed when user makes their choice

​

The Remaining Vulnerability

1. Validator creates a “bet” transaction with their account
2. Validator chooses either input (doesn’t matter which)
3. When it’s the validator’s turn to validate:
   • They check what random seed will be generated
   • If their bet would win, they include the “resolve” transaction in the block
   • If their bet would lose, they skip the “resolve” transaction
4. Other validators might mine it, but validator increases their win rate

​

Coin Flip Example: Probability Manipulation

​

Fair Coin Flip (Without Attack)

• You choose “heads” or “tails” in the bet stage
• Random seed determines outcome in resolve stage
• Probability of winning: 50% (1/2)

​

With Refusing to Mine Attack

• You bet “heads”
• If random seed = “heads”: You mine the block and win ✅
• If random seed = “tails”: You skip the block (other validator might mine it)
  • If other validator mines: You lose ❌
  • If no one mines: Transaction delayed, you try again later

• H H: Win ✅
• T H: Win ✅ (retry after T)
• H T: Win ✅ (retry after H)
• T T: Lose ❌ (retry after T, then T again)

​

Best Practices for Randomness

​

1. Use Multi-Block Randomness

• Separate bet and resolve into different blocks
• Prevents input gaming attacks
• Still vulnerable to selective mining, but reduces risk.

​

2. Use Commit-Reveal Schemes

• Users commit to their choice (hash of choice + secret)
• Later reveal the choice and secret
• Random seed generated after reveal
• Prevents both input gaming and selective mining.

​

3. Use External Oracles

• Use trusted external randomness sources
• Chainlink VRF or similar services
• More secure but requires external dependencies.

​

4. Accept Validator Advantage

• For non-critical randomness, accept that validators have slight advantage
• Use for games where small advantage is acceptable
• Not suitable for high-stakes applications.

​

5. Use Multiple Validators

• Distribute randomness across multiple validators
• Reduces single validator control
• More decentralized approach.