Como vêem os profissionais que trabalhavam em 2010 o caminho de construção do BTC uma década depois

Autor: BTC Podcast Block Digest co-fundador Shinobi; Tradução: Wuzhu, Jinse Finance

Este artigo é um texto escrito por Shinobi há dez anos, discutindo como era o BTC em 2020.

O primeiro artigo desta série pode ser encontrado em "Como os profissionais de 2010 veem o ecossistema BTC dez anos depois?"

Começamos a ver as sementes do potencial da segunda camada brotando da camada base do primeiro década de primitivos. Embora a Lightning Network ainda esteja sujeita a algumas restrições consideráveis, ela realmente está começando a florescer. Esta é apenas a versão inicial limitada que está atualmente designada e implantada. Vários tipos de sidechains já foram implantados: Liquid, RSK e até mesmo a cadeia de tokens vinculada ao BTC desenvolvida pela Commerceblock. Este é apenas o começo.

###SCHNORR e TAPROT

Não demorou muito para termos uma combinação de Schnorr e Taproot. Do ponto de vista de Schnorr, este é um esquema de assinatura de verificação em lote que custa menos e é o próximo grande salto em frente na otimização da construção de scripts multisig BTC. Um multisig é inicialmente apenas uma questão de enviá-lo com todas as chaves públicas e scripts multisig enfiados na saída da transação, e tudo isso deve ser incluído na entrada para usá-lo. O P2SH otimiza o aspeto de saída incluindo uma chave pública multisig e um hash de comprimento constante do script, salvando qualquer pessoa que envie para um endereço multisig e adicionando apenas custo ao remetente. SegWit indiscutivelmente "otimiza" ainda mais, testemunhando descontos para tornar UTXOs que custam multisig mais barato. Schnorr leva todas essas otimizações incrementais ao extremo. Você combina chaves públicas individuais em uma única chave e todos podem colaborar para fazer uma assinatura para ela e, em seguida, verificá-la. Isso proporciona uma economia de custos significativa para todas as tecnologias que usam multisig, incluindo a Camada 2, como o Lightning Network (Lightning) e sidechains federadas, e também traz benefícios de privacidade ao tornar todas essas UTXOs multisig indistinguíveis das UTXOs de assinatura única.

Agora, isso não pode magicamente manter tudo completamente secreto. As atualizações de canais relâmpago (transações) ainda precisam de caminhos de chave separados para reagir às transações de penalização em relação ao estado antigo. Isso significa que eles devem estar presentes nos scripts de saída que criam as impressões digitais. O Taproot resolve esse problema com sua mágica criptográfica, permitindo que você envie uma árvore de merkle com condições de gastos diferentes, apenas precisando das condições utilizadas e das provas de merkle até a raiz do merkle para gastar, sob uma chave pública Schnorr que parece normal. Agora, você pode ocultar esse caminho de script de penalização com o Taproot. Você pode ocultar qualquer caminho de script de condições com o Taproot, escondendo-os sob chaves secretas Schnorr que permitem que todos os participantes cheguem a um consenso sobre algo e realizem transações que parecem normais.

###SIGHASH_ANYPREVOUTPUT

SIGHASH_ANYPREVOUTPUT (anteriormente SIGHASH_NOINPUT) está definido para se tornar o próximo novo primitivo. É uma nova atualização de formato de chave pública/sinal de hash. O sinal de hash especifica quais partes da transação o sinal será submetido. A existência dessa funcionalidade permite que você execute operações como assinar apenas suas entradas e saídas, mas permite que outros adicionem suas próprias entradas e saídas à transação sem torná-la inválida. Atualmente, as assinaturas devem ser submetidas a UTXO exatas da transação exata. Entre outras coisas, SIGHASH_ANYPREVOUT pode submeter a assinatura ao script UTXO em vez de um UTXO específico real. Isso permite uma nova maneira (eltoo) de construir o estado dos canais da Lightning Network, sem a necessidade de chaves de punição ou lidar com estados antigos, permitindo que uma parte enganosa confisque todos os fundos. Em vez disso, se o estado atual do canal falhar em uma competição de pagamentos duplos, ele pode simplesmente reutilizar o estado antigo do canal, garantindo que todos obtenham seu saldo atual do canal na cadeia, em vez do saldo expirado anterior. Tudo o que é necessário é reutilizar o mesmo script no local correto e usar SIGHASH_ANYPREVOUT para alcançar isso.

Isto elimina muitos riscos, como perder o estado atual do canal, resultando em transações de penalização que retêm os seus fundos devido a uma perda acidental. Também pode realizar mais funcionalidades. Agora, podemos ter canais relâmpago com mais de 2 participantes e até mesmo empilhar 'sub-canais' sobre estes canais. Além disso, SIGHASH_ANYPREVOUT e eltoo podem criar Statechains, que é uma forma de construção de canal cooperativo que permite que novos participantes entrem e saiam completamente off-chain, assumindo que a coalizão não conspirará com participantes anteriores para enganar alguém. Isto abre muitas possibilidades para o protocolo que tenho chamado de 'protocolo de UTXO estático de múltiplas partes'.

###OP_CHECKTEMPLATEVERIFY

OP_CTV é uma proposta feita por Jeremy Rubin, com o objetivo de implementar um tipo muito básico de "contrato" no BTC. Um contrato é uma restrição mais complexa sobre o uso de um BTC, não apenas uma assinatura de algumas chaves. O tipo de contrato proposto por Rubin a ser implementado é um "modelo". Essencialmente, isso permite que o script do UTXO exija que a transação de gasto crie saídas precisas específicas. Portanto, uma vez que um UTXO é criado usando OP_CTV, ele é executado por consenso, o que significa que o UTXO deve ser gasto em um endereço específico, com o valor definido no script desse UTXO. Você até pode encadeá-los, de modo que um UTXO seja forçado a gerar mais alguns, e então esses UTXOs sejam forçados a gerar mais alguns, e assim por diante.

Isso tem ampla aplicabilidade universal em todos os lugares. Em um ambiente de alta taxa, uma entidade custodial pode fazer um único UTXO, que garante 100% dos fundos de seus clientes de acordo com regras de consenso de que todos os fundos de seus clientes serão controlados pelo cliente, mesmo que eles não tenham acesso imediato a esses fundos. Isso tem grandes sinergias potenciais com multicanal (fábrica de canais), já que "retiradas" em grande escala como esta também podem ser criadas e usadas como uma fábrica de canais ao mesmo tempo. OP_CTV pode ser usado para criar canais de pagamento que funcionam em pelo menos uma direção, sem a necessidade de envolvimento do recetor ou ter uma chave on-line para receber pagamentos (lembre-se, você pode empilhar canais uns sobre os outros). Ele pode até ser usado para permitir que um único canal processe mais HTLCs de uma só vez, agrupando-os, usando os mesmos truques do primeiro exemplo de retirada hospedada. Pode até criar algum potencial para um novo tipo de moeda.

###Integrar Todos os Elementos

Supondo que todas as propostas acima sejam adotadas e incorporadas ao BTC, eu realmente acredito que, além dos desenvolvedores envolvidos no trabalho de ponta, as pessoas nem sabem que tipo de protocolos e serviços serão construídos usando essas linguagens de programação. Ou coisas estranhas sem fronteiras claras entre serviços ou protocolos.

Eles habilitarão canais multipartidários teoricamente ilimitados em termos de participantes, que podem ser empilhados sobre subcanais de participantes de canal de base. Pode-se construir canais sobre essas 'fábricas de canais' para permitir que as pessoas recebam pagamentos sem precisar possuir as chaves da carteira quente online. Esses canais multipartidários em si podem ser empilhados sobre canais de união (statechains), permitindo que os participantes entrem ou saiam da cadeia sem atividade na cadeia! A construção de 'junção' de canais permitirá que a liquidez se mova relativamente sem problemas entre diferentes canais, realizando uma variedade de coisas que as pessoas nem mesmo começaram a considerar de verdade.

A minha última frase nesta secção é: isto apenas considera o que pode ser feito com o que eu considero ser uma parte direta da pilha de protocolos BTC. Se começares a investigar os serviços de custódia centralizados e o que estes podem oferecer como subconjuntos de BTC, sem serem afetados por regulamentações ou obstáculos legais, então podes fazer muito mais.