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

Fonte: Bitcoin Magazine; Compilação: Five Baht, Golden Finance

Rollups tornou-se recentemente o foco da escalabilidade do BTC, tornando-se a primeira coisa a realmente roubar o show da Rede de iluminação, ganhando mais atenção. Rollups visa 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 ter fundos alocados (ou ‘emprestados’) antecipadamente para receber dinheiro, ou os nós intermediários precisam de saldo de canal para facilitar o fluxo total do montante do pagamento do remetente ao destinatário.

Estes sistemas foram inicialmente desenvolvidos para serem executados em sistemas Turing Completo como Ethereum e outros, mas recentemente houve um foco na sua portabilidade para blockchains baseadas em UTXO, como o BTC. Este artigo não pretende discutir a implementação atual no BTC, mas sim as funcionalidades idealizadas de Rollup, que dependem de capacidades atualmente não suportadas pelo BTC, ou seja, a capacidade de verificar diretamente Prova de conhecimento zero (ZKP) no BTC.

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 com Chave pública/Chave privada, então, para fazer gastos fora da cadeia, os usuários ainda precisam assinar algo com Chave Secreta. Esta 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.

Os operadores Rollup devem incluir um ZKP nas transações para atualizar a raiz de merkle do saldo da conta na cadeia após a conclusão da transação fora da cadeia. Sem o ZKP, a transação é inválida e não pode ser incluída no bloco. Esta 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 maliciosamente para roubar fundos dos usuários ou redistribuí-los desonestamente para outros usuários.

A questão é, se apenas a raiz da árvore de merkle é publicada na cadeia, os usuários podem visualizá-la e acessá-la, então como eles colocam seus ramos na árvore para poderem sair sem permissão quando desejarem?

Rollup Apropriado

Em um Rollup apropriado, toda vez que uma nova transação fora da cadeia é confirmada e o estado da conta do Rollup é alterado, 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 são apenas adicionadas nas transações de atualização do Rollup.

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

Isso pode economizar muito dinheiro e espaço de bloco (economizando dinheiro), enquanto ainda permite que os usuários garantam 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 bloco, ou seja, as transações que não incluem um resumo ou diferença de conta são consideradas transações inválidas.

Prazo de validade

Outra forma de lidar com a questão da disponibilidade de dados de retirada de usuários é colocar os dados em outro lugar que não seja na cadeia de blocos. Isso levanta questões delicadas, 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 para servir como camada de disponibilidade de dados para sistemas como rollup.

Isso cria um dilema de segurança igualmente desafiador. Quando os dados são publicados diretamente na cadeia de blocos do Bitcoin, as regras de consenso podem garantir que eles estejam absolutamente corretos. No entanto, quando eles são publicados em um sistema externo, o melhor que podem 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 outros blocos da cadeia, o que é essencialmente um problema da Máquina Oracle. A cadeia de blocos do BTC não pode verificar completamente nada além do que acontece em seu próprio bloco na cadeia, o melhor que pode fazer é verificar ZKP. No entanto, ZKP não pode verificar se o bloco, que contém os dados do rollup, é realmente divulgado publicamente após a geração. Não pode verificar se as informações externas realmente estão disponíveis para todos.

Isso abriu caminho 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 impede que os usuários retirem fundos. A única solução real é depender completamente do valor e da estrutura de incentivos de sistemas fora do BTC.

Dilema

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 blockchain BTC ou em outro lugar. Essa 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 ao número de rollups que podem existir ao mesmo tempo e à quantidade total de transações que todos os rollups podem processar fora da cadeia. Cada atualização do rollup exige um 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, 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 novas questões de segurança e soberania. Em Rollup que usa BTC para alcançar a disponibilidade de dados, se os dados que os usuários precisam extrair não forem automaticamente publicados na blockchain, o estado do Rollup não pode mudar. Com Validiums, essa garantia depende inteiramente da capacidade dos sistemas externos utilizados para resistir à fraude e ocultação de dados.

Agora, qualquer produtor de Bloco em um sistema de disponibilidade de dados externos pode sequestrar os fundos dos usuários do BTCRollup produzindo um Bloco em vez de realmente transmitir esse Bloco, tornando os dados disponíveis.

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