Ir para o conteúdo
Financial Context Wiki

Carteira hierárquica determinística (HD)

Entenda como uma carteira HD deriva uma árvore de chaves a partir de uma única semente, como as derivações reforçada e normal diferem e o que um backup completo e testável precisa preservar.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

Uma carteira hierárquica determinística (HD) deriva uma árvore reproduzível de pares de chaves criptográficas a partir de uma única semente raiz. A BIP-32 define o mecanismo da árvore de chaves: cada nó é uma chave estendida que contém uma chave e um código de cadeia de 32-byte, e cada chave filha é selecionada por um índice. O mesmo material raiz, as mesmas regras de derivação e o mesmo caminho reproduzem as mesmas chaves filhas.

O caráter “determinístico” torna o backup prático, mas não torna todas as carteiras intercambiáveis. Uma frase mnemônica é uma forma possível de codificar entropia e produzir uma semente, enquanto um caminho de derivação seleciona um nó e uma regra de endereço ou script transforma sua chave pública em algo reconhecido por uma blockchain. Restaurar apenas as palavras pode mostrar uma carteira vazia se a frase secreta, o caminho, a rede, o tipo de script ou as regras de descoberta de contas forem diferentes.

“Hierárquica” significa que a autoridade pode ser dividida em subárvores. Uma chave pública estendida no nível da conta pode permitir que um serviço somente de consulta derive chaves públicas descendentes normais sem possuir as chaves de gasto. Uma chave privada estendida pode derivar a subárvore privada correspondente e deve ser protegida como uma coleção de chaves privadas, não como um único endereço.

Uma carteira HD é um projeto de gerenciamento de chaves, não um objeto de carteira on-chain. A blockchain não armazena a frase mnemônica, a semente, o caminho, os rótulos nem o backup. Esses são registros off-chain mantidos pelo software da carteira e pelo usuário.

Como funciona

1. Da entropia à raiz

A BIP-39 é comumente usada antes da BIP-32, mas os padrões são distintos. A BIP-39 codifica 128-256 bits de entropia mais uma soma de verificação como 12-24 words e, em seguida, aplica PBKDF2-HMAC-SHA512 com 2048 iterações à frase mnemônica normalizada e à frase secreta opcional para produzir uma semente de 512-bit. Cada frase secreta produz uma semente válida, porém diferente; assim, uma frase ausente ou digitada incorretamente não é detectada de forma confiável por uma mensagem de “senha inválida”.

A BIP-32 usa HMAC-SHA512 com a chave Bitcoin seed para transformar os bytes da semente em uma chave privada mestra e um código de cadeia mestre. Essa chave privada estendida raiz é a origem da árvore BIP-32. Nem toda carteira determinística usa BIP-39 ou BIP-32; portanto, a recuperação precisa identificar o esquema real, em vez de inferi-lo pela presença de palavras de recuperação.

2. Chaves estendidas e derivação de chaves filhas

Uma chave privada estendida BIP-32 combina uma chave privada com um código de cadeia; sua chave pública estendida neutralizada combina a chave pública correspondente com o mesmo código de cadeia. A derivação normal de uma chave filha usa a chave pública do nó pai, o código de cadeia e o índice da filha, de modo que uma chave pública estendida pode derivar chaves públicas filhas normais. Ela não pode derivar chaves privadas filhas.

As chaves filhas reforçadas usam índices de 2^31 a 2^32 - 1 e incorporam material da chave privada do nó pai. Elas não podem ser derivadas da chave pública estendida do pai. Os caminhos costumam marcá-las com um apóstrofo, como em m/84'/0'/0'. O reforço limita o dano de uma falha específica da BIP-32: uma chave pública estendida pai, somada a uma chave privada filha não reforçada correspondente, pode revelar a chave privada estendida pai.

3. Os caminhos dão significado à árvore

A BIP-44 define m / purpose' / coin_type' / account' / change / address_index. Os primeiros 3 níveis são reforçados; change e address_index são normais para que as chaves públicas da conta possam gerar endereços de recebimento e de troco. Por convenção, a ramificação 0 é externa e a ramificação 1 é de troco interno. A descoberta BIP-44 examina o histórico de transações e usa um limite de lacuna de 20 endereços externos consecutivos não utilizados.

O caminho é metadado, não segredo nem garantia universal. A BIP-84 atribui o propósito 84' às contas P2WPKH SegWit nativas, enquanto outros propósitos ou estruturas específicas de carteira produzem outras subárvores. O tipo de moeda é uma convenção de namespace, não uma regra imposta por uma blockchain.

4. As chaves não são a carteira inteira

Uma chave pública ainda precisa de regras de rede e de endereço ou script. No Bitcoin, a mesma chave pode participar de diferentes scripts de saída; uma carteira multiassinatura também precisa do limiar, das chaves dos cossignatários, da ordem das chaves e das origens de derivação. Os descritores de saída BIP-380 associam chaves e origens a expressões explícitas de script e podem incluir uma soma de verificação. Por isso, um backup composto apenas pela semente pode ser insuficiente para recriar o que a carteira original monitorava ou podia gastar.

Rótulos da carteira, contatos, observações de transações, chaves importadas, nomes de contas e certas configurações de recuperação de contratos ou contas inteligentes geralmente não são derivados de forma determinística. Eles exigem exportação ou documentação separada.

5. Backup e recuperação são processos testados

Registre a implementação da carteira, o formato da frase mnemônica ou da semente, se existe uma frase secreta, a impressão digital mestra, os caminhos relevantes, as redes, os índices de conta e os descritores de Bitcoin ou dados de política equivalentes. Mantenha os segredos raiz offline e separados dos metadados públicos de recuperação quando for viável. Um xpub não pode gastar por conta própria, mas pode expor saldos, relações entre endereços e futuros descendentes normais.

Teste a recuperação em um ambiente confiável antes de depender do backup. Primeiro compare endereços ou descritores conhecidos sem movimentar fundos; depois verifique as ramificações de recebimento e de troco, contas posteriores, histórico de transações e a assinatura por meio de uma pequena transação controlada. Nunca digite uma frase mnemônica, uma frase secreta ou um xprv em site ou chat de suporte não confiável.

Exemplo

Considere uma conta Bitcoin SegWit nativa em m/84'/0'/0'. O propósito 84' seleciona a convenção BIP-84, 0' seleciona o namespace do tipo de moeda Bitcoin e o último 0' seleciona a primeira conta. Um sistema somente de consulta pode receber a chave pública estendida da conta e derivar ramificações normais sem receber a chave privada da conta.

A primeira chave externa de recebimento fica em m/84'/0'/0'/0/0; a seguinte, em m/84'/0'/0'/0/1. A primeira chave de troco interno fica em m/84'/0'/0'/1/0. Todas descendem da mesma conta, mas a ramificação e o índice selecionam chaves diferentes. Reutilizar a semente com m/44'/0'/0'/0/0 seleciona outra subárvore e outra convenção de saída; um resultado vazio não prova que a semente esteja errada.

Para um registro completo de recuperação de Bitcoin, preserve o backup do segredo raiz separadamente do descritor ou dos metadados equivalentes que identificam a impressão digital, o caminho, a chave pública estendida, o tipo de script e a soma de verificação. Confira vários endereços usados anteriormente em ambas as ramificações. Encontrar somente o primeiro endereço de recebimento comprova uma folha correta, não que todas as contas, saídas de troco ou políticas da carteira tenham sido recuperadas.

Riscos

  • Concentração em uma única raiz: o comprometimento de uma semente raiz ou de uma chave privada estendida de nível suficientemente alto pode expor todos os descendentes em seu escopo.
  • Perda do backup: perder o único backup da semente, ou perder separadamente uma frase secreta BIP-39 não documentada, pode tornar irrecuperáveis todas as chaves derivadas.
  • Falsa confiança na frase secreta: uma frase secreta BIP-39 incorreta cria outra carteira válida, que pode parecer uma restauração bem-sucedida, porém vazia.
  • Incompatibilidade de caminho ou script: a semente correta com propósito, conta, ramificação, rede ou tipo de saída incorreto gera endereços válidos, mas sem relação.
  • Backup incompleto da política: apenas uma semente e um caminho podem não reconstruir condições de gasto multiassinatura, baseadas em descritor, de conta inteligente ou específicas da carteira.
  • Vazamento de privacidade pela chave pública estendida: um xpub pode revelar um agrupamento de endereços e permitir o acompanhamento contínuo de descendentes normais.
  • Comprometimento do pai na BIP-32: um xpub pai junto com uma chave privada filha não reforçada correspondente que tenha vazado pode revelar a subárvore privada do pai.
  • Ferramentas de recuperação não confiáveis: sites, extensões, dispositivos falsificados, ferramentas da área de transferência ou compartilhamento de tela podem capturar todo o segredo raiz.
  • Mídias não testadas: papel, metal, arquivos criptografados ou backups em hardware podem falhar por transcrição incorreta, corrosão, senhas esquecidas ou formatos incompatíveis.
  • Migração incompleta: mover as moedas visíveis e deixar tokens, saídas de troco, funções de contratos, aprovações ou contas posteriores sob a raiz antiga mantém a exposição.

Equívocos comuns

Uma frase de backup inclui todos os detalhes da carteira?

Não. Ela pode reproduzir o material da chave raiz, mas não necessariamente a frase secreta, a convenção de derivação, a rede, os scripts, a política multiassinatura, os rótulos, as chaves importadas ou o histórico de descoberta de contas. Preserve os metadados necessários à carteira real.

É seguro publicar um xpub porque ele não pode gastar?

Não. Normalmente ele não pode assinar, mas pode revelar endereços descendentes normais passados e futuros e seu histórico combinado. Na falha BIP-32 descrita acima, associá-lo a uma chave privada filha não reforçada correspondente também pode comprometer a subárvore pai.

Endereços novos criam backups independentes?

Não. Endereços novos reduzem a reutilização de endereços e melhoram a privacidade, mas os descendentes determinísticos continuam controlados pelo mesmo ancestral. O comprometimento da raiz afeta a subárvore mesmo quando cada pagamento usou um endereço novo.

Restaurar um endereço conhecido prova que a carteira está completa?

Não. Isso valida uma combinação de material raiz, caminho e construção do endereço. A recuperação ainda precisa abranger as ramificações de recebimento e de troco, todas as contas usadas, os scripts ou as políticas e as redes relevantes.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...