generated from 0xBcamp/project-template
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #28 from 0xBcamp/proxy
Proxy
- Loading branch information
Showing
7 changed files
with
514 additions
and
269 deletions.
There are no files selected for viewing
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
140 changes: 140 additions & 0 deletions
140
packages/hardhat/contracts/VRFConsumerBaseV2Upgradeable.sol
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,140 @@ | ||
| // SPDX-License-Identifier: MIT | ||
| pragma solidity ^0.8.4; | ||
|
|
||
| import "@openzeppelin/contracts/proxy/utils/Initializable.sol"; | ||
|
|
||
| /** **************************************************************************** | ||
| * @notice Interface for contracts using VRF randomness | ||
| * ***************************************************************************** | ||
| * @dev PURPOSE | ||
| * | ||
| * @dev Reggie the Random Oracle (not his real job) wants to provide randomness | ||
| * @dev to Vera the verifier in such a way that Vera can be sure he's not | ||
| * @dev making his output up to suit himself. Reggie provides Vera a public key | ||
| * @dev to which he knows the secret key. Each time Vera provides a seed to | ||
| * @dev Reggie, he gives back a value which is computed completely | ||
| * @dev deterministically from the seed and the secret key. | ||
| * | ||
| * @dev Reggie provides a proof by which Vera can verify that the output was | ||
| * @dev correctly computed once Reggie tells it to her, but without that proof, | ||
| * @dev the output is indistinguishable to her from a uniform random sample | ||
| * @dev from the output space. | ||
| * | ||
| * @dev The purpose of this contract is to make it easy for unrelated contracts | ||
| * @dev to talk to Vera the verifier about the work Reggie is doing, to provide | ||
| * @dev simple access to a verifiable source of randomness. It ensures 2 things: | ||
| * @dev 1. The fulfillment came from the VRFCoordinator | ||
| * @dev 2. The consumer contract implements fulfillRandomWords. | ||
| * ***************************************************************************** | ||
| * @dev USAGE | ||
| * | ||
| * @dev Calling contracts must inherit from VRFConsumerBase, and can | ||
| * @dev initialize VRFConsumerBase's attributes in their constructor as | ||
| * @dev shown: | ||
| * | ||
| * @dev contract VRFConsumer { | ||
| * @dev constructor(<other arguments>, address _vrfCoordinator, address _link) | ||
| * @dev VRFConsumerBase(_vrfCoordinator) public { | ||
| * @dev <initialization with other arguments goes here> | ||
| * @dev } | ||
| * @dev } | ||
| * | ||
| * @dev The oracle will have given you an ID for the VRF keypair they have | ||
| * @dev committed to (let's call it keyHash). Create subscription, fund it | ||
| * @dev and your consumer contract as a consumer of it (see VRFCoordinatorInterface | ||
| * @dev subscription management functions). | ||
| * @dev Call requestRandomWords(keyHash, subId, minimumRequestConfirmations, | ||
| * @dev callbackGasLimit, numWords), | ||
| * @dev see (VRFCoordinatorInterface for a description of the arguments). | ||
| * | ||
| * @dev Once the VRFCoordinator has received and validated the oracle's response | ||
| * @dev to your request, it will call your contract's fulfillRandomWords method. | ||
| * | ||
| * @dev The randomness argument to fulfillRandomWords is a set of random words | ||
| * @dev generated from your requestId and the blockHash of the request. | ||
| * | ||
| * @dev If your contract could have concurrent requests open, you can use the | ||
| * @dev requestId returned from requestRandomWords to track which response is associated | ||
| * @dev with which randomness request. | ||
| * @dev See "SECURITY CONSIDERATIONS" for principles to keep in mind, | ||
| * @dev if your contract could have multiple requests in flight simultaneously. | ||
| * | ||
| * @dev Colliding `requestId`s are cryptographically impossible as long as seeds | ||
| * @dev differ. | ||
| * | ||
| * ***************************************************************************** | ||
| * @dev SECURITY CONSIDERATIONS | ||
| * | ||
| * @dev A method with the ability to call your fulfillRandomness method directly | ||
| * @dev could spoof a VRF response with any random value, so it's critical that | ||
| * @dev it cannot be directly called by anything other than this base contract | ||
| * @dev (specifically, by the VRFConsumerBase.rawFulfillRandomness method). | ||
| * | ||
| * @dev For your users to trust that your contract's random behavior is free | ||
| * @dev from malicious interference, it's best if you can write it so that all | ||
| * @dev behaviors implied by a VRF response are executed *during* your | ||
| * @dev fulfillRandomness method. If your contract must store the response (or | ||
| * @dev anything derived from it) and use it later, you must ensure that any | ||
| * @dev user-significant behavior which depends on that stored value cannot be | ||
| * @dev manipulated by a subsequent VRF request. | ||
| * | ||
| * @dev Similarly, both miners and the VRF oracle itself have some influence | ||
| * @dev over the order in which VRF responses appear on the blockchain, so if | ||
| * @dev your contract could have multiple VRF requests in flight simultaneously, | ||
| * @dev you must ensure that the order in which the VRF responses arrive cannot | ||
| * @dev be used to manipulate your contract's user-significant behavior. | ||
| * | ||
| * @dev Since the block hash of the block which contains the requestRandomness | ||
| * @dev call is mixed into the input to the VRF *last*, a sufficiently powerful | ||
| * @dev miner could, in principle, fork the blockchain to evict the block | ||
| * @dev containing the request, forcing the request to be included in a | ||
| * @dev different block with a different hash, and therefore a different input | ||
| * @dev to the VRF. However, such an attack would incur a substantial economic | ||
| * @dev cost. This cost scales with the number of blocks the VRF oracle waits | ||
| * @dev until it calls responds to a request. It is for this reason that | ||
| * @dev that you can signal to an oracle you'd like them to wait longer before | ||
| * @dev responding to the request (however this is not enforced in the contract | ||
| * @dev and so remains effective only in the case of unmodified oracle software). | ||
| */ | ||
| abstract contract VRFConsumerBaseV2Upgradeable is Initializable { | ||
| error OnlyCoordinatorCanFulfill(address have, address want); | ||
| address private vrfCoordinator; | ||
|
|
||
| function __VRFConsumerBaseV2Upgradeable_init( | ||
| address _vrfCoordinator | ||
| ) internal onlyInitializing { | ||
| vrfCoordinator = _vrfCoordinator; | ||
| } | ||
|
|
||
| /** | ||
| * @notice fulfillRandomness handles the VRF response. Your contract must | ||
| * @notice implement it. See "SECURITY CONSIDERATIONS" above for important | ||
| * @notice principles to keep in mind when implementing your fulfillRandomness | ||
| * @notice method. | ||
| * | ||
| * @dev VRFConsumerBaseV2 expects its subcontracts to have a method with this | ||
| * @dev signature, and will call it once it has verified the proof | ||
| * @dev associated with the randomness. (It is triggered via a call to | ||
| * @dev rawFulfillRandomness, below.) | ||
| * | ||
| * @param requestId The Id initially returned by requestRandomness | ||
| * @param randomWords the VRF output expanded to the requested number of words | ||
| */ | ||
| function fulfillRandomWords( | ||
| uint256 requestId, | ||
| uint256[] memory randomWords | ||
| ) internal virtual; | ||
|
|
||
| // rawFulfillRandomness is called by VRFCoordinator when it receives a valid VRF | ||
| // proof. rawFulfillRandomness then calls fulfillRandomness, after validating | ||
| // the origin of the call | ||
| function rawFulfillRandomWords( | ||
| uint256 requestId, | ||
| uint256[] memory randomWords | ||
| ) external { | ||
| if (msg.sender != vrfCoordinator) { | ||
| revert OnlyCoordinatorCanFulfill(msg.sender, vrfCoordinator); | ||
| } | ||
| fulfillRandomWords(requestId, randomWords); | ||
| } | ||
| } |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.