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

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

Rollups recentemente tornou-se o foco da expansão do BTC, tornando-se a primeira coisa a roubar o holofote da Rede de iluminação e ganhando uma atenção mais ampla. Os Rollups têm 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 que alguém alocasse (ou ‘emprestasse’) fundos antecipadamente para receber dinheiro, ou os Nós intermediários precisam de saldo de canal para facilitar o fluxo completo do valor do remetente para o destinatário.

Esses sistemas foram originalmente implementados no Ethereum e em outros sistemas Turing Completo, mas recentemente o foco tem sido em portá-los para blockchains baseadas em UTXO (como o BTC). Este artigo não pretende discutir a implementação atual no BTC, mas sim as funcionalidades do Rollup idealizado que dependem de recursos que o BTC atualmente não suporta, como a capacidade de verificar provas de conhecimento zero (ZKP) diretamente no BTC.

A arquitetura básica do Roll é a seguinte: uma única conta (UTXO no BTC) que armazena o saldo de todos os usuários no Rollup. Essa UTXO contém um compromisso, que existe como a raiz de uma árvore de Merkle, comprometendo todos os saldos atuais das contas existentes no Rollup. Todas essas contas são autorizadas usando chave pública/chave privada, portanto, para fazer gastos fora da cadeia, os usuários ainda precisam assinar determinados conteúdos com a Chave Secreta. Essa parte da estrutura permite que os usuários saiam a qualquer momento sem permissão, apenas provando por meio de uma transação que sua conta faz parte da árvore de Merkle, eles podem sair do Rollup unilateralmente, sem a permissão do operador.

Os operadores de Rollup devem incluir um ZKP nas transações para atualizar na cadeia o saldo da conta durante o processo de conclusão das transações fora da cadeia. Sem este ZKP, a transação será 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 de forma maliciosa 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 for publicada na cadeia, os utilizadores podem visualizá-la e aceder-lhe, mas como podem colocar os seus ramos na árvore para poderem sair sem permissão quando desejarem?

Rollup adequado

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

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

Dessa forma, é possível economizar uma grande quantidade de despesas e espaço de Bloco (economizando assim fundos), ao mesmo tempo que permite aos usuários garantir o acesso às informações necessárias para a saída unilateral. As regras do rollup exigem que esses dados sejam incluídos no rollup formal fornecido aos usuários usando a cadeia de Bloco, ou seja, transações que não incluem um resumo de conta ou diferenças de conta são consideradas inválidas.

Prazo de validade

Outra abordagem para lidar com a questão da disponibilidade dos dados de retirada do usuário é colocar os dados em outro lugar fora da cadeia de blocos. Isso introduz um problema sutil, 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 camada de disponibilidade de dados para sistemas como o rollup.

Isto cria um dilema em que a segurança é igualmente forte. Quando os dados são publicados diretamente na cadeia BTCBloco, as regras de Consenso podem garantir que estejam absolutamente corretos. No entanto, quando 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 uma 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, a melhor coisa que pode fazer é verificar ZKP. No entanto, o ZKP não pode verificar se o bloco que contém os dados do rollup realmente foi divulgado publicamente após a geração. Não pode verificar se as informações externas foram realmente tornadas públicas para todos.

Este abriu a porta para ataques de retenção de dados, ou seja, criar compromissos para dados publicados e usá-los para impulsionar rollup, mas os dados não estão realmente disponíveis. Isso impede que os utilizadores retirem fundos. A única solução verdadeira é depender completamente do valor e estrutura de incentivos fora do BTC.

Enfrentando um dilema

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 noutro local. Esta escolha tem um impacto significativo na segurança, soberania e escalabilidade do rollup.

Por um lado, o uso da cadeia de blocos BTC como camada de disponibilidade de dados impõe um limite rígido à escalabilidade do rollup. O espaço do bloco é limitado, o que define um limite para a quantidade de rollups que podem existir de uma vez e para o número 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 só permite que os dados sejam comprimidos até certo ponto, e nesse ponto não há mais 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 novas questões de segurança e soberania. No Rollup que usa BTC para obter 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 ser alterado. Com o uso de Validiums, essa garantia depende inteiramente da capacidade do sistema externo de resistir a fraudes e ocultação de dados.

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

Então, se conseguirmos realmente implementar o Rollup ideal no BTC, permitindo verdadeiramente levantamentos unilaterais dos utilizadores, como seria isso?