Hardhat-deploy: ¿Soporte para carteras de hardware?

Hola @smartcontracts, esta es definitivamente una característica que me gustaría tener.

Puedo ver 3 opciones:

1. Una posibilidad es agregar un método deployContract a hardhat-deploy-ethers que le permita pasar un firmante ethers (vea este PR que tenía como objetivo hacer eso en hardhat-deploy: https://github.com/wighawag/hardhat- desplegar / tirar / 62). Pero como usuarios de implementación de casco, este no es el más elegante, ya que necesita instanciar al firmante, etc.

2. Tenía la esperanza de que esto se pudiera hacer a nivel de casco y podría ser posible anulando el proveedor de cascos.
   De esta manera, no solo la implementación de casco podría beneficiarse, sino también todos los demás complementos y casos de uso.

3. De lo contrario, hacerlo como parte del despliegue de casco podría funcionar. Solo necesito averiguar cómo se configuraría esto.
   Actualmente, hardhat-deploy le permite nombrar cuentas y estas cuentas son simplemente direcciones como cadenas.
   pasa esa cadena como está en el campo from .
   Con eso en mente, tal vez lo más simple sea cambiar el campo from para que sea una cadena o un objeto. y el objeto podría especificar opciones si es una billetera de hardware o no.
   Pero idealmente me gustaría que esto se pudiera configurar a través de las cuentas nombradas. Desafortunadamente, la estructura actual de la cuenta nombrada no lo hace fácil. Una idea era anteponer la cadena de dirección con alguna cadena de protocolo, como " ledger: // 0x34fe4ff ... "

Muy interesante. Mi reacción inicial es que (idealmente) los complementos no deberían tener que preocuparse si un firmante es una clave privada de texto plano o una billetera de hardware. Quizás podríamos crear un complemento separado que le permita a uno especificar una conexión de billetera de hardware en el campo accounts de la configuración de la red del casco. Entonces podríamos traducirlo a un LedgerSigner (parece que todavía no hay soporte para ethers Trezor). Vea el ejemplo a continuación:

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

Sí, creo que sería la mejor manera. Tenerlo como el nivel más bajo posible

Un problema que puedo ver es que la billetera de hardware no expone la dirección sin confirmación, por lo que cada complemento, herramienta que busca la lista de cuentas solicitaría la entrada del usuario en la billetera, no es ideal.

Entonces, tal vez el objeto de la cuenta debería especificar la dirección y, si realmente no coincide, se produce un error o algo así.

Entonces, tal vez el objeto de la cuenta debería especificar la dirección y, si realmente no coincide, se produce un error o algo así.

Creo que esta es la forma correcta de hacerlo. Experimentaré con esto mañana y veré si puedo lograr que sea relativamente confiable.

¿Está buscando ayuda con otros problemas? Estaría feliz de ayudar donde pueda

No en este momento, pero estoy ansioso por escuchar las funciones que faltan, y estoy disponible para discutirlo como este para conocer la mejor manera de avanzar :)

Estoy experimentando con esto ahora. Desafortunadamente, es bastante trabajo hacer esto a un nivel más bajo en casco. Una solución temporal fácil sería que hardhat-deploy permitiera pasar un firmante a deploy en lugar de solo una dirección. ¿Cómo te sientes sobre eso? Nos permitiría hacer algo como:

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

Hola @smartcontracts , revisa mi respuesta aquí: https://github.com/wighawag/hardhat-deploy/pull/62
Básicamente, quiero mantener hardhat-deploy independiente de ethers o cualquier otra biblioteca en el lado de la API.

Pero como mencioné en mi respuesta allí, esto podría agregarse a través de hardhat-deploy-ethers : https://github.com/wighawag/hardhat-deploy-ethers

¿Qué tan urgente necesitas algo como esto?

Hola @smartcontracts , agregué soporte para el libro mayor en la última versión (0.7.0-beta.51)

No se pudo probar mucho, ya que el soporte del libro mayor parece tener muchos errores (tal vez relacionado con esto: https://github.com/ethers-io/ethers.js/issues/1203). pero tal vez tengas más posibilidades que yo.

Usé la opción 3, que fue bastante fácil de agregar. básicamente agrega una cuenta nombrada con un valor como ledger://<address> ver por ejemplo aquí: https://github.com/wighawag/template-ethereum-contracts/blob/d7eee3fc00b7e6a347a5ef2cd7718998254f2401/hardhat.config.ts#L15

hardhat-deploy convierta eso en la dirección para que aún pueda referirse a esta cuenta nombrada como una dirección, pero detrás de escena asocia esa cuenta a un LedgerSigner. También agregué un registro cuando se detecta una billetera de hardware /.

Hasta que un complemento para casco pueda manejarlo a un nivel bajo, esto debería ser lo suficientemente bueno para la mayoría de los casos de uso. Déjame saber lo que piensas

Esto es fantástico. ¡Probándolo ahora!

Parecía funcionar para una transacción, pero luego sufrió algún tipo de falla. Parece que el paquete de contabilidad de éteres está un poco roto.

@wighawag es genial ver que el soporte de contabilidad llegará pronto. Solo quiero informarles que para mi proyecto hice una corrección y que parece funcionar para mis múltiples implementaciones. Aquí es 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 Puedo enviar relaciones públicas si me pueden señalar en la dirección correcta para hacer la corrección de la manera correcta, mi corrección no es algo que vaya a ir en relaciones públicas; P

Gracias @rokso , echaré un vistazo.
Sin embargo, tenga en cuenta que la última versión del paquete de hardhware-wallet ethers.js podría solucionar el problema de todos modos.

@wighawag No estoy seguro de cómo ethers.js solucionará esto, ya que tendremos que llamar a close explícitamente. ethers.js puede ayudar al exponer el método close

@rokso mirando el diff, cierras después de cada implementación.
ethers.js podría hacer lo mismo a nivel tx

@wighawag sí, eso funciona, pero el usuario tendrá una nueva conexión abierta para cada transacción. Esta solución funcionará para nuestro caso ya que estamos abriendo una nueva conexión.

Creo que la solución inicial propuesta por @smartcontracts es la más elegante:

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

¿Hay un problema abierto sobre el casco? Estaría feliz de echar un vistazo a la implementación de esto.

Hola a todos, solo quería comprobar el estado de esto. ¿Esto ha sido resuelto? Me encuentro con este error localmente: /bindings.js:126 err = new Error( ^ Error: Could not locate the bindings file. Tried: al intentar una configuración que usa ' ledger: // 0x00000000000000addr00000 ' dentro de namedAccounts de la configuración.

No creo que el paquete ethers hardware-wallet haya resuelto sus problemas todavía: https://github.com/ethers-io/ethers.js/issues/1440#issuecomment -816554584