Bitcoin Magazine: Quais são os desafios enfrentados pelo Rollup?

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

Recentemente, Rollups se tornou o foco da escalabilidade do BTC, tornando-se a primeira coisa a realmente roubar os holofotes da Rede de iluminação em termos de atenção mais ampla. Rollups tem como objetivo 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 antecipadamente (ou ‘emprestados’) para receber dinheiro, ou os nós de roteamento intermediários precisam ter saldo de canal para facilitar a transferência de pagamentos do remetente para o destinatário.

Estes sistemas foram inicialmente executados na Ethereum e em outros sistemas Turing Completo, mas recentemente o foco mudou para a portabilidade destes sistemas para blockchains baseadas em UTXO (como o Bitcoin). Este artigo não tem a intenção de discutir o estado atual da implementação no BTC, mas sim discutir as funcionalidades do idealizado Rollup que as pessoas têm procurado há muito tempo, o que depende da capacidade de verificar a Prova de conhecimento zero (ZKP) diretamente no BTC, que atualmente não é suportada.

A estrutura básica do Roll é a seguinte: uma única conta (UTXO em BTC) mantém o saldo de todos os usuários no Rollup. Este 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 usando Chave pública/Chave privada, então, para fazer gastos fora da cadeia, os usuários ainda devem assinar algo com a Chave Secreta. Esta parte da estrutura permite que os usuários saiam a qualquer momento sem permissão, basta que eles gerem uma prova de transação que sua conta faz parte da árvore de Merkle, e eles podem sair do Rollup unilateralmente, sem a necessidade de permissão do operador.

O operador do Rollup deve incluir uma ZKP na transação para atualizar a raiz de merkle do saldo da conta na cadeia ao concluir a transação fora da cadeia. Se não houver essa ZKP, a transação será inválida e não pode ser incluída no bloco. 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 Merkle for publicada na cadeia, e os usuários podem visualizá-la e acessá-la, como eles podem colocar seus ramos na árvore para poderem 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 é alterado, as informações são diretamente colocadas na blockchain. Não é a árvore inteira, que seria muito absurdo, mas sim as informações necessárias para reconstruir a árvore. Em uma implementação simples, os resumos de todas as contas existentes no Rollup conterão o saldo e as contas serão simplesmente adicionadas nas transações de atualização do Rollup.

Em implementações mais avançadas, use a diferença de equilíbrio de contas. Isso essencialmente resume quais contas tiveram fundos adicionados ou retirados durante o processo de atualização. Isso permite que cada atualização do Rollup contenha apenas as alterações de saldo de contas 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 de contas, o que lhes permite reconstruir a árvore de Merkel do saldo atual.

Desta forma, é possível poupar uma grande quantidade de despesas e espaço de Bloco (poupando assim fundos), permitindo ao mesmo tempo que os utilizadores garantam 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 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

Outra maneira de lidar com problemas de disponibilidade de dados de saque 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 o rollup.

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

Isso requer prova de que os dados estão presentes em outras cadeias, o que é essencialmente um problema da Máquina Oracle. A cadeia de bloco do BTC não pode verificar totalmente qualquer coisa que aconteça fora de sua própria cadeia de blocos, a melhor coisa que pode fazer é verificar ZKP. No entanto, ZKP não pode verificar se os dados do bloco que contém os dados de rollup foram realmente divulgados publicamente após a geração. Não pode verificar se as informações externas realmente foram tornadas públicas para todos.

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

Dilema

Isso apresenta 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 BTC ou em outro lugar. Essa escolha tem um impacto significativo na segurança, soberania e escalabilidade do rollup.

Por um lado, o uso da cadeia BTC como camada de disponibilidade de dados imporia um limite rígido à escalabilidade do rollup. O espaço Bloco é limitado, o que estabelece um limite para a quantidade de rollups que podem existir de uma vez e para a quantidade total de transações que podem ser processadas fora da cadeia. Cada atualização do rollup requer espaço Bloco proporcional à quantidade de contas cujos saldos tenham mudado desde a última atualização. A teoria da informação permite apenas 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 camadas diferentes para alcançar a disponibilidade de dados eliminará o limite superior rígido do aumento da escalabilidade, mas também trará novos problemas de segurança e soberania. Em um Rollup que usa BTC para alcançar a disponibilidade de dados, se os dados que o usuário precisa extrair não forem automaticamente publicados na cadeia, o estado do Rollup não pode ser alterado. Com o uso do Validiums, essa garantia depende inteiramente da capacidade do sistema externo usado para 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 transmitir o Bloco real, tornando os dados disponíveis.

Então, se realmente conseguirmos implementar uma implementação ideal de Rollup no BTC, permitindo a retirada unilateral dos usuários, como seria?