Ir para o conteúdo
Financial Context Wiki

Caminhos de derivação de carteiras: padrões, descoberta e recuperação

Aprenda como os caminhos de derivação de carteiras selecionam chaves filhas determinísticas, como os níveis hardened e as convenções de contas diferem e como verificar caminhos durante a recuperação.

Atualizado

Somente para fins educacionais; não constitui recomendação de investimento. Investimentos podem resultar em perdas.

Resposta direta

Um caminho de derivação de carteira é uma sequência ordenada de índices filhos que indica a um algoritmo determinístico qual nó selecionar em uma árvore de chaves. Na notação BIP-32 comum, m/84'/0'/0'/0/7 começa no nó privado mestre m e percorre cinco nós filhos. O apóstrofo marca uma derivação filha hardened. O caminho é um metadado de roteamento: não é chave privada, não criptografa a seed, não identifica sozinho um saldo em blockchain e nada recupera sem o material raiz e o algoritmo corretos.

Para carteiras do estilo BIP-44, o modelo é m / purpose' / coin_type' / account' / change / address_index. Os níveis têm significados acordados, não rótulos arbitrários. purpose seleciona uma convenção de carteira, coin_type separa namespaces de ativos registrados, account separa contas lógicas, change normalmente distingue endereços de recebimento externos (0) de endereços de troco internos (1), e address_index seleciona uma folha. BIP-44 usa derivação hardened nos três primeiros níveis e non-hardened nos dois últimos, permitindo que uma chave pública estendida de conta derive endereços de recebimento e de troco sem possuir chaves privadas.

O mesmo mnemônico pode levar a muitos conjuntos de endereços válidos, mas não relacionados. Para Bitcoin, caminhos comuns de chave única incluem m/44'/0'/account'/change/index para P2PKH, m/49'/0'/account'/change/index para P2WPKH aninhado em P2SH, m/84'/0'/account'/change/index para P2WPKH SegWit nativo e m/86'/0'/account'/change/index para Taproot P2TR de chave única. Uma carteira também deve conhecer a saída ou construção do script; um caminho sozinho não é uma política de carteira Bitcoin completa.

Outros ecossistemas reutilizam partes desta notação sem garantir semântica idêntica. O Ether está registrado como tipo de moeda BIP-44 60, e m/44'/60'/0'/0/index é uma convenção comum de conta de propriedade externa, mas implementações de carteiras têm usado múltiplos layouts de conta. A mesma chave EVM pode gerar o mesmo endereço de conta em várias redes EVM, embora saldos e históricos de transações sejam específicos de cada cadeia. Chaves BLS de validadores Ethereum usam ERC-2333 e ERC-2334 em vez de BIP-32; o caminho m/12381/3600/account/use não possui apóstrofes nem é interoperável com uma árvore BIP-32. Portanto, a recuperação requer implementação, curva, seed ou passphrase, convenção de caminho, rede e construção de endereço exatas, não apenas uma string plausível.

Como identificar e verificar um caminho de derivação

1. Determinar o material raiz e o algoritmo de derivação

Faça o inventário do formato mnemônico, lista de palavras, senha opcional, semente bruta ou chave estendida, e a implementação de software ou hardware que criou a carteira. BIP-39 converte 128 em 256 bits de entropia em um mnemônico e deriva uma semente 512-bit a partir desse mnemônico mais a senha exata; cada senha produz uma semente sintaticamente válida, mas diferente. BIP-32 então deriva chaves estendidas secp256k1 a partir de uma semente. Outras famílias de carteiras podem usar diferentes esquemas mnemônicos, curvas, funções de derivação de chave ou regras de chave mestre, então palavras correspondentes não provam uma raiz correspondente.

2. Identificar o padrão, a rede e a função da chave

Determine se o alvo é uma chave de pagamento Bitcoin, uma conta de propriedade externa EVM, uma chave de validador, um assinante multisig, um administrador de contrato ou outra autoridade. Registre a cadeia e a rede, o padrão e versão aplicáveis, a curva da chave, o tipo de saída ou endereço e o aplicativo da carteira. Um registro de tipo de moeda SLIP-0044 aloca um namespace; isso não prova que toda carteira para esse ativo siga BIP-44, apoie um projeto ou impeça outra cadeia de derivar a mesma chave em outro lugar.

3. Interpretar exatamente cada componente do caminho

Trate / como um limite pai-filho e preserve todos os índices, profundidade e marcadores de endurecimento. Sob BIP-32, filhos normais usam os índices 0 a 2^31 - 1; filhos endurecidos usam 2^31 a 2^32 - 1, comumente escritos com ', h ou H. Assim, 7' codifica o número do filho 2^31 + 7, não o filho comum 7. Confirme como uma interface de importação representa a raiz, se ela aceita um caminho completo ou um sufixo relativo, e se uma chave extendida exportada já se encontra abaixo de parte desse caminho.

4. Vincular o caminho à semântica do endereço ou da saída

Para carteiras da família BIP-44 Bitcoin, confirme os purpose, coin_type, account, change e address_index, e depois confirme independentemente o tipo de script e a rede pretendidos. BIP-49, BIP-84 e BIP-86 usam deliberadamente valores de propósito diferentes para que tipos de saída incompatíveis não apareçam silenciosamente em uma conta. Para carteiras multisig ou de descritor, preserve cada origem de chave, impressão digital do mestre, sufixo de derivação, limiar, ordem das chaves, construção do script e soma de verificação; um caminho não pode reconstruir a política completa.

5. Reproduzir a descoberta de contas e endereços

Não infira perda a partir de uma conta padrão vazia. A verificação de descoberta BIP-44 verifica as contas em ordem e varre a cadeia externa, usando um limite de lacuna de endereços de 20 endereços consecutivamente não usados. Carteiras que criaram endereços além dessa lacuna, usaram ramos internos de forma incomum, pularam contas ou aplicaram uma configuração proprietária podem não ser encontradas por uma verificação padrão. Pesquise apenas com dados confiáveis de observação ou derivação offline, defina limites explícitos, documente cada ramo pesquisado e evite enviar um mnemônico ou chave privada estendida para um site.

6. Verificar a identidade da carteira antes de confiar no saldo

Compare a impressão digital mestre, a chave pública estendida em nível de conta quando apropriado, o caminho de origem completo e vários endereços de recebimento e de troca previamente registrados. Para Bitcoin, derive os scripts de saída esperados ou o descritor e consulte a rede correta para o histórico de transações, incluindo saídas gastas. Para cadeias baseadas em conta, verifique o chainId exato, endereço, contratos de token e atividade histórica. Um saldo vazio é uma evidência fraca: o endereço pode estar errado, a rede ou índice podem diferir, ou os ativos já podem ter sido movidos.

7. Recuperar ou migrar por um fluxo controlado

Use software verificado e compatível em um ambiente confiável; prefira importar um descritor apenas de observação ou chave pública da conta para descoberta antes de expor material de assinatura. Teste a assinatura e recuperação com uma conta isolada ou uma transação pequena, depois reconcilie os endereços derivados, histórico on-chain, propriedade das saídas, taxas e estado final. Se segredos foram inseridos em uma ferramenta de recuperação não confiável, trate-os como comprometidos e migre todos os ativos, funções de contrato, aprovações, deveres de validador e autoridades de recuperação para uma nova raiz, em vez de continuar usando a carteira recuperada.

Exemplos calculados

Interpretação de um caminho Bitcoin com derivação hardened

Considere m/84'/0'/2'/1/17. Seus campos são a finalidade SegWit nativa 84', o tipo de moeda Bitcoin 0', a conta 2', o ramo interno ou de troco 1 e o índice de endereço 17. Como índices hardened BIP-32 somam 2^31 = 2,147,483,648, os números de filho serializados são 84' = 2,147,483,732, 0' = 2,147,483,648 e 2' = 2,147,483,650. Os dois últimos continuam sendo os índices normais 1 e 17; omitir um apóstrofo seleciona outra subárvore, não uma grafia equivalente.

Uma lacuna de descoberta que oculta um endereço usado

Suponha que o ramo externo tenha usado endereços nos índices 0 e 5, e depois a carteira escaneie de 6 a 25 e encontre 20 endereços consecutivos sem uso. Pela regra de lacuna BIP-44, a descoberta para em 25; assim, o endereço usado em 26 fica além da condição de parada e é omitido. Ampliar a varredura até um limite explícito e documentado pode encontrá-lo, mas a causa é a carteira de origem ter criado um endereço além da lacuna padrão sem atividade intermediária.

Cálculo de uma busca de recuperação limitada

Um registro de recuperação não informa qual das 4 famílias de finalidade Bitcoin (44', 49', 84' e 86') foi usada, nem qual das 3 contas, 2 ramificações e primeiros 20 índices. A busca inicial tem 4 × 3 × 2 × 20 = 480 folhas candidatas. Encontrar um endereço conhecido identifica um caminho candidato, não necessariamente a carteira inteira: ainda é preciso verificar troco, índices posteriores, outras contas, descritor e histórico. Explicitar as dimensões torna a recuperação reproduzível e evita tentativas sem limite.

Por que uma xpub de conta não é um dado público comum

Para uma chave filha BIP-32 não hardened, os escalares privados obedecem a child = parent + tweak (mod n). Em um exemplo simplificado módulo 101, se os dados de derivação expostos pela chave pública estendida da conta fixam tweak = 37 e o escalar privado filho 12 vaza, então parent = 12 - 37 mod 101 = 76. O BIP-32 real usa a ordem do grupo secp256k1 e valores derivados por HMAC, mas a consequência algébrica é igual: uma xpub pai junto de uma chave privada descendente não hardened correspondente pode revelar a chave privada estendida pai e sua subárvore. Limites de conta hardened contêm essa falha.

Riscos e falhas de revisão

  • Mnemônico ou frase secreta incorretos: uma única palavra, sua ordem, a normalização Unicode ou uma frase secreta diferente gera outra raiz que pode parecer válida.
  • Esquema de derivação incorreto: aplicar BIP-32 a uma carteira que usou outro esquema mnemônico, curva, KDF ou algoritmo de chave mestra deriva chaves sem relação.
  • Rede ou tipo de moeda incorretos: uma raiz correta em outro namespace pode gerar endereços plausíveis enquanto a blockchain pretendida permanece sem busca.
  • Finalidade ou script incorretos: confundir 44', 49', 84' ou 86' pode omitir a classe de saída Bitcoin que realmente contém fundos.
  • Marcador hardened ausente: 7, 7', 7h e 7H podem ser interpretados de outra forma ou rejeitados; chaves filhas hardened e normais não são intercambiáveis.
  • Índice de conta incorreto: verificar apenas a conta 0' pode omitir fundos ou poderes de contas lógicas posteriores.
  • Confusão entre ramo externo e de troco: escanear apenas o ramo 0 pode omitir saídas de troco no ramo 1 ou uma estrutura própria da carteira.
  • Índice de endereço incorreto: reconhecer o primeiro endereço não prova que índices posteriores, pulados ou endereços importados foram cobertos.
  • Falha pela lacuna de endereços: 20 endereços externos consecutivos sem uso podem interromper a varredura BIP-44 antes de um uso posterior fora do padrão.
  • Falha por conta pulada: a descoberta sequencial pode parar em uma conta sem uso e não alcançar outra criada depois.
  • Política Bitcoin incompleta: sem descritor, scripts, limite, ordem das chaves, impressões digitais ou checksum, um caminho pode não reconstruir as saídas com fundos.
  • Convenção própria da carteira: um aplicativo pode usar estruturas legadas, proprietárias ou de migração que uma ferramenta genérica não enumera.
  • Vazamento de privacidade da chave pública estendida: uma xpub pode revelar grupos de endereços, histórico, saldos e futuros descendentes não hardened.
  • Exposição excessiva da chave privada estendida: importar uma xprv pode expor toda uma subárvore, não apenas a folha necessária para uma operação.
  • Comprometimento da chave pai BIP-32: uma xpub pai junto com uma chave privada filha não hardened correspondente pode revelar a chave privada estendida pai e sua subárvore.
  • Falsa confiança no formato do endereço: um endereço sintaticamente válido não comprova a seed, o caminho, a rede, o script nem a titularidade pretendidos.
  • Confusão entre blockchains com o mesmo endereço: uma chave EVM pode gerar o mesmo endereço em várias redes, embora saldos, nonce, tokens e riscos sejam distintos.
  • Software de recuperação malicioso: site, extensão, ferramenta de compartilhamento de tela, monitor da área de transferência, keylogger ou dispositivo falso pode capturar o segredo raiz.
  • Confusão entre importar e sweep: importar mantém a autoridade antiga ativa; fazer sweep ou migrar cria uma transação e exige revisar taxa e destino.
  • Recuperação incompleta: encontrar um saldo sem verificar assinaturas, troco, contratos de tokens, funções, aprovações, chaves de validadores e backups pode deixar ativos ocultos ou expostos.

Equívocos comuns

O caminho de derivação é uma senha ou segredo?

Não. Um caminho normalmente descreve a estrutura pública e deve ser preservado como metadados de recuperação. Ele não substitui o mnemônico, a senha, a seed, a chave privada ou a política da carteira. Publicar um caminho pode revelar informações organizacionais, mas a posse apenas do caminho não confere autoridade de assinatura.

O mesmo mnemônico sempre restaura automaticamente a mesma carteira?

Não. O resultado também depende do esquema mnemônico, da frase secreta exata, do processamento da semente, do algoritmo de derivação, do caminho, da curva, da rede e da construção do endereço ou script. O software da carteira pode escolher padrões diferentes mesmo quando aceita as mesmas palavras.

O tipo de moeda impede o uso de uma chave em outra blockchain?

Não. O tipo de moeda é um namespace de derivação e uma convenção de compatibilidade, não uma permissão de protocolo. O software pode derivar ou reutilizar uma chave em outro lugar, e redes EVM comumente expõem o mesmo endereço de conta para a mesma chave privada.

Uma conta recuperada sem saldo prova que os ativos desapareceram?

Não. Isso prova apenas que os endereços e a rede consultados atualmente não mostram saldo detectado. Caminhos errados, contas, ramificações, tipos de script, limites de descoberta, indexação de tokens ou seleção de rede podem todos ocultar o histórico pretendido.

Uma ferramenta de recuperação pode testar com segurança todos os caminhos possíveis?

Não. O espaço de busca pode ser grande, as convenções de carteiras não são totalmente universais, e expor um segredo raiz a uma ferramenta não confiável é, por si só, um evento de perda. Use proveniência, impressões digitais e endereços registrados, descoberta offline limitada e software verificado para restringir a busca.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...