Hardhat-deploy: Prise en charge des portefeuilles matériels ?

Hé @smartcontracts, c'est définitivement une fonctionnalité que j'aimerais avoir moi-même.

Je vois 3 options :

1. Une possibilité consiste à ajouter une méthode deployContract à hardhat-deploy-ethers qui vous permettrait de passer un signataire d'éthers (voir ce PR qui visait à le faire dans hardhat-deploy lui-même : https://github.com/wighawag/hardhat- déployer/tirer/62). Mais en tant qu'utilisateurs de casques de sécurité, ce n'est pas le plus élégant car vous devez instancier le signataire, etc.

2. J'espérais que cela pourrait être fait au niveau du casque et cela pourrait bien être possible en remplaçant le fournisseur du casque.
   De cette façon, non seulement hardhat-deploy pourrait en bénéficier, mais tous les autres plugins et cas d'utilisation.

3. Sinon, l'intégrer à hardhat-deploy pourrait fonctionner. J'ai juste besoin de comprendre comment cela serait configuré.
   Actuellement, hardhat-deploy vous permet de nommer des comptes et ces comptes sont simplement des adresses sous forme de chaînes.
   vous passez cette chaîne telle quelle dans le champ from .
   Dans cet esprit, le plus simple serait peut-être de changer le champ from en une chaîne ou un objet. et l'objet pourrait spécifier des options, qu'il s'agisse ou non d'un portefeuille matériel.
   Mais idéalement, j'aimerais que cela soit configurable via les comptes nommés. Malheureusement, la structure actuelle du compte nommé ne facilite pas les choses. Une idée était de préfixer la chaîne d'adresse avec une chaîne de protocole, comme " ledger://0x34fe4ff... "

Très intéressant. Ma première réaction est que (idéalement) les plugins ne devraient pas avoir à se soucier de savoir si un signataire est une clé privée en texte clair ou un portefeuille matériel. Peut-être pourrions-nous créer un plugin séparé qui permet de spécifier une connexion de portefeuille matériel dans le champ accounts de la configuration du réseau du casque. Ensuite, nous pourrions le traduire en un LedgerSigner (il ne semble pas encore pris en charge par les éthers Trezor). Voir exemple ci-dessous :

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

Oui, ce serait la meilleure façon je pense. L'avoir au niveau le plus bas possible

Un problème que je peux voir est que le portefeuille matériel n'expose pas l'adresse sans confirmation, donc chaque plugin, outil qui récupère la liste des comptes demanderait l'entrée de l'utilisateur sur le portefeuille, ce qui n'est pas idéal.

Alors peut-être que l'objet de compte devrait spécifier l'adresse et s'il ne correspond pas, il se trompe, ou quelque chose

Alors peut-être que l'objet de compte devrait spécifier l'adresse et s'il ne correspond pas, il se trompe, ou quelque chose

Je pense que c'est la bonne façon de procéder. Je vais expérimenter cela demain et voir si je peux le rendre relativement fiable.

Vous cherchez de l'aide pour d'autres problèmes ? serais heureux d'aider là où je peux

Pas pour le moment, mais j'ai hâte d'entendre parler des fonctionnalités manquantes, et je suis disponible pour en discuter comme celui-ci pour la meilleure voie à suivre :)

J'expérimente avec ça maintenant. Malheureusement, faire cela à un niveau inférieur avec un casque de sécurité demande beaucoup de travail. Une solution temporaire simple serait que hardhat-deploy permette de transmettre un signataire à deploy par opposition à une simple adresse. Comment te sens tu à propos de ça? Cela nous permettrait de faire quelque chose du genre :

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

Hé @smartcontracts , vérifiez ma réponse ici : https://github.com/wighawag/hardhat-deploy/pull/62
Fondamentalement, je veux garder hardhat-deploy indépendant des éthers ou de toute autre bibliothèque du côté de l'API.

Mais comme mentionné dans ma réponse, cela pourrait être ajouté via hardhat-deploy-ethers : https://github.com/wighawag/hardhat-deploy-ethers

A quel point avez-vous besoin de quelque chose comme ça de toute urgence ?

Hé @smartcontracts, j'ai ajouté la prise en charge du grand livre sur la dernière version (0.7.0-beta.51)

Je n'ai pas pu tester grand-chose car la prise en charge du grand livre semble être assez boguée (peut-être en rapport avec cela : https://github.com/ethers-io/ethers.js/issues/1203). mais peut-être aurez-vous plus de chance que moi.

J'ai utilisé l'option 3 qui était assez facile à ajouter. vous ajoutez essentiellement un compte nommé avec une valeur comme ledger://<address> voir par exemple ici : https://github.com/wighawag/template-ethereum-contracts/blob/d7eee3fc00b7e6a347a5ef2cd7718998254f2401/hardhat.config.ts#L15

hardhat-deploy convertit cela en adresse afin que vous puissiez toujours faire référence à ce compte nommé en tant qu'adresse, mais en arrière-plan, il associe ce compte à un LedgerSigner. J'ai également ajouté un journal lorsqu'un portefeuille matériel est détecté/.

Jusqu'à ce qu'un plugin pour casque de sécurité puisse le gérer à un niveau bas, cela devrait être suffisant pour la plupart des cas d'utilisation. Laissez-moi savoir ce que vous pensez

C'est fantastique. A tester maintenant !

Semblait fonctionner pour une transaction, mais a ensuite eu une sorte de plantage. Il semble que le package du grand livre des éthers soit un peu cassé.

@wighawag ravi de voir le support du grand livre arriver bientôt. Je veux juste vous informer que pour mon projet j'ai fait quelques correctifs et qui semble fonctionner pour mes multiples déploiements. Voici la différence

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 Je peux envoyer des relations publiques si vous pouvez

Merci @rokso je vais regarder.
Notez cependant que cette dernière version du package hardware-wallet ethers.js pourrait quand même résoudre le problème.

@wighawag Je ne sais pas comment ethers.js résoudra ce problème, car nous devrons appeler close explicitement. ethers.js peut aider en exposant la méthode close

@rokso en regardant le diff, vous fermez après chaque déploiement.
ethers.js pourrait faire la même chose au niveau tx

@wighawag oui cela fonctionne mais l'utilisateur devra ouvrir une nouvelle connexion pour chaque transaction. Cette solution fonctionnera pour notre cas car nous ouvrons une nouvelle connexion.

Je pense que la solution initiale proposée par @smartcontracts est la plus élégante :

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

Y a-t-il un problème ouvert sur le casque ? Je serais heureux de jeter un oeil à la mise en œuvre de ce

Salut à tous, je voulais juste vérifier l'état de cela. Cela a-t-il été résolu ? Je rencontre cette erreur localement : /bindings.js:126 err = new Error( ^ Error: Could not locate the bindings file. Tried: lors d'une tentative d'installation qui utilise " ledger://0x0000000000000000addr00000 " dans les namedAccounts de la configuration.

Je ne pense pas que le package de portefeuille matériel ethers ait encore résolu ses problèmes : https://github.com/ethers-io/ethers.js/issues/1440#issuecomment -816554584