chainlink
chainlink copied to clipboard
smartcontractkit
[FEAT] Chainlink upgradeable smart contracts
In order to make upgradeable smart contracts, constructors are not allowed to be had, since we want to store all the data in the proxy as opposed to the implementation.
However, contracts like VRFConsumerBase require a constructor, so for someone to make an upgradeable version of the contracts, we have to add an initialization method ourselves in an edited VRFConsumerBase contract.
It would be nice to have these supported, for example something like this.
Openzeppelin does something like this where they just have a fork of their main contracts that are exactly the same as their main ones, but without constructors and with initializer functions instead. https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable
Expected benefit: Engineers can now build upgradeable smart contracts using Chainlink % of developers: Maybe 5%, however these are senior projects We are getting ahead of the upgradeability trend that is coming our way.
this would save senior engineers hours of time per project to make the contracts upgrade safe. Perhaps this could be an integration with Openzeppelin
@PatrickAlphaC I tried to create an upgradeable smart contract + chain.link and many issues appear when I try to deploy it, hardhat and truffle cannot estimate gas fee and failed to deploy. Here is a small demo: https://github.com/mataide/Chainlink-Upgradeable
Could you make a separate issue with your issues, or a stackoverflow question instead of here?
I don't think the upgradable contract will help.. This will make it very confused to deploy vrf contracts.
Using Chainlink's AggregatorV3Interface.sol with OpenZeppelin upgradable's contract under the UUPS proxy pattern.
Is there any example online to update
priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331); // Kovan Testnet
on version 2 of the smart contract?
Has anyone successfully done so?
Thank you!
Any fresh news on implementing upgradeable chainlink vrfCoordinator? For knowledge purpose, I'd love to implement an upgradeable version of @PatrickAlphaC ' lottery. Since vrfCoordinatorV2 constructor can't be called because of proxy contrains, I have tried implementing VRFConsumerBaseUpgradeable from the retro-cats-contracts repo VRFConsumerBaseUpgradeable I can't make it work, don't get random value, I don't even know how to link a consumer id with this new contract. I am actually lost, so if there is any help or source code available some of you could provide, I would be very happy :) Thanks :)
That would be so cool. @alexroan any thoughts here? I made a MVP of this maybe over a year ago, it's doable but you have to refactor a lot of code.
I know a lot of people are anti-upgradeable contracts...
Yeah @bricedenice59 that was my attempt at this, I remember not loving it and we didn't get an audit or anything on it and scrapped the idea.
I am trying to use ChainlinkClient along with Chainlink Any Api however the library is not safe with upgradable contracts due to one line of code here
https://github.com/smartcontractkit/chainlink/blob/develop/contracts/src/v0.8/ChainlinkClient.sol#L33
If I change that line that I will be able to compile
// from
uint256 private s_requestCount = 1;
// to
uint256 private s_requestCount;
but then I notice futher down, that 1 is used to make "gas costs more efficient" https://github.com/smartcontractkit/chainlink/blob/develop/contracts/src/v0.8/ChainlinkClient.sol#L200
Can anyone explain why that is? Is it that changing from 0 to 1 will be more expensive the first time than from 1 to 2? I don't see having a few extra gas on the first request as a big deal. From looking at this code briefly, it doesn't look like if we don't assign s_requestCount an initial value, then it will be upgrade safe + not change the integrity of the code?
Curious what people think. CC @PatrickAlphaC @hasanza and anyone else
Starting with an empty storage variable is less gas efficient in solidity, it's better to have it be "something". If you want an upgradeable smart contract, you wouldn't want to initialize it though as you said. So, TL;DR, don't worry about that.
Wow.... It's march 2023 and this is still open. Is this something that will be added or not?
For people still needing the same solution. I've created an upgradeable VRFConsumerBaseV2 inside my project itself and used it instead.
Create a VRFConsumerBaseV2Upgradeable.sol file under the contracts directory.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;
import "@openzeppelin/contracts-upgradeable/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);
}
}
Remember that you'll need to install @openzeppelin/contracts-upgradeable for Initializable file.
And then import and use it in your contract's initializable function:
import "./VRFConsumerBaseV2Upgradeable.sol";
// ...
function initialize(
address _minter,
string[] memory _tokenURIs,
uint64 _subscriptionId,
address _vrfCoordinator,
bytes32 _keyHash
) public initializer {
// ... other assignments
subscriptionId = _subscriptionId;
keyHash = _keyHash;
__VRFConsumerBaseV2Upgradeable_init(_vrfCoordinator);
COORDINATOR = VRFCoordinatorV2Interface(_vrfCoordinator);
// ... other initializations of erc721, erc1155 etc.
}
This is just a temporary solution. We need these inside the @chainlink/contracts-upgradeable.
For people still needing the same solution. I've created an upgradeable VRFConsumerBaseV2 inside my project itself and used it instead.
Create a
VRFConsumerBaseV2Upgradeable.solfile under the contracts directory.// SPDX-License-Identifier: MIT pragma solidity ^0.8.4; import "@openzeppelin/contracts-upgradeable/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); } }Remember that you'll need to install
@openzeppelin/contracts-upgradeableforInitializablefile.And then import and use it in your contract's initializable function:
import "./VRFConsumerBaseV2Upgradeable.sol"; // ... function initialize( address _minter, string[] memory _tokenURIs, uint64 _subscriptionId, address _vrfCoordinator, bytes32 _keyHash ) public initializer { // ... other assignments subscriptionId = _subscriptionId; keyHash = _keyHash; __VRFConsumerBaseV2Upgradeable_init(_vrfCoordinator); COORDINATOR = VRFCoordinatorV2Interface(_vrfCoordinator); // ... other initializations of erc721, erc1155 etc. }This is just a temporary solution. We need these inside the
@chainlink/contracts-upgradeable.
Doing something similar myself.. unbelievable that they still haven't added something so simple..
