Já estamos começando a ver as sementes do potencial de segunda camada se desenvolvendo a partir das primitivas da camada base que foram adicionadas ou otimizadas na primeira década. O Lightning, embora ainda esteja sujeito a algumas limitações bastante grandes, está realmente começando a prosperar. E essa é apenas a primeira versão limitada que está atualmente especificada e implantada. Atualmente, existem pesquisas laterais de vários tipos implantados: líquido, RSK e até cadeias de token ligadas ao Bitcoin desenvolvido pelo CommerceBlock. Este é apenas o começo.
Schnorr e Taproot
Logo no horizonte, temos a combinação de Schnorr e Taproot. No lado de Schnorr, é muito mais barato verificar o esquema de assinatura em lotes, bem como o próximo grande salto na otimização da construção de scripts com várias assinaturas no Bitcoin. O MultiSig começou como apenas enchendo todas as chaves e scripts públicos para o Multisig em uma saída de transação para enviá -lo e ter que incluir tudo isso na entrada para gastá -lo. O P2SH otimizou o aspecto de saída, incluindo um hash de comprimento constante das chaves e scripts públicos do multisig, economizando taxas para qualquer pessoa que envie para um endereço multisig e deixando um custo aumentado apenas para o remetente. Segwit, sem dúvida, otimizado “ainda mais, tornando os gastos com vários utxos mais baratos com o desconto da testemunha. Schnorr leva toda essa otimização incremental ao extremo. Você combina as chaves públicas individuais em uma única chave, para a qual todos podem colaborar para fazer uma única assinatura e apenas verificar isso. Isso cria uma economia maciça de custos para todo o uso do MultiSig, incluindo segundas camadas como Lightning e Federated Sidechains, e cria um benefício de privacidade, além de tornar todos esses UTXOS multisigs indistinguíveis dos únicos assinatura.
Agora isso não apenas magicamente torna tudo completamente privado. Os estados do canal de raios (transações) ainda requerem caminhos -chave separados para que suas transações de penalidade reagam ao envio de estados antigos. Isso significa que esses devem estar nos scripts de saída, o que cria uma impressão digital. A Taproot resolve isso com seu cripto-mágico, permitindo que você cometa uma árvore de merkle de diferentes condições de gastos, que exigem apenas a condição usada e a prova de merkle à raiz de merkle para gastar, a uma chave pública de aparência normal. Agora você pode ocultar esse caminho de script de penalidade com a Taproot. Você pode ocultar qualquer caminho de script condicional com a torre, enterrado sob uma tecla Schnorr de aparência perfeitamente normal que permite que todos os participantes concordem em algo e façam uma transação de aparência perfeitamente normal.
SIGHASH_ANYPREVOUTPUT
SIGHASH_ANYPREVOUTPUT (anteriormente SIGHASH_NOINPUT) é esperado que o próximo novo primitivo desça o pipeline. É um novo Formato Público Formato/Sighash Flag Upgrade. SIGHASH SPANGLS Especifique quais partes de uma transação uma assinatura está se comprometendo. Essa funcionalidade existe para que você possa fazer algo como assinar apenas sua entrada e saídas, mas permita que outras pessoas adicionem suas próprias entradas e saídas a uma transação sem invalidar -a. Mas atualmente, uma assinatura precisa se comprometer com um exato Utxo de um exato transação. Sighash_anyPrevout, entre outras coisas, permitiria cometendo uma assinatura com apenas um script UTXOnão um UTXO específico real. Isso permite que uma nova maneira (ELTOO) construa estados do canal de raios que não requerem uma chave de penalidade ou lidar com os estados antigos, permitindo que a parte enganada confisque todo o dinheiro. Em vez disso, o estado atual do canal poderia simplesmente gastar novamente o estado de canal antigo se perdesse a corrida de gastos duplos, garantindo que todos obtenham seu equilíbrio atual de canal em cadeia em oposição a um saldo desatualizado anterior. Você consegue isso apenas reutilizando o mesmo script no lugar certo e usando SIGHASH_ANYPREVOUT.
Isso remove muitos riscos ao perder os estados atuais do canal, resultando em uma transação de penalidade levando seus fundos para um erro honesto. Também permite muito mais. Agora, podemos ter canais de raios com mais de 2 participantes e podem até empilhar “sub-canais” em cima deles. Além disso, Sighash_anyPrevout e ELTOO permitem a criação de Statechains, um tipo de construto de canal federado que permite que os novos participantes entrem e saem completamente da cadeia com a suposição de confiança de que a Federação não vai colar com os participantes anteriores para fraudar ninguém. Isso abre muito potencial para o que eu tenho chamado para mim mesmo “protocolos estáticos de UTXO multipartidários”.
On_CheckTemPlatifes
OP_CTV é uma proposta de Jeremy Rubin para permitir um tipo muito básico de “aliança” no Bitcoin. Uma aliança é restrições mais complicadas para gastar uma moeda além das assinaturas de certas chaves. O tipo de proposta da Aliança Rubin implementaria é um “modelo”. Essencialmente, isso permite que o script de um UTXO exige que saídas exatas específicas sejam criadas pela transação de gastos. Portanto, uma vez que um UTXO é criado usando o OP_CTV, é aplicado por consenso de que o UTXO deve ser gasto em endereços específicos nos valores específicos definidos nesse script desse UTXO. Você pode até acorrentá -los para que um desses UTXOs seja forçado a fazer mais alguns deles, que são forçados a fazer mais alguns, sem parar.
Isso tem enorme aplicabilidade geral em todo o lugar. Em ambientes de alta taxa, um único UTXO pode ser feito por uma entidade de custódia que 100% sob regras de consenso Garanta que todos os seus fundos de seus clientes acabem sob o controle de seus clientes, mesmo que eles não tenham acesso imediato a eles no momento. Isso tem muita sinergia em potencial com canais multipartidários (fábricas de canal), pois uma “retirada” em massa feita assim também pode criar e ser usada simultaneamente como uma fábrica de canal. Op_ctv pode ser usado para criar canais de pagamento que pelo menos trabalham unidirecionalmente sem que a extremidade receptora tenha que participar ou ter uma chave online para receber pagamentos (e lembre -se de que você pode empilhar canais um sobre o outro). Ele pode até ser usado para permitir que um único canal processe mais HTLCs ao mesmo tempo, agrupando -os com o mesmo truque que o primeiro exemplo de retiradas de custódia usa. E pode até criar algum potencial para novos tipos de moedas.
Juntando tudo
Supondo que todas as propostas acima sejam adotadas e incorporadas ao Bitcoin, eu realmente acho que, além dos desenvolvedores realmente trabalhando na vanguarda dessas coisas, as pessoas nem sequer têm a menor pista que tipos de protocolos e serviços serão construídos usando esses primitivos. Ou as coisas estranhas em que não há uma linha divisória clara entre o serviço ou o protocolo.
Eles permitirão canais multipartidários com números de participantes teoricamente ilimitados, que podem empilhar sub-canais na parte superior com subgrupos menores dos participantes do canal base. Os canais podem ser construídos sobre essas “fábricas de canal” que permitem que as pessoas recebam dinheiro sem ter chaves on -line para uma carteira quente. Esses canais multipartidários podem ser empilhados no topo dos canais federados (Statechains) que permitem que os participantes entrem ou saem com Zero atividade na cadeia! E a construção do canal “Splicing” permitirá que a liquidez se mova de maneira relativamente perfeita entre diferentes canais de maneiras que permitirão que todos os tipos de coisas que as pessoas realmente realmente começaram a pensar.
Minha última palavra nesta seção é: isso está apenas considerando o que pode ser feito com coisas que considero partes diretas da própria pilha do protocolo Bitcoin. Você pode fazer muito mais se começar a analisar os serviços de custódia centralizados e qual subconjunto das propriedades do Bitcoin elas podem fornecer a ignorar barreiras regulatórias ou legais de fazê -lo.
Isso é apenas a parte 2 de 4, leia a próxima parte amanhã.
Fonte: bitcoinmagazine.com
