Embora o âmbito das propostas seja bastante amplo, qual poderá ser a razão pela qual a “Grande Recuperação de Scripts” de Rusty Russell é considerada o caminho futuro do desenvolvimento do Bitcoin?

Nota sobre o bloco unicornio: Rusty Russell é um desenvolvedor ativo na comunidade Bitcoin e é altamente respeitado dentro dela. Ele fez contribuições notáveis para o desenvolvimento do kernel do Linux e esteve envolvido em vários projetos de desenvolvimento do Bitcoin Core.

Quando o Bitcoin foi inicialmente projetado, incluía uma linguagem de script completa destinada a cobrir e suportar qualquer caso de uso de segurança potencial que os usuários pudessem propor no futuro. Como Satoshi Nakamoto afirmou antes de desaparecer:

“A natureza do Bitcoin é tal que, uma vez que a versão 0.1 foi lançada, o design central foi estabelecido para o resto da sua vida. Por causa disso, eu queria projetá-lo para suportar todos os tipos de transações que eu pudesse imaginar, mas nas versões posteriores, removemos a capacidade de executar scripts arbitrários. O problema era que cada recurso exigia códigos de suporte especiais e campos de dados, quer fossem usados ou não, o que levou a casos especiais demais. A solução foi o script, que generalizou o problema para que as transações pudessem descrever suas condições de uma maneira específica para elas, e os nós da rede pudessem avaliar e validar essas condições.” - Satoshi Nakamoto, 17 de junho de 2010

O objetivo principal era dar aos usuários uma linguagem genérica o suficiente para permitir que eles organizem seus tipos de transação de acordo com seus desejos. Em outras palavras, dá aos usuários o espaço para projetar e experimentar como eles escrevem seu próprio dinheiro.

Antes do seu desaparecimento, Satoshi Nakamoto removeu 15 opcodes, desativando-os completamente, e adicionou um limite rígido ao tamanho dos blocos de dados que poderiam operar na pilha do mecanismo de script (520 bytes). Isto aconteceu porque ele efetivamente se atrapalhou, deixando para trás muitas maneiras de como scripts complexos poderiam ser potencialmente usados para realizar ataques DOS em toda a rede (enviando grandes quantidades de pedidos de lixo, causando paralisia na rede), criando transações enormes e dispendiosas que poderiam fazer com que os nós falhassem.

Estes opcodes não foram removidos porque Satoshi Nakamoto considerou essas funcionalidades como perigosas, ou que as pessoas não deveriam explorá-las para construir o que poderiam, mas simplesmente (pelo menos à superfície) porque representavam um risco para toda a rede sem limitações de recursos, e assim poderiam impor os piores custos de verificação na rede sem restrições.

Desde então, cada atualização do Bitcoin tem sido, em última análise, uma otimização das funcionalidades restantes, corrigindo outras falhas menos graves deixadas por Satoshi Nakamoto, e expandindo a funcionalidade do subconjunto de scripts que temos.

Ótima recuperação de script

Na conferência Bitcoin++ em Austin no início de maio, o desenvolvedor principal da Lightning Network, Rusty Russell, fez uma proposta muito radical em sua primeira palestra na conferência, onde basicamente propôs reabilitar a maioria dos opcodes desativados por Satoshi Nakamoto antes de seu desaparecimento em 2010.

Desde a ativação do Taproot em 2021 (o Taproot é uma atualização significativa do Bitcoin destinada a melhorar a privacidade, segurança e escalabilidade), o campo de desenvolvimento tem estado um pouco sem rumo. É bem compreendido que o Bitcoin carece de escalabilidade suficiente para fornecer verdadeiramente serviços soberanos a qualquer população significativa no mundo, ou mesmo para fornecer escalabilidade de uma forma minimamente confiável ou custodial que possa superar instituições custodiais e provedores de serviços muito grandes, e não pode realmente escapar das restrições da supervisão governamental.

Este artigo destaca uma compreensão ao nível técnico do Bitcoin, que não é um assunto para debate. A questão debatível é como abordar esta deficiência, que é um tópico muito controverso. Desde a proposta do Taproot, todos têm vindo a propor propostas muito específicas destinadas a resolver problemas que só podem ser alcançados com casos de uso específicos.

Por exemplo, ANYPREVOUT (APO) é uma proposta que permite que assinaturas sejam reutilizadas em diferentes transações, desde que os scripts de entrada e os valores sejam os mesmos. Esta proposta foi projetada especificamente para otimizar a Lightning Network e suas versões multipartidárias. CHECKTEMPLATEVERIFY (CTV) é uma proposta que exige que as moedas sejam gastas apenas por transações que correspondam exatamente a transações predefinidas. A presente proposta destina-se a alargar a funcionalidade das cadeias de transações pré-assinadas, tornando-as completamente desfiáveis. OP_VAULT foi projetado especificamente para definir um "tempo limite" para soluções de armazenamento a frio, para que os usuários possam "cancelar" retiradas do armazenamento frio, enviando-as para configurações de várias assinaturas mais frias para evitar que suas chaves sejam vazadas.

Existem muitas outras propostas, mas penso que compreendeu os pontos-chave. Nos últimos anos, cada proposta visou ligeiramente aumentar a escalabilidade ou melhorar uma única funcionalidade, visto como desejável. É por isso que estas discussões não avançaram. Ninguém está satisfeito com outras propostas porque não atenderam aos casos de uso que desejam ver.

Para além dos proponentes, ninguém acredita que qualquer proposta seja abrangente o suficiente para ser considerada um próximo passo razoável.

Esta é a lógica por trás da "Grande Recuperação de Scripts". Ao advogar e analisar a restauração abrangente de scripts, tal como Satoshi Nakamoto originalmente projetou, podemos realmente tentar explorar todo o espaço funcional de que precisamos, em vez de debater e discutir qual pequena extensão de recurso é suficiente por agora.

OPCODES (Operation Codes)

• OP_CAT: Obter dois dados da pilha e adicioná-los para formar um dado único.
• OP_SUBSTR: Aceita um parâmetro de comprimento (em bytes), obtém um pedaço de dados da pilha, remove os bytes desse comprimento e os coloca de volta na pilha.
• OP_LEFT e OP_RIGHT: Aceita um parâmetro de comprimento, retira um pedaço de dados da pilha e remove bytes do comprimento especificado de um lado ou de outro dele.
• OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT e OP_DOWNSHIFT: Aceite um elemento de dados e execute a operação de bit correspondente sobre ele.
• OP_2MUL, OP_2DIV, OP_MUL, OP_DIV e OP_MOD: Operadores matemáticos para operações de multiplicação, divisão e operações de módulo (retornando o resto da divisão).

Além dos opcodes listados acima para recuperar, Rusty Russell propôs três opcodes adicionais projetados para simplificar a combinação de diferentes opcodes:

OP_CTV (ou TXHASH/código de operação equivalente): Permite a aplicação de regras específicas em partes de uma transação, exigindo que essas partes sejam exatamente consistentes com o conteúdo predefinido.

CSFS: Permite a verificação de assinaturas, não apenas de toda a transação, para que certas partes do script ou dados usados tenham de ser assinadas antes de poderem ser executadas.

OP_TWEAKVERIFY: Uma validação de operação baseada em Schnorr, envolvendo chaves públicas, como adicionar ou subtrair chaves públicas individuais de uma chave pública agregada. Isso pode ser usado para garantir que quando uma parte gasta unilateralmente de uma saída de transação não utilizada compartilhada (UTXO), fundos de todas as outras partes são enviados para uma chave pública agregada que permite gastos cooperativos sem exigir a assinatura da parte que deixa o UTXO compartilhado.

Porque estamos a fazer isto?

As redes de camada 2 são essencialmente extensões da camada base do Bitcoin e são limitadas pelas funcionalidades da camada base. Antes que a Lightning Network pudesse ser implementada, eram necessários três soft forks separados: CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV) e Testemunha Segregada (SegWit).

Sem uma camada base mais flexível, é impossível construir redes Layer2 mais flexíveis. O único atalho é confiar em terceiros, o que é muito direto, mas espero que todos aspiramos a remover a confiança em terceiros o máximo possível de todos os aspectos de interação com a escalabilidade do Bitcoin.

Precisamos ser capazes de fazer coisas que atualmente são impossíveis, como consolidar com segurança dois ou mais indivíduos em uma única saída de transação não utilizada (UTXO) e ser capaz de executar sem confiança na camada base. A flexibilidade atual dos scripts do Bitcoin não é suficiente. No nível mais básico, precisamos de contratos e precisamos de scripts para realmente impor detalhes mais finos sobre a execução de transações para garantir que um usuário que sai com segurança de sua própria UTXO não coloque em risco os fundos de outros usuários.

De uma perspetiva mais elevada, esta é a funcionalidade de que precisamos:

Autoinspeção: Precisamos ser capazes de inspecionar realmente detalhes específicos sobre a transação de gastos em si na pilha, como “esta parte do dinheiro fluirá para uma chave pública específica de uma saída.” Isso me permite usar meu próprio ramo específico do Taproot para extrair meus fundos de forma independente, garantindo que não posso pegar os fundos de mais ninguém. O script executado garantirá que os fundos de outros proprietários sejam enviados de volta para endereços compostos por chaves públicas de outros usuários para evitar a perda de fundos causada por outros participantes.

Forward Data Carrying: Assumindo que desenvolvemos ainda mais o conceito de um único UTXO com um grande número de pessoas, onde qualquer pessoa pode entrar e sair livremente. Neste caso, precisamos de uma maneira de rastrear quem tem quanto dinheiro, normalmente usando árvores Merkle e suas raízes. Isso significa que, quando alguém sai, devemos garantir que "registre" quem tem direito a receber o quê como parte da mudança de fundos de outras pessoas. Trata-se, essencialmente, de um uso específico da introspeção.

Modificação da Chave Pública: Precisamos garantir que as modificações às chaves públicas agregadas possam ser verificadas na pilha. Num esquema de saída de transações não gastas (UTXO) partilhadas, o nosso objetivo é facilitar a cooperação e o fluxo eficiente de fundos através de uma chave pública agregada contendo todos os participantes. Quando alguém sai unilateralmente da UTXO partilhada, precisamos de remover a sua chave pública individual da chave pública agregada. Se todas as combinações possíveis não foram pré-computadas, então a única opção é verificar se subtrair uma chave pública da chave pública agregada geraria uma chave pública válida composta pelas restantes chaves públicas individuais.

Garantir Segurança: Como mencionei acima, a razão para desativar todos esses opcodes foi lidar com ataques DOS (causando crashes de rede ao enviar grandes quantidades de pedidos de lixo), o que poderia levar ao crash dos nós que formam a rede. Uma maneira de lidar com este problema é limitar a quantidade de recursos que qualquer um desses opcodes pode usar.

Quando se trata de verificação de assinatura, a parte mais cara do script do Bitcoin, já temos uma solução para isso chamada Orçamento de Operação de Assinatura (sigops). Cada uso de um opcode de verificação de assinatura consome um certo “budget”, ou seja, o número de operações de assinatura permitidas por bloco, estabelecendo um limite rígido sobre o custo necessário para validar um bloco para uma transação a um usuário. O Taproot muda como isso funciona ao não usar mais um limite de bloco global único, mas tendo cada transação seu próprio limite de sigops (operações de assinatura), proporcional ao tamanho da transação. Isso essencialmente equivale ao mesmo limite global, mas torna mais fácil entender quantos sigops cada transação tem disponível.

A alteração no Taproot em relação ao limite de sigops (operações de assinatura) para cada transação oferece a possibilidade de uma abordagem generalizada, que é também a sugestão proposta por Rusty Russell em relação às limitações de varops. A ideia é alocar um custo para cada opcode reativado para contabilizar o pior cenário que cada opcode poderia criar em termos do custo computacional mais caro durante a verificação. Assim, cada opcode terá seu próprio limite de "sigops", limitando a quantidade de recursos que pode consumir durante a verificação. Isso também será baseado no tamanho de quaisquer transações que usem esses opcodes, tornando conveniente para inferência, enquanto ainda acumula para o limite global implícito de cada bloco. Isso abordará os ataques DOS (causando falhas na rede ao enviar grandes quantidades de solicitações inúteis), que foi também a razão pela qual Satoshi Nakamoto inicialmente desativou todos esses opcodes.

A Força Motriz para a Frente

Acredito que muitos de vocês possam pensar: "Isso é uma grande mudança." Entendo esta perspetiva, mas acho importante compreender que não temos de fazer tudo de uma vez. O valor desta proposta pode não residir necessariamente na restauração completa de todas estas funcionalidades, mas sim em examinarmos minuciosamente uma vasta gama de componentes fundamentais e questionarmos o que funcionalidades desejamos verdadeiramente.

Isto marcaria uma mudança completa dos últimos três anos de discussão e debate, onde estávamos simplesmente a debater mudanças menores e limitadas, mudanças que apenas afetavam certas funcionalidades. É como um quadrado onde todos podem reunir-se e contemplar coletivamente a direção do futuro. Talvez, no final, restauremos todas essas funcionalidades, ou talvez apenas ativemos algumas, porque o consenso consiste em concordar sobre quais funcionalidades todos nós acreditamos que precisam de ser ativadas.

Independentemente do resultado final, esta pode ser uma mudança que impacta positivamente todo o diálogo sobre a nossa direção futura. Na verdade, podemos mapear e compreender totalmente a situação, em vez de avançar às cegas ao debater o próximo passo num caminho obscuro.

Esta não é, de forma alguma, a única maneira de avançar que devemos seguir, mas acredito que apresenta a melhor oportunidade para decidirmos qual caminho tomar. É hora de começar a trabalhar juntos novamente de maneira prática e eficaz.

Declaração:

1. Este artigo originalmente intitulado “伟大的脚本恢复：比特币的前进之路” é reproduzido a partir de [Gate.ioBloquear unicórnio]. Todos os direitos de autor pertencem ao autor original [SHINOBI]. Se tiver alguma objeção à reimpressão, por favor contacte o Gate Learnequipa, a equipa tratará disso o mais depressa possível.

2. Aviso legal: As opiniões expressas neste artigo representam apenas as opiniões pessoais do autor e não constituem qualquer conselho de investimento.

3. As traduções do artigo para outras línguas são feitas pela equipa Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.