Chainlink VRF V2 Audit

Smart Contract Security Assessment

30.09.2021

SUMMARY​

ABSTRACT​

Dedaub was commissioned to perform a security audit on the 2nd version of the VRF smart contracts, on branch “develop” of https://github.com/smartcontractkit/chainlink at commit hash 7547b562579b4f201994fd85fb50d799ae1d918a. Two senior auditors worked over the codebase over one week. The audit examined the contracts:

• contracts/src/v0.8/dev/VRFConsumerBaseV2.sol
• contracts/src/v0.8/dev/VRF.sol
  • This contract was mostly inspected as a diff from the v1 (v0.6/VRF.sol) to v2 (v0.8/dev/VRF.sol) and the cryptographic operations were mostly considered trusted since this code has been well-audited and tested before
• contracts/src/v0.8/dev/VRFCoordinatorV2.sol
• any other functionality highly related with these contracts, but without exhaustive inspection. Specifically, the offchain operations written in vrf_coordinator_v2.go.

SETTING & CAVEATS​

The exhaustively audited code base is of small size, at around 1KLoC, but with extensive interactions and protocol-level complexity. The code and accompanying artifacts (e.g., test suite, documentation) are of excellent quality, developed with high professional standards.

We emphasized protocol-level considerations, in addition to code review. The items below can be considered context notes, possibly to inform future design, or documentation for the benefit of external users.

1. It may not be clear to users what Verified Random Functions truly verify and, consequently, what are the threats. We find statements concerning guarantees even if a Chainlink oracle (“node”) is compromised to be hard to interpret correctly. E.g., the following in the past Chainlink VRF documentation:

   • The proof is published and verified on-chain before it can be used by any consuming applications. This process ensures that the results cannot be tampered with nor manipulated by anyone, including oracle operators, miners, users and even smart contract developers.
     [https://docs.chain.link/docs/chainlink-vrf/]
   • The fundamental benefit of using Chainlink VRF is its verifiable randomness. Even if a node is compromised, it cannot manipulate and/or supply biased answers — the on-chain cryptographic proof would fail. The worst case scenario is that the compromised node does not return a response to a request[...] Even in the unlikely scenario that a node is compromised, its resulting randomness cannot be manipulated.
     [https://blog.chain.link/chainlink-vrf-on-chain-verifiable-randomness/]

   What the above seems to imply is not accurate. If a Chainlink node’s VRF secret key is compromised, the VRF becomes a mere deterministic pseudo-random generator. Its randomness is then, at best, on-chain randomness, which has well-known issues. Certainly, the collusion of a miner and an oracle operator can open the door to attacks.

2. The current design does not accept a seed from the user of the VRF functionality. This is ideal for the usual case, but it is limiting for highly sophisticated clients. Specifically, the typical client contract only has access to on-chain information. In this case, accepting a seed from the client is pointless: the current approach of the VRF functionality both gets the most obtainable in terms of on-chain randomness (by taking the blockhash of a block not mined at the time of the request) and would destroy any seed provided by the caller in the process. However, a more advanced API can be envisioned (perhaps in addition to the current one) that allows the caller to supply their own randomness in the form of a seed. (Such a seed should not then be hashed with a blockhash, or a miner can bias the outcome.) This approach permits, for instance, the use of two separate off-chain randomness sources. If the VRF oracle accepts randomness from the user (in addition to employing its own secret key) the result is a better randomness guarantee: biasing the random outcome would require compromising both randomness sources (i.e., both the secret key of the Chainlink VRF oracle, and the other source of randomness).

VULNERABILITIES & FUNCTIONAL ISSUES​

This section details issues affecting the functionality of the contract. Dedaub generally categorizes issues according to the following severities, but may also take other considerations into account such as impact or difficulty in exploitation:

Issue resolution includes “dismissed” or “acknowledged” but no action taken, by the client, or “resolved”, per the auditors.

CRITICAL SEVERITY​

[No critical severity issues]

HIGH SEVERITY​

MEDIUM SEVERITY​

[No medium severity issues]

LOW SEVERITY​

struct Consumer {
    uint64 subId;
    uint64 nonce;
}
mapping(address => mapping(uint64 => Consumer)) /* consumer */ /* subId */
  private s_consumers;

blockHash = BLOCKHASH_STORE.getBlockhash(rc.blockNum);
if (blockHash == bytes32(0)) {
    revert BlockhashNotInStore(rc.blockNum);
}

if (gasPreCallback < rc.callbackGasLimit) {
    revert InsufficientGasForConsumer(
      gasPreCallback, rc.callbackGasLimit);
}

assembly {
    let g := gas()
    ...
    if iszero(gt(sub(g, div(g, 64)), gasAmount)) {
        revert(0, 0)
    }
    ...
}

// The minimum gas limit that could be requested for a callback.
// Set to 5k to ensure plenty of room to make the call itself.
uint256 public constant MIN_GAS_LIMIT = 5_000;

/**
...
* The minimum amount of gasAmount is MIN_GAS_LIMIT.

OTHER / ADVISORY ISSUES​

This section details issues that are not thought to directly affect the functionality of the project, but we recommend considering them.

return (
    config.minimumRequestConfirmations,
    config.fulfillmentFlatFeeLinkPPM,
    config.maxGasLimit,
    config.stalenessSeconds,
    config.gasAfterPaymentCalculation,
    config.minimumSubscriptionBalance,
    s_fallbackWeiPerUnitLink
);

s_subscriptions[rc.subId].balance -= payment;
s_withdrawableTokens[s_provingKeys[keyHash]] += payment;

s_withdrawableTokens[msg.sender] -= amount;
s_totalBalance -= amount;

s_subscriptions[subId].balance -= amount;
s_totalBalance -= amount

s_totalBalance -= balance

DISCLAIMER​

The audited contracts have been analyzed using automated techniques and extensive human inspection in accordance with state-of-the-art practices as of the date of this report. The audit makes no statements or warranties on the security of the code. On its own, it cannot be considered a sufficient assessment of the correctness of the contract. While we have conducted an analysis to the best of our ability, it is our recommendation for high-value contracts to commission several independent audits, a public bug bounty program, as well as continuous security auditing and monitoring through Dedaub Security Suite.

ABOUT DEDAUB​

Dedaub offers significant security expertise combined with cutting-edge program analysis technology to secure some of the most prominent protocols in DeFi. The founders, as well as many of Dedaub's auditors, have a strong academic research background together with a real-world hacker mentality to secure code. Protocol blockchain developers hire us for our foundational analysis tools and deep expertise in program analysis, reverse engineering, DeFi exploits, cryptography and financial mathematics.