Bitcoin Magazine: Que dilema o Rollup enfrenta?

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

Rollups têm sido recentemente o foco da expansão do BTC e se tornaram a primeira coisa a realmente roubar o holofote da Rede de iluminação, em termos de maior atenção. Rollups visam ser uma segunda camada fora da cadeia que não é limitada ou restrita pela Liquidez central da Rede de iluminação, ou seja, os usuários finais precisam que alguém alocar antecipadamente (ou ‘emprestar’) fundos para que eles possam receber dinheiro, ou intermediários Nós precisam de saldo de canal para facilitar o fluxo completo do valor do remetente para o destinatário.

Esses sistemas eram originalmente executados no Ethereum e em outros sistemas Turing Completo, mas recentemente o foco mudou para a portabilidade deles para blockchains baseadas em UTXO (por exemplo, BTC). Este artigo não pretende discutir o estado atual da implementação no BTC, mas sim a funcionalidade idealizada de Rollup que as pessoas têm buscado há muito tempo, que depende da capacidade de verificação direta de Prova de conhecimento zero (ZKP) no BTC, o que atualmente não é suportado.

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 fazer gastos fora da cadeia, os usuários ainda devem 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 de Merkle, eles podem sair do Rollup unilateralmente, sem a necessidade de permissão do operador.

O operador do Rollup deve incluir uma prova de conhecimento-zero (ZKP) nas transações para atualizar a raiz de Merkle do saldo da conta na cadeia quando as transações fora da cadeia são concluídas. Sem essa ZKP, a transação será inválida e não pode 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 desonestamente para outros usuários.

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

Rollup adequado

Em um Rollup apropriado, sempre que uma nova transação fora da cadeia é confirmada e o estado da conta Rollup é alterado, as informações são diretamente inseridas 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, todos os resumos das contas existentes no Rollup conterão os saldos e as contas são adicionadas apenas nas transações de atualização do Rollup.

Em implementações mais avançadas, variações de equilíbrio são usadas. Trata-se, essencialmente, de um resumo do financiamento que aumentou ou diminuiu durante o processo de atualização. Isso faz com que cada atualização do Rollup contenha apenas as alterações de saldo de conta que ocorrem. O usuário pode então simplesmente digitalizar a cadeia e “fazer o cálculo” desde o início do Rollup para chegar ao estado atual do saldo da conta, o que lhe permite reconstruir a árvore Merkle do saldo atual.

Desta forma, é possível poupar uma grande quantidade 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 a saída unilateral. As regras do rollup exigem que estes dados sejam incluídos no rollup formal fornecido aos utilizadores utilizando a cadeia de blocos, ou seja, as transações que não incluem o resumo da conta ou a diferença de conta são consideradas inválidas.

Período de validade

Outra forma de lidar com a questão da disponibilidade dos dados de retirada do utilizador é colocar os dados em algum lugar fora da cadeia de blocos. Isso introduz uma questão sutil, o rollup ainda precisa garantir que os dados estejam disponíveis em outro lugar. Tradicionalmente, outras cadeias de blocos foram usadas para esse propósito, 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 diretamente publicados na cadeia de blocos BTC, as regras de consenso podem garantir que estejam absolutamente corretos. No entanto, quando são publicados em sistemas externos, o melhor que eles podem fazer é verificar a prova de 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 de Máquina Oracle. A cadeia de blocos do BTC não pode verificar completamente nada além do que acontece em sua própria cadeia de blocos, o melhor que pode fazer é verificar a Prova de Conhecimento Zero (ZKP). No entanto, a ZKP não pode verificar se o bloco que contém os dados do rollup foi realmente transmitido publicamente após sua geração. Não pode verificar se as informações externas realmente estão disponíveis para todos.

Isso abriu as portas para um ataque de retenção de dados, ou seja, criando compromissos em relação à publicação de 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 seus fundos. A única solução real é depender totalmente de um sistema de valor e incentivo fora do BTC.

Entre a espada e a parede

Isto coloca o rollup numa situação difícil. Quando se trata de questões de disponibilidade de dados, basicamente existe uma escolha binária entre publicar os dados na cadeia de blocos BTC ou em outro lugar. 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 imporia um limite rígido à escalabilidade do rollup. O espaço do Bloco é limitado, o que impõe um limite à quantidade de rollup que pode existir de uma vez, bem como à quantidade total de transações que podem ser processadas fora da cadeia. Cada atualização do rollup requer espaço de Bloco proporcional à quantidade de contas cujos saldos mudaram desde a última atualização. A teoria da informação só permite que os dados sejam comprimidos até certo ponto, e isso limita o potencial de escalabilidade.

Por outro lado, o uso de camadas diferentes 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 Rollups que usam BTC para alcançar a disponibilidade de dados, se os dados que o usuário deseja extrair não forem publicados automaticamente na blockchain, o estado do Rollup não poderá mudar. Em Validiums, essa garantia depende totalmente da capacidade dos sistemas externos utilizados de resistir a fraudes e ocultação de dados.

Agora, qualquer produtor de Blocos no sistema de disponibilidade de dados externos pode tomar posse dos fundos dos usuários do BTCRollup produzindo Blocos em vez de transmitir efetivamente esses Blocos, tornando os dados disponíveis.

Então, como seria se realmente implementássemos uma implementação ideal de Rollup no BTC, com retiradas unilaterais do usuário?