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

Source: Bitcoin Magazine; Compilation: Wuzhu, Golden Finance

Rollups têm sido o foco da escalabilidade do BTC recentemente, tornando-se a primeira coisa a realmente roubar o centro das atenções da Rede de iluminação em termos de maior visibilidade. O objetivo do Rollups é ser uma camada fora da cadeia que não seja restrita ou limitada pela liquidez central 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 ter saldo de canal para facilitar o fluxo total do valor do remetente para o destinatário.

Estes sistemas foram inicialmente desenvolvidos para serem executados em blockchains Turing Completo como o Ethereum e outras, mas recentemente a atenção tem-se voltado para a sua portabilidade para blockchains baseadas em UTXO, como o BTC. Este artigo não pretende discutir a implementação atual no BTC, mas sim abordar as funcionalidades ideais de um Rollup, que dependem da capacidade de verificação direta de Prova de conhecimento zero (zk-SNARKs), que o BTC não suporta atualmente.

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 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 permissão do operador.

O operador do Rollup deve incluir uma prova de conhecimento-zero (ZKP) nas transações para atualizar o saldo da conta na cadeia durante o processo de conclusão da transação fora da cadeia. Sem essa ZKP, a transação será inválida e não poderá ser incluída no bloco da cadeia. Essa 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.

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 colocam seus ramos na árvore para poderem sair quando quiserem sem permissão?

Rollup adequado

Em um Rollup apropriado, sempre 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 de contas. Isso essencialmente resume quais contas tiveram acréscimos ou decréscimos de fundos durante o processo de atualização. Isso faz com que cada atualização do Rollup contenha apenas as alterações de equilíbrio de contas 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 equilíbrio de contas, permitindo-lhes reconstruir a árvore de Merkle do equilíbrio atual.

Isso permite economizar muito dinheiro e espaço em Bloco (economizando assim dinheiro), permitindo ao mesmo tempo 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 Bloco, ou seja, transações que não incluem o resumo da conta ou diferenças de conta são consideradas inválidas.

Prazo de Validade

Outra forma de lidar com a questão da disponibilidade dos dados de retirada do utilizador é colocar os dados noutro local fora da cadeia de blocos. Isto levanta uma questão subtil, uma vez que o rollup ainda precisa garantir que os dados estejam disponíveis noutro local. Tradicionalmente, outras cadeias de blocos são usadas para este fim, especialmente concebidas como camada de disponibilidade de dados para sistemas como o rollup.

Isto criou um dilema de segurança igualmente forte. Quando os dados são diretamente publicados 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, os dados foram publicados noutro sistema.

Isso requer prova de que os dados existem em outras cadeias, o que é essencialmente um problema da Máquina Oracle. A cadeia de blocos do BTC não pode verificar totalmente qualquer coisa que aconteça fora de sua própria cadeia de blocos, exceto validar ZKP. No entanto, ZKP não pode verificar se os blocos contendo dados de rollup foram realmente publicados após a geração. Também não pode verificar se as informações externas foram realmente tornadas públicas para todos.

Isto abriu a porta para ataques de bloqueio de dados, ou seja, criar compromissos para publicar dados e usá-los para impulsionar o rollup, mas na realidade os dados não estão disponíveis. Isso faz com que os utilizadores não consigam retirar fundos. A única solução real é depender totalmente do valor e da estrutura de incentivos de sistemas para além do BTC.

A encruzilhada

Isto coloca o rollup num dilema. 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 em outro lugar. 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 definirá um limite rígido para a 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 a quantidade total de transações que podem ser processadas fora da cadeia. A cada atualização do rollup, é necessário um espaço de bloco proporcional ao número de contas cujo saldo tenha mudado desde a última atualização. A teoria da informação permite apenas uma compressão de dados até certo ponto, e nesse ponto não há mais potencial de escalabilidade.

Por outro lado, usar 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. No Rollup que utiliza BTC para alcançar 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 se apropriar dos fundos dos usuários do BTCRollup ao produzir um Bloco em vez de transmitir efetivamente esse Bloco, tornando os dados disponíveis.

Então, se realmente conseguirmos implementar uma implementação ideal de Rollup no BTC, com retiradas unilaterais reais dos usuários, como seria isso?