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

Fonte: Bitcoin Magazine; Compilado por: 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 têm como objetivo ser uma segunda camada fora da cadeia que não é limitada ou restringida pela liquidez central da Rede de iluminação, ou seja, os usuários finais precisam ter fundos alocados (ou ‘emprestados’) antecipadamente para receber dinheiro, ou os nós de roteamento intermediários precisam de saldo de canal para facilitar o fluxo total do valor do remetente para o destinatário.

Estes sistemas foram inicialmente implementados na Ethereum e em outros sistemas Turing Completo, mas recentemente houve um foco na sua portabilidade para blockchains baseadas em UTXO (por exemplo, BTC). Este artigo não pretende discutir o estado atual da implementação no BTC, mas sim as funcionalidades idealizadas de Rollup que as pessoas têm procurado a longo prazo, o que depende da capacidade atualmente não suportada pelo BTC de verificar Prova de conhecimento zero (ZKP) diretamente no BTC.

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. Esta 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, portanto, para fazer gastos fora da cadeia, os usuários ainda precisam assinar algum conteúdo com 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 a necessidade de permissão do operador.

Os operadores Rollup devem incluir um ZKP nas transações para atualizar o saldo da conta na cadeia quando completam 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, como eles podem então colocar seus ramos na árvore para poder sair a qualquer momento sem permissão?

Rollup apropriado

Em um Rollup apropriado, toda vez que uma nova transação fora da cadeia é confirmada e 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á 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 aumentaram ou diminuíram os fundos durante o processo de atualização. Isso permite que cada atualização do Rollup contenha apenas alterações de saldo de 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 que eles reconstruam a árvore de Merkle do saldo atual.

Isso permite economizar custos e espaço de bloco (economizando dinheiro), enquanto ainda 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 usando a 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 o problema de disponibilidade de dados de retirada do utilizador é colocar os dados noutro local fora da cadeia de blocos. Isto introduz um problema subtil, pois o rollup ainda precisa garantir que os dados estão disponíveis noutro local. Tradicionalmente, outras cadeias de blocos são usadas para este fim, sendo especialmente projetadas como uma camada de disponibilidade de dados para sistemas como o rollup.

Isso cria um dilema de segurança igualmente poderoso. Quando os dados são diretamente publicados na cadeia BTCBloco, as regras de consenso podem garantir que ele esteja absolutamente correto. No entanto, quando é publicado em um sistema externo, o melhor que pode ser feito é verificar a prova SPV, ou seja, que os dados foram publicados em outro sistema.

Isto requer uma prova de que os dados estão presentes em outros blocos na cadeia, o que acaba por ser um problema de Máquina Oracle. A cadeia de blocos do Bitcoin não consegue verificar completamente qualquer coisa que aconteça fora do seu próprio bloco, sendo que o melhor que consegue fazer é verificar ZKP. No entanto, o ZKP não consegue verificar se os dados de rollup foram realmente divulgados publicamente após a sua geração. Não consegue 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 usá-los para impulsionar o rollup, mas os dados não estão realmente disponíveis. Isso faz com que os usuários não consigam retirar fundos. A única solução real é depender completamente do valor e da estrutura de incentivos de sistemas além do BTC.

Estar em um dilema

Isso coloca o rollup em um dilema. Quando se trata de problemas de disponibilidade de dados, basicamente há uma escolha binária entre 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, o uso da cadeia BTC como camada de disponibilidade de dados impõe um limite máximo à escalabilidade do rollup. O espaço do Bloco é limitado, o que estabelece um limite para o número de rollups que podem existir de uma só vez e para a quantidade total de transações que todos os rollups podem processar fora da cadeia. Cada atualização do rollup requer espaço no Bloco proporcional à quantidade de contas cujo saldo mudou desde a última atualização. A teoria da informação só permite que os dados sejam comprimidos até certo ponto, e nesse ponto não há mais potencial de expansão.

Por outro lado, usar camadas diferentes 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. Em um Rollup que usa BTC para alcançar a disponibilidade de dados, se os dados que o usuário deseja extrair não forem publicados automaticamente na blockchain, o estado do Rollup não poderá ser alterado. Com o uso de Validiums, essa garantia depende inteiramente da capacidade dos sistemas externos de resistir a fraude 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 produzindo um bloco em vez de transmitir o bloco real, tornando os dados disponíveis.

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