Opcode

O Bitcoin Script tem um vocabulário fixo de 256 valores de byte possíveis, divididos entre opcodes que empilham dados literais e opcodes que agem sobre os dados já empilhados. Um script legado pode executar no máximo 201 opcodes operativos e não pode ultrapassar 10.000 bytes. Para quem compra bitcoin, esse vocabulário pequeno é a razão pela qual uma carteira consegue informar a taxa antes de transmitir a transação, e pela qual o bitcoin não oferece superfície para bugs de contrato descontrolados.

Como funciona

Um nó validador lê um script byte a byte e procura cada byte em uma tabela fixa. Os valores de 0x01 a 0x4b não são instruções de forma alguma: cada um diz que os próximos N bytes são dados literais e pertencem à pilha, e por isso uma chave pública comprimida de 33 bytes aparece em um script como 0x21 seguido da própria chave. Outros três códigos de inserção de dados, OP_PUSHDATA1, OP_PUSHDATA2 e OP_PUSHDATA4, cobrem os itens mais longos, e os valores de 0x51 a 0x60 empilham os inteiros pequenos de 1 a 16 que aparecem nas contagens de quórum.

Tudo acima de 0x60 realiza operações em vez de transportar dados, e são esses os que o bitcoin conta. Um script anterior ao Taproot pode conter no máximo 201 deles, não pode ter nenhum elemento da pilha maior que 520 bytes, não pode manter mais de 1.000 itens em suas pilhas e não pode passar de 10.000 bytes no total. Os quatro números vêm do script.h no Bitcoin Core, e os quatro são regras de consenso, não preferências que o operador de um nó possa relaxar.

Quinze opcodes estão listados na tabela, mas estão mortos. OP_CAT, OP_MUL, OP_LSHIFT e outros doze foram desativados em 2010 depois de um bug que provocava travamentos, e um script que simplesmente contenha um deles falha, mesmo dentro de um ramo que nunca é executado. Nenhum foi reativado. Essa única decisão é a maior razão pela qual o scripting do bitcoin é mais estreito do que a palavra “programável” leva a esperar.

O Tapscript reescreveu a contabilidade dos gastos Taproot. O BIP-342, em vigor desde o bloco 709.632 em novembro de 2021, eliminou tanto o teto de 201 instruções quanto o limite de tamanho de 10.000 bytes, e os substituiu por um orçamento de assinaturas: a transação deve carregar 50 unidades de peso para cada assinatura que o script verificar. Também transformou um bloco de valores de byte indefinidos em códigos OP_SUCCESS, de modo que um script que contenha um deles é válido sem sequer ser executado. Esse é um espaço deixado de propósito para futuras atualizações.

Por que isso importa quando você compra bitcoin

Os opcodes decidem quanto custa o seu saque. Uma saída legada escreve quatro instruções operativas em torno de um hash de 20 bytes em 25 bytes; o equivalente SegWit nativo é um byte de versão e uma inserção de dados, 22 bytes; uma saída Taproot ocupa 34. Como o SegWit moveu o lado de desbloqueio para a testemunha a um quarto do peso, gastar uma saída bech32 leva aproximadamente 68 bytes virtuais contra aproximadamente 148 para a versão legada do mesmo pagamento. Escolher bech32 ou bech32m na hora do saque, sempre que a corretora oferecer, é quase a decisão mais barata deste glossário.

Os opcodes também decidem o que o seu dispositivo de assinatura consegue de fato processar. Uma carteira de hardware que só reconhece os modelos padrão de chave única não pode coassinar um cofre com bloqueio temporal nem uma política incomum, então, se o planejamento de herança ou a multiassinatura estiver em algum lugar dos seus planos, verifique o suporte a scripts nas análises antes de comprar o dispositivo, e não depois que os bitcoins já estiverem nele.

Essa estreiteza é uma propriedade de segurança, não uma deficiência. Não há laços, nem forma de ler outra transação, nem estado que persista entre gastos, então o modo de falha que já drenou bilhões de dólares de cadeias programáveis, um contrato se comportando corretamente diante de entradas que seu autor nunca considerou, não tem onde ocorrer. As perdas de bitcoin vêm de corretoras, phishing e backups perdidos, não de falhas do motor de scripts.

Exemplo prático: o dia em que o OP_NOP2 ganhou dentes

O OP_NOP2 era o byte 0xb1 e não fazia absolutamente nada, um dos dez no-ops numerados deixados na tabela para uso posterior. O BIP-65 lhe deu uma função: confirmar que o locktime da transação já passou e fazer o script falhar se não tiver passado. A regra passou a ser aplicada no bloco 388.381, em 14 de dezembro de 2015, e desde então o opcode é chamado de OP_CHECKLOCKTIMEVERIFY.

O truque é que o software antigo ainda via um byte que não faz nada, então continuava aceitando as novas transações como válidas. Somente os nós atualizados aplicavam o bloqueio temporal. Essa assimetria é o que torna um soft fork suave, e pela mesma rota o OP_NOP3 se tornou OP_CHECKSEQUENCEVERIFY no bloco 419.328, em julho de 2016. Restam oito posições reservadas de no-op, que são a maior parte do espaço de atualização que sobra ao bitcoin sob as regras anteriores ao Taproot e boa parte da razão pela qual tanta atenção de design se deslocou para os valores OP_SUCCESS que o Tapscript criou.

Opcode vs Bitcoin Script

O Bitcoin Script é a linguagem e um opcode é uma palavra do seu vocabulário. A distinção importa quando você lê afirmações sobre o que o bitcoin pode ou não pode fazer, porque quase toda proposta séria da última década foi uma proposta de definir um novo opcode, não de mudar a linguagem ao redor dele. OP_CHECKTEMPLATEVERIFY, OP_CAT e OP_CHECKSIGADD são cada um um único byte com uma única função, e os debates públicos sobre covenants ou cofres são debates sobre se um byte específico deve poder significar algo. A pilha, os limites e a ausência de laços permanecem exatamente como estão quando um novo opcode chega.