Hardhat-deploy: Unterstützung für Hardware-Wallets?

Hey @smartcontracts das ist definitiv ein Feature, das ich selbst gerne hätte.

Ich sehe 3 Möglichkeiten:

1. Eine Möglichkeit besteht darin, eine Methode deployContract zu hardhat-deploy-ethers hinzuzufügen, mit der Sie einen Ether-Unterzeichner passieren können (siehe diesen PR, der dies in hardhat-deploy selbst bezweckt: https://github.com/wighawag/hardhat- bereitstellen/ziehen/62). Aber als Benutzer mit Bauarbeiterhelm ist dies nicht das eleganteste, da Sie den Unterzeichner usw. instanziieren müssen.

2. Ich hatte gehofft, dass dies auf der Ebene des Bauarbeiterhelms getan werden könnte und es durch Überschreiben des Bauarbeiterhelmanbieters durchaus möglich sein könnte.
   Auf diese Weise könnte nicht nur Hardhat-Deploy profitieren, sondern alle anderen Plugins und Anwendungsfälle.

3. Andernfalls könnte es funktionieren, es als Teil des Hardhat-Deploy zu machen. Ich muss nur herausfinden, wie das konfiguriert wird.
   Derzeit können Sie mit Hardhat-Deploy Konten benennen, und diese Konten sind einfach Adressen als Zeichenfolgen.
   Sie übergeben diese Zeichenfolge wie im Feld from .
   Vor diesem Hintergrund wäre es vielleicht am einfachsten, das Feld from entweder in eine Zeichenfolge oder ein Objekt zu ändern. und das Objekt könnte Optionen angeben, unabhängig davon, ob es sich um eine Hardware-Wallet handelt oder nicht.
   Aber idealerweise möchte ich, dass dies über die genannten Konten konfigurierbar ist. leider macht es die aktuelle benannte Kontostruktur nicht einfach. Eine Idee war, der Adresszeichenfolge eine Protokollzeichenfolge voranzustellen , z. B. "

Sehr interessant. Meine erste Reaktion ist, dass sich Plugins (idealerweise) nicht darum kümmern sollten, ob es sich bei einem Unterzeichner um einen privaten Klartextschlüssel oder eine Hardware-Wallet handelt. Vielleicht könnten wir ein separates Plugin erstellen, das es einem ermöglicht, eine Hardware-Wallet-Verbindung im accounts Feld der Hardhat-Netzwerkkonfiguration anzugeben. Dann könnten wir es in einen LedgerSigner übersetzen (scheint noch keine Unterstützung von Ethers Trezor zu haben). Siehe Beispiel unten:

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

Ja, das wäre meiner Meinung nach der beste Weg. Als niedrigstmögliches Level haben

Ein Problem, das ich sehen kann, ist, dass die Hardware-Wallet die Adresse nicht ohne Bestätigung offenlegt, sodass jedes Plugin, jedes Tool, das die Kontoliste abruft, Benutzereingaben auf der Wallet anfordern würde, nicht ideal.

Vielleicht sollte das Kontoobjekt die Adresse angeben und wenn sie tatsächlich nicht übereinstimmt, wird eine Fehlermeldung ausgegeben, oder so etwas

Vielleicht sollte das Kontoobjekt die Adresse angeben und wenn sie tatsächlich nicht übereinstimmt, wird eine Fehlermeldung ausgegeben, oder so etwas

Ich denke, das ist der richtige Weg. Ich werde morgen damit experimentieren und sehen, ob ich es relativ zuverlässig hinbekomme.

Suchen Sie Hilfe bei anderen Problemen? würde gerne helfen wo ich kann

Momentan nicht, aber ich möchte gerne von fehlenden Funktionen hören, und ich stehe Ihnen zur Verfügung, um dies zu besprechen, um den besten Weg zu finden :)

Ich experimentiere jetzt damit. Leider ist es ziemlich viel Arbeit, dies auf einem niedrigeren Niveau in Bauarbeiterhelmen zu tun. Eine einfache vorübergehende Lösung wäre, dass hardhat-deploy einen Unterzeichner an deploy und nicht nur an eine Adresse übergeben könnte. Wie fühlst du dich darüber? Es würde uns ermöglichen, etwas in der Art zu tun:

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

Hey @smartcontracts , überprüfe meine Antwort hier: https://github.com/wighawag/hardhat-deploy/pull/62
Grundsätzlich möchte ich Hardhat-Deploy unabhängig von Ethern oder anderen Bibliotheken auf der API-Seite halten.

Aber wie in meiner Antwort dort erwähnt, könnte dies über hardhat-deploy-ethers hinzugefügt werden: https://github.com/wighawag/hardhat-deploy-ethers

Wie dringend brauchen Sie so etwas?

Hey @smartcontracts Ich habe die Unterstützung für Ledger in der neuesten Version (0.7.0-beta.51) hinzugefügt.

Konnte nicht viel testen, da die Ledger-Unterstützung ziemlich fehlerhaft zu sein scheint (vielleicht im Zusammenhang damit: https://github.com/ethers-io/ethers.js/issues/1203). aber vielleicht hast du bessere chancen als ich.

Ich habe Option 3 verwendet, die ziemlich einfach hinzuzufügen war. Sie fügen grundsätzlich ein benanntes Konto mit einem Wert wie ledger://<address> siehe zum Beispiel hier: https://github.com/wighawag/template-ethereum-contracts/blob/d7eee3fc00b7e6a347a5ef2cd7718998254f2401/hardhat.config.ts#L15

hardhat-deploy wandelt das in die Adresse um, damit Sie dieses benannte Konto immer noch als Adresse bezeichnen können, aber im Hintergrund verknüpft es dieses Konto mit einem LedgerSigner. Ich habe auch ein Protokoll hinzugefügt, wenn eine Hardware-Wallet erkannt wird.

Bis ein Plugin für Bauarbeiterhelme auf niedrigem Niveau damit umgehen kann, sollte dies für die meisten Anwendungsfälle gut genug sein. Lass mich wissen was du denkst

Das ist fantastisch. Jetzt testen!

Scheint für eine Transaktion zu funktionieren, kam dann aber zu einer Art Absturz. Scheint, dass das Ethers-Ledger-Paket etwas kaputt ist.

@wighawag schön zu sehen, dass demnächst Ledger-Unterstützung kommt. Ich möchte Sie nur darüber informieren, dass ich für mein Projekt einige Korrekturen vorgenommen habe und die für meine mehreren Bereitstellungen zu funktionieren scheinen. Hier ist diff

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 Ich kann PR senden, wenn Sie mich in die richtige Richtung weisen können, um den Fix richtig zu machen, mein Fix ist nicht etwas, das in PR gehen wird ;P

Danke @rokso ich schau mal.
Beachten Sie jedoch, dass die letztere Version des Hardware-Wallet-Pakets ethers.js das Problem möglicherweise trotzdem beheben kann.

@wighawag Ich bin close explizit aufrufen müssen. ethers.js kann helfen, indem es die Methode close verfügbar macht

@rokso Wenn Sie sich das Diff
ethers.js könnte dasselbe auf der TX-Ebene tun

@wighawag ja, das funktioniert, aber der Benutzer muss für jede Transaktion eine neue Verbindung öffnen. Diese Lösung wird für unseren Fall funktionieren, da wir eine neue Verbindung öffnen.

Ich denke, die von @smartcontracts vorgeschlagene anfängliche Lösung ist die eleganteste:

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

Gibt es ein offenes Problem zu Bauarbeiterhelmen? Gerne schaue ich mir die Umsetzung an

Hallo zusammen, wollte mich nur mal über den Status informieren. Wurde das gelöst? Ich stoße lokal auf diesen Fehler: /bindings.js:126 err = new Error( ^ Error: Could not locate the bindings file. Tried: beim Versuch, ein Setup zu erstellen , das " namedAccounts der Konfiguration verwendet.

Ich glaube nicht, dass das Ethers Hardware-Wallet-Paket seine Probleme noch gelöst hat: https://github.com/ethers-io/ethers.js/issues/1440#issuecomment -816554584