• oracles are like API in web2
• we’re using Chainlink as it deployed in several blockchain networks
• we’ll be writing the most used Oracle features
• uses: get price feeds and random numbers
• doesn’t make it centralized: VRF
• Chainlink Docs

client makes calls to get data from an oracle like Chainlink

ChainLink VRF

• get contract we’ve written to get random numbers from chainlink
• Chainlink VRF (Verifiable Random Function) is a provably fair and verifiable random number generator (RNG) that enables smart contracts to access random values without compromising security or usability.
• For each request, Chainlink VRF generates one or more random values and cryptographic proof of how those values were determined. The proof is published and verified on-chain before any consuming applications can use it. This process ensures that results cannot be tampered with or manipulated by any single entity including oracle operators, miners, users, or smart contract developers.
• Use Chainlink VRF to build reliable smart contracts for any applications that rely on unpredictable outcomes:
• Building blockchain games and NFTs.
• Random assignment of duties and resources. For example, randomly assigning judges to cases.
• Choosing a representative sample for consensus mechanisms.

Supported networks

Chainlink VRF v2 is currently available on the following networks:

• Ethereum:

  • Mainnet
  • Rinkeby testnet

• BNB Chain

  • Mainnet

  • Testnet

  • Gas price: The current gas price, which fluctuates depending on network conditions

  • Callback gas: The amount of gas used for the callback request that returns your requested random values

  • Verification gas: The amount of gas used to verify randomness on-chain

  Limits

  • Chainlink VRF v2 has some subscription limits and coordinator contract limits.

  Subscription limits

  Each subscription has the following limits:

  • Each subscription must maintain a minimum balance to fund requests from consumer contracts. If your balance is below that minimum, your requests remain pending for up to 24 hours before they expire. After you add sufficient LINK to a subscription, pending requests automatically process as long as they have not expired.

  • The minimum subscription balance must be sufficient for each new consumer contract that you add to a subscription. The required size of the minimum balance depends on the gas lane and the size of the request that the consumer contract makes. For example, a consumer contract that requests one random value will require a smaller minimum balance than a consumer contract that requests 50 random values. In general, you can estimate the required minimum LINK balance using the following formula where max verification gas is always 200,000.

    ((Gas lane maximum * (Max verification gas + Callback gas limit)) / (ETH to LINK price)) + LINK premium = Minimum LINK
    
    

  • Each subscription supports up to 100 consumer contracts. If you need more than 100 consumers, create multiple subscriptions.

  Coordinator contract limits

  You can see the configuration for each network on the Contract Addresses page. You can also view the full configuration for each coordinator contract directly in Etherscan. As an example, view the Ethereum Mainnet VRF v2 coordinator contract configuration.

  • Each coordinator has a MAX_NUM_WORDS parameter that limits the maximum number of random values you can receive in each request.
  • Each coordinator has a maxGasLimit parameter, which is the maximum allowed callbackGasLimit value for your requests.
  • You must specify a sufficient callbackGasLimit to fund the callback request to your consumer contract. This depends on the number of random values you request and how you process them in your fulfillRandomWords() function. If your callbackGasLimit is not sufficient, the callback fails but your subscription is still charged for the work done to generate your requested random values.

  Requirements

  This guide assumes that you know how to create and deploy smart contracts on Ethereum testnets using the following tools:

  • The Remix IDE
  • MetaMask
  • Rinkeby testnet ETH

  Create and fund a subscription

  For this example, create a new subscription on the Rinkeby testnet.

  1. Open MetaMask and set it to use the Rinkeby testnet. The Subscription Manager detects your network based on the active network in MetaMask.
  2. Check MetaMask to make sure you have testnet ETH and LINK on Rinkeby. If you need testnet funds, you can get them from faucets.chain.link.
  3. Open the Subscription Manager page.
  4. Click Create Subscription and follow the instructions to create a new subscription account. MetaMask opens and asks you to confirm payment to create the account on-chain. After you approve the transaction, the network confirms the creation of your subscription account on-chain.
  5. After the subscription is created, click Add funds and follow the instructions to fund your subscription. For this example, a balance of 2 LINK is sufficient. MetaMask opens to confirm the LINK transfer to your subscription. After you approve the transaction, the network confirms the transfer of your LINK token to your subscription account.
  6. After you add funds, click Add consumer. A page opens with your account details and subscription ID.
  7. Record your subscription ID, which you need for your consumer contract. You will add the consumer to your subscription later.

  bitwise operators: 64bits

  1st===0, 31bits
  2nd===32, 63bits
  3rd===64, 95bits
  4th===96, 127bits
  5th===128, 15bits
  6th===160, 191bits
  

  Chainlink With HARDHAT

  $ git clone <https://github.com/pappas999/chainlink-hardhat-box>
  $ cd chainlink-hardhat-box
  $ yarn
  $ npx hardhat deploy
  
  // USING DATA FEEDS
  $ npx hardhat read-price-feed --contract 0x0ef1181768A99E522FB5535fA2e0D172B36d3479
  $ npx hardhat fund-link --contract  0xc719F4B720cB7cBcabB09dF0040b47f3F9CE6a58
  $ npx hardhat request-data --contract  0xc719F4B720cB7cBcabB09dF0040b47f3F9CE6a58
  $ npx hardhat read-data --contract  0xc719F4B720cB7cBcabB09dF0040b47f3F9CE6a58
  
  // using