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

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

Rollups recentemente tornaram-se o foco da expansão do BTC, tornando-se a primeira coisa a realmente roubar o protagonismo da Rede de iluminação em termos de atenção mais ampla. Rollups pretendem ser uma segunda camada fora da cadeia, sem as restrições de Liquidez do núcleo da Rede de iluminação, ou seja, os usuários finais precisam que alguém alocasse antecipadamente (ou ‘emprestasse’) fundos para 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 operar em blockchains Turing Completo, como Ethereum e outros, mas recentemente houve um foco na sua portabilidade para blockchains baseadas em UTXO, como 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 atualmente 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 em forma de raiz de Merkle da árvore de Merkle que compromete todos os saldos atuais das contas existentes no Rollup. Todas essas contas são autorizadas por Chave pública/Chave privada, portanto, para gastar fora da cadeia, os usuários ainda precisam assinar algo com Chave Secreta. Essa parte da estrutura permite que os usuários saiam a qualquer momento sem permissão, basta fazer uma transação provando que sua conta faz parte da árvore Merkle, eles podem sair unilateralmente do Rollup sem a permissão do operador.

Os operadores de Rollup devem incluir um ZKP nas transações para atualizar o saldo da conta na cadeia, durante o processo de conclusão das transações fora da cadeia. Se não houver ZKP, a transação será inválida e não poderá ser incluída no bloco. Esta prova permite que as pessoas verifiquem se todas as alterações nas contas fora da cadeia foram devidamente autorizadas pelo titular da conta e se o operador não atualizou os saldos 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, como os usuários podem colocar seus ramos na árvore para poderem sair sem permissão quando desejarem?

Rollup adequado

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

Em implementações mais avançadas, use diferenças de equilíbrio. Isto essencialmente resume quais contas aumentaram ou diminuíram os fundos durante o processo de atualização. Isso faz com que cada atualização do Rollup contenha 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 saldo da conta, permitindo-lhes reconstruir a árvore de Merkle do saldo atual.

Isso pode economizar muito dinheiro e espaço de bloco (economizando fundos), enquanto ainda 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 oficial fornecido aos usuários usando a cadeia de blocos, ou seja, transações que não incluem resumos ou diferenças de contas são consideradas inválidas.

Validade

Outra forma de lidar com a questão da disponibilidade de dados de retirada do utilizador é colocar os dados noutro local que não seja na cadeia de blocos. Isso introduz um problema subtil, em que o rollup ainda precisa garantir que os dados estejam disponíveis noutro local. Tradicionalmente, outras cadeias de blocos são usadas para esse fim, especialmente projetadas como camadas de disponibilidade de dados para sistemas como o 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 estejam absolutamente corretos. No entanto, quando são publicados em sistemas externos, a melhor coisa que podem fazer é verificar a prova SPV, ou seja, que os dados foram publicados em outro sistema.

Esta necessita de uma prova de que os dados estão na cadeia de bloco externa, que é em última análise um problema da Máquina Oracle. A cadeia de bloco do BTC não consegue verificar completamente qualquer coisa que aconteça fora da sua própria cadeia de bloco, exceto por ZKP. No entanto, o ZKP não pode verificar se os dados de rollup do bloco, gerados, são realmente transmitidos publicamente. Não consegue verificar se a informação externa é realmente pública para todos.

Isso abre as portas para um ataque de retenção de dados, ou seja, criar compromissos em relação aos 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 seus fundos. A única solução real é depender completamente de um sistema de valor e incentivo além do BTC.

Entre a Espada e a Parede

Isto coloca 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 bloqueios 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 BTC como camada de disponibilidade de dados impõe um limite rígido à escalabilidade do rollup. O espaço do bloco é limitado, o que estabelece um limite para o número de rollup 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 uma quantidade proporcional de espaço de bloco para 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, o uso de diferentes camadas para garantir 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 utiliza BTC para garantir 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 os Validiums, essa garantia depende inteiramente da capacidade do sistema externo utilizado para resistir a fraudes e ocultação de dados.

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

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