Um grito comum de muitos neste espaço hoje em dia em resposta a qualquer discussão sobre mudanças no protocolo Bitcoin é “Não mexa com a Camada 1! Você pode simplesmente construí-lo na Camada 2!” Parece uma coisa muito lógica de se fazer, certo? Por que arriscar a segurança e a estabilidade do L1 quando você pode simplesmente construir sobre ele? O problema é que isso falha fundamentalmente na compreensão da relação entre a Camada 1 e a Camada 2.
Um protocolo L2 é uma extensão do L1. Tudo o que um L2 foi projetado para fazer deve, em última análise, reduzir-se ao que o L1 é capaz. A declaração geral de “apenas faça no L2!” ofusca inúmeras realidades implícitas sobre o que pode ou não ser feito em um L2, dado o estado atual da camada base. Por exemplo, imagine tentar construir a Lightning Network sem a existência de scripts com múltiplas assinaturas. Você não poderia. Não seria possível compartilhar o controle entre mais de uma pessoa e todo o conceito de canal de pagamento não seria possível.
A evolução dos canais de pagamento
A razão pela qual os canais de pagamento podem existir é, em primeiro lugar, o fato de que L1 do Bitcoin suporta a capacidade de várias pessoas compartilharem o controle de um UTXO com um script multisig. O que é possível em L2 é inerentemente limitado pelo que é possível em L1; sim, é claro que é possível fazer coisas em L2 que não são possíveis em L1, mas o fator limitante final do que você pode fazer fora da cadeia é o que é possível na cadeia. A confirmação mais rápida do pagamento em um canal de pagamento só é possível porque a custódia na rede pode ser compartilhada entre várias pessoas.
Mesmo isso não é suficiente para um canal de pagamento seguro. O canal de pagamento original tinha uma transação pré-assinada usando um timelock nLocktime que devolve o dinheiro ao financiador após tantos bloqueios e suportava apenas canais de pagamento em uma direção. A maleabilidade das transações tornou o uso desses canais de pagamento originais inseguro. Se a transação de financiamento fosse malecada por alguém antes da confirmação, a transação de reembolso seria invalidada e o financiador não teria como reclamar o seu dinheiro de volta. A outra parte no canal poderia efetivamente manter seu dinheiro como refém.
CHECKLOCKTIMEVERIFY, o opcode absoluto do timelock, foi a solução. CLTV permite que você torne uma moeda impossível de gastar até uma determinada altura de bloco ou momento no futuro. Isso, em combinação com a capacidade de criar scripts que podem ser gastos de diversas maneiras, permitiu que o multisig UTXO tivesse um caminho de script onde o financiador pudesse gastar todos os fundos sozinho após um timelock. Isto garantiu que o financiador seria capaz de reclamar o dinheiro de volta no pior cenário, mesmo que a transação de financiamento fosse maliciosa. O canal ainda poderia facilitar apenas pagamentos unidirecionais.
Para facilitar os pagamentos bidirecionais, era necessária uma solução adequada para a maleabilidade das transações. Este foi um grande motivador para a Segregated Witness. Um timelock é tudo o que é necessário para um canal unidirecional porque o dinheiro apenas aumentou em uma direção. O único risco para o remetente era que a outra parte nunca reivindicasse o que já foi enviado na rede, deixando o restante do dinheiro do remetente preso. O reembolso do timelock deu ao destinatário o incentivo para reivindicar fundos na rede antes do timelock, quando eles perderiam todos os fundos que já haviam sido enviados, e ao remetente um recurso na pior das hipóteses, caso algo acontecesse e deixasse permanentemente o destinatário offline . O script não suporta a aplicação de determinados valores a determinados scripts futuros, portanto, uma transação pré-assinada é o único mecanismo de reembolso inicial viável se os pagamentos fluírem em ambas as direções. Isso reabriu o risco de fundos serem mantidos como reféns.
Com a atualização para o Segwit, esse problema foi resolvido. No lugar do reembolso do timelock que incentiva o comportamento honesto, foi introduzida a chave de penalidade. Dado que os fundos num canal bidireccional podem fluir para a frente e para trás em cada direcção, haverá inevitavelmente um caso em que ambos os lados tinham mais dinheiro num estado anterior do canal do que no actual. Ao estabelecer uma filial na transação pré-assinada de cada estado do canal usando uma chave de penalidade, os usuários podem trocá-las após assinar o novo estado e saber se a outra parte tentar usar uma transação antiga, poderá reivindicar 100% dos fundos no canal. Os timelocks são usados para garantir que o caminho normal de gastos onde os usuários levam seus respectivos saldos não seja válido por um tempo para dar aos participantes do canal a chance de usar a chave de penalidade, se necessário. Porém, há um problema com isso: usar CLTV significa que em algum momento no futuro o canal tem para fechar ou então o timelock irá expirar e você não terá mais aquele período de segurança para penalizar a parte desonesta.
Os canais de pagamento bidirecionais também precisavam de CHECKSEQUENCEVERIFY, ou timelocks relativos, para resolver esse problema. Ao contrário do CLTV, que especifica um horário ou altura de bloco específico no futuro, o CSV especifica um período relativo de tempo ou número de blocos a partir do momento ou bloco em que o UTXO usando CSV no script é confirmado no blockchain. Isso permitiu que o período de segurança funcionasse para o uso da chave de penalidade, sem exigir que os canais fechassem na cadeia em um horário pré-determinado.
Mesmo isso não nos dá a Lightning Network. Ainda não há como encaminhar um pagamento por vários canais de pagamento. Eles podem realizar pagamentos em ambas as direções, mas apenas entre as duas pessoas envolvidas no canal. Para encaminhar pagamentos por vários canais, você precisa, você adivinhou, de outras funcionalidades do L1. Os contratos Hash Time Locked são a forma como isso é feito e exigem tanto CLTV quanto hashlocks. Hashlocks exigem o fornecimento da pré-imagem a um hash para poder gastar as moedas. É como uma assinatura, exceto que você apenas revela a “chave privada” em vez de assinar com ela. Isso permite que o destinatário em um pagamento Lightning forneça um hashlock, e cada canal intermediário entre o remetente e o destinatário crie um script que permite gastar imediatamente com a pré-imagem do hash ou devolver o dinheiro após um timelock. Se o destinatário revelar o hashlock, todos poderão reivindicar o dinheiro para o encaminhamento do pagamento; caso contrário, o dinheiro poderá ser reivindicado de volta e revertido sem finalizá-lo.
Portanto, a Lightning Network, tal como existe hoje, depende inteiramente de cinco funcionalidades sendo possíveis na camada base do Bitcoin. Scripts de múltiplas assinaturas, timelocks absolutos, timelocks relativos, testemunha segregada e hashlocks. Sem qualquer um desses recursos existentes no L1, o Lightning como o conhecemos hoje não seria um L2 possível que poderíamos construir. A sua existência como L2 depende inteiramente da capacidade do L1 de fazer certas coisas. Então, se alguém fizesse isso, em um mundo com um Bitcoin que não suportasse hashlocks, timelocks em script e nenhuma correção de maleabilidade, basta dizer “Basta construir um sistema de canal de pagamento multi-hop bidirecional na Camada 2! Não deveríamos brincar com a Camada 1”, seria uma afirmação completamente incoerente.
A pegada
Dito isto, estritamente falando tecnicamente, ainda teria sido possível construir aquele sistema bidirecional de canal de pagamento multi-hop naquele mundo sem esses três recursos em L1. Em um enorme custo em termos de introduzir confiança em outras pessoas para não roubarem seu dinheiro quando elas forem capazes de fazê-lo. Uma cadeia lateral federada. Todos poderiam simplesmente ter criado uma cadeia federada como Liquid ou Rootstock e adicionado esses recursos à cadeia lateral, construindo a Lightning Network lá, em vez de na cadeia principal. O problema com isso é que não é a mesma coisa. A nível técnico, a rede funcionaria exactamente da mesma forma, mas ninguém que a utilizasse teria realmente o mesmo grau de controlo sobre as suas moedas.
Quando eles fechassem um canal Lightning, ele seria colocado em uma cadeia lateral apoiada por uma federação, ou seja, seria apenas uma entrada contábil no topo da carteira multisig de outra pessoa, onde você não teria capacidade de controlar essas moedas em L1. Você apenas precisa confiar no grupo distribuído que opera a federação para não incomodar a todos. Até mesmo os drivechains (que ironicamente exigem a criação de uma nova funcionalidade L1) são apenas outra forma de federação no final do dia, com algumas restrições extras adicionadas ao processo de retirada. A federação é formada apenas por mineradores, em vez de pessoas que possuem chaves privadas.
Esta é a realidade implícita, quer eles a entendam ou não, subjacente à reação “basta construí-la na L2!” sempre que alguém está discutindo melhorias no L1. Existe o âmbito daquilo que já é possível construir em L2, que é bastante limitado e restringido pelas suas próprias limitações de escala, e depois existe o âmbito daquilo que ainda não é possível. Tudo o que se enquadra nesta última categoria é impossível de construir sem a interferência de alguma entidade confiável ou grupo de entidades que, em última análise, controla os fundos dos usuários para eles.
Qual é o objetivo?
“Camada 2” não é um encantamento mágico. Você não pode simplesmente agitar uma varinha mágica e entoar as palavras, e tudo e qualquer coisa se torna magicamente possível. Existem limitações estritas e inevitáveis sobre o que uma L2 pode realizar, e essas limitações são o que a L1 pode realizar. Este é apenas um fato inerente à realidade da engenharia quando se olha para um sistema como o Bitcoin. Você não pode escapar disso de forma alguma, exceto degradando cada vez mais as suposições de confiança, quanto mais flexível for uma L2 que você construir além das capacidades da L1.
Portanto, quando ocorrem discussões em torno dessas questões, como quais melhorias podem ser feitas na L1, duas coisas são de extrema importância. Primeiro, essas melhorias na L1 estão quase inteiramente centradas em permitir a construção de L2s mais flexíveis e escaláveis. Em segundo lugar, os L2s não podem ativar tudo magicamente. L2s têm suas próprias limitações baseadas nas da L1, e discutir sobre mudanças na L1 sem reconhecer que a única maneira de contornar essas limitações é introduzir entidades confiáveis não é uma conversa honesta.
É hora de começar a reconhecer a realidade se quisermos discutir o que fazer com o Bitcoin daqui para frente, caso contrário, nada acontecerá além da negação da realidade e da iluminação a gás. E isso não é produtivo.
Fonte: bitcoinmagazine.com
