Revista Bitcoin: 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, sendo a primeira coisa a realmente roubar o protagonismo da Rede de iluminação, em termos de atenção mais ampla. Rollups têm como objetivo ser uma segunda camada fora da cadeia, não sujeita às restrições ou limitações de liquidez do núcleo 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 precisam de saldo nos canais para facilitar o fluxo total dos pagamentos do remetente para o destinatário.

Esses sistemas foram originalmente executados no Ethereum e outros sistemas Turing Completo, mas recentemente o foco tem sido em portá-los para blockchains baseadas em UTXO, como BTC. Este artigo não pretende discutir o estado atual da implementação no BTC, mas sim discutir as funcionalidades do Rollup idealizado que as pessoas têm buscado há muito tempo, o que depende da capacidade de verificar diretamente Prova de conhecimento zero (ZKP) no BTC, recurso que atualmente não é suportado.

A estrutura básica do Roll é a seguinte: uma única conta (chamada 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 usando Chave pública/Chave privada, então, para fazer gastos fora da cadeia, os usuários ainda precisam assinar algumas coisas 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 fazem parte da árvore de Merkle, eles podem sair do Rollup unilateralmente, sem permissão do operador.

Os operadores de rollup devem incluir uma ZKP na transação para atualizar a raiz de Merkle do saldo da conta na cadeia ao concluir a transação fora da cadeia. Sem esta ZKP, a transação é inválida e não pode ser incluída no bloco da cadeia. Esta prova permite que as pessoas verifiquem se todas as alterações na conta fora da cadeia foram devidamente autorizadas pelos titulares de contas e se o operador não atualizou maliciosamente o saldo para roubar fundos dos usuários ou redistribuí-los desonestamente para outros usuários.

A questão é que, se apenas a raiz da árvore de 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 quando quiserem, sem a necessidade de permissão?

Rollup adequado

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

Em implementações mais avançadas, use diferenças de saldo. Isso essencialmente resume quais contas tiveram fundos adicionados ou removidos 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, o que lhes permite reconstruir a árvore Merkle do saldo atual.

Desta forma, é possível poupar uma grande quantidade de despesas e espaço de Bloco (economizando assim fundos), ao mesmo tempo que permite aos utilizadores garantir o acesso às informações necessárias para a saída unilateral. As regras do 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 o resumo da conta ou a diferença de contas são consideradas inválidas.

Período de validade

Outra forma de lidar com problemas de disponibilidade de dados de retirada do utilizador é colocar os dados noutro local fora da cadeia de blocos. Isto introduz questões delicadas, uma vez que o rollup ainda precisa garantir que os dados estejam disponíveis noutros locais. Tradicionalmente, outras cadeias de blocos são utilizadas para este propósito, especificamente concebidas como camadas de disponibilidade de dados para sistemas como o rollup.

Isto cria um dilema de segurança igualmente forte. Quando os dados são publicados diretamente na cadeia de blocos BTC, 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 SPV, ou seja, que os dados foram publicados noutro sistema.

Isso requer uma prova de que os dados existem em outras cadeias, o que é essencialmente um problema de Máquina Oracle. A cadeia Bitcoin não pode verificar completamente nada além do que acontece em sua própria cadeia, exceto através da verificação de conhecimento-zero (ZKP). No entanto, a ZKP não pode verificar se o Bloco, que contém dados de rollup, foi realmente divulgado publicamente após a geração. Não pode verificar se as informações externas foram realmente tornadas públicas para todos.

Isso abriu a porta para ataques de retenção de dados, ou seja, criar compromissos para 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 fundos. A única solução real é depender totalmente do valor e da estrutura de incentivos de sistemas fora do 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 de publicar os dados na blockchain do 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 uma camada de disponibilidade de dados define um limite rígido para a escalabilidade do rollup. O espaço de bloco é limitado, o que define um limite para a quantidade de rollups que podem existir e a quantidade 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 cujos saldos mudaram desde a última atualização. A teoria da informação permite apenas a compressão dos dados até certo ponto, e não há mais potencial de expansão além disso.

Por outro lado, o uso de diferentes camadas para alcançar a disponibilidade de dados elimina o limite máximo de escalabilidade dos ganhos, mas também traz 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 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 seqüestrar os fundos dos usuários de BTCRollup produzindo Bloco em vez de realmente transmitir esse Bloco, tornando os dados disponíveis.

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