Bitcoin foi inicialmente projetado com uma linguagem de script totalmente desenvolvida, destinada a abranger e suporte qualquer caso de uso seguro potencial que os usuários possam criar no futuro. Como Satoshi mesmo disse antes de desaparecer:

"A natureza do Bitcoin é tal que, uma vez lançada a versão 0.1, o design central foi definido em pedra para o resto de sua vida. Por causa disso, eu queria projetá-lo para suporte todos os tipos de transação possíveis que eu pudesse pensar. O problema era que cada coisa exigia códigos suporte 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 que transacionam 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 bem entendessem. Ou seja, dar aos utilizadores espaço para conceber e experimentar a forma como programaram o seu próprio dinheiro.

Antes de desaparecer, Satoshi arrancou 15 desses opcodes, desativando-os totalmente e adicionando um limite rígido para o 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 que scripts complicados poderiam ser usados para ataques de negação de serviço a toda a rede, criando transações enormes e caras 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 eles serem usados sem restrições de recursos para limitar o pior custo de validação que poderiam impor à rede.

Cada atualização para Bitcoin desde então acabou simplificando a funcionalidade restante, corrigindo outras falhas menos graves Satoshi nos deixaram, e estendendo a funcionalidade desse subconjunto de script com o qual ficamos.

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 uma forma auto-soberana, e provavelmente nem mesmo de uma forma 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 Bitcoin a nível tecnológico entende isso, não é uma questão de debate. O que é objeto de debate, e muito controverso, é a forma de colmatar esta lacuna. Desde Taproot, todos têm apresentado propostas muito restritas destinadas a abordar apenas casos de uso muito particulares 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 só pode ser gasto por uma transação que corresponde exatamente a uma transação predefinida, foi projetado especificamente para estender a funcionalidade de cadeias de transações pré-assinadas, tornando-as completamente sem confiança. O OP_VAULT foi projetado especificamente para permitir um "período de tempo limite" para esquemas de armazenamento frio, para que um usuário pudesse "cancelar" uma retirada do armazenamento a 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ê entende o ponto. Em vez de tentar abordar de forma abrangente a expressividade e a programabilidade necessárias para escalar Bitcoin de forma fundamental, cada uma das propostas ao longo dos últimos anos foi projetada para dar um pequeno aumento na escalabilidade ou melhorar uma única funcionalidade restrita considerada desejável. Acho que essa é a fonte da razão pela qual nenhuma dessas conversas vai a lugar algum. Ninguém está satisfeito com qualquer outra proposta porque não atende ao caso de uso que eles querem ver construído.

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

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 o projetou inicialmente, podemos realmente tentar explorar todo o espaço de qual funcionalidade precisamos, em vez de brigas e brigas internas 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: Usa um argumento length 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 length e remove muitos bytes de um lado ou de outro de uma parte de dados 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 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 que estão acima são os opcodes que se destinam a ser 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 que exige que certas partes de uma transação sejam exatamente como definidas com antecedência.
• CSFS: Permite verificar assinaturas em relação a dados arbitrários, em vez de apenas toda a transação. Isso permite que você exija que partes de um script, ou dados que eles usam, sejam assinados ordem sejam 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

As camadas 2 são inerentemente uma extensão da camada base de Bitcoin, elas são por sua natureza limitadas em termos de funcionalidade pela funcionalidade da camada base. O Lightning exigia três softforks separados, CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV) e Testemunha Segregada antes que fosse possível implementá-lo de fato.

Você simplesmente não pode construir camadas 2 mais flexíveis sem uma camada de base mais flexível. O único atalho em torno disso são terceiros confiáveis, puros e simples. Espero que todos ambicionemos eliminar de todos os aspetos da interação com Bitcoin escala possível.

Há coisas que precisamos ser capazes de fazer que simplesmente não podemos fazer agora a ordem de agrupar com segurança mais de duas pessoas em um único UTXO de uma forma 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 que os executa 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:

Introspeçã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 permite-me levantar o meu dinheiro sozinho utilizando um ramo Taproot específico meu, ao mesmo tempo que garanto que não posso receber o dinheiro de mais 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 saísse.

Forward Data Carrying: Digamos que vamos ainda mais longe do que a ideia de um canal Lightning com mais de duas pessoas, construímos um único UTXO com uma enorme quantidade de pessoas onde qualquer pessoa pode ir e vir 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 da mudança UTXO do dinheiro de todos os outros. Este é essencialmente um uso específico para introspeçã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 atirar para os esquemas de partilha de UTXO é que exista uma chave agregada com todos os envolvidos, permitindo uma movimentação cooperativa e mais eficiente de fundos. Sempre que alguém deixa uma UTXO compartilhada 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 subtrair uma chave da agregação cria uma chave válida composta pelo resto 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 de verificar Bitcoin scripts. É 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 forma 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 para o mesmo limite global, mas torna mais fácil raciocinar em termos de 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 cenário, 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 restringir quantos recursos poderia consumir na verificação. Também seria baseado no tamanho de qualquer transação que os utilizasse, portanto, mantenha a facilidade de raciocínio sobre isso, enquanto ainda soma 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 aspeto importante deste projeto como proposta para entender é que não precisamos fazer tudo isso. O valor desta proposta não é necessariamente virar tudo isso de volta como um todo, é o fato de que estaríamos realmente olhando de forma abrangente para um conjunto maciço 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 por voltar a ligar tudo isto, talvez acabemos por ativar apenas algumas coisas porque o consenso é que é tudo o que precisamos para permitir a funcionalidade de 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 nos atrapalharmos 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 deles fazemos. É hora de começar a trabalhar juntos de forma produtiva novamente.

Declaração de exoneração de responsabilidade:

1. Este artigo é reproduzido a partir 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 imediatamente.
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.