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

Fonte: Bitcoin Magazine; Tradução: Wu Zhu, Golden Finance

Rollups recentemente tornaram-se o foco da expansão do BTC, tornando-se a primeira coisa a 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 restringida ou limitada pela liquidez central da Rede de iluminação, ou seja, os usuários finais precisam de alocação antecipada (ou “empréstimo”) de fundos para receber dinheiro, ou os nós de roteamento intermediários precisam de saldo de canal para facilitar o fluxo total do montante de pagamento do remetente para o destinatário.

Estes sistemas foram inicialmente implantados em sistemas Turing Complete como Ethereum e outros, mas recentemente houve um foco na sua portabilidade para blockchains baseadas em UTXO, como BTC. Este artigo não pretende discutir o estado atual da implementação em BTC, mas sim as funcionalidades ideais de Rollup que as pessoas têm buscado a longo prazo, as quais dependem de capacidades que atualmente não são suportadas pelo BTC, ou seja, a capacidade de verificar zk-SNARKs 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. 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 fazer gastos fora da cadeia, os usuários ainda devem 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 são parte da árvore de Merkle, eles podem sair do Rollup unilateralmente, sem a necessidade de permissão do operador.

Os operadores de Rollup devem incluir uma ZKP nas transações para atualizar a raiz do merkle do saldo da conta na cadeia ao realizar transações fora da cadeia. Sem esta 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, como é que os utilizadores podem colocar os seus ramos na árvore para poderem sair quando quiserem sem permissão?

Rollup apropriado

Em um Rollup adequado, cada vez que uma nova transação fora da cadeia é confirmada e o estado da conta Rollup muda, as informações são diretamente colocadas 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, os resumos de todas as contas existentes no Rollup conterão os saldos e as contas são apenas adicionadas nas transações de atualização do Rollup.

Em implementações mais avançadas, variações de equilíbrio são usadas. Trata-se, essencialmente, de um resumo do financiamento que aumentou ou diminuiu durante o processo de atualização. Isso faz com que cada atualização do Rollup contenha apenas as alterações de saldo de conta que ocorrem. O usuário pode então simplesmente digitalizar a cadeia e “fazer o cálculo” desde o início do Rollup para chegar ao estado atual do saldo da conta, o que lhe permite reconstruir a árvore Merkle do saldo atual.

Isso permite economizar custos e espaço de bloco (economizando dinheiro), ao mesmo tempo em que permite aos usuários garantir o acesso às informações necessárias para sair unilateralmente. As regras de rollup exigem que esses dados sejam incluídos no rollup formal fornecido aos usuários usando a cadeia de blocos, ou seja, transações sem resumo de conta ou diferença de conta são consideradas inválidas.

Data de validade

Outra maneira de lidar com a questão da disponibilidade dos dados de retirada do utilizador é colocar os dados noutro local fora da cadeia de blocos. Isso introduz problemas subtis, pois o rollup ainda precisa garantir que os dados estejam disponíveis em outro local. Tradicionalmente, outras cadeias de blocos foram usadas para esse fim, especificamente 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 de blocos Bloco 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 em outro sistema.

Isso requer provas de que os dados estão presentes em outras cadeias além da cadeia principal, o que é essencialmente um problema da Máquina Oracle. A cadeia de bloco do BTC não pode verificar completamente qualquer coisa que ocorra fora de sua própria cadeia de blocos, exceto verificar ZKP. No entanto, ZKP não pode verificar se os dados do bloco que contém os dados do rollup foram realmente transmitidos publicamente após a geração. Não pode verificar se as informações externas foram realmente tornadas públicas para todos.

Isso abre a porta para ataques de retenção de dados, onde um compromisso de publicar dados é criado e usado para avançar um rollup, mas os dados não estão realmente disponíveis. Isto faz com que os utilizadores não possam levantar fundos. A única solução real é confiar inteiramente no valor e na estrutura de incentivos do sistema fora do BTC.

Entre a espada e a parede

Isso coloca o rollup em um dilema. Quando se trata de problemas de disponibilidade de dados, basicamente existe 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, usar a cadeia de blocos Bitcoin 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 a quantidade total de transações que todos os rollups podem processar fora da cadeia. Cada atualização de 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 nesse aspecto, não há mais potencial de escalabilidade.

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 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 poderá ser alterado. 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 se apossar dos fundos dos usuários BTCRollup, tornando os dados disponíveis, produzindo Bloco em vez de realmente transmitir esse Bloco.

Então, se nós realmente alcançarmos a implementação ideal do Rollup no BTC, alcançando verdadeiramente saques unilaterais para os usuários, como seria isso?