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

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

Rollups recentemente tornaram-se o foco da expansão do BTC, tornando-se a primeira coisa a roubar o protagonismo da Rede de iluminação, em termos de atenção mais ampla. Rollups têm como objetivo ser uma 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’) antecipadamente para receber dinheiro, ou os Nós intermediários precisam de saldo de canal para facilitar o fluxo total dos pagamentos do remetente para o destinatário.

Esses sistemas foram originalmente executados em Ethereum e outros sistemas Turing Completo, mas recentemente o foco tem sido em portá-los para blockchains baseados em UTXO, como BTC. Este artigo não pretende discutir a implementação atual no BTC, mas sim discutir as funcionalidades do Rollup idealizado, que dependem da capacidade de verificação direta de Prova de conhecimento zero (ZKP) no BTC, que atualmente não é suportada.

A arquitetura básica do Roll é a seguinte: uma única conta (UTXO no BTC) que armazena o saldo de todos os usuários no Rollup. Esta UTXO contém um compromisso que existe 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, os usuários ainda precisam assinar algum conteúdo usando a Chave Secreta para realizar gastos fora da cadeia. Essa parte da estrutura permite que os usuários saiam a qualquer momento, sem permissão, bastando provar que sua conta faz parte da árvore de Merkle, eles podem sair unilateralmente do Rollup sem a necessidade de permissão do operador.

O operador do Rollup deve incluir uma ZKP nas transações para atualizar a raiz merkle do saldo da conta na cadeia durante o processo de conclusão da transação fora da cadeia. Sem essa ZKP, a transação será inválida e não poderá ser incluída na cadeia de blocos. Essa 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 o saldo de forma maliciosa para roubar os fundos dos usuários ou redistribuí-los de maneira desonesta para outros usuários.

O problema é que, se apenas a raiz da árvore de Merkle for publicada na cadeia, os usuários podem visualizá-la e acessá-la, mas como eles adicionariam seus ramos à árvore para que pudessem sair sem permissão quando quisessem?

Rollup apropriado

Em um Rollup apropriado, cada vez que uma nova transação fora da cadeia é confirmada e o estado da conta do Rollup é alterado, as informações são diretamente colocadas na 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 as contas são apenas adicionadas nas transações de atualização do Rollup.

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

Desta forma, é possível poupar uma quantidade significativa 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 formal fornecido aos utilizadores através da cadeia de Bloco, 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

Uma outra abordagem para lidar com a questão da disponibilidade de dados para a retirada de usuários é colocar os dados noutro local além da cadeia Bloco. Isto introduz um problema subtil, uma vez que o rollup ainda precisa garantir que os dados estão disponíveis noutro local. Tradicionalmente, outras cadeias Bloco são usadas para este propósito, especialmente concebidas para servir como camada de disponibilidade de dados para sistemas como o rollup.

Isto criou um dilema em que a segurança é igualmente forte. Quando os dados são publicados diretamente na cadeia de blocos Bitcoin (BTCBloco), as regras de consenso podem garantir que estejam absolutamente corretos. No entanto, quando são publicados em sistemas externos, o melhor que podem fazer é verificar a prova SPV, ou seja, que os dados foram publicados noutro sistema.

Isto requer uma prova de que os dados estão presentes em outras na cadeia, o que é essencialmente um problema de Máquina Oracle. A cadeia de Bloco do Bitcoin não consegue validar completamente nada para além do que acontece na sua própria cadeia, sendo o melhor que consegue fazer a validação de ZKP. No entanto, o ZKP não consegue verificar se, após a geração, os dados do bloco que contém os dados do rollup são realmente divulgados publicamente. Não consegue verificar se as informações externas realmente são tornadas públicas para todos.

Isso abre as portas para ataques de retenção de dados, ou seja, criar compromissos para publicar dados 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 fundos. A única solução real é depender completamente do valor e da estrutura de incentivos dos sistemas além do BTC.

A situação é delicada

Isto colocou o rollup numa situação difícil. Quando se trata de problemas de disponibilidade de dados, basicamente existe uma escolha binária entre publicar os dados na blockchain BTC ou noutro local. 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 define um limite rígido para a escalabilidade do rollup. O espaço do bloco é limitado, o que impõe um limite para a quantidade de rollups que podem existir ao mesmo tempo e para o número total de transações que podem ser processadas fora da cadeia. Cada atualização do rollup requer espaço de bloco proporcional ao número de contas cujos saldos mudaram desde a última atualização. A teoria da informação permite apenas uma compressão dos dados até certo ponto, e não há mais potencial de escalabilidade além disso.

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 novas questões de segurança e soberania. No Rollup que utiliza BTC para alcançar a disponibilidade de dados, se os dados que o usuário precisa extrair não forem automaticamente publicados na blockchain, o estado do Rollup não pode mudar. Com o uso de Validiums, essa garantia depende inteiramente da capacidade do sistema externo em resistir a fraudes e ocultação de dados.

Agora, qualquer produtor de Bloco no sistema de disponibilidade de dados externos pode se apropriar dos fundos dos usuários do BTCRollup produzindo um Bloco em vez de realmente transmitir esse Bloco, tornando os dados disponíveis.

Então, se realmente conseguirmos realizar a implementação ideal do Rollup no BTC, alcançando verdadeiramente saques unilaterais dos usuários, como seria isso?