Já estamos a começar a ver as sementes do potencial da segunda camada a desenvolver-se a partir dos primitivos da camada base que foram adicionados ou otimizados na primeira década. O Lightning, embora ainda sujeito a algumas limitações bastante significativas, está realmente a começar a prosperar. E isso é apenas a primeira versão limitada que está atualmente especificada e implementada. Existem agora cadeias laterais de vários tipos implementadas: Liquid, RSK e até mesmo cadeias de TOKEN atreladas ao Bitcoin desenvolvidas pela Commerceblock. Isto é apenas o início.
Schnorr e Taproot
Logo acima do horizonte, temos a combinação de Schnorr e Taproot. Do lado de Schnorr, este é um esquema de assinatura muito mais barato para verificar em lotes, bem como o próximo grande salto na otimização da construção de scripts multi-assinatura em Bitcoin. Multisig começou como apenas encher todas as chaves públicas e script para o multisig em uma saída de transação para enviar para ele, e ter que incluir tudo isso na entrada para gastá-lo. O P2SH otimizou o aspeto de saída, incluindo um hash de comprimento constante das chaves públicas e scripts do multisig, economizando taxas para quem envia para um endereço multisig e deixando um custo aumentado apenas para o remetente. SegWit indiscutivelmente "otimizado" ainda mais, tornando os gastos multisig UTXOs mais baratos com o desconto 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 criar uma única assinatura, e apenas verifique isso. Isso cria enormes economias de custos para todo o uso de multisig, incluindo segundas camadas como Lightning e cadeias laterais federadas, e cria um benefício de privacidade também, tornando todas essas UTXOs multisig indistinguíveis das de assinatura única.
Agora, isso não torna magicamente tudo completamente privado. Os estados dos canais de raio (transações) ainda requerem caminhos de chaves separados para suas transações de penalidade reagirem à submissão de estados antigos. Isso significa que eles têm que estar nos scripts de saída que cria uma impressão digital. O Taproot resolve isso com sua cripto-mágica permitindo que você comprometa uma árvore de merkle de diferentes condições de gastos, que requerem apenas a condição usada e a prova de merkle para a raiz de merkle para gastar, a uma chave pública Schnorr de aparência normal. Agora você pode ocultar esse caminho de script de penalidade com taproot. Você pode ocultar qualquer caminho de script condicional com Taproot, enterrado sob uma chave Schnorr de aparência perfeitamente normal que permite que todos os participantes concordem com algo e façam uma transação de aparência perfeitamente normal.
SIGHASH_ANYPREVOUTPUT
SIGHASH_ANYPREVOUTPUT (anteriormente SIGHASH_NOINPUT) é esperançosamente a próxima nova primitiva a ser lançada. É um novo formato de chave pública/atualização de sinal de Sighash. Os sinais de Sighash especificam quais partes de uma transação uma assinatura está a comprometer-se. Esta funcionalidade existe para que possa fazer algo como assinar apenas a sua entrada e saídas, mas permitir que outras pessoas adicionem as suas próprias entradas e saídas a uma transação sem a invalidar. Mas atualmente, uma assinatura tem de comprometer-se com um UTXO exato de uma transação exata. SIGHASH_ANYPREVOUT, entre outras coisas, permitiria comprometer uma assinatura apenas com um script UTXO, não um UTXO específico real. Isso permite uma nova forma (eltoo) de construir estados de canal Lightning que não requer uma chave de penalização ou lidar com estados antigos permitindo à parte enganada confiscar todo o dinheiro. Em vez disso, o estado atual do canal poderia simplesmente reutilizar o estado antigo do canal se perdesse a corrida de gastos duplos, garantindo que todos recebam o seu saldo atual do canal na cadeia em vez de um saldo desatualizado anterior. Você consegue isso simplesmente reutilizando o mesmo script no lugar certo e usando SIGHASH_ANYPREVOUT.
Isso elimina muitos riscos em relação à perda dos estados atuais do canal, resultando em uma transação de penalidade levando seus fundos por um erro honesto. Também permite MUITO mais. Agora podemos ter canais Lightning com mais de 2 participantes, e podemos até empilhar "sub-canais" em cima destes. Além disso, SIGHASH_ANYPREVOUT e eltoo permitem a criação de Statechains, um tipo de construção de canal federado que permite que novos participantes entrem e saiam completamente fora da cadeia com a suposição de confiança de que a federação não entrará em conluio com participantes anteriores para fraudar ninguém. Isso abre muito potencial para o que eu tenho chamado para mim mesmo de "protocolos UTXO estáticos multipartidos".
OP_CHECKTEMPLATEVERIFY
OP_CTV é uma proposta de Jeremy Rubin para permitir um tipo muito básico de "covenant" sobre Bitcoin. Um pacto é uma restrição mais complicada para gastar uma moeda além das assinaturas de certas chaves. O tipo de pacto que a proposta de Rubin implementaria é um "modelo". Essencialmente, isso permite que o script de um UTXO exija saídas exatas específicas a serem criadas pela transação de gastos. Assim, uma vez que um UTXO é criado usando OP_CTV, é imposto por consenso que o UTXO tem que ser gasto em endereços específicos nos montantes específicos definidos no script desse UTXO. Você pode até encadeá-los para que um desses UTXOs seja forçado a fazer mais alguns deles, que são forçados a fazer mais alguns, e assim por diante.
Isto tem uma enorme aplicabilidade geral em todo o lado. Em ambientes de alta taxa, um único UTXO pode ser feito por uma entidade custodial que 100% sob regras de consenso garante que todos os fundos de seus clientes acabarão sob o controle de seus clientes, mesmo que eles não tenham acesso imediato a eles no momento. Isso tem muita sinergia potencial com canais multipartidos (channel factories), na medida em que uma "retirada" em massa feita assim também pode simultaneamente criar e ser usada como uma fábrica de canais. OP_CTV pode ser usado para criar canais de pagamento que pelo menos funcionam unidirecionalmente sem que o destinatário tenha que participar ou ter uma chave on-line para receber pagamentos (and lembre-se que você pode empilhar canais em cima de cada other). Pode até ser usado para permitir que um único canal processe mais HTLCs de uma só vez, agrupando-os com o mesmo truque que o primeiro exemplo com retiradas custodial usa. E pode até criar algum potencial para novos tipos de moedas.
Colocando Tudo Junto
Pressupondo que todas as propostas acima sejam adotadas e incorporadas ao Bitcoin, eu realmente acho que, além dos desenvolvedores que trabalham na vanguarda dessas coisas, as pessoas nem têm a menor ideia de que tipos de protocolos e serviços serão construídos usando esses primitivos. Ou as coisas estranhas onde não há uma linha divisória clara entre serviço ou protocolo.
Eles irão permitir canais multi-party com teoricamente números ilimitados de participantes, que podem empilhar sub-canais no topo com sub-grupos menores dos participantes do canal base. Os canais podem ser construídos em cima dessas “fábricas de canais” que permitem que as pessoas recebam dinheiro sem ter chaves online para uma carteira quente. Esses canais multi-party podem eles próprios ser empilhados em cima de canais federados (cadeias de estado) que permitem que os participantes entrem ou saiam com zero atividade on-chain! E a construção do “splicing” de canal permitirá que a liquidez se mova de forma relativamente contínua entre diferentes canais de maneiras que permitirão todo tipo de coisas com as quais as pessoas nem mesmo começaram a pensar.
A minha última palavra nesta secção é: isto está apenas a considerar o que pode ser feito com coisas que considero partes diretas da pilha de protocolos do Bitcoin em si. Pode fazer muito mais se começar a olhar para os serviços de custódia centralizados, e que subconjunto das propriedades do Bitcoin estes podem fornecer, ignorando as barreiras regulatórias ou legais para o fazer.
Esta é apenas a Parte 2 de 4, leia a próxima parte amanhã
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
A Próxima Década, Parte 2: O Caminho a Seguir
Já estamos a começar a ver as sementes do potencial da segunda camada a desenvolver-se a partir dos primitivos da camada base que foram adicionados ou otimizados na primeira década. O Lightning, embora ainda sujeito a algumas limitações bastante significativas, está realmente a começar a prosperar. E isso é apenas a primeira versão limitada que está atualmente especificada e implementada. Existem agora cadeias laterais de vários tipos implementadas: Liquid, RSK e até mesmo cadeias de TOKEN atreladas ao Bitcoin desenvolvidas pela Commerceblock. Isto é apenas o início.
Schnorr e Taproot
Logo acima do horizonte, temos a combinação de Schnorr e Taproot. Do lado de Schnorr, este é um esquema de assinatura muito mais barato para verificar em lotes, bem como o próximo grande salto na otimização da construção de scripts multi-assinatura em Bitcoin. Multisig começou como apenas encher todas as chaves públicas e script para o multisig em uma saída de transação para enviar para ele, e ter que incluir tudo isso na entrada para gastá-lo. O P2SH otimizou o aspeto de saída, incluindo um hash de comprimento constante das chaves públicas e scripts do multisig, economizando taxas para quem envia para um endereço multisig e deixando um custo aumentado apenas para o remetente. SegWit indiscutivelmente "otimizado" ainda mais, tornando os gastos multisig UTXOs mais baratos com o desconto 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 criar uma única assinatura, e apenas verifique isso. Isso cria enormes economias de custos para todo o uso de multisig, incluindo segundas camadas como Lightning e cadeias laterais federadas, e cria um benefício de privacidade também, tornando todas essas UTXOs multisig indistinguíveis das de assinatura única.
Agora, isso não torna magicamente tudo completamente privado. Os estados dos canais de raio (transações) ainda requerem caminhos de chaves separados para suas transações de penalidade reagirem à submissão de estados antigos. Isso significa que eles têm que estar nos scripts de saída que cria uma impressão digital. O Taproot resolve isso com sua cripto-mágica permitindo que você comprometa uma árvore de merkle de diferentes condições de gastos, que requerem apenas a condição usada e a prova de merkle para a raiz de merkle para gastar, a uma chave pública Schnorr de aparência normal. Agora você pode ocultar esse caminho de script de penalidade com taproot. Você pode ocultar qualquer caminho de script condicional com Taproot, enterrado sob uma chave Schnorr de aparência perfeitamente normal que permite que todos os participantes concordem com algo e façam uma transação de aparência perfeitamente normal.
SIGHASH_ANYPREVOUTPUT
SIGHASH_ANYPREVOUTPUT (anteriormente SIGHASH_NOINPUT) é esperançosamente a próxima nova primitiva a ser lançada. É um novo formato de chave pública/atualização de sinal de Sighash. Os sinais de Sighash especificam quais partes de uma transação uma assinatura está a comprometer-se. Esta funcionalidade existe para que possa fazer algo como assinar apenas a sua entrada e saídas, mas permitir que outras pessoas adicionem as suas próprias entradas e saídas a uma transação sem a invalidar. Mas atualmente, uma assinatura tem de comprometer-se com um UTXO exato de uma transação exata. SIGHASH_ANYPREVOUT, entre outras coisas, permitiria comprometer uma assinatura apenas com um script UTXO, não um UTXO específico real. Isso permite uma nova forma (eltoo) de construir estados de canal Lightning que não requer uma chave de penalização ou lidar com estados antigos permitindo à parte enganada confiscar todo o dinheiro. Em vez disso, o estado atual do canal poderia simplesmente reutilizar o estado antigo do canal se perdesse a corrida de gastos duplos, garantindo que todos recebam o seu saldo atual do canal na cadeia em vez de um saldo desatualizado anterior. Você consegue isso simplesmente reutilizando o mesmo script no lugar certo e usando SIGHASH_ANYPREVOUT.
Isso elimina muitos riscos em relação à perda dos estados atuais do canal, resultando em uma transação de penalidade levando seus fundos por um erro honesto. Também permite MUITO mais. Agora podemos ter canais Lightning com mais de 2 participantes, e podemos até empilhar "sub-canais" em cima destes. Além disso, SIGHASH_ANYPREVOUT e eltoo permitem a criação de Statechains, um tipo de construção de canal federado que permite que novos participantes entrem e saiam completamente fora da cadeia com a suposição de confiança de que a federação não entrará em conluio com participantes anteriores para fraudar ninguém. Isso abre muito potencial para o que eu tenho chamado para mim mesmo de "protocolos UTXO estáticos multipartidos".
OP_CHECKTEMPLATEVERIFY
OP_CTV é uma proposta de Jeremy Rubin para permitir um tipo muito básico de "covenant" sobre Bitcoin. Um pacto é uma restrição mais complicada para gastar uma moeda além das assinaturas de certas chaves. O tipo de pacto que a proposta de Rubin implementaria é um "modelo". Essencialmente, isso permite que o script de um UTXO exija saídas exatas específicas a serem criadas pela transação de gastos. Assim, uma vez que um UTXO é criado usando OP_CTV, é imposto por consenso que o UTXO tem que ser gasto em endereços específicos nos montantes específicos definidos no script desse UTXO. Você pode até encadeá-los para que um desses UTXOs seja forçado a fazer mais alguns deles, que são forçados a fazer mais alguns, e assim por diante.
Isto tem uma enorme aplicabilidade geral em todo o lado. Em ambientes de alta taxa, um único UTXO pode ser feito por uma entidade custodial que 100% sob regras de consenso garante que todos os fundos de seus clientes acabarão sob o controle de seus clientes, mesmo que eles não tenham acesso imediato a eles no momento. Isso tem muita sinergia potencial com canais multipartidos (channel factories), na medida em que uma "retirada" em massa feita assim também pode simultaneamente criar e ser usada como uma fábrica de canais. OP_CTV pode ser usado para criar canais de pagamento que pelo menos funcionam unidirecionalmente sem que o destinatário tenha que participar ou ter uma chave on-line para receber pagamentos (and lembre-se que você pode empilhar canais em cima de cada other). Pode até ser usado para permitir que um único canal processe mais HTLCs de uma só vez, agrupando-os com o mesmo truque que o primeiro exemplo com retiradas custodial usa. E pode até criar algum potencial para novos tipos de moedas.
Colocando Tudo Junto
Pressupondo que todas as propostas acima sejam adotadas e incorporadas ao Bitcoin, eu realmente acho que, além dos desenvolvedores que trabalham na vanguarda dessas coisas, as pessoas nem têm a menor ideia de que tipos de protocolos e serviços serão construídos usando esses primitivos. Ou as coisas estranhas onde não há uma linha divisória clara entre serviço ou protocolo.
Eles irão permitir canais multi-party com teoricamente números ilimitados de participantes, que podem empilhar sub-canais no topo com sub-grupos menores dos participantes do canal base. Os canais podem ser construídos em cima dessas “fábricas de canais” que permitem que as pessoas recebam dinheiro sem ter chaves online para uma carteira quente. Esses canais multi-party podem eles próprios ser empilhados em cima de canais federados (cadeias de estado) que permitem que os participantes entrem ou saiam com zero atividade on-chain! E a construção do “splicing” de canal permitirá que a liquidez se mova de forma relativamente contínua entre diferentes canais de maneiras que permitirão todo tipo de coisas com as quais as pessoas nem mesmo começaram a pensar.
A minha última palavra nesta secção é: isto está apenas a considerar o que pode ser feito com coisas que considero partes diretas da pilha de protocolos do Bitcoin em si. Pode fazer muito mais se começar a olhar para os serviços de custódia centralizados, e que subconjunto das propriedades do Bitcoin estes podem fornecer, ignorando as barreiras regulatórias ou legais para o fazer.
Esta é apenas a Parte 2 de 4, leia a próxima parte amanhã