Embora o escopo das propostas seja bastante amplo, qual poderia ser a razão pela qual a "Grande Recuperação de Scripts" de Rusty Russell é considerada o caminho a seguir para o desenvolvimento do Bitcoin?

Nota do unicórnio do bloco: 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, incluiu uma linguagem de script completa destinada a cobrir e apoiar 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 básico foi definido para o resto de sua vida. Por causa disso, eu queria projetá-lo para suportar todos os tipos de transação que eu pudesse pensar, mas em 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 forma 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 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 escrevem seu próprio dinheiro.

Antes de seu desaparecimento, Satoshi Nakamoto removeu 15 opcodes, desabilitando-os completamente, e adicionou um limite rígido no tamanho dos blocos de dados que poderiam operar na pilha do mecanismo de script (520 bytes). Isso ocorreu porque ele efetivamente bagunçou, deixando para trás muitas maneiras como scripts complexos poderiam potencialmente ser usados para realizar ataques de DOS em toda a rede (enviando grandes quantidades de solicitações de lixo, causando paralisia na rede), criando transações enormes e custosas que poderiam derrubar nós.

Esses códigos de operação não foram removidos porque Satoshi Nakamoto os considerava perigosos, ou porque as pessoas não deveriam explorá-los para construir o que quer que fosse, mas simplesmente (pelo menos superficialmente) 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 características restantes, corrigindo outras falhas menos graves deixadas para nós por Satoshi Nakamoto e expandindo a funcionalidade do subconjunto de scripts que restaram.

Ó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 códigos de operação 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 sido um tanto 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 forma minimamente confiável ou custodial que possa superar instituições custodiais e provedores de serviços muito grandes, e não pode verdadeiramente escapar das restrições da supervisão governamental.

Este artigo destaca uma compreensão em nível técnico do Bitcoin, o que não é assunto para debate. A questão discutível é como abordar essa deficiência, que é um tópico muito controverso. Desde a proposta do Taproot, todos têm feito propostas muito específicas visando 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 montantes sejam os mesmos. Esta proposta é especificamente projetada para otimizar a Rede Lightning e suas versões multi-party. CHECKTEMPLATEVERIFY (CTV) é uma proposta que exige que as moedas sejam gastas apenas por transações que correspondam exatamente a transações predefinidas. Esta proposta é projetada para estender a funcionalidade das cadeias de transações pré-assinadas tornando-as totalmente sem confiança. OP_VAULT é especificamente projetado para definir um “tempo limite” para soluções de armazenamento a frio para que os usuários possam “cancelar” retiradas do armazenamento a frio enviando-as para configurações mais frias de multi-assinatura para evitar que suas chaves sejam vazadas.

Existem muitas outras propostas, mas acho que você entendeu os pontos-chave. Nos últimos anos, cada proposta teve como objetivo aumentar ligeiramente a escalabilidade ou melhorar um único recurso pequeno, pois isso foi considerado desejável. Por isso, essas discussões não avançaram. Ninguém está satisfeito com outras propostas porque elas não atenderam aos casos de uso que desejam ver.

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 Script'. Ao advogar e analisar a restauração abrangente de scripts, assim como Satoshi Nakamoto originalmente projetou, podemos realmente tentar explorar todo o espaço funcional de que precisamos, em vez de debater e discutir sobre qual extensão de pequena funcionalidade é boa o suficiente para agora.

OPCODES (Códigos de Operação)

• OP_CAT: Obtenha dois dados da pilha e some-os 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, pega um pedaço de dados da pilha e remove bytes do comprimento especificado de um lado ou de outro.
• 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 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 mais três opcodes adicionais projetados para simplificar a combinação de diferentes opcodes:

OP_CTV (ou TXHASH/código equivalente): Permite a aplicação precisa de certas 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 a transação inteira, de modo que certas partes do script ou dos dados usados devem 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), os fundos de todas as outras partes são enviados para uma chave pública agregada que permite a despesa cooperativa sem exigir a assinatura da parte que deixa o UTXO compartilhado.

Por que estamos fazendo isso?

As redes Layer2 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 aspiremos a remover a confiança em terceiros o máximo possível de cada aspecto 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 duas ou mais pessoas 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 seu próprio UTXO não coloque em risco os fundos de outros usuários.

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

Introspecção: Precisamos ser capazes de realmente inspecionar 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.

Encaminhamento de Dados: Supondo que desenvolvemos ainda mais o conceito de um único UTXO com um grande número de pessoas, onde qualquer um pode entrar e sair livremente. Neste caso, precisamos de uma maneira de rastrear quem tem quanto dinheiro, normalmente usando árvores de Merkle e suas raízes. Isso significa que quando alguém sai, devemos garantir que 'registre' quem tem direito a receber o que como parte do UTXO de troco dos fundos de outras pessoas. Isso é essencialmente um uso específico de introspecção.

Modificação da Chave Pública: Precisamos garantir que as modificações nas chaves públicas agregadas possam ser verificadas na pilha. Em um esquema de saída de transação não gasta (UTXO) compartilhada, nosso objetivo é facilitar a cooperação e o fluxo eficiente de fundos por meio de uma chave pública agregada contendo todos os participantes. Quando alguém sai unilateralmente da UTXO compartilhada, precisamos remover 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 chaves públicas individuais restantes.

Garantindo Segurança: Como mencionei acima, a razão para desativar todos esses opcodes foi lidar com ataques DOS (causando falhas na rede ao enviar grandes quantidades de solicitações inúteis), o que poderia levar à falha dos nós que compõem a rede. Uma maneira de lidar com esse 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 determinado "orçamento", 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íveis.

A mudança 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 considerar 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 usam esses opcodes, tornando conveniente para inferência, ao mesmo tempo que ainda se acumula ao limite global implícito de cada bloco. Isso resolverá ataques de DOS (causando falhas na rede ao enviar grandes quantidades de solicitações inúteis), que também foi o motivo pelo qual Satoshi Nakamoto inicialmente desativou todos esses opcodes.

O Motor Impulsionando para Frente

Acredito que muitos de vocês possam pensar, 'Essa é uma grande mudança.' Entendo essa perspectiva, mas acho importante entender sobre uma proposta é que não precisamos fazer tudo de uma vez. O valor desta proposta pode não necessariamente residir na plena restauração de todas essas funcionalidades, mas sim em examinar minuciosamente uma vasta gama de componentes fundamentais e nos perguntar quais funcionalidades realmente desejamos.

Isso marcaria uma mudança completa dos últimos três anos de discussões e debates, onde estávamos apenas debatendo mudanças pequenas e estreitas, mudanças que afetavam apenas certas funcionalidades. É como um quadrado onde todos podem se reunir e contemplar coletivamente a direção do futuro. Talvez, no final, restauraremos todas essas funcionalidades, ou talvez ativaremos apenas algumas, porque o consenso é concordar sobre quais funcionalidades todos nós acreditamos que precisam ser habilitadas.

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 em um caminho obscuro.

Esta não é de forma alguma a única maneira de avançar que devemos tomar, mas acredito que ela apresenta a melhor oportunidade para decidirmos qual caminho seguir. É 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 [GateBloco unicórnio]. Todos os direitos autorais pertencem ao autor original [SHINOBI]. Se você tiver alguma objeção à reprodução, entre em contato com o Gate Learnequipe, a equipe lidará com isso o mais rápido 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 outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.