Este é o terceiro artigo em um série Mergulhar profundamente em propostas individuais de aliança que atingiram um ponto de maturidade que merecem um detalhamento aprofundado.
TXHASH e CHECKTXHASHVERIFY (TXHASH), apresentados por Steven Roose e Brandon Black com um número BIP atualmente não atribuído, é um pacto de “baseado em modelo” que pode ser visto conceitualmente como uma extensão ou uma versão mais avançada do CheckTemplatify (CTV).
Antes de entrar no âmago da questão de como o TXHASH funciona, vamos atualizar os dados em uma transação de bitcoin.
Em um nível alto, você tem as saídas, as entradas e a testemunha (ou script sig para transações não segidas na entrada).
Campos de transações globais:
- Versão
- Marcador, indicando segwit com um valor de sinalizador
- Bandeira, indicando segwit com um valor de bandeira
- Contagem de entrada
- Contagem de saída
- NlockTime, usado para cronogramas
Cada entrada contém:
- TXID da transação anterior
- VOUT (índice) da saída dessa transação sendo gasta
- Tamanho de scriptsig
- Scriptsig (se uma transação não segida)
- Número da sequência (usado para sinalização RBF e cronogramas relativos).
Cada saída contém:
- Quantidade de Satoshis atribuído à saída
- Scriptpubkeysize, o tamanho do script de travamento
- ScriptpubKey, o script de travamento real
Podemos ignorar o campo das testemunhas ao considerar o TXHASH ou o checktxhashVifify, pois nenhum dos código de operação restringe o campo da testemunha para reter certas propriedades.
Como funciona o txhash
Txhash (somente TAPScript) e ChecktxHashverify (script e TAPScript) têm comportamentos diferentes na pilha devido às diferenças entre o script herdado e o TAPScript. Para os propósitos deste artigo, essas diferenças não são materiais, por isso vamos simplesmente ignorá -las.
Se a CTV é um código de operação de aliança que restringe uma saída de bitcoin para ser gasta apenas de uma maneira singular e exatamente definida, o TXHASH é uma versão sobrecarregada da CTV que permite escolher exatamente quais peças de transação são restringidas e devem ser gastos na maneira exatamente predefinida, e que peças de uma transação podem ser o que alguém deseja em gastos.
Ele oferece o melhor dos dois mundos, exigindo que algo seja feito ao gastar uma moeda restrita da aliança, mas depois permitir que um usuário faça o que quiser com o restante dos fundos disponíveis para eles ou a transação que eles estão criando.
Isso é realizado usando o 'TXFieldSelector'.
A CTV simplesmente usa um único hash da transação predefinida para verificar no tempo de gasto. Com o TXHASH, você precisa de uma maneira de comunicar a que informação com que o hash está se comprometendo e com quais informações não são. Esse é o trabalho do TXFieldSelector.
O TXFieldSelector é essencialmente uma série de bytes (que podem ser variáveis em comprimento), com cada bit comunicando o que os campos em uma transação são cometidos pelo hash que será verificado. Isso permite selecionar campos específicos da transação, nlocktime, versão etc. Permite selecionar campos específicos das entradas e saídas, ou seja, incluir ou não o número da sequência ou o ID de saída anterior ou o anexo da Taproot (um campo de dados específico para os scripts da Taproot). As saídas, se devem se comprometer com o scriptpubkey, os valores da quantidade, ambos ou nenhum. Você também pode decidir exatamente a quais saídas e inserções essas restrições se aplicam.
Existe alguma complexidade e flexibilidade na maneira como o TXFieldSelector é montado, e você pode ler todos os detalhes mais delicados aqui no BIP proposto se estiver interessado nesses, mas o ponto principal de tirar é que permite que você escolha exatamente Quais partes da transação são restritas pela aliança quando alguém passa a saída do sobrecarga e quais peças não são, em um grau muito granular.
Para que é útil o TXHASH
Em primeiro lugar, o TXHASH permite que você faça tudo o que puder com o CTV. Portanto, todo o valor fornecido pela CTV para otimizar os custos de coordenação de qualquer coisa atualmente possível com transações pré-assinadas também é fornecido pelo TXHASH. Mas sobrecarrega essa capacidade massivamente. Em vez de ter que se comprometer com a totalidade de uma transação, você pode se comprometer apenas com as partes de que se importa.
Isso tem dois grandes benefícios em teoria logo de cara. Primeiro de tudo, no gerenciamento de taxas da banda para a camada dois se torna mais fácil de lidar. Atualmente, é necessário o uso de saídas de âncora para dar taxa de transações de liquidação da camada de bump com países para crianças, onde uma transação gastando uma saída de um não confirmado pode adicionar às taxas líquidas para ambos. O TXHASH permite que você se comprometa apenas com as saídas de suas contrapartes em uma transação multipartidária e deixe a sua livre para fazer o que quiser (advertem aqui que outras coisas devem ser feitas para tornar isso seguro para que um terceiro não possa queimar todos os seus fundos em taxas), incluindo diminuir um pouco para RBF a transação.
Segundo, a porta agora está aberta para protocolos multipartidários para permitir garantias granulares sobre o que as transações fora da cadeia estão se comprometendo. Agora, alguns usuários podem receber uma garantia sobre como suas moedas serão gastas, mas não precisam se preocupar com o que algum outro grupo de usuários faz com o deles. Posso ter certeza de que um TXFieldSelector garante que minhas moedas sejam tratadas corretamente, e não preciso me preocupar com onde as moedas de mais ninguém vão.
Em combinação com o CheckSigFromStack (CSFS), o TXHASH pode facilitar um sistema SIGHASH completamente generalizado. A bandeira do Sighash faz parte de uma assinatura que comunica quais partes da transação verificar a assinatura. Eles estão atualmente:
- Sighash_all – assina todas as entradas e saídas
- Sighash_none – assina todas as entradas e sem saídas
- Sighash_single – assina todas as entradas e a saída com o mesmo índice que esta entrada
Nenhum desses sinalizadores de suspanás permite a adição de novas entradas a uma transação sem invalidá -las, mas cada uma possui uma versão de AnyoneCanpay que assina apenas sua própria entrada e saídas apropriadas, permitindo que qualquer outra pessoa adicione novas entradas e novas saídas para a versão de AnyoneCanpay de Sighash_None e Sighash_Single.
Ao poder “desvendar” novos TXFieldSelectors usando o CSFs, os usuários podem imitar um sistema SIGHASH que lhes permita escolher exatamente quais peças individuais de uma transação a assinatura se compromete ou não.
O TXHASH também permite aplicar a igualdade entre o valor de entradas e saídas usando o TXFieldSelectores individuais que se comprometerem apenas a um único campo de valor de uma entrada ou saída que você deseja inspecionar e, em seguida, garantir que seus hashes sejam os mesmos na pilha.
Pensamentos finais
O TXHASH é uma sobrecarga potencial de CTV, permitindo um grau incrivelmente granular de introspecção da transação de gastos que pode ser incrivelmente poderosa, especialmente em combinação com algo como o CSFS.
No entanto, esse poder é expressivo o suficiente para abrir a porta para um espaço de design incrivelmente grande. Um que poderia ter um efeito material nos incentivos gerais do Bitcoin. Coisas como garantir a igualdade de quantidade entre saídas ou entradas estão chegando muito perto do território do que é necessário para a troca automatizada sem confiança na cadeia. Essa é uma fonte séria de valor extraível de mineiro (MEV), que tem sido um problema muito sério de incentivo e centralização para outras blockchains lidar.
O TXHASH não deve ser descartado absolutamente, pois fornece primitivas incrivelmente poderosas para os desenvolvedores de protocolo aproveitar, mas as possíveis implicações de segunda ordem do que as pessoas construirão com ele devem ser pesadas contra os positivos.
Fonte: bitcoinmagazine.com
