Bitcoin foi inicialmente projetado com uma linguagem de script totalmente detalhada, destinada a abranger e apoiar qualquer caso de uso seguro em potencial que os usuários possam criar no futuro. Como o próprio Satoshi disse antes de desaparecer:

"A natureza do Bitcoin é tal que, uma vez que a versão 0.1 foi lançada, o design principal foi definido em pedra para o resto de sua vida. Por causa disso, eu queria projetá-lo para apoiar todos os tipos de transações possíveis que eu pudesse imaginar. O problema era que cada coisa exigia códigos apoiar especiais e campos de dados, quer fosse usada ou não, e cobria apenas um caso especial de cada vez. Teria sido uma explosão de casos especiais. A solução foi o script, que generaliza o problema para que as partes transacionantes possam descrever sua transação como um predicado que a rede de nós avalia." - Satoshi, 17 de junho de 2010.

Toda a intenção era dar aos usuários uma linguagem geral o suficiente para que eles pudessem compor seus próprios tipos de transações como achassem melhor. Ou seja, dar aos usuários espaço para projetar e experimentar como eles programaram seu próprio dinheiro.

Antes de desaparecer, Satoshi arrancou 15 desses opcodes, desabilitando-os totalmente e adicionando um limite rígido ao tamanho de um dado que poderia ser manipulado na pilha do mecanismo de script (520 bytes). Isso foi feito porque ele francamente errou e deixou em aberto um grande número de maneiras pelas quais scripts complicados poderiam ser usados para atacar a negação de serviço em toda a rede, criando enormes e caros para validar transações que travariam nós.

Esses opcodes não foram removidos porque Satoshi achavam que a funcionalidade era perigosa, ou as pessoas não deveriam ser capazes de construir as coisas que podiam com eles, mas apenas (pelo menos aparentemente) por causa do risco para a rede em geral de serem usados sem restrições de recursos para limitar o custo de validação do pior caso que poderiam impor à rede.

Cada atualização para Bitcoin desde então foi finalmente simplificando a funcionalidade deixada, corrigindo outras falhas menos graves Satoshi nos deixaram, e estendendo a funcionalidade daquele subconjunto de script que nos restou.

A GRANDE RESTAURAÇÃO DE SCRIPT

No Bitcoin++ em Austin, no início de maio, o desenvolvedor do Core Lightning, Rusty Russell, fez uma proposta bastante radical durante a primeira apresentação da conferência. Ele essencialmente lançou a ideia de voltar atrás na maioria dos opcodes que Satoshi desativados em 2010 antes de desaparecer.

Nos últimos anos, desde que Taproot ativado em 2021, o espaço de desenvolvimento tem sido francamente sem rumo. Todos sabemos que Bitcoin não é escalável o suficiente para realmente atender a qualquer parcela considerável da população mundial de forma auto-soberana, e provavelmente nem mesmo de uma forma de confiança minimizada ou custodiada que possa ir além de grandes custodiantes e prestadores de serviços incapazes de realmente escapar do braço longo do governo.

Quem entende de Bitcoin em nível tecnológico entende isso, não é uma questão de debate. O que é uma questão de debate, e muito controversa, é como resolver esta lacuna. Desde Taproot, todos têm apresentado propostas muito restritas destinadas a abordar apenas casos de uso muito específicos que poderiam ser habilitados.

ANYPREVOUT (APO), uma proposta para permitir que as assinaturas sejam reutilizáveis em diferentes transações, longo como o script e a quantidade da entrada era a mesma, foi adaptada especificamente para otimizar o Lightning e versões multipartidárias dele. CHECKTEMPLATEVERIFY (CTV), uma proposta para impor moedas que só podem ser gastas por uma transação que corresponda exatamente a uma transação predefinida, foi projetada especificamente para estender a funcionalidade de cadeias de transações pré-assinadas, tornando-as completamente sem confiança. OP_VAULT foi projetado especificamente para permitir um "período de tempo limite" para esquemas de armazenamento frio, de modo que um usuário pudesse "cancelar" uma retirada do armazenamento frio, enviando-o para uma configuração multisig ainda mais fria se suas chaves fossem comprometidas.

Há um monte de outras propostas, mas acho que você entendeu o ponto. Em vez de tentar abordar de forma abrangente a expressividade e a programabilidade necessárias para dimensionar Bitcoin de forma fundamental, cada uma das propostas nos últimos anos foi projetada para dar um pequeno aumento na escalabilidade ou melhorar uma única funcionalidade estreita considerada desejável. Acho que essa é a fonte do porquê de nenhuma dessas conversas ir a lugar nenhum. Ninguém está satisfeito com qualquer outra proposta porque ela não atende ao caso de uso que eles querem ver construído.

Nada é suficientemente abrangente para que alguém pense, fora do autor da proposta, que é o próximo passo sensato.

Essa é a lógica por trás da Grande Restauração de Roteiro. Ao empurrar e analisar uma restauração abrangente do script como Satoshi projetou inicialmente, podemos realmente tentar explorar todo o espaço de qual funcionalidade precisamos, em vez de brigar e brigar internamente sobre qual pequena extensão de funcionalidade é boa o suficiente por enquanto.

OS OPCODES

• OP_CAT: Pega dois dados na pilha e os adiciona para formar um.
• OP_SUBSTR: pega um argumento de comprimento em bytes e pega um pedaço de dados da pilha removendo muitos bytes dele e colocando-o de volta.
• OP_LEFT & OP_RIGHT: usa um argumento de comprimento e remove muitos bytes de um lado ou de outro de um dado na pilha.
• OP_INVERT & OP_AND & OP_OR & OP_XOR & OP_UPSHIFT & OP_DOWNSHIFT: Pega um elemento de dados da pilha e executa a operação correspondente de bit nele.
• OP_2MUL & OP_2DIV & OP_MUL & OP_DIV & OP_MOD: Operadores matemáticos para operações de multiplicação, divisão e módulo (retornando o restante da divisão).

Os acima são os opcodes destinados a serem restaurados. Além destes, Rusty propõe mais três para simplificar a composição de diferentes opcodes.

• OP_CTV (OU TXHASH/equivalente): Algo para permitir a aplicação granular exigindo que certas partes de uma transação sejam exatamente como definidas com antecedência.
• CSFS: Permite verificar assinaturas contra dados arbitrários, em vez de apenas a transação inteira. Isso permite que você exija que partes de um script, ou dados que eles usam, sejam assinados ordem executados.
• OP_TWEAKVERIFY: verifica operações baseadas em Schnorr envolvendo chaves públicas, como adicionar ou subtrair chaves públicas individuais de chaves agregadas. Isso pode ser usado para garantir que, no caso de uma parte deixar uma UTXO compartilhada unilateralmente, os fundos de todos os outros sejam enviados para uma chave pública agregada que não exija que a parte que saiu assine ordem gaste cooperativamente.

POR QUE QUEREMOS FAZER ISSO

Layer 2s são inerentemente uma extensão da camada base de Bitcoin, eles são por sua natureza limitados em termos de funcionalidade pela funcionalidade da camada base. O Lightning exigiu três softforks separados, CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV) e Testemunha segregada antes que fosse possível implementá-lo.

Você simplesmente não pode construir Layer 2s mais flexíveis sem uma camada base mais flexível. O único atalho em torno disso são terceiros confiáveis, pura e simplesmente. Isso é algo que espero que todos aspiramos a remover de todos os aspectos da interação com Bitcoin em escala que pudermos.

Há coisas que precisamos ser capazes de fazer que simplesmente não podemos fazer agora em ordem para embalar com segurança mais de duas pessoas em uma única UTXO de uma maneira que possa ser aplicada sem confiança na camada base, Bitcoin script simplesmente não é flexível o suficiente. No nível mais básico, precisamos de convênios, precisamos da capacidade do script de realmente impor detalhes mais granulares sobre a transação executando-os para garantir que coisas como um usuário sair com segurança de um UTXO por conta própria não coloque os fundos de outros usuários em risco.

Em uma visão alta, este é o tipo de funcionalidade que precisamos:

Introspecção: Precisamos ser capazes de realmente inspecionar detalhes específicos sobre uma transação de gastos em si na pilha, como "essa quantidade de dinheiro vai para essa chave pública em alguma saída". Isso me permite sacar meu dinheiro sozinho usando um ramo Taproot específico meu, garantindo que eu não possa pegar o dinheiro de ninguém. A execução do script imporia, por consenso, que a quantidade correta que todos os outros possuem é enviada de volta para um endereço composto pelas chaves públicas dos outros usuários se eu sair.

Forward Data Carrying: Digamos que vamos ainda mais longe do que a ideia de um canal Lightning com mais de duas pessoas nele, construímos um único UTXO com uma enorme quantidade de pessoas nele, onde qualquer um pode entrar e sair como quiser. De alguma forma, quase sempre com uma árvore merkle e sua raiz, precisamos de alguma maneira de rastrear quem tem quanto dinheiro. Isso significa que, quando alguém sai, temos que ser capazes de garantir que o "registro" de quem tem direito ao que faz parte do troco UTXO do dinheiro de todos os outros. Este é essencialmente um uso específico para introspecção.

Chave pública Modificação: Precisamos da capacidade de garantir que as modificações para agregar chaves públicas possam ser verificadas na pilha. O objetivo a ser alcançado em UTXO esquemas de compartilhamento é que haja uma chave agregada com todos os envolvidos permitindo uma movimentação cooperativa e mais eficiente de fundos. Sempre que alguém deixa um UTXO compartilhado unilateralmente, precisamos remover sua chave individual da chave agregada. Sem pré-calcular todas as combinações possíveis com antecedência, a única opção é ser capaz de verificar se a subtração de uma chave da agregação cria uma chave válida composta pelo restante das chaves individuais.

COMO TORNAR ISSO SEGURO: VAROPS

Como eu disse acima, a razão pela qual todos esses opcodes foram desativados foi para remover riscos de ataques de negação de serviço que poderiam literalmente travar os nós que compõem a rede. Há uma maneira de resolver isso, restringir a quantidade de recursos que qualquer um desses opcodes pode usar.

Já temos essa solução quando se trata de verificação de assinatura, a parte mais cara da verificação de scripts Bitcoin. É o chamado orçamento de sigops. Cada uso de um opcode de verificação de assinatura consome um certo "orçamento" de operações de assinatura permitidas por bloco. Isso coloca um limite rígido no custo que as transações podem impor aos usuários para verificar um bloco individual.

Taproot mudou a maneira como isso funciona, em vez de usar um único limite de bloco global, cada transação tem seu próprio limite de sigops proporcional ao tamanho da transação. Isso funciona essencialmente no mesmo limite global, mas torna mais fácil raciocinar sobre quantos sigops uma transação individual tem disponível.

A mudança na forma como Taproot lida com os limites de sigops em relação a cada transação oferece uma maneira de generalizar isso, que é o que Rusty propõe com um limite de varops. A ideia é atribuir um custo para cada um dos opcodes reativados para levar em conta o pior caso, ou seja, o custo computacional mais caro para validar, que cada opcode poderia criar. Com isso, cada um desses opcodes teria seu próprio limite de "sigops" para conter quantos recursos poderia consumir em verificação. Também seria baseado no tamanho de qualquer transação usando-os, então mantenha a facilidade de raciocínio sobre isso, enquanto ainda adiciona um limite global implícito por bloco.

Isso resolveria os riscos de negação de serviço que fizeram com que Satoshi desabilitasse todos esses opcodes em primeiro lugar.

FORWARD MOMENTUM

Tenho certeza de que muitos de vocês estão pensando "isso é uma mudança muito grande". Posso ter empatia com isso, mas acho que um aspecto importante desse projeto como proposta para entender é que não precisamos fazer tudo isso. O valor desta proposta não é necessariamente reverter tudo isso como um todo, é o fato de que estaríamos realmente olhando para um enorme conjunto de primitivos e nos perguntando o que realmente queremos disso em termos de funcionalidade.

Seria uma cara completa dos últimos três anos de brigas e discussões sobre pequenas mudanças estreitas que só ajudam certas funcionalidades. É uma tenda que poderia reunir todos sob o mesmo teto para avaliar de forma realmente abrangente para onde ir a partir daqui. Talvez acabemos voltando tudo isso, talvez acabemos apenas ativando algumas coisas porque o consenso é que é tudo o que precisamos para habilitar a funcionalidade que todos concordam que precisamos.

Independentemente de qual seja o resultado final, pode ser uma mudança produtiva em toda a conversa em torno de onde vamos a partir daqui. Podemos realmente mapear e obter uma visão abrangente da terra, em vez de ficar discutindo sobre qual caminho obscuro e meio iluminado seguir em seguida.

Este não tem de ser de modo algum o caminho a seguir, mas penso que é a nossa melhor oportunidade para decidir qual o que fazemos. É hora de começar a trabalhar juntos de forma produtiva novamente.

Isenção de responsabilidade:

1. Este artigo é reimpresso de [bitcoinmagazine], Todos os direitos autorais pertencem ao autor original [SHINOBI]. Se houver objeções a esta reimpressão, entre em contato com a equipe Gate Learn, e eles lidarão com isso prontamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.