Hardhat-deploy: دعم لمحافظ الأجهزة؟

مرحبًا smartcontracts ، هذه بالتأكيد ميزة أود أن أحصل عليها بنفسي.

يمكنني رؤية 3 خيارات:

1. أحد الاحتمالات هو إضافة طريقة publishContract إلى hardhat-deploy-ethers تسمح لك بتمرير مُوقِّع ethers (انظر هذا PR الذي يهدف إلى القيام بذلك في hardhat-publish نفسه: https://github.com/wighawag/hardhat- نشر / سحب / 62). ولكن بصفتك مستخدمين للخدمة الثابتة ، فإن هذا ليس هو الأكثر أناقة حيث تحتاج إلى إنشاء مثيل للموقّع ، وما إلى ذلك ...

2. كنت آمل أن يتم ذلك على مستوى hardhat وقد يكون ذلك ممكنًا من خلال تجاوز مزود hardhat.
   وبهذه الطريقة ، لا يمكن الاستفادة من تطبيق hardhat فقط ولكن كل مكون إضافي وحالات استخدام.

3. خلاف ذلك ، جعله كجزء من نشر قوي يمكن أن ينجح. أنا فقط بحاجة لمعرفة كيفية تكوين هذا.
   يسمح لك تطبيق hardhat حاليًا بتسمية الحسابات وهذه الحسابات هي ببساطة عناوين كسلاسل.
   تقوم بتمرير هذه السلسلة كما هي في الحقل from .
   مع أخذ ذلك في الاعتبار ، ربما يكون أبسط شيء هو تغيير الحقل from ليكون إما سلسلة أو كائنًا. ويمكن للكائن تحديد الخيارات سواء كانت محفظة أجهزة أم لا.
   لكن من الناحية المثالية ، أود أن يكون هذا قابلاً للتكوين من خلال الحسابات المحددة. لسوء الحظ ، فإن بنية الحساب المسمى الحالية لا تجعل الأمر سهلاً. كانت إحدى الأفكار هي إرفاق سلسلة العنوان مسبقًا ببعض سلاسل البروتوكول ، مثل " Ledger: // 0x34fe4ff ... "

مثير جدا. كان رد فعلي الأولي (من الناحية المثالية) أن المكونات الإضافية لا يجب أن تهتم بما إذا كان المُوقِّع هو مفتاح خاص بنص عادي أو محفظة أجهزة. ربما يمكننا إنشاء مكون إضافي منفصل يسمح لأحدهم بتحديد اتصال محفظة الأجهزة في الحقل accounts لتكوين شبكة hardhat. ثم يمكننا ترجمته إلى LedgerSigner (يبدو أنه لا يوجد دعم من نوع ethers Trezor حتى الآن). انظر المثال أدناه:

const config = {
  networks: {
    goerli: {
      accounts: [
        {
          platform: "ledger",
          type: "hid",
          path: "m/44'/60'/0'/0/0"
        }
      ],
    }
  }
}

نعم ، سيكون هذا أفضل طريقة على ما أعتقد. الحصول عليها عند أدنى مستوى ممكن

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

لذلك ربما يجب أن يحدد كائن الحساب العنوان وإذا كان لا يتطابق بالفعل ، فهذا يعني أنه خطأ ، أو شيء من هذا القبيل

لذلك ربما يجب أن يحدد كائن الحساب العنوان وإذا كان لا يتطابق بالفعل ، فهذا يعني أنه خطأ ، أو شيء من هذا القبيل

أعتقد أن هذه هي الطريقة الصحيحة للقيام بذلك. سأختبر هذا غدًا وأرى ما إذا كان بإمكاني جعله موثوقًا نسبيًا.

هل تبحث عن مساعدة بخصوص أي قضايا أخرى؟ سأكون سعيدًا للمساعدة حيث يمكنني ذلك

ليس الآن ، لكنني حريص على سماع الميزات المفقودة ، وأنا متاح لمناقشتها مثل هذه للحصول على أفضل طريقة للمضي قدمًا :)

أنا أجرب هذا الآن. لسوء الحظ ، هناك قدر كبير من العمل للقيام بذلك على مستوى أقل في hardhat. ومن شأن حل مؤقت من السهل أن يكون ل hardhat-deploy للسماح بتمرير في الموقع ل deploy بدلا من مجرد عنوان. كيف تشعر حيال ذلك؟ سيسمح لنا بعمل شيء على غرار:

const signer = new LedgerSigner(hre.network.provider, 'default', hre.ethers.utils.defaultPath)
const result = await deploy('MyContract', {
  from: signer,
  args: [],
  log: true,
})

مرحبًا smartcontracts ، تحقق من إجابتي هنا: https://github.com/wighawag/hardhat-deploy/pull/62
في الأساس ، أريد الاحتفاظ بالنشر الثابت بشكل مستقل عن الإيثرات أو أي مكتبة أخرى على جانب واجهة برمجة التطبيقات.

ولكن كما هو مذكور في ردي هناك ، يمكن إضافة هذا من خلال hardhat-deploy-ethers : https://github.com/wighawag/hardhat-deploy-ethers

ما مدى الحاجة الملحة لشيء مثل هذا؟

مرحبًا smartcontracts لقد أضفت دعمًا لدفتر الأستاذ في أحدث إصدار (0.7.0-beta.51)

لا يمكن اختبار الكثير حيث يبدو أن دعم دفتر الأستاذ مليء بالأخطاء (ربما يتعلق بذلك: https://github.com/ethers-io/ethers.js/issues/1203). ولكن ربما ستحظى بفرصة أفضل مني.

لقد استخدمت الخيار 3 الذي كان من السهل جدًا إضافته. تقوم أساسًا بإضافة حساب مسمى بقيمة مثل ledger://<address> انظر على سبيل المثال هنا: https://github.com/wighawag/template-ethereum-contracts/blob/d7eee3fc00b7e6a347a5ef2cd7718998254f2401/hardhat.config.ts#L15

قم بتحويل ذلك إلى العنوان بحيث لا يزال بإمكانك الإشارة إلى هذا الحساب المسمى كعنوان ، ولكن وراء الكواليس يربط هذا الحساب بـ LedgerSigner. لقد أضفت أيضًا سجلًا عند اكتشاف محفظة أجهزة /.

حتى يتمكن المكون الإضافي لـ hardhat من التعامل معه عند مستوى منخفض ، يجب أن يكون هذا جيدًا بما يكفي لمعظم حالات الاستخدام. اسمحوا لي أن أعرف ما هو رأيك

هذا رائع. اختبرها الآن!

يبدو أنه يعمل من أجل معاملة واحدة ولكن بعد ذلك حصل على نوع من الانهيار. يبدو أن حزمة دفتر الأستاذ الخاص بالإيثر معطلة بعض الشيء.

wighawag من الرائع رؤية دعم دفتر الأستاذ قريبًا. أريد فقط أن أبلغكم أنه بالنسبة لمشروعي قمت ببعض الإصلاحات ويبدو أنها تعمل مع عمليات النشر المتعددة الخاصة بي. هنا فرق

diff --git a/node_modules/hardhat-deploy/dist/src/helpers.js b/node_modules/hardhat-deploy/dist/src/helpers.js
index 3b588fa..67dce8f 100644
--- a/node_modules/hardhat-deploy/dist/src/helpers.js
+++ b/node_modules/hardhat-deploy/dist/src/helpers.js
@@ -290,6 +290,10 @@ function addHelpers(deploymentManager, partialExtension, network, getArtifact, s
         if (options.log || hardwareWallet) {
             print(`: deployed at ${deployment.address} with ${receipt === null || receipt === void 0 ? void 0 : receipt.gasUsed} gas\n`);
         }
+        if(hardwareWallet){
+            const __eth = await ethersSigner._eth
+            await __eth.transport.device.close()
+        }
         return Object.assign(Object.assign({}, deployment), { address, newlyDeployed: true });
     }
     async function deterministic(name, options) {
@@ -396,7 +400,7 @@ function addHelpers(deploymentManager, partialExtension, network, getArtifact, s
                 transaction = await provider.getTransaction(deployment.transactionHash);
             }
             if (transaction) {
-                const { ethersSigner } = await getOptionalFrom(options.from);
+                const { ethersSigner, hardwareWallet } = await getOptionalFrom(options.from);
                 const { artifact } = await getArtifactFromOptions(name, options);
                 const abi = artifact.abi;
                 const byteCode = linkLibraries(artifact, options.libraries);
@@ -421,9 +425,17 @@ function addHelpers(deploymentManager, partialExtension, network, getArtifact, s
                             ' not specified in new transaction, cant compare');
                     }
                     if (transaction[field] !== newTransaction[field]) {
+                        if(hardwareWallet){
+                            const __eth = await ethersSigner._eth
+                            await __eth.transport.device.close()
+                        }
                         return { differences: true, address: deployment.address };
                     }
                 }
+                if(hardwareWallet){
+                    const __eth = await ethersSigner._eth
+                    await __eth.transport.device.close()
+                }
                 return { differences: false, address: deployment.address };
             }
         }

wighawag يمكنني إرسال العلاقات العامة إذا كان بإمكانك توجيهي في الاتجاه الصحيح للقيام

شكرا @ rokso سآخذ نظرة.
لاحظ أن الإصدار الأخير من حزمة ethers.js hardhware-wallet قد يحل المشكلة على أي حال.

wighawag لست متأكدًا من كيفية إصلاح ethers.js لهذا الأمر ، حيث سيتعين علينا الاتصال بـ close صراحة. يمكن أن تساعد ethers.js عن طريق عرض طريقة close

rokso عند النظر إلى الفرق ، تغلق بعد كل عملية نشر.
يمكن لـ ethers.js أن يفعل الشيء نفسه على مستوى tx

wighawag نعم هذا يعمل ولكن المستخدم سيفتح اتصالًا جديدًا لكل معاملة. سيعمل هذا الحل مع حالتنا لأننا نفتح اتصالًا جديدًا.

أعتقد أن الحل الأولي الذي اقترحه smartcontracts هو الأكثر أناقة:

const config = {
  networks: {
    goerli: {
      accounts: [
        {
          platform: "ledger",
          type: "hid",
          path: "m/44'/60'/0'/0/0"
        }
      ],
    }
  }
}

هل هناك قضية مفتوحة على hardhat؟ سأكون سعيدًا لإلقاء نظرة على تنفيذ هذا

مرحبًا بالجميع ، أردت فقط التحقق من حالة هذا. هل تم حل هذا؟ أواجه هذا الخطأ محليًا: /bindings.js:126 err = new Error( ^ Error: Could not locate the bindings file. Tried: أثناء محاولة إعداد يستخدم " دفتر الأستاذ: // 0x00000000000000addr00000 " ضمن namedAccounts من التكوين.

لا أعتقد أن حزمة محفظة أجهزة ethers قد حلت مشكلاتها حتى الآن: https://github.com/ethers-io/ethers.js/issues/1440#issuecomment -816554584