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

Fonte: Bitcoin Magazine; Compilado por: Wu Zhu, Jinse Finance

Rollups has recently become the focus of BTC expansion, becoming the first thing that really steals the limelight from the Lightning Network and gains wider attention. Rollups aims to be an off-chain second layer that is not restricted or limited by the core Liquidez of the Lightning Network, which means that end users need someone to allocate (or “lend”) funds in advance 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 executados em Ethereum e outros sistemas Turing Completo, mas recentemente o foco mudou para a sua portabilidade para blockchains baseados em UTXO (como o BTC). Este artigo não pretende discutir o estado atual da implementação no BTC, mas sim as funcionalidades do idealizado Rollup que têm sido perseguidas a longo prazo, dependendo da capacidade de verificar diretamente a prova de conhecimento zero (ZKP) no BTC, o que não é suportado atualmente.

A estrutura básica do Roll é a seguinte: uma única conta (UTXO em BTC) armazena 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 usando Chave pública/Chave privada, portanto, para fazer gastos fora da cadeia, os usuários ainda devem assinar alguma informação usando 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 do Rollup unilateralmente, sem a necessidade de permissão do operador.

Os operadores de Rollup devem incluir um ZKP na transação para atualizar a raiz merkle do saldo da conta na cadeia quando uma transação fora da cadeia é concluída. Sem este 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 proprietário 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 Merkle for publicada na cadeia, os usuários podem visualizá-la e acessá-la, mas como eles podem colocar seus ramos na árvore para poderem sair sem permissão quando quiserem?

Rollup Apropriado

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

Em implementações mais avançadas, utiliza-se a diferença de equilíbrio de contas. Essencialmente, trata-se de um resumo de quais contas aumentaram ou diminuíram os fundos durante o processo de atualização. Isso permite que cada atualização do Rollup contenha apenas as alterações de saldo de conta ocorridas. Em seguida, os usuários podem simplesmente percorrer a cadeia e ‘calcular’ a partir do início do Rollup para obter o estado atual do saldo de contas, o que lhes permite reconstruir a árvore de Merkle do saldo atual.

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

Prazo de validade

Outra abordagem para lidar com a questão da disponibilidade de dados de retirada do usuário é colocar os dados em outros lugares fora da cadeia de bloco. Isso introduz um problema sutil, rollup ainda precisa garantir que os dados estejam disponíveis em outros lugares. Tradicionalmente, outras cadeias de bloco são usadas para esse fim, projetadas especificamente para servir como camada de disponibilidade de dados para sistemas como rollup.

Isto cria um dilema de segurança igualmente forte. 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 num sistema externo, o melhor que podem fazer é verificar a prova SPV, ou seja, que os dados foram publicados noutro sistema.

Isso requer uma prova de que os dados existem em outras cadeias que não a própria cadeia, e isso é, em última análise, um problema da Máquina Oracle. A cadeia de blocos do Bitcoin não pode verificar completamente nada além do que acontece em sua própria cadeia de blocos, o melhor que pode fazer é verificar o ZKP. No entanto, o ZKP não pode verificar se o bloco contendo dados de rollup foi realmente transmitido publicamente após a geração. Ele não pode verificar se as informações externas foram realmente tornadas públicas para todos.

Isto abriu a porta para ataques de retenção de dados, ou seja, criar compromissos para dados publicados e utilizá-los para impulsionar rollup, mas os dados não estão realmente disponíveis. Isto faz com que os utilizadores não consigam retirar fundos. A única solução verdadeira é depender completamente do valor e estrutura de incentivos de sistemas que não se baseiam no BTC.

Entre a espada e a parede

Isso apresenta um dilema para o rollup. Quando se trata de problemas de disponibilidade de dados, basicamente existe uma escolha binária entre publicar dados na cadeia de blocos BTC ou em outro lugar. Essa escolha tem um grande impacto na segurança, soberania e escalabilidade do rollup.

Por um lado, usar a cadeia BTCBloco como camada de disponibilidade de dados definiria um limite rígido para a escalabilidade do rollup. O espaço do Bloco é finito, o que impõe um limite à quantidade de rollups que podem existir de uma vez e à 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 a partir daí 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 um Rollup que utiliza 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 poderá mudar. Com o uso de Validiums, essa garantia depende inteiramente da capacidade dos sistemas externos utilizados para 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 do BTCRollup produzindo Blocos em vez de realmente transmitir o Bloco, tornando os dados disponíveis.

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