Hardhat-deploy: उन्नयन योग्य अनुबंधों की तैनाती पर प्रश्न

जिस तरह से हार्डहैट-तैनाती डिफ़ॉल्ट रूप से स्क्रिप्ट को तैनात करने पर विचार करती है, वह यह है कि वे बेकार हैं। प्रॉक्सी परिनियोजन पर भी यही लागू होता है। यह विकास/तैनाती के लिए अच्छा बनाता है क्योंकि आपको केवल यह सोचने की ज़रूरत है कि आप किस राज्य में बनना चाहते हैं और हार्डहैट-तैनाती उस राज्य तक पहुंचने के लिए सब कुछ कर देगी,

तो आपके प्रश्न का उत्तर देने के लिए, मैं आमतौर पर अपने प्रारंभिक कार्य को बेकार बनाने के लिए करता हूं, इसलिए इसे फेंकने के बजाय इसे पहले ही प्रारंभ कर दिया गया है। मैं इस प्रकार उस फ़ंक्शन को पोस्ट अपग्रेड फ़ंक्शन के रूप में जोड़ सकता हूं और सभी ठीक काम करते हैं। विकास में मैं इनिशियलाइज़ फंक्शन को चीजों को करने के लिए बदल सकता हूँ जब मैं ज़रूरत पड़ने पर अपग्रेड करता हूँ।

अधिक जटिल परिदृश्य के लिए आप प्रत्येक अपग्रेड को अलग परिनियोजन स्क्रिप्ट में व्यवस्थित कर सकते हैं।

एक अनिर्दिष्ट विशेषता है जो परिवर्तनों के अधीन है: upgradeIndex पैरामीटर जो आपको परिनियोजित स्क्रिप्ट को निर्दिष्ट करने देता है जिसे क्रम में निष्पादित करने की आवश्यकता है।

यह परीक्षण के लिए बहुत अच्छा है क्योंकि आप अपग्रेड इतिहास के बीच किसी भी बिंदु पर योरू प्रॉक्सी का परीक्षण कर सकते हैं और सभी कार्यों को सुनिश्चित कर सकते हैं।

आपके त्वरित उत्तर के लिए धन्यवाद।
ऐसा लगता है कि मैं सब काम सुचारू रूप से करने में कामयाब रहा। मैं deploy() और फिर execute के साथ OpenZeppelin Initializable आधार अनुबंध के initialize फ़ंक्शन का उपयोग करता हूं। execute() सच हो जाता है और जब मैं अनुबंधों को अपग्रेड करता हूं तो यह नहीं चलता है:

// deploy/01_deploy_skin_rewards.js

module.exports = async ({
  getNamedAccounts,
  deployments,
}) => {
  const {deploy} = deployments;
  const {deployer} = await getNamedAccounts();
  await deploy('SkinRewards', {
    from: deployer,
    proxy: {
      owner: deployer,
      proxyContract: 'OpenZeppelinTransparentProxy',
    },
    args: [],
    log: true,
  });
};
module.exports.tags = ['SkinRewards'];

और फिर

// deploy/02_init_skin_rewards.js

require('dotenv').config();
const RewardPeriods = ethers.BigNumber.from(process.env.REWARD_PERIODS);
module.exports = async ({getNamedAccounts, deployments}) => {
  const { deployer } = await getNamedAccounts();
  const SnookGame = await deployments.get('SnookGame');
  const SnookState = await deployments.get('SnookState');
  const SnookToken = await deployments.get('SnookToken');
  const SkillToken = await deployments.get('SkillToken');
  const Afterdeath = await deployments.get('Afterdeath');
  const Treasury = await deployments.get('Treasury');

  await deployments.execute(
    'SkinRewards',
    {from:deployer},
    'initialize',
    RewardPeriods,
    Treasury.address,
    SnookGame.address,
    SnookState.address,
    SnookToken.address,
    SkillToken.address,
    Afterdeath.address
  );
  deployments.log('Initialized SkinRewards');
  return true;
};
module.exports.tags = ['initSkinRewards'];
module.exports.id = 'initSkinRewards';

क्या इस पद्धति को _अच्छा अभ्यास_ माना जा सकता है? क्या आपने इसे वैसे ही खोजा है?

जैसा कि मैंने ऊपर उल्लेख किया है, SkinRewards में मुझे OpenZeppelin के Initializable अनुबंध से विरासत में मिला है जो initialize() फ़ंक्शन को पहले कॉल करने के लिए परिभाषित करता है। इसलिए मैं नहीं देखता कि मैं इसे पोस्टअपग्रेड कैसे चला सकता हूं। क्या तुम समझा सकते हो? धन्यवाद

यह अच्छा लगता है, methodName ("पोस्टअपग्रेड") का उपयोग करने की तुलना में नुकसान यह है कि आप 1 के बजाय 2 टीएक्स निष्पादित कर रहे हैं

यदि आप अपने इनिशियलाइज़ फंक्शन को इडम्पोटेंट बनाते हैं, यानी इसे बिना थ्रो किए कई बार कॉल किया जा सकता है, तो यह सुनिश्चित कर लें कि आगे की कॉल स्टेट को संशोधित नहीं करेगी (यदि पहले से ही इनिशियलाइज़ हो तो स्किप करके), तो आप इसे methodName विकल्पों के माध्यम से उपयोग कर सकते हैं। . पहली तैनाती भी इसे निष्पादित करेगी।

ध्यान दें, क्योंकि आप तर्कों का उपयोग करते हैं और परिनियोजन फ़ंक्शन सेटअप है ताकि आप केवल प्रॉक्सी विकल्प को बंद कर सकें और एक काम करने वाला अपरिवर्तनीय अनुबंध हो, methodName विकल्प तर्क के लिए args विकल्पों का उपयोग करता है।
इसका मतलब है कि प्रॉक्सी कार्यान्वयन के निर्माता को भी इन तर्कों की आवश्यकता है। यदि आप प्रॉक्सी के बिना अनुबंध का उपयोग करने का इरादा नहीं रखते हैं, तो आप तर्कों के साथ कुछ भी नहीं कर सकते हैं।

वास्तव में सुविधा के लिए यदि कार्यान्वयन अनुबंध में शून्य तर्क है, तो यह निर्माता को पूरी तरह से अनदेखा कर देता है लेकिन मुझे यकीन नहीं है कि यह एक अच्छा विचार था।

यहां methodName विकल्प वाली स्क्रिप्ट होगी:

// deploy/01_deploy_skin_rewards.js

module.exports = async ({
  getNamedAccounts,
  deployments,
}) => {
  const {deploy} = deployments;
  const {deployer} = await getNamedAccounts();
  await deploy('SkinRewards', {
    from: deployer,
    proxy: {
      methodName: 'initialize`,
      owner: deployer,
      proxyContract: 'OpenZeppelinTransparentProxy',
    },
    args: [
      RewardPeriods,
      Treasury.address,
      SnookGame.address,
      SnookState.address,
      SnookToken.address,
      SkillToken.address,
      Afterdeath.address
    ],
    log: true,
  });
};
module.exports.tags = ['SkinRewards'];

_यदि आप अपने इनिशियलाइज़ फंक्शन को इडम्पोटेंट बनाते हैं, यानी इसे बिना थ्रो किए कई बार कॉल किया जा सकता है, तो यह सुनिश्चित कर लें कि आगे की कॉल स्टेट को संशोधित नहीं करेगी (यदि पहले से ही इनिशियलाइज़ हो तो स्किप करके), तो आप इसे मेथडनाम विकल्पों के माध्यम से उपयोग कर सकते हैं। पहली तैनाती इसे भी निष्पादित करेगी।_

इसका मतलब है कि हम https://github.com/OpenZeppelin/openzeppelin-contracts-upgradable/blob/release-v4.0/contracts/proxy/utils/Initializable.sol से AS-IS फ़ंक्शन initialize() उपयोग नहीं कर सकते हैं। .

@फ्रीबाइट वास्तव में

मैं इस तरह का व्यवहार पाने के लिए एक विकल्प जोड़ने पर विचार करूंगा

बहुत बहुत धन्यवाद!

एक और सवाल तैनात अनुबंधों का उपयोग करने के बारे में है। विशेष रूप से, मैं Uniswap को पुनः प्राप्त करने के लिए कह रहा हूँ।

प्लगइन डॉक्स के इस हिस्से से मैं नहीं देखता कि मैं तैनात यूनिस्वैप अनुबंध के पते की आपूर्ति कैसे करता हूं। Uniswap NPM कलाकृतियों के साथ build फ़ोल्डर के साथ आता है लेकिन मैं विशिष्ट पते पर अनुबंध के बारे में जानने के लिए प्लगइन कैसे बनाऊं? हम परिनियोजन स्क्रिप्ट में ईथर का उपयोग नहीं करना चाहते हैं, है ना?

निम्नलिखित कोड वह नहीं है जो हम परिनियोजन स्क्रिप्ट में चाहते हैं:

const { ethers } = require("hardhat");

const UniswapV2FactoryArtifact = require('@uniswap/v2-core/build/UniswapV2Factory.json');
const UniswapV2FactoryAddress = '0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f';

module.exports = async ({getNamedAccounts, deployments}) => {
  const {deployer} = await getNamedAccounts();
  const UniswapFactory = await ethers.getContractAt(UniswapV2FactoryArtifact.abi, UniswapV2FactoryAddress);
// continue...

मैं deployments var में Uniswap परिनियोजन कैसे प्राप्त करूं?

पहले से परिनियोजित अनुबंधों के लिए उनके लिए संबंधित परिनियोजन फ़ोल्डर में फ़ाइलें बनाना सबसे अच्छा है
इसलिए मेननेट यूनिस्वैप के लिए और यह मानते हुए कि आपके पास हार्डहैट.कॉन्फिग.जेएस में कॉन्फ़िगर किया गया मेननेट नेटवर्क है, आप "डिप्लॉयमेंट्स/मेननेट/यूनिस्वापफैक्टरी.जेसन" फाइल बना सकते हैं। कम से कम इसे एक पता और अबी फ़ील्ड की आवश्यकता है

तब आप उस नेटवर्क पर तैनाती के माध्यम से इसे एक्सेस कर सकते हैं

आप जिस दस्तावेज़ लिंक की ओर इशारा करते हैं, वह आपको कलाकृतियों (इसलिए uniswap बिल्ड फ़ोल्डर) या स्क्रिप्ट को तैनात करने की अनुमति देता है, लेकिन बाद वाला तभी काम करता है जब प्रश्न में परियोजना ने इन तैनाती स्क्रिप्ट को कहीं उजागर किया हो

मैं इसे अपने स्वयं के प्रोजेक्ट जैसे https://github.com/wighawag/universal-forwarder में करता हूं जो उपयोगकर्ता को केवल npm पैकेज स्थापित करने की अनुमति देता है और वे पूरी परियोजना को अपने परीक्षण या अपने नेटवर्क पर तैनात करते हैं। लेकिन uniswap वह प्रदान नहीं करता है

महान। बहुत - बहुत धन्यवाद।

प्रॉक्सी के लिए पुन: प्रारंभ कार्य

मैंने हार्डहैट-तैनाती 0.8.0 में एक नया विकल्प जोड़ा ( methodName के बजाय जो अभी भी उपलब्ध है)

देखें https://github.com/wighawag/template-ethereum-contracts/blob/595c1b5ec9cdf1276f4d3a43b4825bcef78bd2cd/deploy/004_deploy_erc20_always_proxied_via_openzeppelin_proxy.ts#L12 -L26

अगर आपको कोई समस्या आती है तो मुझे बताएं