As carteiras on-chain conseguem uma correspondência aproximada de 1-1 entre transações: para cada transação econômica que um usuário realiza, é necessário aproximadamente uma transação de blockchain. As agregações, coinjoin, pagamentos de corte, etc. mudam um pouco essa afirmação. Mas é aproximadamente correta.

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 ocorrer em um único canal de Lighting, que por sua vez está ligado a uma única saída de transação não gasta (UTXO). Essencialmente, pegamos a dimensão 'tempo' - transações - e alcançamos uma escalabilidade significativa ao colapsar essa dimensão.

Mas criar mesmo um único UTXO por utilizador não é, possivelmente, suficientemente bom. Por isso, existem muitas propostas por aí para alcançar uma escalabilidade ainda maior, permitindo que vários utilizadores partilhem um único UTXO de forma auto-soberana. Novamente, colapsando outra dimensão de 'espaço' de escalabilidade - os utilizadores - num único UTXO.

O nosso objetivo aqui é fazer uma visão geral de todas estas propostas, descobrir que padrões técnicos elas partilham, descobrir que tipos de novos opcodes e outras atualizações de forquilha suave elas precisam para funcionar, e criar uma tabela de comparação de como todas as partes se encaixam. Ao longo do caminho, também iremos definir o que é realmente um protocolo L2, que tipo de escalabilidade a Lightning já é capaz, e compreender que melhorias precisamos de fazer às mempools para alcançar tudo isto.

Obrigado vai paraFulgur Venturespara patrocinar esta pesquisa. Eles não tiveram controle editorial sobre o conteúdo deste post 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 é a Camada 2?

Frequentemente, o termo "Camada 2" é definido de forma ampla, a ponto de até mesmo uma entidade semelhante a um banco (por exemplo, Liquid) poder ser definida como uma Camada 2. Para os fins deste artigo, adotaremos uma definição estrita: uma Camada 2 (L2) é um sistema denominado em 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 seja:

1. Ninguém é capaz de roubar fundos de forma lucrativa no sistema, tendo em conta as punições e custos dentro do sistema. Os custos e punições fora do sistema, como a perda de reputação, as consequências legais, etc., não são considerados na nossa definição.
2. (Preferido) Os verdadeiros proprietários dos fundos podem retirar unilateralmente os 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 L2 sejam capazes de representar quantidades e transações de valor tão pequeno que não podem ser representadas na cadeia. Por exemplo, no Lightning, HTLCs podem ter um valor muito pequeno para serem representados na cadeia. Nesse caso, o valor do HTLC é adicionado à taxa de transação da transação de compromisso. Embora um nó Lightning possa 'roubar' um HTLC poeira fechando um canal no momento certo, fazê-lo é mais caro.¹menor do que o valor do HTLC, tornando o roubo sem lucro.

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

Com esta definição, coisas como o Lightning são consideradas sistemas L2. No entanto, sistemas como o Liquid, Cashu e Fedimint não são L2, porque outra parte ou partes têm controle dos seus fundos. Esquemas de validação do lado do cliente, como o RGB, também não são L2s sob esta definição, porque não podem transacionar BTC de forma confiável. Por fim,@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39">Statechains não consegue passar, 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 delas?

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

Covenants Recursivos

Um pacto recursivo é um pacto com a propriedade de que as regras que limitam como um UTXO pode ser gasto podem ser aplicadas recursivamente, para UTXOs filho da transação de gasto indefinidamente. Os pactos recursivos têm...há muito tempo considerado indesejável por algunsporque podem encumbrir moedas indefinidamente. Ou, pelo menos, indefinidamente sem a permissão de uma terceira parte, como um governo.

Metas

O Lightning é o atual sistema de Camada 2 "melhor da classe" disponível. No entanto, ele tem limitações. Nomeadamente:

1. Dimensionamento - O Lightning atualmente requer pelo menos um UTXO por utilizador 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 maneira de olhar para isso é perguntar quantos novos canais podem ser criados por ano⁴. A criação de uma saída de raiz da torneira tem um custo marginal de 43vB; se a criação de canais for amortizada, com muitos canais criados em uma única transação, o outro overhead da transação pode ser tornado negligível e um número bastante grande de canais pode ser aberto por ano para integrar novos utilizadores. Por exemplo, suponha que 90% da capacidade do bloco fosse dedicada à abertura de novos canais de raiz da torneira Lightning:

Estima-se quecerca de metade da população global possui um smartphone, 4,3 bilhões de pessoas. Portanto, podemos, de fato, integrar 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. Em algumas ocasiões, os utilizadores vão querer mudar de carteira, aumentar ou diminuir a capacidade do canal, etc. O método mais eficiente para alterar a capacidade de um canal é através emenda, implementado de forma notável em Carteira Phoenix.

Assim como a abertura de canais, 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 demusig, é a saída taproot 43vB mais a camada 2,

57.5vB taproot keypath gasto, para um total de 100.5vB. Se assumirmos novamente um uso de espaço de bloco de 90%, obtemos:

Finalmente, note 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 serem enviados para o endereço de compromisso, ou com o suporte de fecho cooperativo-para-novo-canal em ambas as implementações de carteira.

Claro, 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 de que, com a tecnologia atual, é pelo menos tecnicamente possível suportar centenas de milhões de usuários autossuficientes do Lightning.

Visão geral da Camada 2

Sob a nossa definição de sistemas de Camada 2, existem dois principais padrões de design em discussão na comunidade de desenvolvimento do Bitcoin:

1. Canais
2. UTXOs virtuais

No padrão de 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 alterando 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 realmente minerada.

No padrão de design Virtual UTXO (V-UTXO), do qual Ark é o exemplo mais proeminente, os V-UTXOs são criados através de covenants ou acordos multi-party, através da criação de transações que poderiam ser mineradas para retirar unilateralmente os fundos V-UTXO ao colocá-los on-chain, mas não estão no “fluxo principal”. Nesse aspecto, os V-UTXOs são semelhantes aos canais. Mas ao contrário dos canais, os esquemas V-UTXO fazem transações gastando os próprios V-UTXOs, em (conceptualmente) um único⁶transação pré-assinada.

O padrão de design do "caminho feliz" é o uso de um caminho de script "todos concordam", como um multisig N-of-N; taproot é projetado especificamente para esse conceito, permitindo que o caminho da chave seja um multisig N-of-N 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 os UTXOs virtuais são "reais" em muitos sentidos, é bastante fácil construir canais em cima dos UTXOs virtuais simplesmente criando UTXOs virtuais que, se minerados, levariam à criação dos UTXOs necessários para os canais. Nesse sentido, os esquemas de UTXO virtual são uma forquilha.

camada ligeiramente inferior do que canais.

Relâmpago

O status quo, implementado em produção como a Rede Lightning, com base principalmente na 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(s) protocolo(s) Lightning atual (típico) que são amplamente utilizados.

Como discutido acima, a característica chave do Lightning é o seu limite de escalabilidade do usuário final, devido à necessidade de ter pelo menos um UTXO por usuário. Dito isto, para o elemento de roteamento "central" do Lightning - os nós públicos de Lightning que roteiam a grande maioria das transações - estes limites de escalabilidade não são uma grande preocupação, já que 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 pagamentos pode facilmente suportar um grande número de transações por segundo. É por isso também que tantos futuros sistemas L2 esperam participar também na rede Lightning. Também vemos isto na forma como os sistemas existentes que não são exatamente L2, como o Cashu, dependem fortemente da rede Lightning para serem realmente úteis: o uso principal do Cashu provavelmente é enviar e receber pagamentos Lightning.

Canais não interativos

Esta construção melhora os canais Lightning ao usar OP_CTV para reduzir os requisitos de interatividade. No entanto, como não melhora o limite de escala de 1-UTXO-por-utilizador, não iremos discuti-lo mais.

Fábricas de Canal

Aqui temos várias partes negociando um único endereço n-of-n multisig, juntamente com um gasto de transação que endereço multisig para criar n diferentes UTXO dividindo os fundos. Essas UTXOs, por sua vez, são usadas 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. Isto permite potencialmente poupar espaço na cadeia quando os canais são fechados, uma vez que as n partes podem, em teoria, encerrar cooperativamente todos os canais nn de uma só vez.

Uma vez que as fábricas de canal estão a negociar os UTXO's que poderiam ser minerados, mas não se espera que sejam realmente minerados no caminho feliz, 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 simples fábricas de canais descritas acima provavelmente são impraticáveis além de pequenos números de partes devido à coordenação necessária para realmente obter um benefício de escalabilidade. Assim, propostas de covenants como OP_Evictou CTV (através de árvores txout) têm como objetivo permitir resultados mais refinados, onde as partes individuais podem ser forçadas on-chain, sem forçar todos on-chain de uma só vez.

Eltoo/LN-Simetria

Uma vez que Eltoo é um nome terrivelmente confuso, apenas usaremos o nome atualizado LN-Symmetry no futuro.

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 Lightning, removendo a complexidade das penalidades. No entanto, é provável que esta seja uma desvantagem em cenários não fiáveis, uma vez que são indiscutivelmente necessárias sanções para desencorajar a fraude.

LN-Simetria precisa de uma forquilha suave para ativarSIGHASH_ANYPREVOUT, o que é necessário para permitir que transações de estado re-gastem outras transações de estado durante atualizações.

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

Ark

O Ark adota uma nova abordagem para escalonamento de transações: UTXOs virtuais totalmente transferíveis (V-UTXOs), que podem ser mesclados e divididos de forma atômica⁷ transações fora da cadeia. Na Ark, um coordenador central, o Ark Service Provider (ASP), fornece V-UTXOs para usuários com um tempo de vida definido, por exemplo, 4 semanas. Estes períodos são conhecidos como rounds. Estes V-UTXOs são criados através de txouts de piscina, um por rodada, através de algum tipo de mecanismo como CTV para permitir que um único txout on-chain se comprometa com uma árvore de V-UTXOs. A expiração da rodada é como a Ark alcança uma vantagem de escala: 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 txouts de pool 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 on-chain (retirada unilateral).

Para transacionar V-UTXOs entre partes, o coordenador da Arca coassina 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 tempos limite cuidadosos – veja os documentos da Arca para obter todos os detalhes – essa dependência é o que torna os gastos do V-UTXO sem confiança: os V-UTXO não podem ser reivindicados on-chain, a menos que novos V-UTXOs sejam criados em uma transação de pool diferente. Há algumas maneiras potenciais de realmente implementar essa dependência. Mas os detalhes exatos não são relevantes para os propósitos deste artigo.

Observe que isso significa que um determinado ASP terá muitas rodadas ativas diferentes acontecendo ao mesmo tempo. Novas rodadas são frequentemente criadas para permitir que fundos em rodadas existentes sejam transferidos. Mas as rodadas existentes se sobrepõem às novas rodadas, pois geralmente expiram algum tempo depois das novas rodadas e novas transações de pool serem criadas.

Economia Ark

Quando um V-UTXO é gasto, o ASP deve fornecer BTC correspondente em um novo txout 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 V-UTXO tem um custo de valor temporal do dinheiro, devido à liquidez que o ASP tem que 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 utilizador é 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, pedindo fundos para cobrir o intervalo de tempo entre agora e quando a rodada expira. Isso significa que o custo de liquidez para gastar um V-UTXO na verdade diminui à medida que o V-UTXO envelhece e o tempo de expiração se aproxima, eventualmente - em teoria - chegando a zero quando a rodada finalmente expira.

Finalmente, lembre-se de que o custo para gastar um V-UTXO está relacionado com o tamanho total do V-UTXO gasto. Não o montante pago ao destinatário. Isto significa que as carteiras destinadas a transacionar V-UTXOs diretamente (em oposição a gerir um V-UTXO para os fins de, por exemplo, um canal de iluminação baseado em V-UTXO), têm de fazer compromissos na forma como dividem os fundos em V-UTXOs. Um único V-UTXO minimiza o custo de levantamento unilateral, enquanto maximiza as taxas de transação baseadas na liquidez; a divisão dos fundos em muitos V-UTXOs faz o oposto. Isto é completamente diferente da economia do Bitcoin on-chain, ou transações Lightning.

Qual é o custo desta liquidez? No momento da escrita, a carteira Lightning Phoenix cobra uma taxa de 1% para reservar liquidez de canal por 1 ano; na pior das hipóteses, a Phoenix teria que amarrar seus fundos por 1 ano. No entanto, isso pressupõe que a liquidez não seja utilizada. É bastante possível que o custo de capital para a Phoenix seja, na verdade, mais alto, e eles estão assumindo que o cliente médio utiliza sua liquidez recebida em menos de um ano. A Phoenix também ganha dinheiro com taxas de transação, potencialmente subsidiando a liquidez do canal. Por fim, a Phoenix pode não ser lucrativa!

A taxa dos títulos do Tesouro dos EUA dá-nos outra estimativa. No momento da escrita, a taxa da Letra do Tesouro de 3 meses é de cerca de 5% ao ano. Como há um argumento de que essa taxa está inflacionada devido ao dólar americano ser inflacionário, assumiremos que o custo de liquidez para fundos denominados em BTC é de 3% ao ano para nossa análise.

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

eventualmente caindo para zero. Supondo que o usuário tente mover seus fundos para uma nova rodada duas semanas antes da expiração, o usuário está pagando cerca de 1,5% ao ano em custos de liquidez para alcançar a autoguarda 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 utilizadores podem não ver isto como um custo trivial. E este custo pressupõe que os custos fixos de cada ronda tenham sido tornados insignificantes pela 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 que as txouts da pool sejam criadas uma vez por hora, em média. Durante um período de 4 semanas, isso equivale a 672 transações on-chain. Isso significa que, apenas para manter seus fundos, os usuários do ASP coletivamente têm que pagar por quase o mesmo número de transações que os usuários! Provavelmente seria mais barato para eles abrirem seus próprios canais Lightning, mesmo que o ASP exija que eles esperem uma hora inteira para uma confirmação.

Inicializando o Ark

Um novo ASP com poucos utilizadores enfrenta um dilema: ou os ASP rounds acontecem raramente, e os utilizadores têm de esperar muito tempo pelo round proposto para reunir V-UTXOs suficientes para alcançar uma escalabilidade útil e redução de taxas de transação. Ou as transações do pool ASP acontecem frequentemente, com altas taxas de transação pagas por utilizador. Como mostrámos na secção anterior, pode ser necessário um grande número de utilizadores para amortizar rounds frequentes e os seus txouts de pool subjacentes.

Porque as rondas expiram, este problema é um 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 rondas expiram, há menos flexibilidade quanto à criação dos novos txouts que suportam estas rondas: se as taxas forem altas por uma semana ou duas, os utilizadores cujos txouts de pool estão a expirar não têm outra escolha senão (coletivamente) pagar essas taxas elevadas para manter a sua custódia sobre os seus fundos. Com os canais Lightning, há muito mais flexibilidade quanto à abertura real de um canal.

Embora os autores do Ark inicialmente tenham imaginado um cenário muito otimista onde novos blocos a cada poucos segundos, a inicialização inicial provavelmente terá que acontecer com casos de uso que possam esperar várias horas para que uma transação Ark seja confirmada, se as taxas de transação não forem subsidiadas.

Interatividade

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

Considere o que acontece a 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 fica offline, colocar esse V-UTXO na cadeia tem custos significativos de transação, pois o ASP agora precisa recuperar fundos em vários níveis da árvore 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 poderia simplesmente registrar V-UTXOs não gastos como saldo custodial. Ou talvez até mesmo ter uma política de apreensão dos fundos!

Pessoalmente, suspeito que, dado o custo não trivial da autocustódia na Ark, muitos usuários escolherão ASPs com uma política de rolar fundos para uma nova rodada e simplesmente aceitarão o potencial de fraude no final de cada rodada. Isso é mais barato do que movimentar proativamente seus fundos com antecedência suficiente para garantir segurança no caso de, por exemplo, eles não ligarem o telefone a tempo de sua carteira mover os fundos para uma nova rodada.

Ark Avançado

Pode ser viável reduzir os requisitos de liquidez da Ark através de pactos mais avançados, se for típico que a liquidez seja utilizada em parte de uma ronda. Por exemplo, vamos supor que 50% do valor total de V-UTXO em um pool txout tenha sido gasto. Se o ASP pudesse resgatar apenas essa parte do pool txout da rodada, poderia recuperar 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 pactos suficientemente avançados™. Muito provavelmente através de algum tipo de soft-fork de revival de script que adiciona muitos opcodes úteis ao mesmo tempo.

Da mesma forma, através dos convênios Sufficiently Advanced™, toda a estrutura da árvore txout poderia ser substituída por algum tipo de esquema de saque rotativo, potencialmente oferecendo economia de espaço. Vamos cobrir isso em uma seção posterior, pois essa técnica é potencialmente útil para outros esquemas.

A questão da custódia no final da rodada é outro caso em que os acordos Sufficiently Advanced™ poderiam resolver um problema: um acordo, em particular, um acordo de prova ZK, poderia forçar a ASP a recriar todos os V-UTXOs não gastos na próxima rodada, eliminando o problema da custódia reverter para eles no final de uma rodada. Embora provavelmente não seja possível tornar isso confiável, já que o usuário provavelmente precisará de alguns dados da ASP para gastar seu V-UTXO na nova rodada, isso poderia impedir que a ASP ganhasse financeiramente com fraudes contra usuários offline.

Pagamento de Taxa On-Chain em Retirada Unilateral

Semelhante ao Lightning, a economia de pagamento de taxas on-chain e o valor real de um V-UTXO após as taxas determinam se a utilização do Ark atende à nossa definição de L2 via retirada unilateral ou fraude que não beneficia o ASP. Discutiremos mais detalhadamente os detalhes disso quando discutirmos o padrão de design da árvore txout.

Rollups de Validade

Uma grande classe de construções semelhantes a sidechain, geralmente propostas para usar várias formas de tecnologia de prova de conhecimento zero (ZK) para impor as regras da cadeia. A tecnologia de prova de ZK é a diferença crítica entre a tecnologia de rollup de validade e outras formas de sidechain: se o esquema de prova de ZK funcionar, a validade das transações pode ser garantida por meio de matemática em vez de confiar em uma terceira parte. O aspecto de 'conhecimento zero' de uma prova de ZK na verdade não é um requisito neste caso de uso: está perfeitamente bem se a prova 'vazar' informações sobre o que está provando. Acontece apenas que a maioria dos esquemas matemáticos para essa classe de prova acontecem de serem provas de conhecimento zero.

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

Quanto ao que diz respeito ao pacto... A tecnologia de Prova de Zero-Conhecimento ainda é uma área muito nova, 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 de prova de conhecimento zero. Em vez disso, é geralmente aceito que esquemas específicos usariam opcodes mais gerais, em particular OP_CAT, para validar provas de conhecimento zero por meio de scripts. Por exemplo, StarkWare é campanhater o OP_CAT adotado.

Rolamentos de validade é um tópico de grande potencial, com tantos projetos de baixa substância / alta empolgação, que não discutiremos isso além de destacar quais opcodes potencialmente tornam essa classe de design viável.

BitVM

De uma forma muito grosseira, BitVM é uma maneira de construir um canal relâmpago entre duas partes de modo que as regras do canal 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 em dia, e porque não pode ser usado diretamente para criar um sistema L2 que escala além do limite de 1-UTXO por usuário, não iremos discuti-lo mais.

Canais Hierárquicos

Canais hierárquicos¹⁰ visa tornar o redimensionamento de canais rápido e barato: "Os canais hierárquicos fazem pela capacidade do canal o que o 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 Bitcoin de qualquer maneira. Portanto, não vamos discuti-los mais. Os seus proponentes deveriam simplesmente implementá-los! Eles não precisam da nossa permissão.

CoinPool

O 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 novos recursos de 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 merkle; este último poderia também ser realizado com OP_CAT.

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

Rede Enigma

Enquanto me pediram para cobrir a Rede Engima, parece haver uma falta de documentação sobre o que a proposta realmente é. postagem no blog faz muitas reivindicações; o página do MIT está vazio. Como a postagem do blog não deixa claro o que exatamente deveria estar acontecendo, não discutiremos mais.

Considerações da Mempool

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

Fixação de transações

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

O exemplo mais simples de fixação decorre do fato de que, sem o RBF completo, a substituição da transação pode ser desativada. Assim, podemos ter uma transação com taxa de baixa taxa, com substituição desativada, que não será minerada, mas não pode ser substituída. Essencialmente, 100% do poder de hash corrigiu esse problema ativando o RBF completo e, no momento da redação, o RBF completo deve ser ativado por padrão na próxima versão do Bitcoin Core (após...)11 anos de esforço!).

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

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

apenas taxa) do que a soma das taxas pagas por todas as transações que estão a ser substituídas.

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

Regra #3 o pinning é facilmente corrigido através detaxa de substituição por taxa, e esta correção funciona em todas as situações. Infelizmente, não está claro se a RBFR será adotada pelo Core num futuro próximo, pois eles gastaram uma quantidade substancial de esforço em uma solução parcial inferior, Transações TRUC/V3.

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

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

RBF é o padrão ouro para pagamento de taxas porque é o mais eficiente em termos de espaço em bloco na maioria dos casos¹¹ Situações: A(s) transação(ões) de substituição não necessita(m) de quaisquer entradas ou saídas adicionais, em relação ao que teria sido necessário se a taxa correta tivesse sido adivinhada na primeira tentativa.

A eficiência é importante, pois as ineficiências no pagamento de taxas tornampagamento de taxa fora de banda uma fonte lucrativa de receita para grandes mineradores; 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 atualmente disponíveis exigem algum tipo de processo AML/KYC para fazer um pagamento de taxa, com a notável exceção do acelerador mempool.space, que a partir de agosto de 2024, aceita Lightning sem uma conta.

Para utilizar o RBF diretamente em situações com transações pré-assinadas, é necessário pré-assinar variantes de taxa que cubram 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 A criança paga pelos pais (CPFP), geralmente através de saídas âncora.

A ideia por trás de uma saída â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 essa(s) saída(s) em transações secundárias. Isso, claro, é muito ineficiente quando aplicado a protocolos como o LN, que têm pequenas transações on-chain, quase duplicando o tamanho total de uma transação de compromisso LN usando uma saída de âncora efêmera. Seria menos preocupante quando aplicado a protocolos que fazem uso de 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 as taxas. Em um aplicativo típico de “cliente”, isso pode ser uma carga geral significativa, 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 existentes focadas no consumidor sejam vulneráveis a roubo pelo lado remoto do canal em ambientes de alta taxa devido à incapacidade de pagar as taxas.

SIGHASH_ANYONECANPAY pode ser usado para pagamento de taxa em alguns casos, permitindo que inputs adicionais sejam adicionados às transações assinadas; SIGHASH_SINGLE permite que outputs também sejam adicionados. Lightning usa isso para transações HTLC. No momento, essa prática pode ser vulnerável a transaction pinning 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 alta taxa de comissão/baixa taxa de comissão. O RBFR corrige esse problema; a abordagem usada em transações TRUC/V3 não é capaz de corrigir esse problema. Este estilo de pagamento de taxa não é tão eficiente quanto o RBF. Mas pode ser mais eficiente do que as saídas de âncora.

Finalmente, houve uma variedade de propostas de forquilha suave para adicionar um patrocínio de taxa sistema 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.

Substituição de Ciclismo

O Ataque de Ciclismo de Substituição¹⁴aproveita a substituição de transações para tentar substituir uma transação L2 desejada tempo suficiente para que uma indesejada seja minerada em seu lugar. Essencialmente, os ataques de ciclagem de substituição são, para o atacante, uma alternativa às técnicas de fixação de transações, pois têm como objetivo impedir que uma transação desejada e honesta seja minerada tempo suficiente para permitir que uma transação indesejada e desonesta seja minerada em seu lugar. Ao contrário dos ataques de fixação de transações, um ataque de ciclagem de substituição não pode ocorrer por acidente.

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

A substituição cíclica aproveita isso usando a pré-imagem após o tempo limite, para substituir a transação que tenta resgatar a saída HLTC via o mecanismo de tempo limite sem que a vítima aprenda a pré-imagem. Um ataque bem-sucedido de substituição cíclica faz isso por 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 ciclo de substituição custa dinheiro. Uma implementação do Lightning consciente de prazos gastará taxas cada vez 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 rebatendo 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 para os mineradores. No final de cada ciclo de substituição, há uma transação que foi removida dos mempools, mas é totalmente válida e poderia ser minerada se apenas os mineradores ainda a tivessem em seus mempools.

Padrões de Recursos e Forks Suaves

Agora que lhe demos uma visão geral da variedade de sistemas de Camada 2 dependentes de acordos existentes e dos desafios da mempool, vamos tentar resumir essa informação a um conjunto de recursos de soft fork notáveis (principalmente novos códigos de operação) e padrões de design que esses sistemas de Camada 2 compartilham. Para propostas de soft fork, também discutiremos os riscos técnicos e desafios específicos de cada proposta para a implantação.

OP_Expire

Vamos começar por aqui. OP_Expire foi proposto¹⁶ como uma maneira simples de eliminar o ataque de ciclo de substituição, corrigindo o problema na fonte: o fato de que os HTLC 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 ao HTLC, e possivelmente outros casos de uso. OP_Expire tornaria possível que uma saída de transação não pudesse ser gasta após um determinado momento, permitindo que as condições de gastos da HTLC fossem uma verdadeira OR exclusiva em vez de uma "OR de programadores".

Um soft-fork OP_Expire real provavelmente consistiria em duas características, semelhantes a como o OP_CheckLockTimeVerifyeOP_CheckSequenceVerifyos códigos de operação são compostos por duas partes:

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

Embora o OP_Expire por si só mal se qualifique como um pacto, parece ser útil para muitos sistemas de camada 2 dependentes de pactos. No entanto, pode não ser suficientemente útil, 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 tal forma que, após uma reorganização profunda, transações previamente mineradas possam ser mineradas em novos blocos. Este princípio de design tenta evitar o cenário do pesadelo de um grande número de moedas confirmadas tornando-se permanentemente inválidas — e, assim, as pessoas que dependem dessas moedas perdem dinheiro — se uma falha de consenso levar a uma grande reorganização.

No caso de uma grande reorganização, as transações que usam expiração podem se tornar impossíveis de minerar devido à altura de expiração ser alcançada. A proposta OP_Expire propõe mitigar esse problema tratando as saídas de transações que usam expiração de maneira semelhante às transações coinbase, tornando-as também impossíveis de gastar por cerca de 100 blocos.

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

SIGHASH_ANYPREVOUT

BIP-118propõe dois novos modos de hashing 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 pela LN-Symmetry para evitar a necessidade de assinar separadamente cada estado de canal anterior que possa precisar ser reagido.

SIGHASH_ANYPREVOUT também pode ser potencialmente útil em casos em que queremos usar variantes de taxa de comissão RBF pré-assinadas em conjunto com transações pré-assinadas, pois o fato de a assinatura não depender mais de um txid específico evita umexplosão combinatorial de variantes de taxa de comissãoNo 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 se comprometer com o valor do UTXO.

Uma objeção inicial ao SIGHASH_ANYPREVOUT era a ideia de que as carteiras se meteriam em problemas ao usá-lo 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 um segundo output com o mesmo script for criado acidentalmente, o SIGHASH_ANYPREVOUT permite um ataque de replay trivial para roubar essas moedas. No entanto, como existem tantos outros riscos inerentes às carteiras e implementações L2, essa preocupação parece ter desaparecido.

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

OP_CheckTemplateVerify

Nossa primeira proposta de opcode específico de 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: fazer o hash da transação de gasto de uma maneira especificada que não se comprometa com as UTXOs de entrada e verificar o digest resultante contra o elemento superior da pilha. Isso permite que a transação de gasto seja restrita antecipadamente, sem possibilitar restrições verdadeiras de convênio recursivo.

Por que não são possíveis acordos recursivos em CTV? Por causa das funções de hash: o CTV verifica a transação de gastos em relação a um hash de modelo e não há como¹⁸de criar um modelo contendo um CTV com um hash de si mesmo.

Dito isto, isso 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 sequência relativae o tamanho de bloco limitado realmente alcançando o fim de tal cadeia poderia facilmente levar milhares de anos.

A proposta CTV atual em BIP-119tem apenas um modo de hash, conhecido como DefaultCheckTemplateVerifyHash, que basicamente compromete todos os aspectos da transação de gastos 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, esse é um problema potencial devido a tornar o pagamento de taxas fora de banda uma economia de custos não trivial nos casos em que as transações usando CTV são pequenas.

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

LNHANCE

Uma proposta para implementar CTV é combiná-la com mais dois opcodes, OP_CheckSigFromStack(Verify) e OP_InternalKey. O problema é que, até o 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 carecem completamente de qualquer justificativa sobre o que se espera que os opcodes realmente façam em exemplos do mundo real, muito menos em scripts de exemplo detalhados.

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

OP_TXHASH

Similar ao CTV, esta proposta alcança uma funcionalidade de convênio não recursiva através do hash dos dados da transação de gasto. Ao contrário do CTV, a proposta TXHASH fornece um mecanismo de 'seletor de campo', permitindo flexibilidade na forma como a transação de gasto é restrita. Essa flexibilidade alcança dois objetivos principais:

1. Possibilitando a adição de taxas a uma transação sem quebrar um protocolo multi-tx.
2. Protocolos multiusuários onde os usuários apenas restringem suas próprias entradas e saídas.

O principal problema com OP_TXHASH é que o mecanismo de seletor de campo adiciona bastante complexidade, tornando a revisão e teste desafiadores em comparação com a proposta CTV muito mais simples. No momento, simplesmente não houve muita análise de design sobre o quão benéfico o mecanismo de seletor de campo seria na realidade, ou como exatamente seria usado. Assim, não discutiremos mais sobre isso.

OP_CAT

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

DUP CAT DUP CAT…

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

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

1. Montar 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 pacto 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 através de assinaturas cuidadosamente construídas. No entanto, é mais provável que uma forquilha suave OP_CAT seja combinada 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 depois reutilizando a mesma assinatura com o OP_CheckSig para validar que a transação de gastos corresponde.²⁰

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

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

Falando de forma simplificada, usar OP_CAT para isso requer que toda a parte não-testemunha da transação de gastos seja colocada na pilha por meio da testemunha. Para casos de uso CTV típicos, como árvores txout, a transação de gastos não terá nenhum dado de testemunha. Como o espaço de testemunha tem um desconto de 75%, isso aumenta nossa taxa efetiva de transação para a transação filha em apenas 25%. Nada mal!

O OP_CAT é Muito Poderoso?

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

Um ótimo exemplo é como OP_CAT é considerado suficiente para permitir eficiência e segurança razoavelmente Verificação STARK a ser implementada no script Bitcoin. Uma vez que os STARKs são capazes de provar declarações extremamente gerais, tornando possível implementar STARKs de forma eficiente tem ramificações significativas que vão além do escopo de sistemas L2, pois permitiria que muitos sistemas diferentes fossem construídos em cima do Bitcoin. Um argumento forte 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 potencial problema-chave, chamado de “MEV que é evIL” (MEVil)por Matt Corallo. Em resumo, MEVil é qualquer circunstância em que grandes mineradores/pools possam extrair valor adicional, empregando estratégias sofisticadas de mineração de transações - além de maximizar simplesmente as taxas totais - que são impraticáveis para mineradores/pools menores 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 concretos do OP_CAT que podem ser potencialmente prejudiciais. Por exemplo, a proposta Drivechains tem sido revisto aqui, e é amplamente considerado como prejudicial ao Bitcoin. É acredita-se ser possívelimplementar Drivechain com OP_CAT. Outro exemplo são propostas de token, como Taproot Assets. Embora seja impossível em geral impedir que sejam implementadas comvalidação do lado do cliente, há propostas para implementá-las com OP_CAT de maneiras que são potencialmente muito mais atrativas para os usuários finais, ao mesmo tempo que usam muito mais espaço de 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 os convênios, o OP_CAT seria usado principalmente para concatenar dados e, em seguida, hashá-los. Outra maneira de alcançar esse mesmo objetivo é com algum tipo de opcode de hash incremental que leva um estado intermediário SHA256 de algum tipo e hash de mais dados nele; SHA256 em si opera em blocos de 64 bytes. Existem muitos designs possíveis para opcodes de hashing incremental.

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

Claro, uma vez que o hashing incremental pode fazer praticamente o que o OP_CAT pode fazer, apenas de forma mais eficiente, partilha todas as preocupações sobre o OP_CAT ser demasiado poderoso.

Revival de Script

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

Embora OP_CAT por si só torne os convênios (recursivos) possíveis, um "reavivamento de roteiro" completo tornaria os convênios mais sofisticados possíveis – e muito mais fáceis de implementar – já que partes da transação de gastos poderiam ser manipuladas diretamente. Por exemplo, você pode imaginar um script de convênio que usa opcodes aritméticos para garantir que o valor total dos txouts na transação esteja de acordo com alguma propriedade desejada.

Novamente, a ressurreição do script levanta todas as mesmas preocupações e mais, sobre ser excessivamente poderoso que o OP_CAT sozinho faz.

Simplicidade

Semelhante ao Script Revival, a Simplicity está relacionada com as L2 e os pactos, tornando possível fazer qualquer coisa. Ao contrário do Script Revival, um fork suave 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, a Simplicidade é tanto demasiado simples como 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 a partir 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 jatos implementar? Provavelmente, jatos seriam implementados em C ++, como qualquer outro opcode, exigindo uma forquilha suave para cada novo jato.

OP_FancyTreeManipulationStuff

Existe uma grande variedade de opcodes relativamente especializados que foram propostos para manipular árvores de forma eficiente em espaço para propostas L2 dependentes de covenants. Por exemplo, os Coinpools propuseram ambos TAPLEAF_UPDATE_VERIFY e ainda OP_MERKLESUB, ambos manipulam árvores de taproot de maneiras necessárias para a proposta Coinpools e o MATEA proposta propôs um opcode OP_CheckContractVerify que, basicamente, verifica declarações sobre árvores de merkle.

Para os propósitos 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 opcodes mais genéricos, como a manipulação de OP_CAT. Mas todas têm a desvantagem de adicionar complexidade ao sistema de script, para um caso de uso potencialmente específico.

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

Piscinas 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 possuindo 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 compartilhados" associado a ele: como o valor de txout é dividido? Se o pool de fundos for 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 cima do 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 alterações de estado: transações comprovam por meio de suas testemunhas que as alterações no estado do conjunto de UTXO são válidas; o prova de trabalho nos permite chegar a um consenso sobre qual conjunto de transações está correto. Isso significa que os fundos do pool também serão baseados na validação de alterações de estado: estamos provando para cada nó do Bitcoin que as regras do fundo do pool estão sendo seguidas em cada alteração de estado.

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

Com essas restrições em mente, em que estruturas de dados os fundos de fundos serão baseados? Inevitavelmente, todos eles são algum tipo de árvore. Especificamente, algum tipo de árvore de Merkle. Eles têm que ser uma árvore, porque essa é praticamente a única estrutura de dados escalonável na ciência da computação; eles têm que ser merkleizados, porque essa é basicamente a única maneira razoável de se comprometer criptograficamente com o estado da árvore. Finalmente, as atualizações da árvore serão inevitavelmente publicadas no blockchain do Bitcoin, porque esse é o únicomeio de publicação todos os usuários L2 compartilham, e o único que podemos forçar os usuários a publicar para mover moedas. E porque qualquer implementação do pacto vai precisar de partes da árvore para validar que as regras do pacto estão sendo seguidas.

Então, com a teoria de alto nível fora do caminho, como é que isto se traduz realmente 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 fundo de reserva pode mudar, grosso modo, uma vez. Por exemplo, um canal Lightning padrão se enquadra nesta 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 a partir dos dados da blockchain e recuperar seus fundos gastando-os.

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

Árvore de 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 predefinidas, impostas com acordos simples como transações pré-assinadas ou CTV, dividindo o valor desse UTXO em quantias menores e menores até que se atinjam os 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 por causa dos bytes usados nos txouts e txins necessários para criar essa camada.

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

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

A escalabilidade das árvores txout tem economias de escala interessantes. O custo para o primeiro V-UTXO ser colocado na cadeia, em um pool de fundos com n V-UTXOs, é aproximadamente 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 o primeiro V-UTXO é colocado na cadeia, os V-UTXOs subsequentes tornam-se mais baratos 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. Isto significa que para colocar todos os V-UTXOs na cadeia, o custo total para o fazer através de uma árvore de txout seria um pequeno múltiplo do custo total para o fazer numa única transação. Surpreendentemente eficiente!

Ou talvez não... Se o tamanho total dos resgates do pool de fundos 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 tão profundas que realmente resgatar cada uma delas...

V-UTXO na árvore é impossível.

Uma questão em aberto com árvores txout é quem paga as taxas, e como? Uma solução óbvia é usar saídas de âncora sem chave nas transações folha e permitir que quem quiser que as transações 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 lugar óbvio para tirar taxas para RBF é o valor V-UTXO. Mas como garantir que apenas o proprietário tenha a capacidade de assinar uma transação de taxa mais alta? Em muitas circunstâncias, não é óbvio como fazer isso de uma forma que seja mais eficiente do que uma saída de âncora sem chave. No entanto, não fazer isso representa sérios desafios para os esquemas usados pelas carteiras de usuários finais, que podem não ter um UTXO para gastar para executar um CPFP, se os próprios V-UTXOs não puderem ser gastos imediatamente.

Por fim, é necessário pensar cuidadosamente nos incentivos existentes nos sistemas de árvore de txout, levando em consideração o pagamento de taxas. Por exemplo, em um sistema como o Ark, se um conjunto de V-UTXOs individualmente custa muito dinheiro para valer a pena levá-los para V-UTXOs on-chain, um coordenador não cooperativo pode se recusar a permitir que esses V-UTXOs sejam resgatados off-chain e, em seguida, obter lucro roubando o valor desses V-UTXOs em uma única transação UTXO quando o tempo limite for atingido.

Se for esse o caso, argumentavelmente esse sistema não atenderia aos nossos critérios para ser uma Camada 2 para pequenos V-UTXOs.

Esquemas Baseados em Saldo

A máquina de estado de uma árvore de txout ainda é relativamente simples: ou o fundo existe, ou é gasto, para criar dois ou mais fundos menores. Com convenções mais avançadas, poderíamos tratar o fundo 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 daquilo que é essencialmente uma base de dados partilhada. Porquê? Porque o objetivo aqui é compartilhar um UTXO entre muitos proprietários diferentes. Finalmente, se realmente quisermos obter uma melhoria de escalabilidade, devemos fazê-lo de uma forma que coloque o mínimo possível desses dados de propriedade em cadeia.

Esses requisitos nos levam inherentemente a algum tipo de estrutura de dados merkle-arborizada, como uma árvore de soma merkle. Manipular essa estrutura de dados vai exigir inherentemente 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, tal como nas árvores txout, não é possível obter uma escala melhor do que log(n) mantendo propriedades de segurança semelhantes. Porquê? Vamos supor que tínhamos um hipotético OP_ZKP que, através de alguma matemática avançada, necessitava de apenas 32 bytes para provar qualquer afirmação. Embora esta prova de conhecimento-zero (zk-proof) pudesse provar que a estrutura de dados merkelizada foi manipulada de acordo com as regras do sistema de camada 2, falharia em fornecer os dados necessários para que o próximo utilizador também efetuasse uma alteração de estado. Isto não cumpre o nosso critério preferido de permitir levantamentos incondicionais: no máximo, um utilizador poderia conseguir um levantamento incondicional. Mas nenhum outro utilizador poderia fazê-lo.

Por outro lado, se as partes modificadas da estrutura de dados merklized forem publicadas através do covenant scriptsig — por exemplo, o irmão digere em uma árvore 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 da cadeia do Bitcoin. No entanto, as garantias de segurança serão mais fracas do que é possível por meio do Bitcoin.

Finalmente, observe como as árvores de txout e uma abordagem baseada em saldo podem ser combinadas. Se a estrutura de dados sendo manipulada for uma árvore de txout, os fundos podem ser adicionados à árvore de 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 de txout. Da mesma forma, os fundos podem ser removidos por todos os mecanismos normalmente disponíveis para uma árvore de txout. O Advanced Ark é um exemplo dessa classe de esquema.

Rácio de Dados de Falha

As L2 alcançam escalabilidade adicionando um requisito de interatividade em situações adversas. 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 do 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 em capacidade ~100% do tempo. Como a mineração de Bitcoin atua como um sistema de leilão, leiloando o espaço do bloco ao licitante mais alto, na prática isso significa que a taxa mínima para que uma transação seja minerada sobe e desce conforme a demanda aumenta e diminui.

A taxa de taxa sempre leva em conta a economia L2 e os modos de falha. Por exemplo, no Lightning, HTLCs "do tamanho de poeira" que são muito pequenos para serem resgatados on-chain de forma lucrativa, use um modelo de segurança diferente dos HTLCs maiores. Embora o protocolo Lightning ainda não implemente isso corretamente, em teoria, esse limite deve ser dinâmico, baseado em taxas à medida que sobem e descem, idealmente até o ponto em que uma parte poderia escolher se um HTLC existe ou não em uma determinada transação de compromisso com base na taxa de taxa.

Foram propostos vários ataques em que esta situação é intencionalmente desencadeada no Lightning, como inundação e saque.²²e o ataque de saída em massa²³. Como a capacidade do blockchain do Bitcoin é compartilhada em todos os casos de uso, ataques entre diferentes sistemas L2 também são possíveis: por exemplo, acionando uma saída em massa na Arca para lucrar com os canais Lightning.

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

Em segundo lugar, antes que os novos esquemas de compartilhamento de UTXO sejam amplamente adotados, pesquisas cuidadosas devem ser feitas sobre a lucratividade potencial de ataques durante alta demanda por espaço de bloco. Por exemplo, em um sistema como Ark, onde o ASP pode resgatar fundos usando muito menos espaço de bloco do que outras partes, pode ser o caso de provocar intencionalmente taxas altas e depois apreender fundos que não podem ser retirados lucrativamente unilateralmente, o que configura uma fraude lucrativa, violando as condições para um verdadeiro sistema L2.

Limpeza de consenso

Existem várias coisas que Satoshi errou no protocolo inicial do Bitcoin, em particular, ataques de negação de serviço por script, o ataque timewarp e problemas com a árvore de merkle. Anteriormente, vários outros bugs de consenso já foram corrigidos com soft-forks, como a troca de avaliação do tempo baseado em nLockTime em relação ao tempo médio passado, (tentativa de) corrigir o problema de txid duplicado, etc.

A mais recente forquilha suave, taproot, teve um processo de implementação relativamente contencioso, levando bastante tempo para ser realmente implementada. Um argumento para fazer primeiro uma limpeza de consenso suave antes de habilitar qualquer novo código de operação ou outras funcionalidades para novos tipos de Camada 2, é que aprenderíamos mais sobre o quão disposta a comunidade em geral está para implementar o que deveria ser uma forquilha suave relativamente não controversa que beneficia, sem dúvida, a todos.

Teste de L2 Dependente de Fork Suave

Os desenvolvedores não precisam esperar que uma forquilha suave realmente aconteça para testar suas ideias. Uma abordagem particularmente sofisticada está sendo usada pelos desenvolvedores do Ark em Arca sem aliança é simular os pactos de que necessitam com transações pré-assinadas. Isso permite que eles testem as ideias da Arca com BTC real, na rede principal, com as mesmas características de confiança, como se espera que a Arca alcance com convênios. A contrapartida é que a Arca sem pacto exige que todas as partes estejam online para assinar as transações pré-assinadas. Uma vez que o clArk trabalha com BTC real, ele pode até ser útil o suficiente para usar 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 convênios impediriam. Por exemplo, se um protocolo proposto quiser usar CTV para impor que uma árvore txout seja gasta em uma árvore de transações, cada uso de CTV pode ser substituído por um NOP ou CheckSig. Embora na realidade a árvore txout não esteja realmente sendo imposta, cada pedaço de código interagindo com a árvore e cada parte pode ser testado como se fosse, e como NOP e CheckSig são permitidos em scripts padrão, o protocolo pode ser testado na mainnet com fundos reais.

Possíveis Soft-Forks

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 — então, onde as necessidades de um projeto são atendidas de forma mais eficiente por algum outro soft-fork diretamente, não incluiremos OP_CAT.

Também vamos deixar de fora todas as opcodes propostas de manipulação da árvore de Merkle. Todas são muito específicas para casos de uso e têm pouca chance de serem adotadas neste momento. Na medida em que essas opcodes são úteis, implementar seus efeitos via OP_CAT e/ou Script Revival é um caminho muito mais provável para adoção.

CTV é o vencedor claro aqui, seguido por SIGHASH_ANYPREVOUT (OP_Expire é útil para muitas coisas por ser uma correção de ciclismo de substituição, mas não essencial). O CTV ganha porque muitas coisas se encaixam no padrão de design de "certifique-se de que a transação de gastos corresponda a esse modelo"; mesmo OP_CAT construções podem fazer uso eficiente de CTV.

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

Minha recomendação pessoal: faça um soft-fork de limpeza de consenso, seguido de CTV.

Aviso Legal:

1. Este artigo foi reproduzido a partir de [petertodd], Encaminhe o título original 'O roteiro do Ethereum está fora de rumo?', Todos os direitos autorais pertencem ao autor original [petertodd]. Se houver objeções a esta reimpressão, entre em contato com oGate Aprenderequipa e eles tratarão disso prontamente.

2. Aviso de responsabilidade: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.

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