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

Source: Bitcoin Magazine; Compilation: Wuzhu, Golden Finance

Rollups recentemente se tornaram o foco da expansão do BTC, tornando-se a primeira coisa a realmente roubar o protagonismo da Rede de iluminação e atrair uma atenção mais ampla. Rollups visam ser uma segunda camada fora da cadeia, não restrita ou limitada pela Liquidez central da Rede de iluminação, ou seja, os usuários finais precisam ter fundos alocados (ou ‘emprestados’) com antecedência para receber dinheiro, ou os Nós de roteamento intermediários precisam ter saldo de canal para facilitar o fluxo total do valor do remetente para o destinatário.

Estes sistemas foram originalmente implementados em sistemas Turing Completo como Ethereum e outros, mas recentemente houve um foco na sua portabilidade para blockchains baseadas em UTXO, como o BTC. Este artigo não pretende discutir o estado atual da implementação no BTC, mas sim as funcionalidades ideais do Rollup que as pessoas têm buscado a longo prazo, as quais dependem da capacidade atualmente não suportada do BTC de verificar provas de conhecimento zero (ZKP) diretamente no BTC.

A estrutura básica do Roll é a seguinte: uma única conta (UTXO em BTC) guarda 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, então, para gastar fora da cadeia, os usuários ainda devem assinar certos conteúdos com 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 permissão do operador.

Os operadores de Rollup devem incluir um ZKP nas transações para atualizar a raiz de Merkle do saldo da conta na cadeia, fora da cadeia, durante o processo de conclusão da transação 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 maliciosamente 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 utilizadores podem visualizá-la e aceder-lhe, mas como podem colocar os seus ramos na árvore para que possam sair sem permissão quando desejarem?

Rollup apropriado

Em um Rollup apropriado, toda vez que uma nova transação fora da cadeia é confirmada e o estado da conta do Rollup é alterado, as informações são colocadas diretamente na cadeia de blocos. 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 às transações de atualização do Rollup.

Em implementações mais avançadas, utiliza-se a diferença de saldo. Isso essencialmente resume quais contas tiveram seus fundos aumentados ou reduzidos durante o processo de atualização. Isso permite que cada atualização do Rollup contenha apenas as alterações de saldo da 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 da conta, o que lhes permite reconstruir a árvore de Merkle do saldo atual.

Desta forma, é possível poupar uma grande quantidade de despesas e espaço de Bloco (poupando assim fundos), ao mesmo tempo que permite aos utilizadores garantir o acesso à informação necessária para uma saída unilateral. As regras de rollup exigem que estes dados sejam incluídos no rollup formal fornecido aos utilizadores através da cadeia de Bloco, ou seja, as transações que não incluem um resumo de conta ou diferenças de conta são consideradas inválidas.

Período de validade

Outra abordagem para lidar com a questão da disponibilidade de dados de retirada de usuários é colocar os dados em outros lugares além da cadeia Bloco. Isso introduz um problema sutil, rollup ainda precisa garantir que os dados estejam disponíveis em outro lugar. Tradicionalmente, outras cadeias Bloco são usadas para esse fim, especialmente projetadas como camada de disponibilidade de dados para sistemas como rollup.

Isso cria um dilema de segurança igualmente desafiador. 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 em sistemas externos, o melhor que podem fazer é verificar a prova de SPV, ou seja, que os dados foram publicados em outro sistema.

Isso requer uma prova de que os dados estão presentes em outras cadeias, que é essencialmente um problema de Máquina Oracle. A cadeia BTC Bloco não pode verificar completamente qualquer coisa que ocorra fora de sua própria cadeia Bloco, o melhor que pode fazer é verificar ZKP. No entanto, ZKP não pode verificar se o bloco que contém dados de 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 abre as portas para ataques de retenção de dados, ou seja, criar um compromisso com a divulgação de dados e usá-lo 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 fora do BTC.

Em um dilema

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

Por um lado, o uso da cadeia de blocos do BTC como camada de disponibilidade de dados estabelece um limite rígido para a escalabilidade do rollup. O espaço do bloco é limitado, o que impõe um limite ao número de rollups que podem existir ao mesmo tempo e ao número total de transações que podem ser processadas fora da cadeia. Cada atualização do rollup requer espaço de bloco proporcional ao número de contas que tiveram alterações de saldo desde a última atualização. A teoria da informação permite apenas que os dados sejam comprimidos até certo ponto, e não há mais potencial de escalabilidade além disso.

Por outro lado, o uso de diferentes camadas para alcançar a disponibilidade de dados eliminará o limite máximo de escalabilidade, mas também trará novas questões 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 automaticamente publicados na cadeia, o estado do Rollup não poderá mudar. Com o uso de Validiums, essa garantia depende inteiramente da capacidade dos sistemas externos de 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 transmitir realmente o Bloco, tornando os dados disponíveis.

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