VRF Security Considerations Update (#1864)

* VRF Security Considerations Update * Fix temp build issue * Edits and anchor fixes * Edits * Edit
smartcontractkit · Apr 4, 2024 · e761b60 · e761b60
1 parent c9feef8
commit e761b60
Show file tree

Hide file tree

Showing 5 changed files with 11 additions and 31 deletions.
diff --git a/src/content/vrf/v1/security.mdx b/src/content/vrf/v1/security.mdx
@@ -12,7 +12,7 @@ Gaining access to high quality randomness onchain requires a solution like Chain
 
 - [Use `requestId` to match randomness requests with their fulfillment in order](#use-requestid-to-match-randomness-requests-with-their-fulfillment-in-order)
 - [Choose a safe block confirmation time, which will vary between blockchains](#choose-a-safe-block-confirmation-time-which-will-vary-between-blockchains)
-- [Do not re-request randomness](#do-not-re-request-randomness)
+- [Do not allow re-requesting or cancellation of randomness](#do-not-allow-re-requesting-or-cancellation-of-randomness)
 - [Don't accept bids/bets/inputs after you have made a randomness request](#dont-accept-bidsbetsinputs-after-you-have-made-a-randomness-request)
 - [`fulfillRandomness` must not revert](#fulfillrandomness-must-not-revert)
 - [Use `VRFConsumerBase` in your contract, to interact with the VRF service](#use-vrfconsumerbase-in-your-contract-to-interact-with-the-vrf-service)
@@ -43,11 +43,9 @@ For further details, take a look at the consensus documentation for the chain yo
 
 Understanding the blockchains you build your application on is very important. You should take time to understand [chain reorganization](https://blog.ethereum.org/2015/08/08/chain-reorganisation-depth-expectations/) which will also result in a different VRF output, which could be exploited.
 
-## Do not re-request randomness
+## Do not allow re-requesting or cancellation of randomness
 
-Any re-request of randomness is an incorrect use of VRF. Doing so would give the VRF service provider the option to withhold a VRF fulfillment if the outcome is not favorable to them and wait for the re-request in the hopes that they get a better outcome, similar to the considerations with block confirmation time.
-
-Re-requesting randomness is easily detectable onchain and should be avoided for use cases that want to be considered as using VRF correctly.
+Any re-request or cancellation of randomness is an incorrect use of VRF. dApps that implement the ability to cancel or re-request randomness for specific commitments must consider the additional attack vectors created by this capability. For example, you must prevent the ability for any party to discard unfavorable randomness.
 
 ## Don't accept bids/bets/inputs after you have made a randomness request
 

diff --git a/src/content/vrf/v2/direct-funding/examples/get-a-random-number.mdx b/src/content/vrf/v2/direct-funding/examples/get-a-random-number.mdx
@@ -89,8 +89,9 @@ The deployed contract requests random values from Chainlink VRF, receives those
 
 1.  Call `getRequestStatus()` and specify the `requestId` to display the random words.
 
-<Aside type="note" title="Note on Requesting Randomness">
-  Do not re-request randomness. For more information, see the [VRF Security Considerations](/vrf/v2/security) page.
+<Aside type="note" title="Note on Requesting or Cancelling Randomness">
+  Do not allow re-requesting or cancellation of randomness. For more information, see the [VRF Security
+  Considerations](/vrf/v2/security#do-not-allow-re-requesting-or-cancellation-of-randomness) page.
 </Aside>
 
 ## Analyzing the contract

diff --git a/src/content/vrf/v2/security.mdx b/src/content/vrf/v2/security.mdx
@@ -10,7 +10,7 @@ Gaining access to high quality randomness onchain requires a solution like Chain
 
 - [Use `requestId` to match randomness requests with their fulfillment in order](#use-requestid-to-match-randomness-requests-with-their-fulfillment-in-order)
 - [Choose a safe block confirmation time, which will vary between blockchains](#choose-a-safe-block-confirmation-time-which-will-vary-between-blockchains)
-- [Do not re-request randomness](#do-not-re-request-randomness)
+- [Do not allow re-requesting or cancellation of randomness](#do-not-allow-re-requesting-or-cancellation-of-randomness)
 - [Don't accept bids/bets/inputs after you have made a randomness request](#dont-accept-bidsbetsinputs-after-you-have-made-a-randomness-request)
 - [The `fulfillRandomWords` function must not revert](#fulfillrandomwords-must-not-revert)
 - [Use `VRFConsumerBaseV2` in your contract to interact with the VRF service](#use-vrfconsumerbasev2-in-your-contract-to-interact-with-the-vrf-service)
@@ -31,11 +31,9 @@ In principle, miners/validators of your underlying blockchain could rewrite the
 
 You must choose an appropriate confirmation time for the randomness requests you make. Confirmation time is how many blocks the VRF service waits before writing a fulfillment to the chain to make potential rewrite attacks unprofitable in the context of your application and its value-at-risk.
 
-## Do not re-request randomness
+## Do not allow re-requesting or cancellation of randomness
 
-Any re-request of randomness is an incorrect use of VRFv2. Doing so would give the VRF service provider the option to withhold a VRF fulfillment if the outcome is not favorable to them and wait for the re-request in the hopes that they get a better outcome, similar to the considerations with block confirmation time.
-
-Re-requesting randomness is easily detectable onchain and should be avoided for use cases that want to be considered as using VRFv2 correctly.
+Any re-request or cancellation of randomness is an incorrect use of VRFv2. dApps that implement the ability to cancel or re-request randomness for specific commitments must consider the additional attack vectors created by this capability. For example, you must prevent the ability for any party to discard unfavorable randomness.
 
 ## Don't accept bids/bets/inputs after you have made a randomness request
 

diff --git a/src/content/vrf/v2/subscription/examples/get-a-random-number.mdx b/src/content/vrf/v2/subscription/examples/get-a-random-number.mdx
@@ -120,7 +120,8 @@ The deployed contract requests random values from Chainlink VRF, receives those
 You deployed a simple contract that can request and receive random values from Chainlink VRF. To see more advanced examples where the contract can complete the entire process including subscription setup and management, see the [Programmatic Subscription](/vrf/v2/subscription/examples/programmatic-subscription) page.
 
 <Aside type="note" title="Note on Requesting Randomness">
-  Do not re-request randomness. For more information, see the [VRF Security Considerations](/vrf/v2/security) page.
+  Do not allow re-requesting or cancellation of randomness. For more information, see the [VRF Security
+  Considerations](/vrf/v2/security#do-not-allow-re-requesting-or-cancellation-of-randomness) page.
 </Aside>
 
 ## Analyzing the contract

diff --git a/src/features/data/chains.ts b/src/features/data/chains.ts
@@ -436,24 +436,6 @@ export const CHAINS: Chain[] = [
       },
     ],
   },
-  {
-    page: "starknet",
-    label: "StarkNet",
-    title: "StarkNet Data Feeds",
-    img: "/assets/chains/starknet.svg",
-    networkStatusUrl: "https://testnet.starkscan.co/stats",
-    tags: ["default"],
-    supportedFeatures: ["feeds"],
-    networks: [
-      {
-        name: "StarkNet testnet",
-        explorerUrl: "https://testnet.starkscan.co/contract/%s",
-        networkType: "testnet",
-        rddUrl: "https://reference-data-directory.vercel.app/feeds-starknet-testnet-goerli-1.json",
-        queryString: "starknet-testnet",
-      },
-    ],
-  },
   {
     page: "solana",
     label: "Solana",