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

Fonte: Bitcoin Magazine; Compilação: Wuzhu, Golden 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 têm como objetivo ser uma segunda camada fora da cadeia que não é restringida ou limitada 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 nos canais para facilitar a transferência de pagamentos do remetente para o destinatário.

Estes sistemas foram inicialmente implementados em Ethereum e 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 em BTC, mas sim as funcionalidades dos rollups idealizados, que têm sido alvo de busca a longo prazo, dependendo da capacidade atualmente indisponível no BTC de verificar zero conhecimento (zk-SNARKs) diretamente.

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 da raiz de Merkle da árvore de Merkle, comprometendo todos os saldos atuais das contas no Rollup. Todas essas contas são autorizadas com Chave pública/Chave privada, portanto, para gastar fora da cadeia, os usuários ainda devem assinar certos conteúdos com Chave Secreta. Essa parte da estrutura permite que os usuários saiam a qualquer momento, sem permissão, apenas provando que sua conta faz parte da árvore de Merkle, eles podem sair do Rollup unilateralmente, sem a necessidade de permissão do operador.

O operador Rollup deve incluir um ZKP nas transações para atualizar a raiz de merkle do saldo da conta na cadeia ao concluir a transação fora da cadeia. Sem esse ZKP, a transação será inválida e não pode ser incluída no bloco da cadeia. 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 desonestamente para outros usuários.

A questão é, se apenas a raiz da árvore de Merkle for publicada na cadeia, como é que os utilizadores colocam os seus ramos na árvore para que possam sair quando quiserem sem permissão?

Rollup adequado

Em um Rollup apropriado, sempre que uma nova transação fora da cadeia é confirmada e o estado da conta do Rollup sofre alterações, 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á os saldos e as contas serão apenas adicionadas nas transações de atualização do Rollup.

Em implementações mais avançadas, use a diferença de saldo. Essencialmente, isso é um resumo de quais contas tiveram fundos adicionados ou retirados durante o processo de atualização. Isso permite que cada atualização Rollup contenha apenas as alterações de saldo de 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 saldo da conta, permitindo que eles reconstruam a árvore Merkle do saldo atual.

Isso permite economizar custos significativos e espaço de bloco (economizando dinheiro), ao mesmo tempo em que permite que os usuários garantam acesso às informações necessárias para saída unilateral. As regras de rollup exigem que esses dados sejam incluídos no rollup oficial fornecido aos usuários usando a cadeia de blocos, ou seja, transações sem resumo de conta ou diferenças de conta são consideradas inválidas.

Período de validade

Outra forma de lidar com o problema da disponibilidade dos dados de retirada do utilizador é colocar os dados noutro lugar fora da cadeia de blocos. Isso introduz um problema subtil, 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 o rollup.

Isto cria um dilema, onde a segurança é igualmente forte. Quando os dados são diretamente publicados na cadeia BTCBloco, as regras do Consenso podem garantir que estejam absolutamente corretos. No entanto, quando são publicados num sistema externo, o melhor que podem fazer é verificar a prova SPV, ou seja, que os dados foram publicados noutro sistema.

Isso requer uma prova de que os dados estão presentes em outras cadeias, o que acaba sendo um problema de Máquina Oracle. A cadeia de blocos BTC não pode verificar totalmente qualquer coisa que aconteça fora de sua própria cadeia de blocos, exceto verificar ZKP. No entanto, ZKP não pode verificar se o bloco que contém os dados do rollup foi realmente divulgado publicamente após a geração. Ele não pode verificar se as informações externas estão realmente 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 avançar com rollup, mas os dados não estão realmente disponíveis. Isso impede que os usuários retirem seus fundos. A única solução real é depender completamente do valor e da estrutura de incentivos de sistemas além do BTC.

Encurralado

Isso cria um dilema para o rollup. Quando se trata de problemas de disponibilidade de dados, basicamente existe uma escolha binária entre publicar os dados na cadeia de blocos do BTC ou em outro lugar. Essa escolha tem um grande impacto 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 Bloco é limitado, o que impõe um limite ao número de rollups que podem existir ao mesmo tempo e à quantidade total de transações que podem ser processadas fora da cadeia. Cada atualização do rollup requer um espaço Bloco proporcional à quantidade de contas cujos saldos mudaram desde a última atualização. A teoria da informação só permite a compressão dos dados até certo ponto, o que significa que não há mais potencial de escalabilidade.

Por outro lado, o uso de diferentes camadas 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. Em Rollup que usa BTC para alcançar disponibilidade de dados, se os dados que os usuários precisam extrair não foram automaticamente publicados na blockchain, o estado do Rollup não pode mudar. Com Validiums, essa garantia depende completamente da capacidade dos sistemas externos usados de 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 blocos em vez de transmitir os blocos, tornando os dados disponíveis.

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