AUTOR ORIGINAL: SHINOBI

Compilação original: Bloco unicórnio

Apesar do alcance da proposta, qual é a razão pela qual a "ótima recuperação de roteiro" de Rusty Russell pode ser o caminho a seguir para o desenvolvimento de Bitcoin?

Bloco unicórnio Nota: Rusty Russell é um desenvolvedor ativo na comunidade Bitcoin e é muito respeitado na comunidade. Ele trabalhou extensivamente no desenvolvimento do kernel Linux e esteve envolvido em muitos longo Bitcoin projetos de desenvolvimento principais.

Bitcoin foi originalmente projetado para ter uma linguagem de script completa projetada para cobrir e suporte quaisquer possíveis casos de uso de segurança que os usuários possam criar no futuro. Como Satoshi Nakamoto disse antes de desaparecer:

"A essência do Bitcoin é que, uma vez lançada a versão 0.1, o design central é determinado para o resto do ciclo de vida. Portanto, eu queria projetá-lo para suporte todos os tipos de negociação possíveis que eu pudesse pensar. O problema é que tudo requer códigos suporte especiais e campos de dados, usados ou não, o que leva a casos especiais mais longos. A solução é um script que generaliza o problema para que ambas as partes possam descrever suas transações com condições específicas que a rede Nó avalia ou valida com base nessas condições." - Satoshi Nakamoto, 17 de junho de 2010

Todo o seu propósito é dar aos usuários uma linguagem que seja comum o suficiente para que eles organizem seus tipos de transações como desejarem. Ou seja, curtas para os usuários desenharem e experimentarem como escrever suas próprias moedas.

Antes de desaparecer, Satoshi Nakamoto removeu 15 desses códigos de operação, desativou-os totalmente e adicionou um limite rígido na pilha do mecanismo de script que limitava o tamanho dos blocos de dados que podiam ser manipulados (520 bytes). Isso porque ele realmente se ferrou, deixando para trás muitas maneiras que scripts complexos poderiam ser usados para realizar ataques DOS em toda a rede (enviando um grande número de solicitações de spam, fazendo com que a rede caísse), criando transações enormes e caras que travariam nós.

Esses códigos de operação não foram removidos porque Satoshi Nakamoto achava que os recursos eram perigosos ou que as pessoas não deveriam usá-los para construir algo que pudesse ser alcançado, mas simplesmente (pelo menos superficialmente) por causa do risco que representam para toda a rede sem restrições de recursos, como os piores custos de validação que poderiam impor à rede sem limitações.

Desde então, cada atualização de Bitcoin acabou sendo uma otimização funcional dos recursos restantes, corrigindo outras falhas menos graves que Satoshi Nakamoto nos deixou e expandindo a funcionalidade do nosso subconjunto de script restante.

Ótima recuperação de script

Na conferência Austin Bitcoin++ no início de maio, o desenvolvedor do Core Rede de iluminação, Rusty Russell, fez uma proposta muito radical em seu primeiro discurso na conferência, onde ele basicamente teve a ideia de reativar a grande Código de operação de saudade que Satoshi Nakamoto havia desativado antes de desaparecer em 2010.

Nos anos desde a ativação do Taproot em 2021 (Taproot é uma grande atualização para Bitcoin que visa melhorar a privacidade, segurança e escalabilidade), o espaço de desenvolvimento tem sido um pouco sem rumo. Todos sabemos que Bitcoin não é suficientemente escalável para fornecer serviços auto-soberanos a qualquer tamanho considerável da população mundial, e pode nem sequer ser capaz de fornecer escalabilidade a prestadores de serviços que podem ultrapassar grandes depositários e prestadores de serviços, e não podem verdadeiramente libertar-se das restrições de braço longo dos governos, de uma forma que minimize a confiança ou a custódia.

Este artigo aponta para o nível técnico de Bitcoin, que não é uma questão a ser debatida. A questão sobre a qual vale a pena discutir é como corrigir essa falha, que é um tópico muito controverso. Desde que Taproot foi introduzido, todos têm vindo a apresentar propostas muito restritas que visam resolver problemas que só podem ser alcançados para casos de uso específicos.

Por exemplo, ANYPREVOUT (APO) é uma proposta que permite que assinaturas sejam reutilizadas em diferentes transações, longo como o script e o valor inserido são os mesmos, e esta proposta é especificamente projetada para otimizar o Rede de iluminação e suas versões mais longo. CHECKTEMPLATEVERIFY (CTV) é uma proposta que exige que as moedas físicas só sejam gastas por transações que correspondam exatamente a transações predefinidas, e esta proposta foi projetada para estender a funcionalidade de cadeias de transações pré-assinadas, tornando-as completamente sem confiança. OP_VAULT foi projetado especificamente para definir um "tempo limite" para uma solução de armazenamento a frio, para que os usuários possam "desbuscar" do armazenamento a frio, enviando-o para uma configuração de longo mais fria para evitar que seus Chave Secreta sejam comprometidos.

Há outras propostas mais longas, mas penso que já se percebe o essencial. Ao longo dos últimos anos, cada proposta foi concebida para aumentar ligeiramente a escalabilidade ou melhorar uma única pequena funcionalidade, uma vez que tal é considerado desejável. Essa é a causa principal da razão pela qual estas discussões não avançaram. Ninguém ficou satisfeito com as outras propostas porque não atendiam aos casos de uso que queriam ver.

Ninguém além do patrocinador da proposta acredita que qualquer proposta é suficientemente abrangente para ser considerada um próximo passo razoável.

Esta é a lógica por trás de "Great Script Recovery". Ao empurrar e analisar uma recuperação completa de scripts, como Satoshi Nakamoto originalmente projetado, podemos realmente tentar explorar todos os curtas de recursos de que precisamos, em vez de discutir e brigar internamente sobre quais pequenas extensões de recursos são boas o suficiente agora.

OPCODES (Código de operação)

• OP_CAT: Pega duas partes de dados da pilha e as adiciona para formar um dado.
• OP_SUBSTR: Aceite um parâmetro de comprimento (em bytes), obtenha um pedaço de dados da pilha, remova os bytes desse comprimento e coloque-o de volta na pilha.
• OP_LEFT e OP_RIGHT: Aceita um parâmetro length que pega um pedaço de dados da pilha e remove bytes do comprimento especificado de um lado ou do outro.
• OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT e OP_DOWNSHIFT: Aceita um elemento de dados e executa as operações de bit correspondentes nele.
• OP_ 2 MUL, OP_2D IV, OP_MUL, OP_DIV e OP_MOD: Operadores matemáticos para operações de multiplicação, divisão e módulo (retornando o restante da divisão).

Além dos lista acima de Códigos de Operação para recuperar, Rusty Russell propõe mais três Códigos de Operação projetados para simplificar a combinação de diferentes Códigos de Operação:

OP_CTV (ou TXHASH/equivalente Código de operação): Permite a aplicação refinada de certas partes de uma transação que devem ser exatamente como predefinidas.

CSFS: Permite que as assinaturas sejam verificadas, não apenas para toda a transação, o que requer que certas partes do script ou os dados usados sejam assinados ordem sejam executados.

OP_TWEAKVERIFY: Valida operações baseadas em Schnorr que envolvem Chave pública, como adicionar ou subtrair Chave pública individuais do Chave pública agregado. Isso pode ser usado para garantir que, quando uma parte deixa unilateralmente uma saída de transação compartilhada não utilizada (UTXO), todos os fundos dos outros participantes são enviados para uma chave pública agregada que não requer a assinatura da parte que parte parte para fazer gastos cooperativos.

Por que estamos fazendo isso

Camada 2 redes são essencialmente extensões da camada base do Bitcoin, e são funcionalmente restringidas pelas funções da camada base. Rede de iluminação requer três Soft Fork separados antes que eles possam realmente ser implementados: CHECKLOCKTIMEVERIFY (CLTV), checksequenceverify (csv) e SegWit (Testemunha Segregada).

Sem uma camada base mais flexível, não é possível construir uma rede de camada 2 mais flexível. O único atalho é confiar em terceiros, o que é muito simples e direto, e espero que todos aspiramos a remover terceiros confiáveis de todos os aspetos da interação com Bitcoin em escala tanto quanto possível.

Precisamos ser capazes de fazer algo que não é possível atualmente em ordem mesclar com segurança mais de duas pessoas em uma única saída de transação não utilizada (UTXO) e ser capazes de executar sem confiança na camada base. Bitcoin flexibilidade atual do Script não é suficiente. No nível mais básico, precisamos de contratos, e precisamos de scripts que possam realmente impor detalhes mais finos sobre a execução de transações para garantir que um usuário saia com segurança de sua própria UTXO não coloque os fundos de outros usuários em risco.

Numa perspetiva mais elevada, é disso que precisamos:

Introspeção: Precisamos ser capazes de realmente verificar detalhes específicos na pilha sobre a transação de gastos em si, como "essa quantidade de dinheiro irá para essa chave pública de alguma saída". Isso me permite retirar meus fundos por conta própria usando minha própria agência Taproot específica, garantindo que não posso retirar fundos de mais ninguém. O script executado garantirá que os fundos de outros proprietários sejam enviados de volta para o Endereço que consiste na Chave pública de outros usuários, caso outros participantes causem perda de fundos.

Forward Data Carrying: Digamos que pegamos o conceito de um único UTXO, por exemplo, com um grande número de pessoas, que qualquer pessoa pode ir e vir como quiser. Neste caso, precisamos de uma maneira de rastrear quem tem mais ou menos dinheiro, geralmente usando o Árvore de Merkle e suas raízes. Isso significa que, quando alguém sai, temos que nos certificar de "registrar" quem tem direito ao quê como parte da mudança UTXO para os fundos de todos os outros. Trata-se, basicamente, de um uso específico da introspeção.

Chave pública Modificação: Precisamos garantir que as modificações no Chave pública agregado possam ser verificadas na pilha. No esquema de partilha de Resultados de Transações Não Utilizadas (UTXO, o nosso objetivo é facilitar a cooperação e o fluxo eficiente de fundos através de um Chave pública agregado que inclua todos os participantes. Quando alguém abandona unilateralmente uma UTXO partilhada, temos de retirar a sua Chave pública pessoal do Chave pública agregado. Se todas as combinações possíveis não forem calculadas previamente, a única opção é verificar se a subtração de uma chave pública da chave pública agregada produzirá uma chave pública válida que consiste nas chaves públicas individuais restantes.

Como estar seguro: VAROPS Como disse acima, a razão para desativar todos esses Códigos de Operação é abordar ataques DOS (que fazem com que a rede falhe enviando um grande número de solicitações de spam), o que pode fazer com que os nós que compõem a rede falhem. Uma maneira de resolver esse problema é limitar a quantidade de recursos que podem ser usados por qualquer um desses códigos de operação.

Quando se trata de verificação de assinatura, a parte mais cara do script Bitcoin, já temos essa solução, que é chamada de orçamento de operação de assinatura (sigops). Cada uso do Código de operação de verificação de assinatura consome um determinado "orçamento", ou seja, o número de operações de assinatura permitidas por bloco, o que define um limite rígido para o custo que uma transação pode gerar para validar um bloco.

Taproot muda essa forma de trabalhar, não mais longo usando um único limite de Bloco global, mas em vez disso, cada transação tem seu próprio limite sigops (operação de assinatura), proporcional ao tamanho da transação. Isso basicamente equivale ao mesmo limite global, mas é mais fácil entender que cada transação tem longo menos sigops disponíveis.

A mudança no limite de sigops (operação de assinatura) do Taproot para processar cada transação abre a possibilidade de uma abordagem de generalização, que é o que Rusty Russell sugeriu em termos de limites de varops. A ideia é atribuir um custo a cada Código de operação reativado para conta para o pior cenário que cada Código de operação pode criar, ou seja, o custo computacional mais caro incorrido no momento da validação. Desta forma, cada Código de operação terá o seu próprio limite de "sigops", limitando a quantidade de recursos que pode consumir durante o processo de validação. Isso também será baseado no tamanho de quaisquer transações que usem esses Código de operação, de modo que a inferência possa ser facilitada enquanto ainda se acumula até o limite global implícito por Bloco.

Isso resolveria o ataque DOS (enviando muitas solicitações de spam, fazendo com que a rede falhasse) por causa dessas transações de spam, e o que fez com que Satoshi Nakamoto desativasse inicialmente todos esses códigos de operação.

Impulso para avançar

Tenho certeza de que vocês pensarão: "Isso é muita mudança". Eu entendo isso, mas acho que um aspeto importante para entender como proposta é que não precisamos fazer tudo. O valor desta proposta não é necessariamente que todos esses recursos sejam totalmente restaurados, mas que vamos dar uma olhada holística em um vasto conjunto de componentes fundamentais e nos perguntar o que realmente queremos em termos de funcionalidade.

Seria uma mudança completa em relação aos últimos três anos de disputas e debates o facto de termos estado apenas a discutir pequenas alterações estreitas que só têm determinadas funções. É como uma praça onde todos podem se reunir e olhar para a direção do futuro. Talvez eventualmente restauremos todos esses recursos, ou talvez acabemos ativando apenas alguns deles, porque o Consenso é que esses são os que todos concordamos que precisam ser ativados.

Independentemente do resultado final, esta pode ser uma mudança que impacta positivamente toda a conversa sobre o nosso rumo futuro. Na verdade, podemos mapear e obter uma imagem completa da situação, em vez de tatear o nosso caminho debatendo qual caminho obscuro seguir a seguir.

Não é de forma alguma o caminho que temos de seguir, mas acho que é a melhor oportunidade para decidirmos qual o caminho que queremos seguir. É hora de começar a trabalhar juntos novamente de forma prática e produtiva.