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

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

Rollups has recently become the focus of BTC scalability, becoming the first thing to truly steal the spotlight from the Lightning Network, in terms of broader attention. Rollups aims to be an off-chain second layer that is not constrained or limited by the Liquidity constraints of the Lightning Network core, that is, end users need someone to pre-allocate (or ‘lend’) funds in order to receive money, or intermediate routing nodes need channel balances to facilitate the full flow of payment amounts from sender to receiver.

Estes sistemas foram inicialmente implementados em Ethereum e outros sistemas Turing Completo, mas recentemente o foco mudou para 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 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 zero conhecimento prova (ZKP) diretamente 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, portanto, para realizar gastos fora da cadeia, os usuários ainda devem assinar alguns conteúdos com a Chave Secreta. Esta parte da estrutura permite que os usuários saiam a qualquer momento sem permissão, apenas provando que suas contas são parte da árvore de Merkle, eles podem sair unilateralmente do Rollup, sem a necessidade de permissão do operador.

Os operadores de Rollup devem incluir um ZKP nas transações para atualizar o saldo da conta na cadeia ao concluir transações fora da cadeia. Sem este ZKP, a transação será inválida e não pode ser incluída na cadeia de blocos. 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 os 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, o usuário poderá visualizá-la e acessá-la, mas como eles colocam seus ramos na árvore para sair sem permissão quando quiserem?

Rollup apropriado

Em um Rollup apropriado, cada vez 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, 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á 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 equilíbrio. Isso essencialmente resume quais contas tiveram aumento ou redução de fundos durante o processo de atualização. Isso faz com que cada atualização do Rollup inclua apenas as alterações de saldo da 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 equilíbrio da conta, permitindo-lhes reconstruir a árvore de Merkle do equilíbrio atual.

Isso permite economizar custos e espaço de bloco (economizando dinheiro), ao mesmo tempo em que permite que os usuários mantenham acesso às informações necessárias para sair unilateralmente. As regras do rollup exigem que esses dados sejam incluídos no rollup formal fornecido aos usuários usando a blockchain, ou seja, transações que não incluem resumo de conta ou diferenças de conta são consideradas inválidas.

Período 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 levanta questões sutis, 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 como camada de disponibilidade de dados para sistemas como o rollup.

Isto cria um dilema de segurança igualmente poderoso. Quando os dados são publicados diretamente na cadeia BTCBloco, as regras do Consenso podem garantir que estejam absolutamente corretos. No entanto, quando são publicados num sistema externo, o melhor que podem fazer é verificar a prova SPV, ou seja, que os dados foram publicados noutro sistema.

Isso requer prova de que os dados estão presentes em outros blocos da cadeia, o que acaba sendo um problema da Máquina Oracle. A cadeia de blocos do BTC não pode verificar completamente qualquer coisa que aconteça fora do seu próprio bloco, o melhor que pode fazer é verificar o ZKP. No entanto, o ZKP não pode verificar se o bloco que contém os dados do rollup foi realmente transmitido publicamente após a geração. Não pode verificar se as informações externas realmente foram tornadas públicas para todos.

Isto abriu a porta 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 os usuários de retirar fundos. A única solução real é depender completamente do valor e estrutura de incentivos de sistemas fora do BTC.

Entra e Sai do Vale

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

Por um lado, usar a cadeia BTC como camada de disponibilidade de dados impõe um limite rígido à escalabilidade do rollup. O espaço de Bloco é limitado, o que estabelece um limite para o número de rollups que podem existir ao mesmo tempo e para o número total de transações que todos os rollups juntos podem processar fora da cadeia. Cada atualização do rollup requer um espaço de Bloco proporcional ao número de contas cujo saldo mudou desde a última atualização. A teoria da informação permite apenas que os dados sejam comprimidos até certo ponto, a partir do qual não há mais potencial de expansão.

Por outro lado, o uso de diferentes camadas para alcançar a disponibilidade de dados eliminará o limite rígido de escalabilidade, mas também trará novos problemas de segurança e soberania. Em Rollups que usam BTC para alcançar a disponibilidade de dados, se os dados que os usuários precisam extrair não forem publicados automaticamente 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 à 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, tornando os dados disponíveis, produzindo Blocos em vez de transmitir o Bloco real.

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