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

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

Rollups tornaram-se recentemente 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. Os Rollups têm como objetivo ser uma segunda camada fora da cadeia que não está sujeita às restrições ou limitações de liquidez do núcleo da Rede de iluminação, ou seja, os usuários finais precisam que alguém aloque antecipadamente (ou ‘empreste’) fundos para receber dinheiro, ou os nós intermediários precisam de saldo de canal para facilitar o fluxo total dos pagamentos do remetente ao destinatário.

Estes sistemas foram originalmente implementados em Ethereum e outros sistemas Turing Completo, mas recentemente houve um foco na sua portabilidade para blockchains baseados em UTXO, como BTC. Este artigo não tem a intenção de discutir o estado atual da implementação em BTC, mas sim discutir as funcionalidades ideais do Rollup que têm sido procuradas há muito tempo, dependendo da capacidade de verificar diretamente provas de conhecimento zero (ZKP) em BTC, o que atualmente não é suportado.

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, compromisso de todos os saldos atuais das contas no Rollup. Todas essas contas são autorizadas com Chave pública/Chave privada, portanto, para fazer gastos fora da cadeia, os usuários ainda precisam assinar algum conteúdo com Chave Secreta. Esta parte da estrutura permite que os usuários saiam a qualquer momento sem permissão, apenas provando que suas contas fazem parte da árvore de Merkle, eles podem sair unilateralmente do Rollup, sem a necessidade de permissão do operador.

Os operadores Rollup devem incluir um ZKP nas transações para atualizar a raiz do merkle do 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 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 usuários podem visualizá-la e acessá-la, então como eles podem colocar seus ramos na árvore para que possam sair quando quiserem sem permissão?

Rollup adequado

Em um Rollup apropriado, cada vez que uma nova transação fora da cadeia é confirmada e o estado da conta do 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á os saldos e as contas sã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, isso é um resumo de quais contas tiveram fundos adicionados ou removidos durante o processo de atualização. Isso permite que cada atualização do Rollup contenha apenas as mudanças de equilíbrio de contas que ocorreram. Em seguida, os usuários podem simplesmente varrer a cadeia e ‘calcular’ a partir do início do Rollup para obter o estado atual do equilíbrio de contas, permitindo que eles reconstruam a árvore de Merkle do equilíbrio de contas atual.

Isso permite economizar custos e espaço de bloco (economizando assim dinheiro), ao mesmo tempo em que permite que os usuários garantam 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 por meio de uma cadeia de blocos, 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

Uma outra forma de lidar com a questão da disponibilidade dos dados de retirada dos utilizadores é colocar os dados noutro local fora da cadeia Bloco. Isto levanta a delicada questão de garantir que os dados continuem a estar disponíveis nesse local. Tradicionalmente, outras cadeias Bloco são usadas para este fim, especialmente concebidas como camadas de disponibilidade de dados para sistemas como rollup.

Isto cria um dilema de segurança igualmente poderoso. 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 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 outras cadeias, o que é essencialmente um problema de Máquina Oracle. A cadeia de blocos do BTC não pode validar completamente nada além do que acontece em sua própria cadeia de blocos, o melhor que pode fazer é validar ZKP. No entanto, ZKP não pode verificar se o bloco contendo os dados 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.

Isso abriu a porta para ataques de retenção de dados, ou seja, criar compromissos com dados publicados e utilizá-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 totalmente do valor e da estrutura de incentivos de sistemas além do BTC.

Entre a espada e a parede

Isso apresenta um dilema para 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 impacto significativo na segurança, soberania e escalabilidade do rollup.

Por um lado, usar a cadeia de blocos BTC como camada de disponibilidade de dados imporá 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 ao mesmo tempo e o total de transações que podem ser processadas fora da cadeia. Cada atualização do rollup requer um 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, o que significa que 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 de escalabilidade, mas também traz novas questões de segurança e soberania. Em Rollups que usam BTC para disponibilidade de dados, se os dados que o usuário deseja extrair não forem automaticamente publicados na blockchain, o estado do Rollup não pode ser alterado. Com 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 BTCRollup, tornando os dados disponíveis, produzindo Bloco em vez de transmitir o Bloco real.

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