Rollups se tornaram o foco narrativo da escala do Bitcoin ultimamente, tornando-se a primeira coisa a realmente “roubar os holofotes” da Lightning Network em termos de maior participação mental. Rollups visam ser uma camada dois off-chain que não é limitada ou restringida pelas limitações de liquidez que são centrais para a Lightning Network, ou seja, usuários finais exigem que alguém aloque (ou “empreste”) fundos a eles com antecedência para poder receber dinheiro, ou nós de roteamento intermediários que exigem saldos de canal que podem facilitar a movimentação do valor do pagamento do remetente ao destinatário.
Esses sistemas foram originalmente desenvolvidos para funcionar no Ethereum e outros sistemas Turing completos, mas ultimamente o foco mudou para portá-los para blockchains baseados em UTXO, como o Bitcoin. Este artigo não vai discutir o estado atual das coisas sendo implementadas no Bitcoin atualmente, mas vai discutir a função de um rollup idealizado que as pessoas estão buscando a longo prazo, dependendo de recursos que o Bitcoin atualmente não suporta, ou seja, a capacidade de verificar Provas de Conhecimento Zero (ZKPs) no Bitcoin diretamente.
A arquitetura básica de um roll é a seguinte: uma única conta (ou no caso do Bitcoin UTXO), mantém os saldos de todos os usuários no rollup. Este UTXO contém um compromisso na forma de uma raiz merkle de uma árvore merkle que se compromete com todos os saldos atuais de contas existentes no rollup. Todas essas contas são autorizadas usando pares de chaves pública/privada, então, para propor um gasto off-chain, um usuário ainda deve assinar algo com uma chave. Esta parte da estrutura permite que os usuários saiam sem permissão quando quiserem, simplesmente elaborando uma transação provando que sua conta é parte da árvore merkle, eles podem sair unilateralmente do rollup sem a permissão do operador.
O operador do rollup deve incluir um ZKP em transações que atualizam a raiz merkle dos saldos de contas on-chain no processo de finalização de transações off-chain, sem esse ZKP a transação será inválida e, portanto, não poderá ser incluída no blockchain. Essa prova permite que as pessoas verifiquem se todas as alterações em contas off-chain foram devidamente autorizadas pelo(s) titular(es) da conta e se o operador não conduziu uma atualização maliciosa de saldos para roubar dinheiro de usuários ou realocá-lo para outros usuários desonestamente.
O problema é que, se apenas a raiz da árvore merkle for publicada na cadeia, onde os usuários podem visualizá-la e acessá-la, como eles colocam seu ramo na árvore para poderem sair sem permissão quando quiserem?
Rollups adequados
Em um rollup adequado, as informações são colocadas diretamente no blockchain toda vez que novas transações off-chain são confirmadas e o estado das contas do rollup muda. Não a árvore inteira, isso seria absurdo, mas as informações necessárias para reconstruir a árvore. Em uma implementação ingênua, o resumo de todas as contas existentes no rollup teria saldos e contas simplesmente adicionados na transação atualizando o rollup.
Em implementações mais avançadas, um diff de saldo é usado. Este é essencialmente um resumo de quais contas tiveram dinheiro adicionado ou subtraído delas durante o curso de uma atualização. Isso permite que cada atualização de rollup inclua apenas o mudanças para saldos de contas que ocorrem. Os usuários podem então simplesmente escanear a cadeia e “fazer as contas” desde o início do rollup para chegar ao estado atual dos saldos de contas, o que lhes permite reconstruir a árvore merkle de saldos atuais.
Isso economiza muita sobrecarga e espaço de bloco (e, portanto, dinheiro), ao mesmo tempo em que permite que os usuários garantam acesso às informações necessárias para que eles saiam unilateralmente. Incluir esses dados em um rollup formal que usa o blockchain para disponibilizá-los aos usuários é obrigatório pelas regras do rollup, ou seja, uma transação que não inclui o resumo da conta ou o diff da conta é considerada uma transação inválida.
Validades
A outra maneira de lidar com o problema da disponibilidade de dados para os usuários retirarem é colocar os dados em outro lugar além do blockchain. Isso introduz problemas sutis, o rollup ainda precisa impor que os dados foram disponibilizados em outro lugar. Tradicionalmente, outros blockchains são usados para esse propósito, projetados especificamente para funcionar como camadas de disponibilidade de dados para sistemas como rollups.
Isso cria o dilema de garantias de segurança serem tão fortes. Quando os dados são postados diretamente no blockchain do Bitcoin, as regras de consenso podem garantir que eles estejam corretos com absoluta certeza. No entanto, quando são postados em um sistema externo, o melhor que podem fazer é verificar uma prova SPV de que os dados foram postados em outro sistema.
Isso envolve verificar uma atestação de que os dados existem em outras cadeias, o que é, em última análise, um problema de oráculo. O blockchain do Bitcoin não pode verificar nada completamente, exceto o que ocorre em seu próprio blockchain, o melhor ele pode fazer é verificar um ZKP. Um ZKP, no entanto, não pode verificar se um bloco contendo dados de rollup foi realmente transmitido publicamente após ser produzido. Ele não pode verificar se informações externas estão realmente disponíveis publicamente para todos.
Isso abre a porta para ataques de retenção de dados, onde um compromisso com os dados que estão sendo publicados é criado e usado para avançar o rollup, mas os dados não são realmente disponibilizados. Isso torna os fundos dos usuários além de sua capacidade de sacar. A única solução real para isso é depender inteiramente do valor e da estrutura de incentivos de sistemas completamente externos ao Bitcoin.
A Rocha e o Lugar Duro
Isso cria um dilema em termos de rollups. Quando se trata da questão da disponibilidade de dados, há essencialmente uma escolha binária entre postar os dados no blockchain do Bitcoin ou em outro lugar. Essa escolha tem implicações enormes tanto para a segurança e soberania do rollup quanto para sua escalabilidade.
Por um lado, usar o blockchain do Bitcoin para a camada de disponibilidade de dados introduz um teto rígido sobre o quanto os rollups podem escalar. Há apenas um certo espaço de bloco, e isso coloca um limite superior sobre quantos rollups podem existir ao mesmo tempo e quantas transações todos os rollups em conjunto podem processar fora da cadeia. Cada atualização de rollup requer espaço de bloco proporcional à quantidade de contas que tiveram alterações de saldo desde a última atualização. A teoria da informação só permite que os dados sejam compactados até certo ponto, e nesse ponto não há mais potencial para ganhos de escala.
Por outro lado, usar uma camada diferente para disponibilidade de dados remove o teto rígido em ganhos de escalabilidade, mas também introduz novos problemas de segurança e soberania. Em um rollup usando Bitcoin para disponibilidade de dados, literalmente não é possível que o estado do rollup mude sem que os dados necessários para os usuários retirarem sejam postados atomicamente no blockchain. Com Validiums, essa garantia depende inteiramente da capacidade de qualquer sistema externo que esteja sendo usado para resistir a jogos e retenção de dados.
Qualquer produtor de bloco no sistema externo de disponibilidade de dados agora é capaz de manter os fundos dos usuários do Bitcoin rollup como reféns ao produzir um bloco e não transmiti-lo para disponibilizar os dados.
Então, qual será, se algum dia chegarmos a uma implementação de rollup ideal no Bitcoin que realmente permita a retirada unilateral do usuário? A rocha ou o lugar difícil?
Fonte: bitcoinmagazine.com
