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

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

Rollups tornou-se recentemente o foco da expansão do BTC, tornando-se a primeira coisa a realmente roubar o protagonismo da Rede de iluminação e obter uma atenção mais ampla. Rollups têm como objetivo ser uma segunda camada fora da cadeia, não limitada ou restringida pela liquidez central da Rede de iluminação, ou seja, os usuários finais precisam que alguém aloque (ou ‘empreste’) fundos com antecedência para poderem 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 desenvolvidos para serem executados em plataformas como Ethereum e outras plataformas Turing Completo, mas recentemente houve um foco em portá-los 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 dependem de capacidades ainda 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 no BTC) armazena o saldo de todos os usuários no Rollup. Essa UTXO contém um compromisso na forma de uma raiz de Merkle da árvore de Merkle, comprometendo todos os saldos atuais das contas existentes no Rollup. Todas essas contas são autorizadas com chaves públicas/privadas, portanto, os usuários ainda precisam assinar determinado conteúdo com uma Chave Secreta para fazer transações fora da cadeia. Essa parte da estrutura permite que os usuários saiam a qualquer momento, sem permissões, bastando provar que sua conta faz parte da árvore de Merkle, para que possam 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 ao concluir a transação fora da cadeia. 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 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 de Merkle for publicada na cadeia, os usuários poderão visualizá-la e acessá-la, mas como eles colocam seus ramos na árvore para que possam sair sem permissão quando quiserem?

Rollup adequado

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 cadeia de blocos. 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á o saldo e as contas serão adicionadas apenas nas transações de atualização do Rollup.

Em implementações mais avançadas, é utilizado o diferencial de saldo. Isso essencialmente resume quais contas aumentaram ou diminuíram os fundos durante o processo de atualização. Isso permite que cada atualização de Rollup contenha apenas as alterações de saldo de conta 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, permitindo que eles reconstruam a árvore Merkle do saldo atual.

Dessa forma, é possível economizar uma grande quantidade de despesas e espaço de Bloco (economizando assim dinheiro), ao mesmo tempo 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 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

Uma outra forma de lidar com a questão da disponibilidade dos dados de retirada do utilizador é colocar os dados noutro local fora da cadeia de blocos. Isto levanta questões subtils, pois o rollup ainda precisa de garantir que os dados estão disponíveis noutro local. Tradicionalmente, outras cadeias de blocos são usadas para este propósito, sendo especificamente concebidas como uma camada de disponibilidade de dados para sistemas como o 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 eles estão absolutamente corretos. No entanto, quando são publicados em sistemas externos, o melhor que podem fazer é verificar a prova SPV, ou seja, que os dados foram publicados em outro sistema.

Isto requer provas de que os dados estão na cadeia de outros, este é essencialmente um problema de Máquina Oracle. A cadeia de Blocos do Bitcoin não consegue verificar completamente qualquer coisa que aconteça fora da sua própria cadeia, a melhor coisa que pode fazer é verificar ZKP. No entanto, ZKP não consegue verificar se os dados de rollup na cadeia de blocos, depois de gerados, foram realmente divulgados publicamente. Não pode verificar se as informações externas foram realmente tornadas públicas para todos.

Isso abriu a porta para ataques de retenção de dados, ou seja, criar compromissos com os dados publicados e usá-los para impulsionar rollup, mas os dados não estão realmente disponíveis. Isso faz com que os usuários não consigam recuperar os fundos. A única solução real é depender totalmente do valor e da estrutura de incentivos de sistemas fora do BTC.

A situação é delicada

Isto 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. 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 definirá um limite rígido para a escalabilidade do rollup. O espaço Bloco é limitado, o que define um limite para a quantidade de rollups que podem existir ao mesmo tempo 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 só permite que os dados sejam comprimidos até certo ponto, o que significa que não há mais potencial de escalabilidade.

Por outro lado, usar diferentes camadas para implementar a disponibilidade de dados eliminará o limite máximo de escalabilidade dos ganhos, mas também trará novas questões de segurança e soberania. Em um Rollup que usa BTC para implementar a disponibilidade de dados, se os dados que o usuário precisa extrair não forem publicados automaticamente na blockchain, o estado do Rollup não poderá ser alterado. Com 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 Blocos em vez de transmitir realmente esse Bloco, garantindo assim a disponibilidade dos dados.

Então, se realmente conseguirmos implementar o Rollup ideal no BTC, alcançando verdadeiramente levantamentos unilaterais dos usuários, como seria isso?