Cheap Randomness

Coqnet offers three approaches to tackle random numbers

Generating random numbers in Blockchain contexts bring different challenges. Due to its deterministic nature, creating a random number with high entropy and low predictability requires specialized approaches.

Reliable random numbers are crucial for gaming applications, fair distribution mechanisms, lottery systems, random selection processes and many more use cases. Coqnet offers multiple approches to tackle these challenges, each with its own trade-offs between security, speed, cost and decentralization. They are:

1. Backend-based random generation process

2. Native VRF precompile contracts (soon)

3. Chainlink VRF integration (soon)

Backend-based random generation process

This approach leverages a secure backend service to generate and provide cryptographically secure random numbers to smart contracts. Off-chain computation has available battle-tested libraries that make super easy the creation of proper random numbers.

It is totally possible to add another on-chain layer of randomness of top the off-chain. The Cop Pot Bonanza game does exactly that. It all starts at the backend by using the crypto library in this way:

// Generating a 32-bytes length random number
import { randomBytes } from 'crypto';

export function generateRandomUint256(): bigint {
  return BigInt('0x' + randomBytes(32).toString('hex'));
}

Once the random number is generated, the backend calls a smart contract method. At that point, the random number becomes an input. In turn, the smart contract will use its hashing method keccak256 to add extra randomness on top of the backend random number. Let's see it here:

function _genPseudoRandom(uint256 randomWord) internal view virtual returns (uint256) {
    // solhint-disable-next-line not-rely-on-block-hash
    return uint256(keccak256(abi.encodePacked(blockhash(block.number - 1), block.prevrandao, randomWord)));
}

In that snippet, the variable randomWord is the random number sent by the backend. Once the method _genPseudoRandom returns the backend-sourced pseudo random number, it is ready to be used.

Let's discuss its advantages and disadvantages:

Advantages

• Immediate response time in the same transaction

• Cost-effective

• Customizable implementation

• Easy to maintain and update

• Virtually possible to create infinite random numbers

Disadvantages

• Relies on backend trust

• Centralization concerns

• Potential for manipulation

• Single point of failure

Risks

This implementation brings inherent centralization risks. First of all, the backend becomes the single source of randomness. It also has the full control ove the number generation and opens the door for a possible manipulation. Also, once the backend gets compromised, it would be possible to perform certain attacks, such as seed prediction or network-level atacks.

Those risks could be mitigated by using the commit-reveal pattern. Let's study that next.

Commit-Reveal Scheme for Secure Randomness

This patterns enforces two-pahse process that prevents manipulation by requiring a commitment to a random value first, before knowing its impact on the game results. Once the commitment to a certain value is done and published on-chain, it becomes impossible to alter the value in the process. Also, all commitment values could be later verified by using on-chain logs.

In this pattern there are three parties involved: end-user, backend and smart contract. Let's dissect this process and take the Coq Pot Bonanza game as context for the sake of explanation:

• The end-user places a bet, initiating the game

• The backend generates a random number by using a salt

• The backend creates a commitment hash, which is published to the Blockchain

• The commitment hash is saved in the smart contract for later verification if required

• The end-user spins the casino and the previous random number is used to compute his result

• The backend publishes the random number and the salt

• Anyone can verify that hashing the random number and salt is equivalent to the commitment hash published previously

• If they are not equal, the random number was changed in the process

There is an ongoing discussion about implemeting a Provable Virtual Machine Randomness by the Avalanche team. Let's see that next.

Native VRF Precompile contracts

The Verifiable Random Function (VRF) precompile is a protocol-level solution for generating secure random numbers within the entire Avalanche ecosytem, which Coqnet is part of. This native implementation will provide a trustless, efficient and cost-effective method for generating verifiable random numbers.

Features

• Immediate availability through a contract call

• Low computational overhead to set up

• Native EVM compatibility

• Guaranteed determinism across nodes

• Cryptographic verification capabilities

• Consensus-backed randomness

• Transparent operation and manipulation resistance

Usage

This is an exploratory way of how the precompile will work. It shouldn't be that much different from using already existent precompile contracts:

interface IVRFPrecompile {
    function getRandomness() external returns (uint256);
}

contract GameWithNativeVRF {
    IVRFPrecompile private constant VRF = IVRFPrecompile(0x0000000000000000000000000000000000000123);
    
    function executeGameAction() external {
        uint256 randomNumber = VRF.getRandomness();
        // Game logic using randomNumber
    }
}

The native VRF precompile contract will represent a huge step towards facilitating the creation of random numbers on-chain, which, as of today, its implementation is very unpleasent for developers. This functionality will provide developers with robust and secure solutions for their decentralized applications.

Chainlink VRF integration

Chainlink's VRF is a standar random number generation method adopted in most Blockchains and adopted by the majority of developers. Through its oracle network, Chainlink enables an environment for creating cryptographically secure randomness with proven security and reliability. Any time soon, Chainlink will offer its VRF functionality to Coqnet.

Let's see some advantages and disadvantages of this approach:

Advantages

• Battle-tested solution

• Cross-chain compatibility

• Decentralized oracle network

• Strong security guarantees

Disadvantages

• Higher latency

• Additional costs (LINK tokens)

• External dependency

• More complex implementation

Below you will find a table comparing all three solutions with their pros and cons:

The choice of randomness generation mechanism in Coqnet depends heavily on specific use case requirements. For high-frequency, low-stakes applications like casual games, the backend-provided randomness offers a practical balance of speed and simplicity. The upcoming native VRF precompile promises to provide a robust, protocol-level solution that could become the standard for Coqnet applications requiring secure randomness. Meanwhile, Chainlink VRF remains a proven solution for applications requiring the highest level of decentralized security and cross-chain compatibility.