As carteiras on-chain alcançam um mapeamento aproximadamente 1-1 de transações para transações: para cada transação econômica que um usuário realiza, aproximadamente uma transação em blockchain é necessária. Agregações, coinjoin, pagamentos de corte, etc. mudam um pouco essa afirmação. Mas é aproximadamente correto.

O Lightning alcançou um mapeamento de muitos para um de transações para transações: a magia do Lightning é que um número efetivamente infinito de transações econômicas pode acontecer em um único canal Lightning, que por sua vez está ligado a uma única saída de transação não gasta (UTXO). Essencialmente, pegamos a dimensão do 'tempo' - transações - e alcançamos uma escalabilidade significativa ao colapsar essa dimensão.

Mas criar até mesmo um único UTXO por usuário, talvez, não seja bom o suficiente. Por isso, existem muitas propostas por aí para alcançar ainda maior escalabilidade, permitindo que vários usuários compartilhem um único UTXO de forma auto-soberana. Novamente, colapsando outra dimensão de escalabilidade - os usuários - em um único UTXO.

Nosso objetivo aqui é fazer uma visão geral de todas essas propostas, descobrir quais padrões técnicos elas compartilham, descobrir que tipos de novos opcodes e outras atualizações de garfo suave elas precisam para funcionar e criar uma tabela de comparação de como todas as partes se encaixam. No caminho, também definiremos o que é um protocolo L2, que tipo de escalabilidade o Lightning já é capaz e entenderemos que melhorias precisamos fazer nos mempools para alcançar tudo isso.

Agradecimentos vão para Fulgur Venturespor patrocinar esta pesquisa. Eles não tiveram controle editorial sobre o conteúdo desta postagem e não o revisaram antes da publicação.

Obrigado também vai paraDaniela Brozzoni, Sarah Cox, e outros para revisão pré-publicação.

Definições

O que é Camada 2?

Muitas vezes, o termo "Camada 2" é definido amplamente, a ponto de até mesmo uma entidade semelhante a um banco (por exemplo, Líquido) poder ser definida como uma Camada 2. Para os propósitos deste artigo, adotaremos uma definição estrita: uma Camada 2 (L2) é um sistema denominado Bitcoin, com o objetivo de permitir que o BTC seja transacionado com mais frequência do que o número de transações on-chain com outras partes. De tal forma que:

1. Ninguém é capaz de roubar fundos de forma lucrativa no sistema, levando em consideração as punições e custos dentro do sistema. Custos e punições fora do sistema, como perda de reputação, consequências legais, etc., não são considerados em nossa definição.
2. (Preferencial) Os verdadeiros donos dos fundos podem unilateralmente retirar seus fundos, menos as taxas de transação, sem a cooperação de terceiros.

A primeira opção é necessária porque queremos que nossos sistemas de Camada 2 sejam capazes de representar quantidades e transações de valor tão pequeno que não podem ser representadas on-chain. Por exemplo, no Lightning, os HTLCs podem ter um valor muito pequeno para ser representado on-chain. Nessa circunstância, o valor do HTLC é adicionado à taxa de transação da transação de compromisso. Enquanto um nó de Lightning pode "roubar" um HTLC poeira fechando um canal no momento certo, fazê-lo é mais caro¹do que o HTLC vale, tornando o roubo não lucrativo.

Dito isso, a retirada unilateral é sempre nosso objetivo de design principal.²

Com esta definição, coisas como o Lightning são considerados sistemas L2. No entanto, sistemas como Liquid, Cashu e Fedimint não são L2, porque outra parte ou outras partes têm controle sobre seus fundos. Esquemas de validação do lado do cliente como RGB também não são L2s nesta definição, porque não são capazes de transacionar BTC de forma confiável. Finalmente, @RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39">Statechains não consegue passar no teste, porque a entidade Statechain pode roubar fundos se não seguir o protocolo.

O que são Covenants?

... e por que os sistemas L2 mais escaláveis precisam deles?

No script do Bitcoin, os convênios são mecanismos pelos quais a maneira como um txout pode ser gasto é restrita antecipadamente, de modo que a forma das transações usadas para gastar esse txout seja pré-definida ou de outra forma restrita de uma forma que não seja puramente limitada a assinaturas. Sistemas L2 que compartilham UTXOs entre várias partes precisam de convênios porque precisam de maneiras de restringir como o UTXO pode ser gasto para implementar as regras e incentivos do protocolo L2.

Pactos Recursivos

Um pacto recursivo é um pacto com a propriedade de que as regras que restringem como um UTXO pode ser gasto podem ser aplicadas de forma recursiva, aos UTXOs filhos da transação de gasto indefinidamente. Pactos recursivos têm há muito tempo tem sido considerado indesejável por algunsporque eles podem sobrecarregar moedas indefinidamente. Ou pelo menos, indefinidamente sem a permissão de um terceiro, como um governo.

Metas

O Lightning é o atual sistema 'melhor da categoria' Camada 2 disponível. No entanto, ele possui limitações. A saber:

1. Escalando - O Lightning atualmente requer pelo menos uma UTXO por usuário final.³
2. Liquidez - O Lightning requer que os fundos sejam amarrados em canais.
3. Interatividade - O Lightning requer que os destinatários dos pagamentos estejam online para recebê-los de forma confiável.

Ao avaliar sistemas de Camada 2, nosso objetivo será melhorar essas limitações-chave, idealmente sem adicionar novas limitações.

Limites de Escalonamento do Lightning

O que significa "um UTXO por usuário final" na prática? Como os canais Lightning podem operar indefinidamente, uma forma de ver isso é perguntar quantos novos canais podem ser criados por ano⁴. Criar uma saída de taproot tem um custo marginal de 43vB; se a criação do canal for amortizada, com muitos canais criados em uma única transação, as demais sobrecargas da transação podem ser tornadas negligíveis e um número bastante grande de canais pode ser aberto por ano para integrar novos usuários. Por exemplo, suponha que 90% da capacidade do bloco fosse usada para abrir novos canais do Lightning de taproot:

Estima-se que cerca de metade da população global possui um smartphone, 4,3 bilhões de pessoas. Portanto, podemos realmente embarcar uma porcentagem significativa de toda a população que provavelmente será capaz de utilizar um canal Lightning por ano.

No entanto, os canais não duram para sempre. De vez em quando, os usuários desejarão trocar de carteiras, aumentar ou diminuir a capacidade do canal, etc. O método mais eficiente para alterar a capacidade de um canal é por meio deemenda, implementado principalmente emCarteira Phoenix.

Assim como a abertura do canal, a emenda também pode ser feita de forma amortizada para melhorar a eficiência, com várias operações de emenda compartilhando uma única transação para reduzir o número de entradas e saídas necessárias para adicionar e remover fundos⁵. Assim, o espaço de bloco delta necessário por splice de usuários, assumindo o uso de musig, é a saída taproot 43vB mais o

57.5vB chave de caminho de gasto taproot, totalizando 100.5vB. Se assumirmos novamente uma utilização de espaço de bloco de 90%, obtemos:

Finalmente, observe como a troca de canais Lightning entre carteiras pode ser feita em uma única transação, confiando na próxima carteira para assinar uma transação de compromisso após os fundos terem sido enviados para o endereço de compromisso, ou com suporte próximo de encerramento cooperativo-para-nova-canal em ambas as implementações de carteira.

Certamente, existem casos de uso concorrentes para o Bitcoin além dos canais Lightning, e como isso se traduzirá em taxas é difícil de saber. Mas esses números nos dão uma ideia aproximada que sugere que, com a tecnologia atual, é pelo menos tecnicamente possível suportar centenas de milhões de usuários autônomos do Lightning.

Visão geral da Camada 2

De acordo com nossa definição de sistemas L2, existem dois principais padrões de design sendo discutidos na comunidade de desenvolvimento do Bitcoin:

1. Canais
2. Virtual UTXOs

No padrão do canal, do qual o Lightning é o principal exemplo, o protocolo avança trocando transações pré-assinadas entre as partes que poderiam ser mineradas, mas não estão no 'caminho feliz'. Essas transações pré-assinadas dividem um UTXO entre as partes; as transações ocorrem mudando repetidamente o saldo desse split, com novas transações pré-assinadas. Como haverá muitas transações válidas diferentes possíveis gastando o mesmo UTXO, algum mecanismo de incentivo é necessário para garantir que a transação correta seja a que realmente é minerada.

No padrão de design Virtual UTXO (V-UTXO), do qual Ark é o exemplo mais proeminente, os V-UTXOs são criados por meio de convenants ou acordo multi-parte, por meio da criação de transações que poderiam ser mineradas para retirar unilateralmente os fundos V-UTXO, colocando-os na cadeia, mas não estão no 'caminho feliz'. Nesse aspecto, os V-UTXOs são semelhantes aos canais. Mas, ao contrário dos canais, os esquemas V-UTXO realizam transações gastando os próprios V-UTXOs, em (conceitualmente) um único⁶transação pré-assinada.

O padrão de design do “caminho feliz” é o uso de um caminho de script de “todas as partes concordam”, como um N-of-N multisig; o taproot é projetado especificamente para esse conceito, permitindo que o caminho da chave seja um N-of-N multisig via musig. Supondo que todas as partes concordem, o caminho feliz permite que as moedas sejam gastas de forma eficiente (e privada).

Curiosamente, uma vez que as UTXOs virtuais são “reais” em muitos sentidos, é bastante fácil construir canais em cima das UTXOs virtuais simplesmente criando UTXOs virtuais que, se minerados, levariam à criação das UTXOs necessárias para os canais. Nesse sentido, os esquemas de UTXO virtuais são um

camada ligeiramente inferior às canais.

Relâmpago

O status quo, implementado em produção como a Camada 2, com base principalmente no padrões BOLT. Lightning é uma combinação de várias coisas, incluindo canais Lightning e HTLCs, a rede de roteamento P2P, roteamento de cebola, padrões de fatura, etc. Notavelmente, Lightning não é um sistema de consenso, então diferentes elementos do 'sistema Lightning' não precisam ser adotados da mesma maneira por todos os usuários. Para fins deste artigo, quando dizemos 'Lightning', usaremos no sentido amplo, incluindo atualizações facilmente previsíveis para o (típico) protocolo(s) Lightning atualmente amplamente utilizados.

Como discutido acima, a característica chave do Lightning é o seu limite de escalabilidade para o usuário final, devido à necessidade de ter pelo menos uma UTXO por usuário. Dito isso, para o elemento de roteamento "core" do Lightning - os nós públicos do Lightning que roteiam a grande maioria das transações - esses limites de escalabilidade não são muito preocupantes, pois o Lightning funciona muito bem se houver muito mais usuários finais do que nós de roteamento, porque cada canal público usado para o roteamento de pagamento pode facilmente suportar um grande número de transações por segundo. É por isso que muitos sistemas futuros de L2 também esperam participar da rede Lightning. Também vemos isso em como sistemas existentes não-quite-L2 como Cashu dependem muito da rede Lightning para serem realmente úteis: o uso primário do Cashu provavelmente é enviar e receber pagamentos do Lightning.

Canais não interativos

Esta construção melhora os canais Lightning ao usar o OP_CTV para reduzir os requisitos de interatividade. No entanto, como não melhora o limite de escalonamento de 1-UTXO-por-usuário, não discutiremos mais sobre isso.

Canais de Fábricas

Aqui temos várias partes negociando um único endereço de multisig n-de-n, juntamente com uma transação gastando esse endereço de multisig para criar n diferentes UTXOs dividindo os fundos. Esses UTXOs, por sua vez, são usados para canais de pagamento. Os canais podem ser usados com a mesma segurança como se tivessem sido abertos diretamente on-chain, porque no caso de o estado do canal precisar ser colocado on-chain, a transação dividida pode ser minerada. Isso potencialmente economiza espaço on-chain quando os canais são fechados, já que as n partes podem - em teoria - fechar cooperativamente todos os nn canais de uma vez só.

Como as fábricas de canal estão negociando UTXOs que podem ser minerados, mas não se espera que sejam realmente minerados no caminho feliz, elas são um exemplo muito primitivo de V-UTXOs.

As fábricas de canais por si só não exigem nenhum soft-fork para serem possíveis. No entanto, as fábricas de canais simples descritas acima são provavelmente impraticáveis além de um pequeno número de partes devido à coordenação necessária para realmente alcançar um benefício de escala. Assim, propostas de convênios como OP_Evictou CTV (por meio de árvores txout) tem como objetivo permitir resultados mais refinados em que as partes individuais possam ser forçadas em cadeia, sem forçar todos em cadeia de uma vez.

Eltoo/LN-Simetria

Como Eltoo é um nome terrivelmente confuso, a partir de agora usaremos apenas o nome atualizado LN-Symmetry.

Enquanto os canais Poon-Dryja incentivam o estado correto a ser publicado on-chain punindo estados incorretos, o LN-Symmetry permite que estados incorretos sejam atualizados com uma transação adicional. Isso tem a vantagem de simplificar os canais do Lightning, eliminando a complexidade das penalidades. No entanto, é provável que isso seja uma desvantagem em cenários não confiáveis, já que as penalidades são indiscutivelmente necessárias para desencorajar a fraude.

LN-Symmetry precisa de um garfo suave para habilitarSIGHASH_ANYPREVOUT, que é necessário para permitir que transações de estado reutilizem outras transações de estado durante as atualizações.

Por si só, o LN-Symmetry não oferece melhorias de dimensionamento nos canais convencionais do Lightning. Mas defensores argumentaramque torna coisas como fábricas de canais mais fáceis de implementar.

Ark

Ark adota uma nova abordagem para dimensionamento de transações: UTXOs virtuais totalmente transferíveis (V-UTXOs), que podem ser mesclados e divididos atomicamente⁷transações off-chain. No Ark, um coordenador central, o Provedor de Serviços Ark (ASP), fornece V-UTXOs para usuários com tempo de vida definido, por exemplo, 4 semanas. Esses períodos são conhecidos como rodadas. Esses V-UTXOs são criados por meio de pool txouts, um por rodada, por meio de algum tipo de mecanismo, como CTV, para permitir que uma única txout on-chain se comprometa com uma árvore de V-UTXOs. A expiração da rodada é como o Ark obtém uma vantagem de escalabilidade: no final de uma rodada, o pool txout é desbloqueado, permitindo que o ASP o gaste unilateralmente com uma única assinatura em uma pequena transação. Devido ao tempo de expiração da rodada, os próprios V-UTXOs expiram quando os pool txouts que os criam expiram: os usuários que possuem um V-UTXO devem gastar esse V-UTXO antes que o tempo de expiração do pool txout seja atingido ou colocá-lo na cadeia (saque unilateral).

Para transacionar V-UTXOs entre as partes, o coordenador Ark co-assina transações que gastam um ou mais V-UTXOs, de modo que as transações só são válidas se um ou mais outros V-UTXOs forem criados em uma rodada diferente. Em combinação com alguns timeouts cuidadosos - consulte a documentação Ark para obter todos os detalhes - essa dependência é o que torna o gasto de V-UTXOs sem confiança: os V-UTXOs não podem ser reivindicados na cadeia, a menos que novos V-UTXOs sejam criados em uma transação de pool diferente. Existem algumas maneiras potenciais de implementar essa dependência. Mas os detalhes exatos não são relevantes para os fins deste artigo.

Observe como isso significa que um determinado ASP terá muitas rodadas ativas diferentes acontecendo ao mesmo tempo. Novas rodadas são frequentemente criadas para permitir a transferência de recursos em rodadas existentes. Mas as rodadas existentes se sobrepõem às novas rodadas, pois geralmente expiram em algum momento após novas rodadas, e novas rodadas de pool são criadas.

Economia Ark

Quando um V-UTXO é gasto, o ASP deve fornecer BTC correspondente em uma nova saída de transação de pool representando uma nova rodada. Mas eles não podem recuperar o valor do V-UTXO gasto até que a rodada expire. Assim, a economia de gastos de V-UTXO tem um custo de valor-tempo do dinheiro, devido à liquidez que o ASP deve fornecer.

Especificamente, o custo é incorrido quando o V-UTXO é gasto. Embora o V-UTXO não seja gasto, ele representa um UTXO potencial muito real que poderia ser colocado em cadeia para retirar unilateralmente os fundos; o usuário é o proprietário desses fundos. No entanto, para gastar o V-UTXO, o ASP deve criar um novo pool txout, usando fundos que o ASP obtém em outro lugar, enquanto os fundos no V-UTXO gasto não estão disponíveis para o ASP até que o tempo de expiração seja atingido.

Assim, gastar um V-UTXO requer um empréstimo de curto prazo, emprestando fundos para cobrir o intervalo de tempo entre agora e quando a rodada expirar. Isso significa que o custo de liquidez para gastar um V-UTXO realmente diminui à medida que o V-UTXO envelhece e o tempo de expiração se aproxima, eventualmente - teoricamente - chegando a zero quando a rodada finalmente expirar.

Por fim, lembre-se de que o custo de gastar um V-UTXO está relacionado ao tamanho total do V-UTXO gasto. Não ao valor pago ao destinatário. Isso significa que as carteiras destinadas a transações diretas de V-UTXOs (em oposição à gestão de um único V-UTXO para fins, por exemplo, de um canal baseado em V-UTXO Lighting), têm que fazer compensações na forma como dividem os fundos em V-UTXOs. Um único V-UTXO minimiza o custo de saque unilateral, ao mesmo tempo que maximiza as taxas de transação baseadas em liquidez; dividir os fundos em muitos V-UTXOs faz o oposto. Isso é completamente diferente da economia do Bitcoin on-chain ou das transações do Lightning.

Qual é esse custo de liquidez? No momento em que escrevo, a carteira Lightning Phoenix cobra uma taxa de 1% para reservar liquidez do canal por 1 ano; na pior das hipóteses, Phoenix teria que amarrar seus fundos por 1 ano. No entanto, isso pressupõe que a liquidez não seja usada. É bem possível que o custo de capital para Phoenix seja de fato maior, e eles estão assumindo que o cliente médio usa sua liquidez recebida em menos de um ano. Phoenix também ganha dinheiro com taxas de transação, potencialmente subsidiando a liquidez do canal. Finalmente, Phoenix pode não ser rentável!

A taxa de Letra do Tesouro dos EUA nos dá outra estimativa. No momento da redação, a taxa de Letra do Tesouro de 3 meses está em torno de 5% ao ano. Como há um argumento de que essa taxa está inflada devido ao dólar americano ser inflacionário, vamos supor que o custo de liquidez para fundos denominados em BTC seja de 3% ao ano para nossa análise.

Se o intervalo da rodada for de 4 semanas, isso significa que uma transação começaria com um custo de liquidez de

eventualmente declinando para zero. Supondo que o usuário tente mover seus fundos para uma nova rodada duas semanas antes do vencimento da rodada, o usuário está pagando cerca de 1,5% ao ano em custos de liquidez para alcançar a auto-custódia de seus fundos. Por outro lado, se o usuário esperar até o último momento.⁸ , o custo poderia ser quase zero, com o risco de perder o tempo de expiração.

Os usuários podem não ver isso como um custo trivial. E este custo pressupõe que os custos fixos de cada rodada tenham se tornado insignificantes através da amortização das taxas de transação e outros custos ao longo de um grande número de participantes.

E se os custos fixos não forem tão insignificantes? Suponha que o ASP tenha 1000 usuários e as transações de pool sejam criadas em média uma vez por hora. Ao longo de um período de 4 semanas, isso representa 672 transações na cadeia. O que significa que, apenas para manter seus fundos, os usuários do ASP coletivamente têm que pagar por quase a mesma quantidade de transações que os usuários! Provavelmente seria mais barato para eles todos abrirem seus próprios canais Lightning, mesmo que o ASP exija que eles esperem uma hora inteira para uma confirmação.

Inicializando Ark

Um novo ASP com poucos usuários enfrenta um dilema: ou as rodadas ASP acontecem com pouca frequência, e os usuários têm que esperar muito tempo para que a rodada proposta reúna V-UTXOs suficientes para alcançar um dimensionamento útil e redução da taxa de transação. Ou as transações do pool ASP acontecem com frequência, com altas taxas de transação pagas por usuário. Como mostramos na seção anterior, pode levar muitos usuários para amortizar rodadas frequentes e seus txouts de pool subjacentes.

Porque as rodadas expiram, esse problema é contínuo, ainda pior do que o enfrentado pelos canais Lightning: pelo menos um canal Lightning pode continuar a ser útil indefinidamente, permitindo que um canal seja aberto agora e amortizado gradualmente ao longo de muitos meses. Em segundo lugar, porque as rodadas expiram, há menos flexibilidade quanto a quando criar as novas txouts que respaldam essas rodadas: se as taxas forem altas por uma semana ou duas, os usuários cujas txouts de pool estão expirando não têm escolha a não ser (coletivamente) pagar essas altas taxas para manter a custódia sobre seus fundos. Com os canais Lightning, há muito mais flexibilidade quanto a quando realmente abrir um canal.

Enquanto os autores do Ark inicialmente imaginavam um cenário muito otimista onde novas rodadas a cada poucos segundos, a inicial inicialização provavelmente terá que acontecer com casos de uso que podem esperar várias horas para uma transação Ark confirmar, se as taxas de transação não forem subsidiadas.

Interatividade

O Ark não custodial é um protocolo altamente interativo: como seus V-UTXOs expiram, você tem prazos rígidos para interagir com seu ASP, caso contrário, o ASP pode optar por pegar seus fundos. Essa interatividade também não pode ser terceirizada: enquanto o Lightning temtorres de vigia que desencorajam as contrapartes de tentar roubá-lo – mesmo que seu canal não esteja online – os proprietários de moedas da Arca devem usar suas próprias chaves privadas para atualizar fundos sem confiança. A coisa mais próxima possível em Ark de torres de vigia seria assinar transações permitindo que uma torre de vigia retire unilateralmente seus fundos on-chain até o tempo de expiração, o que tem um custo significativo de taxa de transação.

Considere o que acontece com um V-UTXO se o proprietário ficar offline: após o término do round, o ASP precisa recuperar os fundos para obter sua liquidez de volta para os próximos rounds. Se um proprietário de V-UTXO ficar offline, colocar esse V-UTXO on-chain tem custos significativos de transação, pois o ASP agora precisa recuperar fundos em vários níveis da árvore de V-UTXO. O ASP pode recriar os V-UTXOs não gastos em um novo round. Mas isso não é confiável do ponto de vista dos proprietários de V-UTXO, pois eles não podem gastar esses V-UTXOs sem obter dados.⁹do ASP. O ASP também pode simplesmente registrar V-UTXOs não gastos como saldo custodiado. Ou talvez até mesmo ter uma política de apreensão dos fundos!

Pessoalmente, suspeito que, dada a alta custo de auto-guarda em Ark, muitos usuários escolherão ASPs com uma política de rolar os fundos para uma nova rodada e simplesmente aceitar o potencial de fraude no final de cada rodada. Isso é mais barato do que mover proativamente seus fundos cedo o suficiente para garantir a segurança no caso de, por exemplo, falharem em ligar o telefone a tempo de mover os fundos para uma nova rodada.

Ark Avançado

Pode ser viável reduzir os requisitos de liquidez da Ark por meio de covenants mais avançados, se for típico que a liquidez seja usada em parte de uma rodada. Por exemplo, vamos supor que 50% do valor total de V-UTXO em um txout de pool tenha sido gasto. Se o ASP pudesse resgatar apenas essa parte do pool txout da rodada, eles poderiam recuperar a liquidez mais rapidamente, reduzindo os custos gerais de liquidez. Embora nenhuma proposta concreta sobre como fazer isso tenha sido publicada, certamente parece que isso deveria ser possível com convênios suficientemente avançados™. Muito provavelmente através de algum tipo de soft-fork de revival de script que adiciona muitos opcodes úteis de uma só vez.

Da mesma forma, através de pactos Sufficiently Advanced™, toda a estrutura da árvore txout poderia ser substituída por algum tipo de esquema de retirada contínua, potencialmente oferecendo economia de espaço. Vamos abordar isso em uma seção posterior, já que essa técnica pode ser potencialmente útil para outros esquemas.

A questão da custódia no final da rodada é outro caso em que os convênios Sufficiently Advanced™ poderiam resolver um problema: um convênio, em particular, um convênio de prova ZK, poderia forçar o ASP a recriar todos os V-UTXO's não gastos na próxima rodada, removendo o problema da custódia revertendo para eles no final de uma rodada. Embora provavelmente não seja possível tornar isso sem confiança, pois o usuário provavelmente precisará de alguns dados do ASP para gastar seu V-UTXO na nova rodada, poderia impedir o ASP de obter ganhos financeiros com fraudes contra usuários offline.

Pagamento de Taxa On-Chain em Retirada Unilateral

Similar ao Lightning, a economia de pagamento de taxa on-chain e o valor real de um V-UTXO após as taxas determinam se o uso do Ark atende à nossa definição de um L2 através de saque unilateral, ou fraude que não beneficia a ASP. Vamos discutir os detalhes disso mais adiante quando discutirmos o padrão de design da árvore de txout.

Rollups de validade

Uma grande classe de construções laterais, geralmente propostas para usar várias formas de tecnologia de prova de conhecimento zero (ZK) para impor as regras da cadeia. A tecnologia à prova de ZK é a diferença crítica entre a tecnologia de acumulação de validade e outras formas de sidechain: se o esquema à prova de ZK funcionar, a validade das transações pode ser garantida pela matemática, em vez de confiar em terceiros. O aspecto de "conhecimento zero" de uma prova ZK não é realmente um requisito neste caso de uso: tudo bem se a prova "vazar" informações sobre o que está provando. Acontece que a maioria dos esquemas matemáticos para essa classe de prova são provas de conhecimento zero.

Do ponto de vista do Bitcoin, um esquema de rollup de validade requer um pacto, pois queremos ser capazes de criar UTXO's para o esquema que só podem ser gastos se as regras do esquema forem seguidas. Não se trata necessariamente de um processo descentralizado. Muitos esquemas de acumulação de validade são, na verdade, totalmente centralizados; A prova de rollup está provando que o sequenciador centralizado de transações seguiu as regras para uma determinada sequência de transações.

Quanto a que aliança... A tecnologia Zero-Knowledge Proof ainda é um campo muito novo, com avanços ainda sendo feitos com frequência. Portanto, é altamente improvável que vejamos quaisquer opcodes adicionados ao Bitcoin que validem diretamente quaisquer esquemas específicos à prova de ZK. Em vez disso, é geralmente aceito que esquemas específicos usariam opcodes mais gerais, em particular OP_CAT, para validar provas de ZK por meio de scripts. Por exemplo StarkWare É campanhapara ter o OP_CAT adotado.

Pacotes cumulativos de validade é um tópico potencial tão grande, com tantos projetos de baixa substância/alto hype, que não vamos discuti-lo mais além de apontar quais opcodes potencialmente tornam essa classe de design viável.

BitVM

Falando de forma muito geral, o BitVM é uma forma de construir um canal de relâmpago entre duas partes de modo que as regras do canal de relâmpago sejam aplicadas por uma prova de conhecimento zero. Como na verdade não precisa de convênios para ser implementado no Bitcoin hoje e porque não pode ser usado diretamente para criar um sistema L2 que ultrapasse o limite de 1-UTXO-por-usuário, não vamos discuti-lo mais.

Canais Hierárquicos

Canais Hierárquicos¹⁰visa tornar a redimensionamento de canal rápido e barato: "Canais hierárquicos fazem pela capacidade do canal o que a LN faz pelo bitcoin". No entanto, eles ainda não excedem fundamentalmente o limite de 1 UTXO por usuário. Eles também não exigem nenhuma alteração no protocolo do Bitcoin de qualquer forma. Portanto, não vamos discuti-los mais. Seus defensores devem simplesmente implementá-los! Eles não precisam da nossa permissão.

CoinPool

CoinPool permite que vários usuários compartilhem um único UTXO, transfiram fundos entre diferentes usuários e retirem unilateralmente. A proposta do documento CoinPool requer três novas características softfork, SIGHASH_ANYPREVOUT, um SIGHASH_GROUP permitindo que uma assinatura se aplique apenas a UTXOs específicos, e um OP_MerkleSub para validar a remoção de ramos específicos de uma árvore de Merkle; este último também poderia ser realizado com OP_CAT.

No momento, o desenvolvimento do CoinPool parece ter estagnado, com o último compromisso com o site de especificações sendo há dois anos.

Rede Enigma

Enquanto eu fui solicitado a cobrir a Engima Network, parece haver uma falta de documentação sobre o que a proposta realmente é. Bitfinex’spostagem no blog faz muitas reivindicações; o página do MIT está vazio. Como a postagem no blog não deixa claro o que exatamente está acontecendo, não iremos discutir mais sobre isso.

Considerações do Mempool

A política atual do mempool no Bitcoin Core não é ideal para sistemas L2. Aqui vamos abordar alguns dos principais desafios que eles enfrentam e possíveis melhorias.

Fixação de Transação

Em última análise, uma exploração econômica, ataques de fixação de transação, referem-se a uma variedade de situações em que alguém pode intencionalmente (ou inadvertidamentetornam difícil conseguir que uma transação desejada seja minerada devido à transmissão anterior de uma transação conflitante que não é minerada. Isso é uma exploração econômica, porque em uma situação real de bloqueio de transação, existe uma transação desejável que os mineradores lucrariam se a minerarem; a transação de bloqueio conflitante não é minerada em um período razoável de tempo, se é que é minerada.

O exemplo mais simples de pinning vem do fato de que sem full-RBF, a substituição de transação pode ser desativada. Assim, podemos ter uma transação de baixa taxa de comissão, com a substituição desativada, que não será minerada, mas não pode ser substituída. Essencialmente, 100% do poder de hash resolveu esse problema habilitando o full-RBF e, no momento da escrita deste texto, o full-RBF deve estar habilitado por padrão na próxima versão do Bitcoin Core (após o fork).11 anos de esforço!).

Isso deixa a Regra #3 do BIP-125 fixando, o único problema de fixação restante que é relevante para protocolos L2 de vários participantes e não corrigido no Bitcoin Core. Para referência, a Regra #3 do BIP-125 afirma o seguinte:

Uma transação de substituição é necessária para pagar a taxa absoluta mais alta (não

maior que a soma das taxas pagas por todas as transações que estão sendo substituídas.

Esta regra pode ser explorada através da transmissão de uma grande e baixa taxa de taxa de fixação de transações gastando a(s) saída(s) relevante(s) para o protocolo multipartido (alternativamente, um grupo de transações). Como a transação tem uma taxa baixa, ela não será minerada em tempo hábil, se é que alguma vez. No entanto, como tem uma taxa total alta, substituí-la por uma transação diferente é antieconômica.

Regra nº 3 a fixação é bastante facilmente corrigida através desubstituir por taxa de taxae esta solução funciona em todas as situações. Infelizmente, não está claro se RBFR será adotado pelo Core em um futuro próximo, já que eles gastaram uma quantidade substancial de esforço em uma solução parcial inferior.Transações TRUC/V3.

Pagamento de Taxas: RBF, CPFP, SIGHASH_ANYONECANPAY, Âncoras e Patrocínio

Uma vez que as taxas de taxa são imprevisíveis, pagar de forma confiável e econômica em situações em que as transações são pré-assinadas é difícil. O padrão-ouro para o pagamento de taxas é usar o RBF, começando com uma estimativa inicial de "bola baixa" e substituindo a transação por versões de taxas mais altas, conforme necessário, até que ela seja minerada. Por exemplo, o software de calendário OpenTimestamps usa o RBF dessa maneira há anos, e o LND adicionou suporte para prazo ciente RBF na v0.18.

A RBF é o padrão-ouro para pagamento de taxas porque é a mais eficiente em quase todos os bloqueios¹¹situações: as transações de substituição não precisam de entradas ou saídas extras, em relação ao que seria necessário se a taxa correta tivesse sido adivinhada na primeira tentativa.

A eficiência é importante, porque as ineficiências no pagamento de taxas fazem com que pagamento de taxa fora de banda uma fonte lucrativa de receita para grandes mineradoras; Mineradores menores e descentralizados não podem lucrar com pagamentos de taxas fora da banda devido à impraticabilidade e inutilidade de pagar a um pequeno minerador para obter uma transação confirmada. O pagamento de taxas fora de banda também parece convidar a problemas de AML/KYC: atualmente, a maioria dos sistemas de pagamento de taxas fora de banda realmente disponíveis agora exigem algum tipo de processo AML/KYC para fazer um pagamento de taxa, com a notável exceção do mempool.space acelerador, que, no momento da escrita (agosto de 2024), aceita Lightning sem precisar de uma conta.

Para fazer uso do RBF diretamente em situações com transações pré-assinadas, você precisa pré-assinar variantes de taxas cobrindo toda a gama de taxas potenciais. Embora isso seja bastante viável em muitos casos, pois o número de variantes necessárias geralmente é pequeno¹², até agora o protocolo Lightning de produção - e outros protocolos propostos - optaram por usar Child-Pays-For-Parent (CPFP), geralmente por meio de saídas âncora.

A ideia por trás de uma saída de âncora é adicionar uma ou mais saídas a uma transação com um valor mínimo ou zero, com a intenção de pagar taxas via CPFP gastando essas saída(s) em transações secundárias. Isso, é claro, é muito ineficiente quando aplicado a protocolos como o LN, que possuem transações pequenas na cadeia, quaseduplicando o tamanho total de uma transação de compromisso LN usando saída de âncora efêmera. Seria menos preocupante quando aplicados protocolos que utilizam transações maiores, como qualquer coisa que use OP_CAT para implementar convenants.

Um problema menos óbvio com as saídas de âncora é a necessidade de manter UTXOs adicionais para pagar taxas. Em uma aplicação típica de "cliente", isso pode ser um fardo geral significativo, pois sem as saídas de âncora muitas vezes não há necessidade de manter mais de um UTXO. De fato, é provável que algumas carteiras Lightning focadas no consumidor existentes sejam vulneráveis a roubo pelo lado remoto do canal em ambientes de alta taxa devido à incapacidade de pagar taxas.

SIGHASH_ANYONECANPAY pode ser usado para pagamento de taxas em alguns casos, permitindo que entradas adicionais sejam adicionadas às transações assinadas; SIGHASH_SINGLE permite que as saídas também sejam adicionadas. O Lightning usa isso para transações HTLC. No momento, essa prática pode ser vulnerável à fixação de transações se não for tratada com cuidado¹³, como um atacante poderia adicionar um grande número de entradas e/ou saídas a uma transação para criar um pin de taxa alta/baixa. O RBFR resolve esse problema; a abordagem usada em transações TRUC/V3 não é capaz de resolver esse problema. Esse estilo de pagamento de taxa não é tão eficiente quanto o RBF. Mas pode ser mais eficiente do que saídas âncora.

Finalmente, houve uma variedade de propostas de garfo suave para adicionar um patrocínio de taxasistema para o protocolo Bitcoin. Isso permitiria que as transações declarassem dependências de outras transações, de modo que a transação patrocinadora só pudesse ser minerada se a transação patrocinada também fosse minerada (provavelmente no mesmo bloco). Isso poderia ser muito mais eficiente do que um CPFP tradicional, já que a transação patrocinadora poderia declarar essa dependência usando significativamente menos vbytes do que o tamanho de uma entrada de transação.

Ciclo de Reposição

O Ataque de Ciclismo de Substituição¹⁴ aproveita a substituição da transação para tentar substituir uma transação L2 desejada por tempo suficiente para obter uma transação indesejada minerada. Essencialmente, os ataques de ciclo de substituição são, para o atacante, uma alternativa às técnicas de fixação de transações, na medida em que visam impedir que uma transação desejada e honesta seja minerada por tempo suficiente para permitir que uma transação indesejada e desonesta seja minerada. Ao contrário dos ataques de fixação de transações, um ataque de ciclagem de substituição não pode acontecer por acidente.

O exemplo canônico é contra um Contrato Bloqueado por Tempo e Hashed (HTLC). Embora seja fácil pensar em um HTLC como sendo um contrato para permitir uma transação a ser gasta através da revelação de uma pré-imagem, ou através de um tempo limite. Na realidade, devido às limitações de script do Bitcoin, um HTLC permite que uma transação sempre seja gasta através da revelação de uma pré-imagem e, em seguida, após um tempo limite, adicionalmente através do mecanismo de tempo limite.

A substituição da ciclagem aproveita isso usando a pré-imagem após o tempo limite para substituir a transação que tenta resgatar a saída HLTC por meio do mecanismo de tempo limite sem que a vítima aprenda a pré-imagem. Um ataque de ciclagem de substituição bem-sucedido faz isso tempo suficiente para que o HTLC de um canal diferente expire.

Um desafio principal na exploração lucrativa do ciclo de substituição é que cada rodada de substituição custa dinheiro. Uma implementação do Lightning awareness de prazos gastará taxas mais altas ao tentar gastar a saída HTLC expirada antes do vencimento da próxima saída HTLC, que por sua vez expira. Em segundo lugar, qualquer pessoa pode derrotar o ataque simplesmente rebroadcastando a transação substituída¹⁵uma vez que o ciclo de substituição estiver concluído.

Assim como o pinning de transações, a substituição cíclica também é uma exploração econômica em relação aos mineradores. No final de cada ciclo de substituição, existe uma transação que foi removida dos mempools, mas que ainda é totalmente válida e poderia ser minerada se os mineradores ainda a tivessem em seus mempools.

Padrões de Recursos e Garfos Suaves

Agora que demos uma visão geral da variedade de sistemas L2 dependentes de alianças e desafios de mempool, vamos tentar destilar essas informações para um conjunto de recursos de garfo suave notáveis (principalmente novos opcodes) e padrões de design que esses sistemas L2 compartilham. Para propostas de garfo suave, também discutiremos os riscos técnicos específicos da proposta e desafios de implantar cada proposta.

OP_Expire

Vamos começar por aqui. OP_Expire foi proposto¹⁶como uma maneira simples de eliminar o ataque de ciclagem de substituição, corrigindo o problema na fonte: o fato de que os HTLCs podem ser gastos de duas maneiras diferentes ao mesmo tempo. No contexto dos sistemas L2, isso é relevante para qualquer coisa que use um mecanismo semelhante a HTLC e possivelmente outros casos de uso. OP_Expire tornaria possível que uma saída de transação fosse inutilizável após um determinado momento, permitindo que as condições de gasto do HTLC fossem um verdadeiro OU exclusivo em vez de um "OU de programadores".

Um soft-fork OP_Expire real provavelmente consistiria em duas características, semelhante ao modo como o OP_CheckLockTimeVerifyeOP_CheckSequenceVerifyos opcodes são divididos em duas partes:

1. Um campo de altura de expiração para transações, muito provavelmente implementado no anexo de taproot.
2. Um código de operação OP_Expire que verifica se a altura de expiração está definida para pelo menos a altura desejada.

Embora o OP_Expire em si mal se qualifique como um convênio, parece ser útil para muitos sistemas de Camada 2 dependentes de convênios. No entanto, pode não ser útil o suficiente, dado que a substituição cíclica também pode ser mitigada pela retransmissão altruísta.¹⁵

Um desafio muito notável ao implantar e usar OP_Expire são as reorganizações: a comunidade técnica do Bitcoin, começando com Satoshi¹⁷tentou garantir que o protocolo de consenso do Bitcoin seja projetado de forma que, após uma reorganização profunda, transações previamente mineradas possam ser mineradas em novos blocos. Esse princípio de design tenta evitar o cenário de pesadelo de um grande número de moedas confirmadas se tornando permanentemente inválidas - e, portanto, as pessoas que dependem dessas moedas perdendo dinheiro - se uma falha de consenso levar a uma grande reorganização.

No caso de uma grande reorganização, as transações que usam a expiração podem se tornar inmináveis devido à sua altura de expiração ser atingida. A OP_Expire proposta, propõe mitiGate esta questão tratando as saídas de transações de expiração de forma semelhante às transações coinbase, também tornando-as impagáveis para ~100 blocos.

Uma barreira significativa para implantar a expiração da transação é chegar a um consenso sobre se essa compensação é aceitável ou mesmo necessária. Os tipos de transações em que OP_Expire seria útil já envolvem tempos de espera relativamente longos em que os fundos do usuário estão congelados. Adicionar ainda mais tempo a esses tempos de espera não é desejável. Além disso, as transações de gastos duplos sempre foram outra maneira de invalidar moedas após uma reorganização: com o aumento do uso de RBF e o uso proposto de saídas de âncora sem chave, a expiração da transação faria uma diferença significativa?

SIGHASH_ANYPREVOUT

BIP-118propõe dois novos modos de hash de assinatura, ambos dos quais não se comprometem com o UTXO específico sendo gasto. SIGHASH_ANYPREVOUT, que (essencialmente) se compromete com o scriptPubKey em vez disso, e SIGHASH_ANYPREVOUTANYSCRIPT, que permite qualquer script. Como discutido acima, isso foi originalmente proposto para uso pelo LN-Symmetry para evitar a necessidade de assinar separadamente cada estado de canal anterior que possa precisar de reação.

SIGHASH_ANYPREVOUT também é potencialmente útil em casos em que queremos usar variantes de taxa de taxa RBF pré-assinadas em conjunto com transações pré-assinadas, uma vez que o fato de que a assinatura não depende mais de um txid específico evita umexplosão combinatória de variantes fee-rateNo entanto, a proposta atual do BIP-118 não aborda esse caso de uso e pode ser incompatível com ele devido ao fato de que o SIGHASH_ANYPREVOUT também é proposto para comprometer o valor do UTXO.

Uma objeção inicial a SIGHASH_ANYPREVOUT era a ideia de que as carteiras teriam problemas ao usá-las de maneiras inadequadas. O problema é que, uma vez que uma única assinatura SIGHASH_ANYPREVOUT tenha sido publicada, ela pode ser usada para gastar qualquer txout com o script especificado. Assim, se uma segunda saída com o mesmo script é criada acidentalmente, SIGHASH_ANYPREVOUT permite um ataque de repetição trivial para roubar essas moedas. No entanto, como existem tantas outras armas de pé inerentes às carteiras e implementações L2, essa preocupação parece ter desaparecido.

No momento, a comunidade técnica em geral parece razoavelmente positiva sobre a implementação do BIP-118. No entanto, como discutido acima em nossa discussão sobre LN-Symmetry, há um debate sobre se seu principal caso de uso — LN-Symmetry — é realmente uma boa ideia.

OP_CheckTemplateVerify

Nossa primeira proposta de opcode específico do convênio, OP_CheckTemplateVerify - ou "CTV" como é comumente referido - tem como objetivo criar um opcode de convênio muito específico e restrito, fazendo exatamente uma coisa: hash da transação de gasto de uma maneira especificada que não se compromete com os UTXOs de entrada e verificando o resumo resultante contra o elemento superior da pilha. Isso permite que a transação de gasto seja limitada antecipadamente, sem possibilitar restrições verdadeiras de convênio recursivo.

Por que covênios recursivos não são possíveis em CTV? Porque as funções de hash: o CTV verifica a transação de gastos em relação a um hash de modelo, e não há nenhuma maneira¹⁸de criar um modelo contendo um CTV com um hash de si mesmo.

Dito isso, essa não é necessariamente uma limitação real: você pode facilmente hash uma cadeia de hashes de modelo CTV para uma profundidade de dezenas de milhões de transações em apenas alguns segundos em um computador moderno. Com timelocks de nSequence relativoe o tamanho limitado do bloco realmente chegando ao fim de tal cadeia poderia facilmente levar milhares de anos.

A proposta atual da CTV em BIP-119tem apenas um modo de hash, conhecido como DefaultCheckTemplateVerifyHash, que essencialmente se compromete com todos os aspectos da transação de gasto no hash do modelo. Do ponto de vista prático, isso significa que em muitas circunstâncias o único mecanismo disponível para pagamento de taxas será CPFP. Como mencionado acima, isso é um problema potencial devido a tornar o pagamento de taxas fora de banda uma economia não trivial nos casos em que as transações que usam CTV são pequenas.

É justo dizer que CTV tem o maior suporte entre a comunidade técnica de qualquer proposta de opcode de aliança devido à sua simplicidade relativa e ampla gama de casos de uso.

LNHANCE

Uma proposta para implementar o CTV é combiná-lo com mais dois opcodes, OP_CheckSigFromStack (Verify) e OP_InternalKey. O problema é que, no momento da escrita, a documentação naquele pull-req e os BIPs associados simplesmente não são suficientes para argumentar a favor ou contra essa proposta. Os BIPs estão completamente carentes de qualquer racional para o que se espera que os opcodes façam em exemplos do mundo real, e muito menos em scripts de exemplo detalhados.

Embora os autores provavelmente tenham boas razões para sua proposta, cabe a eles explicar essas razões e justificá-las adequadamente. Assim, não discutiremos isso mais.

OP_TXHASH

Similar ao CTV, esta proposta alcança uma funcionalidade de contrato não-recursivo por meio de hash de dados da transação de gastos. Ao contrário do CTV, a proposta TXHASH fornece um mecanismo de 'seleção de campo', permitindo flexibilidade na forma como a transação de gastos é limitada. Essa flexibilidade alcança dois objetivos principais:

1. Permitindo a adição de taxas a uma transação sem quebrar um protocolo de várias transações.
2. Protocolos multiusuários onde os usuários apenas restringem suas próprias entradas e saídas.

O principal problema com o OP_TXHASH é que o mecanismo seletor de campo adiciona bastante complexidade, tornando a revisão e os testes desafiadores em comparação com a proposta CTV muito mais simples. No momento, simplesmente não houve muita análise de design sobre quão benéfico o mecanismo seletor de campo realmente seria, ou como exatamente seria usado. Portanto, não vamos discuti-lo mais.

OP_CAT

O operador de concatenação, que concatena os dois elementos superiores da pilha e empurra o resultado concatenado de volta para a pilha. O Bitcoin originalmente foi enviado com OP_CAT ativado. Mas Satoshiremovido silenciosamente em 2010, provavelmente devido ao fato de que a implementação inicial era vulnerável a ataques DoS devido à falta de restrições no tamanho do elemento de script resultante. Considere o seguinte script:

DUP CAT DUP CAT...

Sem restrição de tamanho do elemento, cada iteração DUP CAT dobra o tamanho do elemento superior da pilha, eventualmente usando toda a memória disponível.

A concatenação é suficiente para implementar muitos tipos de acordos, incluindo acordos recursivos, fazendo o seguinte:

1. Monte uma transação parcial, sem dados de testemunha, na pilha com uma ou mais invocações de OP_CAT (e qualquer lógica específica do convênio necessária).
2. Validar que a transação na pilha corresponde à transação de gastos.

Acontece que, por abusando da matemática das assinaturas Schnorr, é possível realizar a segunda etapa com OP_CheckSig via assinaturas cuidadosamente construídas. No entanto, é mais provável que um soft-fork OP_CAT seja combinado com OP_CheckSigFromStack, permitindo que a segunda etapa seja realizada validando que uma assinatura na pilha é uma assinatura válida para a transação¹⁹e então reutilizando essa mesma assinatura com OP_CheckSig para validar que a transação de gastos corresponde.²⁰

O fato de que só precisamos montar a transação sem os dados da testemunha é um ponto-chave: o contrato só precisa validar o que a transação faz - suas entradas e saídas - e não os dados da testemunha (se houver) que realmente a tornam válida.

Limites de tamanho de script do módulo, a combinação de OP_CAT e OP_CheckSigFromStack é suficiente para construir muitos tipos de convênios, incluindo convênios recursivos. Em comparação com soluções mais eficientes como CTV, é mais caro. Mas a diferença de custo é menor do que você esperaria!

Grosso modo, usar OP_CAT para fazer isso requer que toda a parte não testemunhal da transação de gastos seja colocada na pilha por meio da testemunha. Para casos de uso típicos de CTV, como árvores txout, a transação de gastos não terá dados de testemunhas. Como o espaço da testemunha é descontado em 75%, isso aumenta nossa taxa de transação efetiva para a transação infantil em apenas 25%. Nada mau!

OP_CAT é muito poderoso?

Este é provavelmente o maior obstáculo político e técnico para implementar o OP_CAT: é muito difícil prever quais serão os casos de uso possíveis com o OP_CAT. E uma vez que o "gato" está fora da bolsa, é muito difícil colocá-lo de volta.

Um ótimo exemplo é como OP_CAT é alegado ser suficiente para permitir razoavelmente eficiente e seguro Verificação STARK a ser implementada no script do Bitcoin. Uma forte argumentação contra o OP_CAT é que esses casos de uso podem não ser totalmente bons para os usuários do Bitcoin.

A criação de Valor Minerável Centralizador prejudicial é um problema potencial chave, denominado de 'MEV que é mau' (MEVil)por Matt Corallo. Em resumo, MEVil é qualquer circunstância em que grandes mineradores/pools podem extrair valor adicional ao empregar estratégias sofisticadas de mineração de transações - além de simplesmente maximizar as taxas totais - que são impraticáveis para os menores mineradores/pools adotarem. A complexidade potencial de instrumentos financeiros que poderiam ser criados com OP_CAT torna muito difícil descartar o MEVil. O MEVil significativo já apareceu no Bitcoin a partir de protocolos de leilão de tokens; felizmente, esse caso específico foi derrotado por meio da adoção de full-RBF.

Além do potencial do MEVil, existem muitos outros casos de uso OP_CAT concretos que são potencialmente prejudiciais. Por exemplo, a proposta de Drivechains foi revisado aqui, e é amplamente considerado prejudicial ao Bitcoin. É acredita-se ser possívelpara implementar o Drivechain com OP_CAT. Outro exemplo são as propostas de token, como Ativos Taproot. Embora seja impossível, em geral, impedi-los de serem implementados comvalidação do lado do cliente, existem propostas para implementá-las com OP_CAT de maneiras que são potencialmente muito mais atraentes para os usuários finais, enquanto também usam muito mais espaço em bloco, o que poderia potencialmente superar as transações de Bitcoin “legítimas”. Esses casos de uso também podem levantar questões legais devido à frequência com que os protocolos de token são usados para fraudes financeiras.

Hashing Incremental

Para covenants, o OP_CAT seria usado principalmente para concatenar dados e, em seguida, hash. Outra maneira de alcançar esse mesmo objetivo é com algum tipo de opcode de hash incremental que pega um estado intermediário SHA256 de algum tipo e hash mais dados nele; O próprio SHA256 opera em blocos de 64 bytes. Existem muitos designs possíveis para opcodes de hash incremental.

Uma decisão de design importante é se expor ou não os bytes do estado intermediário real na pilha em algum tipo de forma canônica, ou representá-los em algum novo tipo de item de pilha opaco cujo valor real dos bytes não pode ser manipulado diretamente. SHA256 é especificado para um vetor de inicialização particular e fixo, e parece ser desconhecido se as propriedades criptográficas do SHA256 são verdadeiras se estados intermediários/vetores de inicialização arbitrários forem permitidos.

Claro, uma vez que o hash incremental pode fazer praticamente o que o OP_CAT pode fazer, apenas de forma mais eficiente, ele compartilha todas as preocupações sobre o OP_CAT ser muito poderoso.

Ressurreição do Script

OP_CAT foi um dos 15 códigos de operação que Satoshi desativou. Além de restaurar OP_CAT, Rusty Russell está propondo²¹para essencialmente restaurar o script do Bitcoin para a 'Visão Original de Satoshi' ao reabilitar a maioria desses opcodes, adicionando limites de DoS e potencialmente adicionando mais alguns no mesmo garfo suave. Em particular, um OP_CheckSigFromStack é provável.

Embora OP_CAT por si só permita covenants (recursivos), uma completa "revitalização do script" tornaria possíveis covenants mais sofisticados - e muito mais fáceis de implementar - pois partes da transação de gastos poderiam ser manipuladas diretamente. Por exemplo, você poderia imaginar um script de covenant que usa opcodes aritméticos para garantir que o valor total dos txouts na transação siga alguma propriedade desejada.

Novamente, o ressurgimento do script levanta todas as mesmas preocupações, e mais, sobre ser excessivamente poderoso que apenas o OP_CAT faz.

Simplicidade

Similar ao Script Revival, Simplicity é relevante para L2's e acordos, tornando possível fazer qualquer coisa. Ao contrário do Script Revival, um soft-fork de Simplicity adicionaria uma linguagem de programação completamente nova ao sistema de script do Bitcoin, baseada em nove operadores primitivos conhecidos como combinadores.

Na prática, Simplicidade é tanto muito simples, quanto não simples de todo. Os combinadores primitivos são tão ridiculamente de baixo nível que operações básicas como a adição têm de ser implementadas laboriosamente do zero; a Simplicidade pura seria excepcionalmente verbosa na prática. Assim, qualquer uso real da Simplicidade faria uso de um sistema de substituição de código, semelhante a chamadas de funções de biblioteca, conhecido como jatos. Isso representa um problema prático/político: como decidir em quais garfos implementar? Provavelmente, os garfos seriam implementados em C++, como qualquer outro código de operação, exigindo um garfo suave para cada novo garfo.

OP_FancyTreeManipulationStuff

Há uma grande variedade de códigos de operação relativamente especializados que foram propostos para manipulação de árvores de forma eficiente em um espaço para propostas dependentes de covenants da Camada 2. Por exemplo, os Coinpools propuseram ambosTAPLEAF_UPDATE_VERIFYeOP_MERKLESUB, ambos manipulam árvores de taproot de maneiras necessárias para a proposta Coinpools e o MATTa proposta propôs um opcode OP_CheckContractVerify que, basicamente, verifica declarações sobre árvores de merkle.

Para os fins deste artigo, não precisamos entrar em detalhes sobre cada uma dessas muitas propostas. Em vez disso, podemos falar sobre elas como um grupo: todas são propostas relativamente específicas para casos de uso que tornam uma classe de Camada 2 possível, idealmente sem efeitos colaterais indesejados. Todas têm a vantagem da eficiência: todas usam menos espaço de bloco do que alcançar o mesmo objetivo com opcode genéricos como a manipulação OP_CAT. Mas todas têm a desvantagem de adicionar complexidade ao sistema de script, para um caso de uso potencialmente de nicho.

A mesma dinâmica aconteceria se o Bitcoin adotasse o sistema de script Simplicity. O equivalente aos opcodes em Simplicity é adicionar um jato para um padrão comumente usado. Novamente, implementar jatos para operações específicas de casos de uso, como manipulação de árvores, tem prós e contras semelhantes à implementação de opcodes complexos para operações específicas de casos de uso.

Pools de Fundos

Todos os sistemas L2 que tentam ter vários usuários compartilhando um único UTXO podem ser considerados como algum tipo de pool de fundos multiusuário, com os usuários tendo posse de algum tipo de direito de saque. Potencialmente, também haverá um mecanismo para adicionar fundos ao pool (além de criar o pool com fundos pré-atribuídos).

Para que um pool de fundos seja útil, ele deve ter algum tipo de "estado de dados de compartilhamento" associado a ele: como o valor do txout é dividido? Se o pool de fundos evoluir ao longo do tempo, esse estado também deve mudar à medida que os fundos são adicionados ou removidos do pool. Como estamos construindo em Bitcoin, adicionar ou remover fundos do pool inevitavelmente envolverá gastar o UTXO que o pool controla.

Lembre-se de que o próprio sistema de consenso do Bitcoin é baseado na validação de mudanças de estado: as transações provam por meio de suas testemunhas que as mudanças no estado do conjunto UTXO são válidas; a prova de trabalho nos permite chegar a um consenso sobre qual conjunto de transações está correto. Isso significa que os pools de fundos também serão baseados na validação de mudanças de estado: estamos provando para cada nó Bitcoin que as regras do pool de fundos estão sendo seguidas em cada mudança de estado.

Mas há outro aspecto chave para os pools de fundos L2 sem confiança: quando o estado do pool de fundos muda, o sistema deve publicar intrinsecamente dados suficientes para que os usuários que participam do pool de fundos possam recuperar seus fundos. Se não fizermos isso, então nosso sistema falha em fornecer retirada unilateral, sem a cooperação de terceiros. Muitos esquemas baseados em rollup falham aqui: eles sofrem com falhas de disponibilidade de dados, onde o usuário não consegue recuperar seus fundos se os coordenadores de terceiros ficarem offline, porque eles não têm como obter os dados necessários para eles construírem uma transação de recuperação de fundos válida.

Com essas restrições em mente, em quais estruturas de dados os fundos de pools serão baseados? Inevitavelmente, todas elas são algum tipo de árvore. Especificamente, algum tipo de árvore de Merkel. Elas precisam ser uma árvore, porque essa é praticamente a única estrutura de dados escalável em ciência da computação; elas precisam ser merkelizadas, porque essa é basicamente a única maneira razoável de se comprometer criptograficamente com o estado da árvore. Por fim, as atualizações na árvore inevitavelmente serão publicadas na blockchain do Bitcoin, porque essa é a meio de publicaçãotodos os usuários da Camada 2 compartilham, e o único que podemos forçar os usuários a publicar para mover moedas. E porque qualquer implementação de contrato vai precisar de partes da árvore para validar que as regras do contrato estão sendo seguidas.

Então, com a teoria de alto nível fora do caminho, como isso realmente se traduz em scripts e transações de Bitcoin?

Transações Individuais Pré-Assinadas

O caso degenerado de uma árvore, com exatamente uma folha. Aqui, o estado do nosso pool de fundos pode mudar, grosso modo, apenas uma vez. Por exemplo, um canal padrão do Lightning se enquadra nessa categoria e, uma vez aberto, só pode ser fechado. Os dados que são publicados quando um canal é fechado são a própria transação, que é informação suficiente para a contraparte no canal aprender o txid dos dados do blockchain e recuperar seus fundos gastando-os.

A única "aliança" necessária aqui é a aliança mais básica: a transação pré-assinada.

Árvores TxOut

O próximo padrão de design mais complexo que vemos em pools de fundos é a árvore txout. Ark é um exemplo notável. Aqui, o pool de fundos pode ser dividido gastando o UTXO raiz em uma árvore de transações pré-definidas, aplicadas com convênios simples como transações pré-assinadas ou CTV, dividindo o valor desse UTXO em quantidades cada vez menores até que sejam alcançados nós folha que podem ser gastos pelos proprietários legítimos.

É importante reconhecer que o objetivo da árvore txout é dar aos usuários opções de como recuperar seus fundos, e essas opções têm um custo: uma árvore txout sempre será uma maneira mais cara de dividir um pool de fundos, devolvendo-os aos seus proprietários, do que simplesmente dividir o UTXO em uma única transação. Cada camada na árvore adiciona custo devido aos bytes usados nos txouts e txins necessários para criar essa camada.

Então, que tipo de opções um txout tree pode fornecer? Novamente, Ark é um ótimo exemplo: não queremos que o resgate na cadeia de um único V-UTXO exija que todos os V-UTXOs sejam colocados na cadeia. Ao usar uma árvore, o resgate pode dividir a árvore em partes menores até que o V-UTXO desejado seja colocado na cadeia.

Assim como no caso de transação individual pré-assinada, as informações sendo publicadas são as próprias transações, o que informa a carteira de outros usuários como gastar seus fundos, se necessário.

A escalabilidade das árvores de txout tem economias interessantes de escala. O custo para colocar a primeira V-UTXO na cadeia, em um pool de fundos com n V-UTXOs, é aproximadamente log2(n)log2(n) vezes mais caro do que uma única transação, pois log2(n) níveis de transações divididas devem ser colocados na cadeia. No entanto, uma vez que a primeira V-UTXO é colocada na cadeia, as V-UTXOs subsequentes se tornam mais baratas para resgatar na cadeia, porque outra pessoa já pagou o custo de obter as transações intermediárias mineradas.

Lembre-se de que o número total de elementos em uma árvore binária com

n leaves is 2n. Isso significa que para colocar todos os V-UTXOs na cadeia, o custo total para fazê-lo por meio de uma árvore de txout seria um pequeno múltiplo do custo total para fazê-lo em uma única transação. Surpreendentemente eficiente!

Ou talvez não... Se o tamanho total dos resgates do fundo for suficientemente alto, eles podem representar uma demanda não trivial no espaço total do bloco. O espaço do bloco é um sistema de oferta e demanda, então em algum momento as taxas aumentarão devido à alta demanda. No extremo, é bastante possível criar árvores txout tão grandes e profundas que realmente resgatar cada

V-UTXO na árvore é impossível.

Uma questão em aberto com árvores de txout é quem paga as taxas e como? Uma solução óbvia é usar saídas de âncora sem chave nas transações de folha e permitir que quem quiser que as transações de folha sejam mineradas pague as taxas via CPFP. Em alguns casos de uso, os próprios V-UTXOs podem ser gastos imediatamente após a criação, sem atraso CSV, para que os próprios V-UTXOs possam ser gastos para adicionar taxas via CPFP.

RBF é complexo de implementar devido à permissão: o local óbvio para cobrar taxas para RBF é o valor V-UTXO. Mas como garantir que apenas o proprietário tem a capacidade de assinar uma transação com taxa mais alta? Em muitas circunstâncias, não é óbvio como fazer isso de forma mais eficiente do que uma saída de âncora sem chave. No entanto, a falha em fazer isso apresenta desafios sérios para esquemas usados por carteiras de usuários finais, que podem não ter um UTXO para gastar para realizar um CPFP, se os próprios V-UTXOs não puderem ser gastos imediatamente.

Finalmente, é necessário pensar cuidadosamente nos incentivos existentes em sistemas de árvore de txout, levando em conta o pagamento de taxas. Por exemplo, em um sistema como o Ark, se um conjunto de V-UTXOs custar individualmente muito dinheiro para valer a pena serem levados a V-UTXOs on-chain, um coordenador desonesto poderia se recusar a permitir que esses V-UTXOs fossem resgatados off-chain e, em seguida, obter lucro roubando o valor desses V-UTXOs em uma única transação de UTXO assim que um tempo limite for atingido.

Se este for o caso, é discutível que tal sistema não atenda aos nossos critérios para ser um L2 para pequenos V-UTXOs.

Esquemas Baseados em Saldo

A máquina de estado de uma árvore de txout ainda é relativamente simples: ou o pool de fundos existe ou é gasto para criar dois ou mais pools de fundos menores. Com convenções mais avançadas, poderíamos tratar o pool de fundos como um saldo em evolução, com a capacidade de adicionar e subtrair fundos desse saldo.

Para fazer isso, precisamos implementar uma máquina de estado não trivial. Mas também precisamos do que é essencialmente uma base de dados partilhada. Por que? Porque o objetivo aqui é compartilhar um UTXO entre muitos proprietários diferentes. Finalmente, se realmente vamos obter uma melhoria de escalabilidade, devemos fazê-lo de uma forma que coloque o mínimo possível desses dados de propriedade na cadeia.

Esses requisitos naturalmente nos levam a algum tipo de estrutura de dados merkelizada em forma de árvore, como uma árvore de soma de merkle. Manipular essa estrutura de dados vai exigir algo como OP_CAT, algum tipo de opcode de verificação de prova de conhecimento zero, ou um opcode de manipulação de árvore específico de propósito.

Curiosamente, assim como nas árvores txout, você não pode fazer melhor do que a ordem log(n) enquanto mantém propriedades de segurança similares. Por quê? Vamos supor que tivéssemos um hipotético OP_ZKP que, através de algumas matemáticas avançadas, precisasse de apenas 32 bytes para provar qualquer declaração. Embora essa prova zk pudesse provar que a estrutura de dados merkelizada foi manipulada de acordo com as regras do sistema da camada 2, ela não forneceria os dados necessários para que o próximo usuário também faça uma mudança de estado. Isso não atende aos nossos critérios preferidos de permitir retirada incondicional: no máximo, um usuário poderia conseguir uma retirada incondicional. Mas nenhum outro usuário poderia fazê-lo.

Em contraste, se as partes modificadas da estrutura de dados merklizada forem publicadas via scriptsig do pacto — por exemplo, os dígests irmãos em uma árvore de Merkle — o próximo usuário tem dados suficientes para atualizar sua compreensão do estado do sistema e fazer uma retirada incondicional.

Uma possível maneira de contornar esse problema é se o pacto exigir prova de publicação em um meio de publicação diferente do que a cadeia do Bitcoin. No entanto, as garantias de segurança serão mais fracas do que é possível via Bitcoin.

Finalmente, observe como as árvores txout e uma abordagem baseada em equilíbrio podem ser combinadas. Se a estrutura de dados que está sendo manipulada for uma árvore txout, os fundos poderiam ser adicionados à árvore txout gastando a saída e adicionando novos fundos, com um script de convênio que valida que os fundos foram de fato adicionados à árvore txout. Da mesma forma, os fundos podem ser removidos por todos os mecanismos normalmente disponíveis para uma árvore txout. A Arca Avançada é um exemplo dessa classe de esquema.

Taxa de Falha de Dados

As L2s alcançam a escalabilidade adicionando um requisito de interatividade em situações adversárias. Em quase todos os casos, isso significa que as partes honestas no protocolo têm prazos para obter transações mineradas; se os prazos não forem cumpridos, os fundos podem ser roubados.

A capacidade máxima de bloco em todas as blockchains descentralizadas (e centralizadas) é limitada por restrições técnicas. No Bitcoin, o tamanho máximo do bloco é tal que o Bitcoin opera essencialmente na capacidade ~100% do tempo. Como a mineração de Bitcoin atua como um sistema de leilão, leiloando o espaço do bloco para o licitante mais alto, na prática isso significa que a taxa mínima para obter uma transação minerada aumenta e diminui à medida que a demanda aumenta e diminui.

A taxa de pagamento sempre influencia na economia e nos modos de falha da Camada 2. Por exemplo, no Lightning, os HTLCs de tamanho 'poeira' que são muito pequenos para serem resgatados de forma lucrativa na cadeia usam um modelo de segurança diferente dos HTLCs maiores. Embora o protocolo Lightning ainda não implemente corretamente isso, teoricamente esse limite deve ser dinâmico, baseado nas taxas de pagamento à medida que elas sobem e descem, idealmente até o ponto em que uma parte possa escolher se um HTLC existe ou não em uma determinada transação de compromisso com base na taxa de pagamento.

Uma variedade de ataques foram propostos onde essa situação é intencionalmente ativada no Lightning, como inundação e saque²²e o ataque de saída em massa²³. Como a capacidade da blockchain do Bitcoin é compartilhada entre todos os casos de uso, também são possíveis ataques entre diferentes sistemas L2: por exemplo, provocar uma saída em massa na Ark para lucrar com os canais Lightning.

L2 que compartilham UTXO entre vários usuários fazem com que esses problemas sejam potencialmente piores, pois a demanda máxima de espaço em bloco durante uma falha é proporcionalmente maior. Até o momento, nunca vimos falhas em grande escala no Lightning onde um grande número de canais precisou ser fechado de uma vez. Há um bom argumento de que devemos obter experiência operacional adicional com o Lightning e sua escala aproximada de 1-UTXO por usuário, antes de empurrar os limites ainda mais com esquemas de compartilhamento de UTXO.

Em segundo lugar, antes que novos esquemas de compartilhamento UTXO sejam amplamente adotados, uma pesquisa cuidadosa deve ser feita sobre a lucratividade potencial dos ataques durante a alta demanda por espaço de bloqueio. Por exemplo, em um sistema como o Ark, onde o ASP pode resgatar fundos usando muito menos espaço de bloqueio do que outras partes, pode ser o caso de que intencionalmente acionar altas taxas de taxa e, em seguida, apreender fundos que não podem ser retirados unilateralmente de forma lucrativa é uma fraude lucrativa, violando ambas as nossas condições para um verdadeiro sistema L2.

Limpeza de consenso

Há várias coisas que Satoshi errou no protocolo inicial do Bitcoin, em particular, ataques de DoS a scripts, o ataque timewarp e problemas com a árvore de merkle. Anteriormente, vários outros bugs de consenso já foram corrigidos com forks suaves, como a mudança para avaliar o nLockTime baseado em tempo em relação ao tempo médio passado, (tentativa de) corrigir o problema de txid duplicado, etc.

O soft-fork mais recente, taproot, teve um processo de implantação relativamente contencioso, levando bastante tempo para realmente ser implantado. Um argumento para fazer um soft-fork de limpeza de consenso primeiro, antes de habilitar quaisquer novos opcodes ou outros recursos para novos tipos de L2, é que aprenderíamos mais sobre como a comunidade em geral está disposta a implementar o que deveria ser um soft-fork relativamente incontroverso que sem dúvida beneficia a todos.

Testando Soft-Fork Dependente da Camada 2

Os desenvolvedores não precisam esperar que um garfo suave realmente aconteça para testar suas ideias. Uma abordagem particularmente sofisticada sendo usada pelos desenvolvedores do Ark emArca sem aliança é simular os convênios que eles precisam com transações pré-assinadas. Isso permite que eles testem as ideias da Ark com BTC real, na mainnet, com as mesmas características de confiança, como se espera que a Ark consiga com os covenants. A compensação é que a Arca sem convênio exige que todas as partes estejam online para assinar as transações pré-assinadas. Como o clArk trabalha com BTC real, ele pode até ser útil o suficiente para ser usado na produção para certas transferências de casos de uso que podem tolerar o trade-off de interatividade.

Uma abordagem mais simples é simplesmente fingir que certas partes não podem fazer as ações que os pactos impediriam. Por exemplo, se um protocolo proposto deseja usar o CTV para garantir que uma árvore de txout seja gasta em uma árvore de transações, cada uso do CTV pode ser substituído por um NOP ou CheckSig. Embora na realidade a árvore de txout não esteja sendo realmente aplicada, cada código que interage com a árvore e cada parte pode ser testada como se estivesse, e como NOP e CheckSig são permitidos em scripts padrão, o protocolo pode ser testado na mainnet com fundos reais.

Potenciais Garfos Suaves

Qual é o caminho a seguir? Aqui vamos traçar todos os principais esquemas L2 que analisamos, e quais soft-forks são úteis (U) ou necessários (R) para tornar esses esquemas L2 bem-sucedidos. Como discutido acima, OP_CAT (e, por extensão, Script Revival, que inclui OP_CAT), pode emular todos os outros soft-forks nesta lista — com exceção de OP_Expire e Fee Sponsorship — de modo que onde as necessidades de um projeto são mais eficientemente atendidas por algum outro soft-fork diretamente, não incluiremos OP_CAT.

Também vamos deixar de fora todos os códigos de operação de manipulação de árvore de Merkle propostos. Todos eles são muito específicos, muito específicos para casos de uso, para ter uma chance significativa de serem adotados neste momento. Na medida em que esses códigos de operação são úteis, implementar seus efeitos por meio de OP_CAT e / ou Script Revival é um caminho muito mais provável para adoção.

CTV é o claro vencedor aqui, seguido por SIGHASH_ANYPREVOUT (OP_Expire é útil para muitas coisas sendo uma correção de ciclagem de substituição, mas não essencial). CTV vence porque tantas coisas se encaixam no padrão de design de 'garantir que a transação de gastos corresponda a este modelo'; até mesmo construções OP_CAT podem fazer uso eficiente de CTV.

Ao contrário do OP_CAT, o CTV não parece aumentar muito o risco de consequências não intencionais além de incentivar pagamentos de taxas fora da banda em certos casos. Isso não é o ideal. Mas ninguém apresentou uma alternativa amplamente apoiada.

Minha recomendação pessoal: faça uma limpeza de consenso soft-fork, seguida por CTV.

Aviso Legal:

1. Este artigo é reimpresso de [ petertodd], Encaminhe o Título Original 'O roteiro do Ethereum está fora do caminho?', Todos os direitos autorais pertencem ao autor original [petertodd]. Se houver objeções a esta reprodução, entre em contato com oGate Aprenderequipe e eles lidarão com isso prontamente.

2. Isenção de Responsabilidade por Responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.

3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.