Hardhat-deploy: OpenZeppelin UUPS प्रॉक्सी सपोर्ट

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

प्रॉक्सी जिस्ट को संगत बने रहने के लिए उसके कंस्ट्रक्टर में एक डमी/अप्रयुक्त मालिक का तर्क होना चाहिए।

क्या यह यूयूपीएस का उपयोग करना अब फायदेमंद नहीं होगा? यूयूपीएस का उपयोग करने का कारण लेनदेन कॉल पर गैस की बचत करना है क्योंकि प्रॉक्सी को यह जांचने की आवश्यकता नहीं है कि क्या यह कॉल करने वाला व्यवस्थापक है।

हो सकता है कि मैं इसे याद कर रहा हूं, क्या आप कुछ छद्म कोड के साथ विस्तृत कर सकते हैं कि यूयूपीएस प्रॉक्सी (अप्रयुक्त तर्क के साथ) के साथ हार्डहैट-तैनाती का उपयोग कैसे करें?

धन्यवाद

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

धन्यवाद @ विघवाग , अंत में इसके आसपास हो गया।

रुचि रखने वालों के लिए मैंने यह अनुबंध बनाया है:

pragma solidity ^0.8.0;

import "@openzeppelin/contracts/proxy/ERC1967/ERC1967Proxy.sol";

// Kept for backwards compatibility with older versions of Hardhat and Truffle plugins.
contract UUPSProxy is ERC1967Proxy {
  constructor(
    address _logic,
    address, // This is completely unused by the uups proxy, required to remain compatible with hardhat deploy: https://github.com/wighawag/hardhat-deploy/issues/146
    bytes memory _data
  ) payable ERC1967Proxy(_logic, _data) {}
}

और फिर मेरी तैनाती कुछ इस तरह दिखती है ( proxyContract: "UUPSProxy" महत्वपूर्ण हिस्सा होने के नाते):

  await deploy(CONTRACT, {
    from: deployer,
    proxy: {
      proxyContract: "UUPSProxy",
      // ... your other config, initializers etc
    },
    log: true,
  });

@JasoonS कृपया आप उस UUPSProxy अनुबंध कोड के उद्देश्य को स्पष्ट कर सकते हैं? क्या यह सिर्फ एक डमी अनुबंध है ताकि हार्डहैट-तैनाती वास्तविक प्रॉक्सी के निर्माता के इंटरफ़ेस को जान सके? या क्या यह वास्तव में किसी तरह प्रॉक्सी अनुबंध से संबंधित है जो तैनात हो जाता है?

वास्तव में admin की भूमिका क्या है, मुझे एक त्रुटि मिलती है चाहे वह कोई भी हो, deployer (= अपग्रेड व्यवस्थापक) या यदि मैं फ़ील्ड छोड़ देता हूं।

proxy: {
      proxyContract: "UUPSProxy",
      execute: {
        methodName: "initialize",
        args: [admin],
      },
    },

@marceljay कृपया (हमेशा) आपको जो त्रुटि मिलती है उसे पेस्ट करें :-)

हाय @aspiers , मैंने

तो इस काम को हार्डहैट-तैनाती के साथ करने के लिए हम इसे उसी कन्स्ट्रक्टर के साथ एक पारदर्शी प्रॉक्सी के रूप में तैनात करते हैं, लेकिन हम केवल व्यवस्थापक फ़ील्ड को अनदेखा करते हैं और वही प्रभाव प्राप्त करते हैं।

ऐसा लगता है कि मेरे लिए काम कर रहा है @marceljay

अस्वीकरण मेरे कोड स्निपेट का ऑडिट नहीं किया गया है: sweat_smile: - मैं बुरी तरह से कॉन्फ़िगर किए गए प्रॉक्सी के लिए कोई जिम्मेदारी नहीं लेता: हंसते हुए:

@marceljay आह, हाँ, मैं आपकी समस्या का अनुमान लगा सकता हूं। मैंने अपनी मूल प्रतिक्रिया संपादित की।

निम्नलिखित कोड कार्यान्वयन पर क्या करना है। तो मेरे पास कार्यान्वयन (प्रॉक्सी नहीं) पर एक फ़ंक्शन है जिसे प्रारंभिक कहा जाता है जो 1 तर्क (व्यवस्थापक) लेता है।

execute: {
  methodName: "initialize",
  args: [admin],
},

@marceljay आह, हाँ, मैं आपकी समस्या का अनुमान लगा सकता हूं। मैंने अपनी मूल प्रतिक्रिया संपादित की।

निम्नलिखित कोड कार्यान्वयन पर क्या करना है। तो मेरे पास कार्यान्वयन (प्रॉक्सी नहीं) पर एक फ़ंक्शन है जिसे प्रारंभिक कहा जाता है जो 1 तर्क (व्यवस्थापक) लेता है।

execute: {
  methodName: "initialize",
  args: [admin],
},

हाँ अब यह सही समझ में आता है, देखा कि आपने जवाब संपादित किया है :)

क्या आप जानते हैं कि ERC1967Proxy अनुबंध वही है जो OZ अपग्रेड प्लगइन द्वारा उपयोग किया जाता है?

@JasoonS स्पष्टीकरण के लिए बहुत बहुत धन्यवाद लेकिन मुझे अभी भी यह पूरी तरह से नहीं मिला है। ऊपर आपने एक अनुबंध शुरू किया है:

contract UUPSProxy is ERC1967Proxy {

क्या यह वास्तव में आपके द्वारा ऊपर पोस्ट किए गए नमूना await deploy कोड द्वारा वास्तविक रूप से

हम इसे उसी कंस्ट्रक्टर के साथ एक पारदर्शी प्रॉक्सी के रूप में तैनात करते हैं

लेकिन अगर यह वास्तव में इसे तैनात कर रहा है तो मुझे नहीं लगता कि यह संभवतः कैसे काम कर सकता है, क्योंकि वह अनुबंध ERC1967Proxy से विरासत में मिला है UUPSUpgradeable , तो वास्तविक यूयूपीएस कार्यक्षमता कहां से आएगी?

क्या यह वास्तव में आपके द्वारा ऊपर पोस्ट किए गए नमूना प्रतीक्षा परिनियोजन कोड द्वारा वास्तविक रूप से तैनात किया जाता है

हाँ, यह वास्तव में इसे तैनात करता है।

क्योंकि वह अनुबंध ERC1967Proxy से विरासत में मिला है न कि UUPSUpgradable

यह ERC1967Proxy (दोनों UUPS और ओपनज़ेपेलिन से पारदर्शी प्रॉक्सी erc1967, https://docs.openzeppelin.com/contracts/4.x/api/proxy#transparent-vs-uups) का उपयोग करने वाला है। UUPSUpgradeable अनुबंध का उपयोग कार्यान्वयन अनुबंध द्वारा किया जाता है (यह प्रॉक्सी का हिस्सा नहीं है)।

तो वास्तविक यूयूपीएस कार्यक्षमता कहां से आएगी?

डिजाइन द्वारा कार्यान्वयन अनुबंध में यूयूपीएस कार्यक्षमता होती है, (जो अच्छा है क्योंकि यह अधिक गैस कुशल है क्योंकि तर्क प्रॉक्सी में ही नहीं है, लेकिन खराब है क्योंकि गलती से एक गैर-संगत अनुबंध में अपग्रेड करना और अपग्रेडबिलिटी को तोड़ना संभव है। )

इसके अलावा, मैं निश्चित रूप से परदे के पीछे का विशेषज्ञ नहीं हूं, यह सिर्फ मेरे अपने शोध से है।

@JasoonS ने 1 सितंबर, 2021 को रात 9:18 बजे टिप्पणी की:

क्योंकि वह अनुबंध ERC1967Proxy से विरासत में मिला है न कि UUPSUpgradable

यह ERC1967Proxy (दोनों UUPS और openzeppelin से पारदर्शी प्रॉक्सी erc1967, docs.openzeppelin.com/contracts/4.x/api/proxy#transparent-vs-uups का उपयोग करें) का उपयोग करने वाला है।

सही। और ERC-1967 कार्यान्वयन पते, बीकन पते और व्यवस्थापक पते के भंडारण स्थान को निर्दिष्ट करने के अलावा बहुत कुछ नहीं करता है। BTW मजेदार तथ्य मैंने देखा: ERC-1967 के अनुरूप, OZ UUPS कार्यान्वयन वास्तव में EIP1822 का उल्लंघन करता है जो कार्यान्वयन पते के लिए थोड़ा अलग भंडारण स्थान निर्दिष्ट करता है।

UUPSUpgradeable अनुबंध का उपयोग कार्यान्वयन अनुबंध द्वारा किया जाता है (यह प्रॉक्सी का हिस्सा नहीं है)।

डी'ओह, बिल्कुल! मुझे यह देखने में मदद करने के लिए धन्यवाद कि मैं यहाँ क्या खो रहा था।

तो वास्तविक यूयूपीएस कार्यक्षमता कहां से आएगी?

डिजाइन द्वारा कार्यान्वयन अनुबंध में यूयूपीएस कार्यक्षमता होती है, (जो अच्छा है क्योंकि यह अधिक गैस कुशल है क्योंकि तर्क प्रॉक्सी में ही नहीं है, लेकिन खराब है क्योंकि गलती से एक गैर-संगत अनुबंध में अपग्रेड करना और अपग्रेडबिलिटी को तोड़ना संभव है। )

हां, इसलिए कार्यान्वयन को UUPSUpgradeable ।

इस महान मदद के लिए फिर से बहुत बहुत धन्यवाद!