Bitcoin Magazine: Quais são os desafios do Rollup?

Fonte: Bitcoin Magazine; Compilado por: Wuzhu, Jinse Caijing

Rollups have recently become the focus of BTC expansion, becoming the first thing that truly steals the spotlight from the Rede de iluminação and gaining wider attention. Rollups aim to be a second layer outside the Rede de iluminação core Liquidez constraints, where end users need someone to allocate (or ‘borrow’) funds in advance to receive money, or intermediate routing Nós need channel balances to facilitate the full flow of payment amounts from senders to receivers.

Estes sistemas foram inicialmente executados em Ethereum e outros sistemas Turing Completo, mas recentemente houve um foco na sua portabilidade para blockchains baseados em UTXO (por exemplo, BTC). Este artigo não pretende discutir o estado atual da implementação em BTC, mas sim as funcionalidades ideais do Rollup, as quais dependem de capacidades atualmente não suportadas pelo BTC, ou seja, a capacidade de verificar zk-SNARKs diretamente no BTC.

A estrutura básica do Roll é a seguinte: um único conta (UTXO no BTC) mantém o saldo de todos os usuários no Rollup. Esta UTXO contém um compromisso que existe como a raiz de Merkle da árvore Merkle, comprometendo todos os saldos atuais da conta existentes no Rollup. Todas essas contas são autorizadas com Chave pública/Chave privada, portanto, para gastar fora da cadeia, os usuários ainda precisam assinar certas informações com Chave Secreta. Essa parte da estrutura permite que os usuários saiam a qualquer momento sem permissão, basta fazer uma transação que provem que sua conta faz parte da árvore Merkle, eles podem sair do Rollup unilateralmente, sem a necessidade de permissão do operador.

O operador do Rollup deve incluir uma ZKP nas transações para atualizar a raiz de merkle do saldo da conta na cadeia principal durante o processo de conclusão da transação fora da cadeia. Sem essa ZKP, a transação será inválida e não pode 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 maliciosamente o saldo para roubar fundos dos usuários ou realocá-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 Apropriado

Em um Rollup apropriado, cada 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, que 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 a diferença de saldo. Isso essencialmente resume quais contas tiveram fundos adicionados ou retirados durante o processo de atualização. Isso permite que cada atualização Rollup contenha apenas as alterações de saldo de conta ocorridas. 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 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 uma saída unilateral. As regras de rollup exigem que esses dados sejam incluídos no rollup oficial fornecido aos usuários usando a cadeia de bloco, ou seja, transações que não incluem o resumo da conta ou diferenças de conta são consideradas inválidas.

Validade

Outra forma de lidar com a questão da disponibilidade de dados de extração do utilizador é colocar os dados noutro local fora da cadeia de bloco. Isto introduz um problema subtil, o rollup ainda precisa garantir que os dados estejam disponíveis noutro local. Tradicionalmente, outras cadeias de bloco são usadas para este propósito, especialmente concebidas como camada de disponibilidade de dados para sistemas como o rollup.

Isso cria um dilema de segurança igualmente forte. Quando os dados são diretamente publicados na cadeia BTCBloco, as regras de Consenso podem garantir que eles estejam absolutamente corretos. No entanto, quando eles são publicados em um sistema externo, o melhor que eles podem fazer é verificar a prova SPV de que os dados foram publicados em outro 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 completamente nada além do que acontece em seu próprio bloco na cadeia, no máximo, ela pode verificar ZKP. No entanto, ZKP não pode verificar se os dados de rollup em um bloco foram realmente divulgados publicamente após a geração. Não pode verificar se as informações externas realmente são públicas para todos.

Isso abriu a porta para ataques de retenção de dados, ou seja, criar compromissos em relação aos 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 além do BTC.

Estar em um impasse

Isto coloca o rollup numa situação difícil. 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, 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 de uma vez e para o número total de transações que todos os rollups podem processar fora da cadeia. Cada atualização do rollup requer 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, e a partir daí não há mais potencial de expansão.

Por outro lado, o uso de diferentes camadas para alcançar a disponibilidade de dados eliminará o limite rígido de ganhos 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 pode mudar. Com Validiums, essa garantia depende inteiramente da capacidade dos sistemas externos usados para resistir à fraude e ocultação de dados.

Agora, qualquer produtor de blocos no sistema de disponibilidade de dados externos pode sequestrar os fundos dos usuários do BTCRollup produzindo blocos em vez de transmitir os blocos reais, tornando os dados disponíveis.

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