Bitcoin Magazine: Quais são os desafios que o Rollup enfrenta?

Fonte: Bitcoin Magazine; Tradução: Wu Zhu, Jinse Finance

Rollups recentemente se tornaram o foco da expansão do BTC, tornando-se a primeira coisa a realmente roubar o holofote da Rede de iluminação em termos de atenção mais ampla. Rollups visam ser uma segunda camada fora da cadeia que não é limitada ou restringida pela Liquidez central da Rede de iluminação, ou seja, os usuários finais precisam ter fundos alocados (ou “emprestados”) com antecedência para receber dinheiro, ou os Nós intermediários precisam de saldo de canal para facilitar o fluxo total do valor do remetente para o destinatário.

Esses sistemas foram originalmente executados na Ethereum e em outros sistemas Turing Completo, mas recentemente houve um foco em portá-los para blockchains baseadas em UTXO, como Bitcoin. Este artigo não pretende discutir o estado atual da implementação no Bitcoin, mas sim discutir as funcionalidades do Rollup idealizado, que dependem da capacidade de verificação direta de prova de conhecimento zero (zk-SNARKs) no Bitcoin, atualmente não suportada.

A arquitetura básica do Roll é a seguinte: uma única conta (UTXO no BTC) armazena o saldo de todos os usuários no Rollup. Esta UTXO contém um compromisso na forma da raiz de Merkle da árvore de Merkle, comprometendo todos os saldos atuais das contas existentes no Rollup. Todas essas contas são autorizadas usando Chave pública/Chave privada, portanto, para realizar transações fora da cadeia, os usuários ainda precisam assinar algum conteúdo com Chave Secreta. Essa parte da estrutura permite que os usuários saiam a qualquer momento sem permissão, apenas com a prova de transação de que sua conta faz parte da árvore de Merkle, eles podem sair unilateralmente do Rollup sem a permissão do operador.

Os operadores de Rollup devem incluir um ZKP nas transações para atualizar a raiz do merkle do saldo da conta na cadeia ao concluir transações fora da cadeia, caso contrário, a transação será inválida e não pode ser incluída no bloco. Esta prova permite que as pessoas verifiquem se todas as alterações na conta fora da cadeia foram devidamente autorizadas pelo titular da conta e se o operador não atualizou os saldos maliciosamente para roubar fundos dos usuários ou redistribuí-los desonestamente para outros usuários.

A questão é, se apenas a raiz da árvore de Merkle for publicada na cadeia, os usuários podem visualizá-la e acessá-la, então como eles colocam seus ramos na árvore para que possam sair quando quiserem sem permissão?

Rollup apropriado

Em um Rollup apropriado, toda vez que uma nova transação fora da cadeia é confirmada e o estado da conta Rollup sofre alterações, as informações são diretamente colocadas na blockchain. Não é a árvore inteira, o que seria absurdo, mas sim as informações necessárias para reconstruir a árvore. Em uma implementação simples, o resumo de todas as contas existentes no Rollup conterá os saldos, e as contas serão apenas adicionadas nas transações de atualização do Rollup.

Na implementação avançada, o saldo diferencial é usado. Essencialmente, é um resumo de quais contas tiveram adições ou subtrações de fundos durante o processo de atualização. Isso permite que cada atualização Rollup contenha apenas as alterações de saldo ocorridas nas contas. Em seguida, os usuários podem simplesmente percorrer a cadeia e ‘calcular’ a partir do início do Rollup para obter o estado atual do saldo das contas, permitindo que eles reconstruam a árvore Merkle do saldo atual.

Desta forma, é possível poupar uma grande quantidade de despesas e espaço de Bloco (poupando assim fundos), ao mesmo tempo que permite aos utilizadores garantir o acesso às informações necessárias para sair unilateralmente. As regras de rollup exigem que estes dados sejam incluídos no rollup oficial fornecido aos utilizadores através da cadeia de Bloco, ou seja, as transações que não incluem um resumo de conta ou diferença de conta são consideradas inválidas.

Prazo de validade

Outra maneira de lidar com problemas de disponibilidade de dados de retirada do usuário é colocar os dados em outro lugar fora da cadeia de blocos. Isso introduz problemas sutis, pois o rollup ainda precisa garantir que os dados estejam disponíveis em outro lugar. Tradicionalmente, outras cadeias de blocos são usadas para esse fim, projetadas especificamente como uma camada de disponibilidade de dados para sistemas como rollup.

Isso cria um dilema de segurança igualmente forte. Quando os dados são publicados diretamente na cadeia de blocos do Bitcoin, as regras de consenso podem garantir que ele seja absolutamente correto. No entanto, quando é publicado em um sistema externo, o melhor que pode fazer é verificar a prova de SPV, ou seja, que os dados foram publicados em outro sistema.

Isso requer uma prova de que os dados existem em outras cadeias além da cadeia, e isso é um problema final da Máquina Oracle. A cadeia de Blocos do Bitcoin não pode verificar completamente nada além do que acontece em sua própria cadeia de Blocos, o melhor que pode fazer é verificar ZKP. No entanto, ZKP não pode verificar se a cadeia de Blocos que contém dados rollup foi realmente divulgada publicamente após a geração. Não pode verificar se as informações externas realmente estão disponíveis para todos.

Isso abriu as portas para ataques de retenção de dados, ou seja, criar compromissos com os dados publicados e usá-los para impulsionar o rollup, mas os dados não estão realmente disponíveis. Isso faz com que os usuários não consigam retirar os fundos. A única solução real é depender completamente do valor e da estrutura de incentivos de sistemas fora do BTC.

Entre a espada e a parede

Isto coloca rollup numa situação difícil. Quando se trata de questões de disponibilidade de dados, basicamente existe uma escolha binária entre publicar os dados na cadeia de blocos BTC ou noutro lugar. Esta escolha tem um impacto significativo na segurança, soberania e escalabilidade do rollup.

Por um lado, usar a cadeia BTCBloco como camada de disponibilidade de dados imporia um limite rígido à escalabilidade do rollup. O espaço do Bloco é finito, o que impõe limites à quantidade de rollups que podem existir ao mesmo tempo e ao número total de transações que podem ser processadas fora da cadeia. Cada atualização do rollup requer uma quantidade proporcional de espaço do Bloco para contas que tiveram mudanças de saldo desde a última atualização. A teoria da informação só permite que os dados sejam comprimidos até certo ponto, e nesse sentido, não há mais potencial de escalabilidade.

Por outro lado, usar camadas diferentes para alcançar a disponibilidade de dados elimina o limite rígido dos ganhos de escalabilidade, mas também traz novos problemas de segurança e soberania. No Rollup que usa BTC para alcançar a disponibilidade de dados, se os dados que os usuários precisam extrair não forem automaticamente publicados na blockchain, o estado do Rollup não poderá ser alterado. Com o uso de Validiums, essa garantia depende totalmente da capacidade dos sistemas externos de resistir a fraudes e ocultação de dados.

Agora, qualquer produtor de Bloco no sistema de disponibilidade de dados externos pode sequestrar fundos de usuários BTCRollup produzindo Blocos em vez de transmitir o Bloco real, tornando os dados disponíveis.

Então, se realmente conseguirmos implementar uma implementação ideal de Rollup no BTC e realmente permitir saques unilaterais de usuários, como seria?