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

Fonte: Bitcoin Magazine; Compilado por: Wuzhu, Jinse Finance

Rollups recentemente tornou-se o foco da escalabilidade do BTC, tornando-se a primeira coisa realmente a roubar o protagonismo da Rede de iluminação e ganhando 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 (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 montante de pagamento do remetente para o destinatário.

Estes sistemas foram originalmente implementados em Ethereum e outros sistemas Turing Completo, mas recentemente o foco mudou para a 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 do Rollup ideal que as pessoas têm procurado a longo prazo, as quais dependem de capacidades atualmente não suportadas pelo BTC, ou seja, a capacidade de verificar Prova de conhecimento zero (ZKP) diretamente no BTC.

A estrutura básica do Roll é a seguinte: uma única conta (UTXO em BTC) armazena o saldo de todos os usuários no Rollup. Esta UTXO contém um compromisso, que existe na forma de 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 fazer gastos 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 provando que suas contas fazem 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 na transação para atualizar a raiz do merkle do saldo da conta na cadeia ao concluir a transação fora da cadeia. Sem essa 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 maliciosamente o saldo para roubar fundos dos usuários ou redistribuí-los desonestamente para outros usuários.

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

Rollup adequado

Em um Rollup apropriado, cada vez que uma nova transação fora da cadeia é confirmada e o estado da conta Rollup sofre alterações, as informações são colocadas diretamente 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.

Num nível mais avançado de implementação, use diferenças de saldo. Isto é essencialmente um resumo de quais contas aumentaram ou diminuíram os fundos durante o processo de atualização. Isso faz com que cada atualização de Rollup contenha apenas mudanças de saldo de conta ocorridas. Em seguida, os usuários podem simplesmente varrer 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 de Merkle do saldo atual.

Isso permite economizar custos e espaço de bloco (economizando dinheiro), ao mesmo tempo em que permite que os usuários garantam o acesso às informações necessárias para sair unilateralmente. 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, transações sem resumo de conta ou diferenças de conta são consideradas inválidas.

Validade

Outra maneira de lidar com problemas de disponibilidade de dados de retirada de usuários é colocar os dados em outro lugar fora da cadeia de bloco. Isso introduz problemas sutis, rollup ainda precisa garantir que os dados estejam disponíveis em outro lugar. Tradicionalmente, outras cadeias de bloco são usadas para esse fim, especialmente projetadas como 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 BTCBloco, as regras de 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 uma prova de que os dados existem em outras cadeias, o que é, em última instância, um problema de Máquina Oracle. A cadeia de bloco do Bitcoin não pode verificar completamente nada além do que acontece em 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. Isso não pode verificar se as informações externas foram realmente tornadas públicas para todos.

Isso abriu as portas para ataques de retenção de dados, ou seja, criar promessas de publicação de dados e usá-las para impulsionar rollup, mas os dados não estão realmente disponíveis. Isso faz com que os usuários não possam retirar seus fundos. A única solução real é depender completamente de valores e estruturas de incentivo fora do BTC.

Estar em um dilema

Isso coloca o rollup em um dilema. 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 do BTCBloco Blockchain como camada de disponibilidade de dados define um limite rígido para a escalabilidade do rollup. O espaço do Bloco é limitado, o que estabelece um limite para a quantidade de rollups que podem existir de uma só vez e para o 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 certa compressão de dados, e nesse ponto não há mais potencial de expansão.

Por outro lado, o uso de diferentes camadas para alcançar a disponibilidade de dados eliminará o limite rígido dos ganhos de escalabilidade, mas também trará 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 utilizado para resistir à fraude 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, tornando os dados disponíveis, produzindo o Bloco em vez de realmente transmitir esse Bloco.

Então, se realmente conseguirmos implementar a implementação ideal do Rollup no BTC e realmente permitirmos a retirada unilateral do usuário, como seria isso?