Hardhat-deploy: دعم وكيل OpenZeppelin UUPS

التخطيط لتقديم الدعم محليًا ولكن في الوقت الحالي لا يزال من الممكن استخدامها مع النشر الثابت. يحتاج الوكيل إلى أن يكون لديه مالك وهمي / غير مستخدم يجادل في مُنشئه ليظل متوافقًا.

يحتاج الوكيل إلى أن يكون لديه مالك وهمي / غير مستخدم يجادل في مُنشئه ليظل متوافقًا.

ألن يجعل ذلك استخدام UUPS غير مفيد؟ سبب استخدام UUPS هو توفير الغاز في مكالمات المعاملات لأن الوكيل لا يحتاج إلى التحقق مما إذا كان المسؤول هو الذي يجري المكالمة.

ربما أفتقدها ، هل يمكنك أن تشرح مع بعض الشفرات الزائفة كيفية استخدام hardhat-publish مع وكلاء uups (مع الوسيطة غير المستخدمة)؟

شكرا

لن تؤثر على الغاز ، إنها مجرد حجة وهمية بحيث يمكن نشرها بدون تغيير في الكود. المُنشئ لا يحتاج إلى فعل أي شيء بهذه الحجة.
سأرى ما إذا كان بإمكاني إجراء التغيير لجعله يعمل دون أي تغيير قريبًا. يجب أن يكون تغييرًا بسيطًا حيث يمكنك تحديد المُنشئ للوكيل أو ربما ببساطة تحديد أنه وكيل UUPS

شكرًا wighawag ،

للمهتمين قمت بإنشاء هذا العقد:

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 ؟ هل هو مجرد عقد وهمي حتى يعرف تطبيق hardhat واجهة مُنشئ الوكيل الفعلي؟ أم أنها في الواقع تتعلق بطريقة ما بعقد الوكيل الذي يتم نشره؟

ما هو بالضبط دور admin ، أحصل على خطأ بغض النظر عما إذا كان موجودًا ، أو deployer (= ترقية المسؤول) أو إذا حذفت الحقل.

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

marceljay يرجى (دائمًا) لصق الخطأ (الأخطاء) التي تحصل عليها :-)

مرحبًا aspiers ، لم

لذلك لإنجاز هذا العمل باستخدام hardhat-publish ، نقوم بنشره بنفس المُنشئ كوكيل شفاف ، لكننا نتجاهل حقل المسؤول ونحصل على نفس التأثير.

يبدو أنه يعمل معي marceljay

إخلاء المسؤولية لم يتم تدقيق مقتطف الشفرة الخاص بي: sweat_smile: - لا أتحمل أي مسؤولية عن الخوادم الوكيلة التي تمت تهيئتها بشكل سيئ: الضحك:

marceljay آه ، نعم ، يمكنني تخمين مشكلتك. لقد قمت بتحرير ردي الأصلي.

الكود التالي هو ما يجب القيام به عند التنفيذ. لذلك لدي وظيفة في التنفيذ (وليس الوكيل) تسمى التهيئة تأخذ في وسيطة واحدة (المشرف).

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

marceljay آه ، نعم ، يمكنني تخمين مشكلتك. لقد قمت بتحرير ردي الأصلي.

الكود التالي هو ما يجب القيام به عند التنفيذ. لذلك لدي وظيفة في التنفيذ (وليس الوكيل) تسمى التهيئة تأخذ في وسيطة واحدة (المشرف).

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

نعم الآن يبدو الأمر منطقيًا تمامًا ، لقد رأيت أنك قمت بتحرير الإجابة :)

هل تعلم ما إذا كان العقد ERC1967Proxy هو نفسه الذي يستخدمه البرنامج المساعد لترقيات OZ؟

JasoonS شكرا جزيلا للتفسيرات ولكن ما زلت لا تحصل عليه تماما. أعلاه قمت بنشر عقد يبدأ:

contract UUPSProxy is ERC1967Proxy {

هل يتم نشر ذلك فعليًا من خلال نموذج الرمز await deploy الذي نشرته أعلاه ، أم أنه مجرد عقد وهمي بحيث يعرف hardhat-publish واجهة مُنشئ الوكيل الفعلي ، أو أي شيء آخر؟ انت كتبت:

ننشره بنفس المُنشئ كوكيل شفاف

ولكن إذا تم بالفعل نشر ذلك ، فأنا لا أرى كيف يمكن أن يعمل ، لأن هذا العقد يرث من ERC1967Proxy وليس UUPSUpgradeable ، إذن من أين تأتي وظيفة UUPS الفعلية؟

هل يتم نشر ذلك فعليًا عن طريق العينة في انتظار نشر التعليمات البرمجية التي نشرتها أعلاه

نعم ، إنها تنشرها بالفعل.

لأن هذا العقد يرث من ERC1967Proxy غير قابل للترقية UUPS

من المفترض استخدام ERC1967Proxy (يستخدم كل من UUPS والوكلاء الشفافين من openzeppelin erc1967 ، https://docs.openzeppelin.com/contracts/4.x/api/proxy#transparent-vs-uups). يتم استخدام العقد UUPSUpgradeable بواسطة عقد التنفيذ (وهو ليس جزءًا من الوكيل).

إذن من أين ستأتي وظيفة UUPS الفعلية؟

من خلال التصميم ، يحمل عقد التنفيذ وظيفة UUPS ، (وهو أمر جيد لأنه أكثر كفاءة في استخدام الغاز لأن المنطق ليس في الوكيل نفسه ، ولكنه سيء ​​لأنه من الممكن الترقية إلى عقد غير متوافق عن طريق الخطأ وكسر إمكانية الترقية ).

أيضًا ، أنا بالتأكيد لست خبيرًا في البروكسيات ، هذا فقط من بحثي الخاص.

JasoonS علق في 1 سبتمبر 2021 9:18 مساءً :

لأن هذا العقد يرث من ERC1967Proxy غير قابل للترقية UUPS

من المفترض استخدام ERC1967Proxy (يستخدم كل من UUPS والوكلاء الشفافين من openzeppelin erc1967 ، docs.openzeppelin.com/contracts/4.x/api/proxy#transparent-vs-uups ).

حق. ولا يقوم ERC-1967 بالكثير باستثناء تحديد موقع تخزين عنوان التنفيذ وعنوان المرشد وعنوان المسؤول. حقيقة ممتعة لاحظتها في راجع للشغل: وفقًا لـ ERC-1967 ، فإن تطبيق OZ UUPS ينتهك في الواقع EIP1822 الذي يحدد موقع تخزين مختلف قليلاً لعنوان التنفيذ.

يتم استخدام العقد UUPSUpgradeable بواسطة عقد التنفيذ (وهو ليس جزءًا من الوكيل).

D'oh ، بالطبع! شكرا لمساعدتي في معرفة ما كنت أفتقده بغباء هنا.

إذن من أين ستأتي وظيفة UUPS الفعلية؟

من خلال التصميم ، يحمل عقد التنفيذ وظيفة UUPS ، (وهو أمر جيد لأنه أكثر كفاءة في استخدام الغاز لأن المنطق ليس في الوكيل نفسه ، ولكنه سيء ​​لأنه من الممكن الترقية إلى عقد غير متوافق عن طريق الخطأ وكسر إمكانية الترقية ).

نعم ، لذلك يجب أن يرث التطبيق من UUPSUpgradeable .

شكرا جزيلا مرة أخرى على هذه المساعدة الرائعة!