Bitcoin Magazine: Quais são os desafios do Rollup?

Fonte: Bitcoin Magazine; Compilação: Wu Zhu, Golden Finance

Rollups têm sido o foco da expansão do BTC recentemente, tornando-se a primeira coisa a realmente roubar o holofote da Rede de iluminação e ganhar mais atenção. Rollups visam ser uma segunda camada fora da cadeia que não é limitada ou restrita pela Liquidez central da Rede de iluminação, ou seja, os usuários finais precisam que alguém aloque (ou ‘empreste’) fundos com antecedência para receber dinheiro, ou os Nós intermediários precisam ter saldo de canal para facilitar o fluxo total dos pagamentos do remetente para o destinatário.

Estes sistemas eram originalmente executados na Ethereum e em outros sistemas Turing Completo, mas recentemente houve um foco na sua portabilidade para blockchains baseadas em UTXO (por exemplo, BTC). Este artigo não pretende discutir o estado atual da implementação no BTC, mas sim as funcionalidades de Rollup idealizadas que as pessoas têm perseguido a longo prazo, as quais dependem de capacidades que o BTC atualmente não suporta, ou seja, a capacidade de verificar zero conhecimento (ZKP) diretamente no BTC.

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

Os operadores Rollup devem incluir um ZKP nas transações para atualizar os saldos das contas na cadeia com sucesso fora da cadeia. Sem este ZKP, a transação será inválida e não pode ser incluída na cadeia de blocos. Esta prova permite que as pessoas verifiquem se todas as alterações nas contas fora da cadeia foram devidamente autorizadas pelo titular da conta e se o operador não atualizou os saldos de forma maliciosa 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, como eles podem então colocar seus ramos na árvore para que possam sair quando quiserem sem permissão?

Rollup apropriado

Em um Rollup apropriado, cada vez que uma nova transação fora da cadeia é confirmada e o estado da conta Rollup muda, as informações são adicionadas diretamente à blockchain. Não é a árvore inteira, isso 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á o saldo e a conta é apenas adicionada nas transações de atualização do Rollup.

Em implementações mais avançadas, use diferenças de equilíbrio. Essencialmente, isto resume quais contas tiveram fundos adicionados ou removidos durante o processo de atualização. Isto faz com que cada atualização do Rollup contenha apenas as alterações de saldo das contas que ocorreram. Então, os usuários podem simplesmente escanear a cadeia e ‘calcular’ a partir do início do Rollup para obter o estado atual do saldo da conta, permitindo-lhes reconstruir a árvore Merkle do saldo atual.

Dessa forma, é possível economizar uma grande quantidade de despesas e espaço de bloco (economizando assim fundos), ao mesmo tempo que permite aos usuários garantir o acesso às informações necessárias para a saída unilateral. As regras de rollup exigem que esses dados sejam incluídos no rollup formal fornecido aos usuários usando a cadeia de blocos, ou seja, as transações que não incluem um resumo de conta ou diferenças de conta são consideradas inválidas.

Prazo de validade

Outra forma de lidar com a questão da disponibilidade de dados de retirada do usuário é colocar os dados em outros lugares fora da cadeia de Bloco. Isso levanta questões delicadas, rollup ainda precisa garantir a disponibilidade dos dados em outros lugares. Tradicionalmente, outras cadeias de Bloco são usadas para este fim, sendo especialmente projetadas como camada de disponibilidade de dados para sistemas como rollup.

Isso cria um dilema de segurança igualmente poderoso. Quando os dados são publicados diretamente na cadeia de blocos do BTCBloco, as regras de consenso podem garantir que estejam absolutamente corretos. No entanto, quando são publicados em sistemas externos, a melhor coisa que podem fazer é verificar a prova SPV, ou seja, que os dados foram publicados em outro sistema.

Isso requer prova de que os dados existem em outros blocos na cadeia, o que acaba sendo um problema de Máquina Oracle. A cadeia de blocos do BTC não pode verificar completamente nada além do que acontece em seu próprio bloco na cadeia, o melhor que pode fazer é verificar a prova de conhecimento zero (ZKP). No entanto, ZKP não pode verificar se o bloco que contém os dados do rollup foi realmente transmitido publicamente após a geração. Não pode verificar se as informações externas realmente foram tornadas públicas para todos.

Esta abriu a porta para ataques de retenção de dados, ou seja, criar compromissos para a publicação de dados e usá-los para impulsionar o rollup, mas os dados não estão realmente disponíveis. Isso faz com que os utilizadores não consigam retirar fundos. A única solução real é depender totalmente do valor e da estrutura de incentivos de sistemas que não se baseiam no BTC.

Entre a espada e a parede

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

Por um lado, usar a cadeia BTCBloco como uma camada de disponibilidade de dados coloca um limite rígido na escalabilidade dos rollups. O espaço do bloco é limitado, o que define um limite máximo para o número de rollups que podem existir ao mesmo tempo e o número total de transações que todos os rollups podem processar no Fora da Cadeia. Cada atualização de rollup requer espaço Bloco proporcional à quantidade de conta cujo saldo foi alterado desde a última atualização. A teoria da informação só permite que os dados sejam compactados até certo ponto, momento em que não há mais potencial de expansão.

Por outro lado, o uso de camadas diferentes para alcançar a disponibilidade de dados elimina o limite rígido dos ganhos de escalabilidade, mas também traz novas questões de segurança e soberania. Em um 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 inteiramente 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 os fundos dos usuários do BTCRollup produzindo Bloco em vez de transmitir o Bloco real, garantindo assim a disponibilidade dos dados.

Então, se realmente conseguirmos implementar o Rollup ideal no BTC, alcançando verdadeiramente levantamentos unilaterais dos utilizadores, como seria isso?