Ramo de Merkle do Taproot

Cada hash no ramo é um irmão da taptree, em ordem da sua folha para cima até a raiz. O BIP-341 limita o ramo a 128 hashes, 4.096 bytes, e a árvore ordenada faz com que o ramo não carregue nenhum bit de direção esquerda ou direita. O comprimento do seu ramo é público, então uma folha mais profunda revela a profundidade mínima da sua árvore e dá pistas sobre qual carteira construiu a saída.

Como funciona

Um ramo de Merkle do Taproot viaja dentro do bloco de controle, o último item da pilha de testemunhas de um gasto por caminho de script depois que qualquer anexo foi removido.

O bloco de controle tem uma forma fixa. O byte zero carrega a versão da folha mais a paridade da coordenada Y da chave de saída. Os bytes 1 a 32 contêm a chave pública interna. Tudo depois disso é o ramo: m hashes consecutivos de 32 bytes, então o bloco de controle mede 33 + 32m bytes, e m deve ser um número inteiro de 0 a 128. Qualquer outro comprimento faz o gasto falhar antes que um único opcode seja executado.

A verificação começa por baixo. Um nó calcula o hash do script revelado sob a etiqueta TapLeaf, depois incorpora cada hash do ramo, um por vez, sob a etiqueta TapBranch, comparando os dois valores de 32 bytes em ordem lexicográfica a cada passo e colocando o menor primeiro na entrada do hash. O que resulta é a raiz da taptree, que recebe hash junto com a chave interna sob a etiqueta TapTweak, é somada ao ponto interno e é comparada com os 32 bytes na saída que está sendo gasta.

Essa comparação é todo o truque. Como o BIP-341 ordena os dois filhos antes de calcular o hash deles, um ramo nunca diz de que lado um irmão estava: o verificador deduz isso. A justificativa é direta sobre o motivo, dizendo que o projeto não se importa com a posição de scripts específicos na árvore, apenas que eles estejam de fato comprometidos.

O teto de 128 é um limite de segurança, e não um limite arbitrário. A profundidade em uma árvore empacotada de forma ótima fica perto do logaritmo na base dois de um dividido pela probabilidade de uma folha, então a profundidade 129 significaria um script com chance de uso abaixo de 1 em 2^128, que, segundo o BIP-341, provavelmente pode ser excluído. No outro extremo, uma taptree de uma única folha tem m igual a 0, um ramo vazio e um hash de folha que já é a raiz.

Onde você vê isso

Ramos de Merkle do Taproot aparecem em qualquer transação que gaste uma saída bc1p revelando um script em vez de assinar com a chave.

O BIP-341 desenvolve um exemplo em uma árvore de cinco folhas. A, B, C e E são hashes TapLeaf e AB é um hash TapBranch sobre os dois primeiros. Para gastar usando o script D, o bloco de controle carrega C, depois E, depois AB: três hashes, 96 bytes de ramo, um bloco de controle de 129 bytes. E recebe hash antes de CD quando esses dois se combinam, porque E é o menor na ordenação.

O custo de privacidade é o que se deve planejar. A seção de segurança do BIP-341 diz que a profundidade de um script revela a profundidade mínima da árvore, o que sugere o software de carteira que construiu a saída e ajuda a análise de cadeia a agrupar endereços, e recomenda se afastar da árvore que as probabilidades das folhas dariam. A reutilização de folhas é a outra armadilha: gastar uma saída diferente pode republicar os mesmos hashes do ramo, então dois gastos que compartilham um irmão de 32 bytes parecem relacionados.

Ramo de Merkle do Taproot vs bloco de Merkle

Um ramo de Merkle do Taproot prova que um script pertence a um endereço; um bloco de Merkle prova que uma transação pertence a um bloco. O ramo da taptree é crítico para o consenso, recalculado por todo nó completo que valida o gasto, e não tem posição porque a ordenação eliminou a necessidade de dizer esquerda ou direita. Uma prova sobre a árvore de transações de um bloco não pode tomar emprestado esse truque, já que a ordem das transações sob a raiz de Merkle de um bloco é fixa e significativa, então ela tem que carregar o percurso além dos hashes.