Hardhat-deploy: Suporte para carteiras de hardware?

Ei, @smartcontracts, esse é definitivamente um recurso que eu gostaria de ter.

Posso ver 3 opções:

1. Uma possibilidade é adicionar um método deployContract a hardhat-deploy-ethers que permitiria que você passasse um signatário ethers (veja este PR que pretendia fazer isso no próprio hardhat-deploy: https://github.com/wighawag/hardhat- implantar / puxar / 62). Mas, como um usuário de implantação de capacete de segurança, isso não é o mais elegante, pois você precisa instanciar o signatário, etc ...

2. Eu esperava que isso pudesse ser feito no nível do capacete de segurança e poderia muito bem ser possível substituindo o fornecedor do capacete.
   Desta forma, não apenas o hardhat-deploy poderia se beneficiar, mas todos os outros plugins e casos de uso.

3. Caso contrário, torná-lo parte da implantação do capacete de segurança pode funcionar. Eu só preciso descobrir como isso seria configurado.
   Atualmente, a implantação do capacete de segurança permite que você nomeie contas e essas contas são simplesmente endereços como strings.
   você passa essa string como está no campo from .
   Com isso em mente, talvez o mais simples seja alterar o campo from para ser uma string ou um objeto. e o objeto pode especificar opções, seja uma carteira de hardware ou não.
   Mas, idealmente, gostaria que isso fosse configurável por meio das contas nomeadas. infelizmente, a estrutura atual da conta nomeada não facilita isso. Uma ideia era acrescentar ao início da string de endereço alguma string de protocolo, como " ledger: // 0x34fe4ff ... "

Muito interessante. Minha reação inicial é que (idealmente) os plug-ins não deveriam se importar se o signatário é uma chave privada de texto simples ou uma carteira de hardware. Talvez pudéssemos criar um plugin separado que permitisse especificar uma conexão de carteira de hardware no campo accounts da configuração de rede do hardhat. Então poderíamos traduzi-lo em um LedgerSigner (parece que ainda não há suporte para éteres Trezor). Veja o exemplo abaixo:

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

Sim, essa seria a melhor maneira, eu acho. Ter o nível mais baixo possível

Um problema que posso ver é que a carteira de hardware não expõe o endereço sem confirmação, portanto, cada plugin, ferramenta que busca a lista de contas solicitaria a entrada do usuário na carteira, o que não é o ideal.

Então, talvez o objeto de conta deva especificar o endereço e se ele realmente não corresponder, então ocorrerá um erro ou algo assim

Então, talvez o objeto de conta deva especificar o endereço e se ele realmente não corresponder, então ocorrerá um erro ou algo assim

Acho que essa é a maneira certa de fazer isso. Vou experimentar isso amanhã e ver se consigo torná-lo relativamente confiável.

Você está procurando ajuda para outros problemas? ficaria feliz em ajudar onde eu puder

Não agora, mas estou ansioso para ouvir sobre os recursos ausentes, e estou disponível para discutir como este para conhecer o melhor caminho a seguir :)

Estou experimentando isso agora. Infelizmente, é um pouco trabalhoso fazer isso em um nível inferior no capacete. Uma solução temporária fácil seria hardhat-deploy permitir a passagem de um signatário para deploy em vez de apenas um endereço. Como você se sente sobre isso? Isso nos permitiria fazer algo como:

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

Ei @smartcontracts , verifique minha resposta aqui: https://github.com/wighawag/hardhat-deploy/pull/62
Basicamente, eu quero manter a implantação do hardhat independente de ethers ou de qualquer outra biblioteca do lado da API.

Mas, como mencionei na minha resposta, isso pode ser adicionado por meio de hardhat-deploy-ethers : https://github.com/wighawag/hardhat-deploy-ethers

Com que urgência você precisa de algo assim?

Ei @smartcontracts , adicionei suporte para razão na versão mais recente (0.7.0-beta.51)

Não foi possível testar muito, pois o suporte ao razão parece ter muitos bugs (talvez relacionado a isso: https://github.com/ethers-io/ethers.js/issues/1203). mas talvez você tenha uma chance melhor do que eu.

Usei a opção 3, que foi bem fácil de adicionar. basicamente você adiciona uma conta nomeada com valor como ledger://<address> veja por exemplo aqui: https://github.com/wighawag/template-ethereum-contracts/blob/d7eee3fc00b7e6a347a5ef2cd7718998254f2401/hardhat.config.ts#L15

hardhat-deploy converter para o endereço para que você ainda possa se referir a essa conta nomeada como um endereço, mas nos bastidores ele associa essa conta a um LedgerSigner. Eu também adicionei um registro quando uma carteira de hardware é detectada /.

Até que um plugin para hardhat possa lidar com isso em um nível baixo, isso deve ser bom o suficiente para a maioria dos casos de uso. Diz-me o que pensas

Isto é fantástico. Testando agora!

Parecia funcionar para uma transação, mas depois ocorreu algum tipo de falha. Parece que o pacote do livro razão do ethers está um pouco quebrado.

@wighawag ótimo ver o suporte do razão em breve. Só quero informar que fiz algumas correções para o meu projeto e que parece funcionar para minhas várias implantações. Aqui está o 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 eu posso enviar PR se você puder me apontar na direção certa para fazer a correção da maneira certa, minha correção não é algo que irá no PR; P

Obrigado @rokso vou dar uma olhada.
Observe, porém, que a última versão do pacote ethers.js hardhware-wallet pode corrigir o problema de qualquer maneira.

@wighawag Não tenho certeza de como ethers.js vai consertar isso, já que teremos que chamar close explicitamente. ethers.js pode ajudar expondo o método close

@rokso olhando para o diff, você fecha após cada implantação.
ethers.js poderia fazer o mesmo no nível tx

@wighawag sim, isso funciona, mas o usuário terá que abrir uma nova conexão para cada transação. Esta solução funcionará para o nosso caso, pois estamos abrindo uma nova conexão.

Acho que a solução inicial proposta por @smartcontracts é a mais elegante:

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

Existe um problema aberto no capacete de segurança? Eu ficaria feliz em dar uma olhada na implementação deste

Ei, pessoal, só queria verificar o status disso. Isso foi resolvido? Estou encontrando este erro localmente: /bindings.js:126 err = new Error( ^ Error: Could not locate the bindings file. Tried: ao tentar uma configuração que usa ' razão: // 0x00000000000000addr00000 ' dentro de namedAccounts da configuração.

Não acho que o pacote ethers hardware-wallet tenha resolvido seus problemas ainda: https://github.com/ethers-io/ethers.js/issues/1440#issuecomment -816554584