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

Fonte: Bitcoin Magazine; Tradução: Wuzhu, Jinse Finance

Rollups recentemente se tornaram o foco da expansão do BTC, sendo a primeira coisa a realmente roubar o protagonismo da Rede de iluminação e atrair mais atenção. Rollups têm como objetivo ser uma segunda camada fora da cadeia, sem as restrições de Liquidez do núcleo 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 de saldo de canal para facilitar o fluxo total do valor 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 idealizadas de Rollup que as pessoas têm perseguido a longo prazo, as quais dependem de capacidades que atualmente não são suportadas pelo BTC, ou seja, a capacidade de verificar Prova de conhecimento zero (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 como uma raiz de árvore Merkle, comprometendo todos os saldos atuais das contas no Rollup. Todas essas contas são autorizadas usando Chave pública/Chave privada, portanto, para gastar 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 sua conta faz parte da árvore Merkle, 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 Merkle do saldo da conta na cadeia após a conclusão da transação fora da cadeia. Sem esta ZKP, a transação será inválida e não pode ser incluída no bloco da cadeia. Esta prova permite que as pessoas verifiquem se todas as alterações na conta fora da cadeia foram devidamente autorizadas pelos titulares 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, os usuários poderão visualizá-la e acessá-la, mas como eles colocarão seus ramos na árvore para que possam sair quando quiserem sem permissão?

Rollup apropriado

Em um Rollup apropriado, sempre que uma nova transação fora da cadeia é confirmada e o estado da conta Rollup sofre alterações, as informações são diretamente colocadas na blockchain. Não é a árvore inteira, que 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 subtraídos durante o processo de atualização. Isso faz com que cada atualização do Rollup contenha apenas alterações de saldo de conta ocorridas. Em seguida, o usuário pode 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 de Merkle do saldo atual.

Isso permite economizar custos e espaço de bloco significativos (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 oficial fornecido aos usuários usando a cadeia de blocos, ou seja, transações sem 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 retirada do usuário é colocar os dados em outro lugar fora da cadeia de blocos. Isso introduz problemas sutis, onde 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 de blocos BTC, as regras de consenso podem garantir que eles estejam absolutamente corretos. No entanto, quando eles são publicados em sistemas externos, o melhor que eles podem fazer é verificar uma prova SPV, ou seja, que os dados foram publicados em outro sistema.

Isso requer uma prova de que os dados estão presentes em outras cadeias que não na cadeia, o que é essencialmente um problema de Máquina Oracle. A cadeia de blocos do Bitcoin não pode verificar completamente nada que aconteça fora de sua própria cadeia de blocos, exceto por verificar os ZKP. No entanto, os ZKP não podem verificar se um bloco contendo dados de rollup foi realmente divulgado publicamente após a geração. Eles não podem 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, promessas de publicação de dados e uso para impulsionar rollup, mas os dados não estão realmente disponíveis. Isso impede que os usuários retirem fundos. A única solução real é depender totalmente do valor e estrutura de incentivo de sistemas além do BTC.

Encontrar-se numa situação difícil

Isso coloca o rollup em um dilema. Quando se trata de problemas de disponibilidade de dados, basicamente existe uma escolha binária entre publicar dados na blockchain 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 definirá 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 número total de transações que todos os rollups podem processar fora da cadeia. A cada atualização do rollup, o espaço do Bloco deve ser proporcional ao número de contas cujos saldos mudaram desde a última atualização. A teoria da informação permite que os dados sejam comprimidos até certo ponto, e não há mais potencial de expansão nesse ponto.

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. 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 poderá ser alterado. Com o uso de Validiums, essa garantia depende inteiramente da capacidade do sistema externo de resistir a 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 produzindo Bloco em vez de realmente transmitir o Bloco, tornando os dados disponíveis.

Então, se conseguirmos realmente implementar uma implementação ideal de Rollup no BTC e permitir retiradas unilaterais dos usuários, como seria isso?