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

Fonte: Bitcoin Magazine; Tradução: Wuzhu, Jinse Caijing

Rollups recentemente tornaram-se o foco da expansão do BTC, tornando-se a primeira coisa a realmente roubar o foco 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 é restrita ou limitada pela liquidez central da Rede de iluminação, ou seja, os usuários finais precisam que os fundos sejam alocados (ou “emprestados”) com antecedência 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.

Esses sistemas foram originalmente implantados no Ethereum e em outros sistemas Turing Completo, mas recentemente o foco tem se deslocado para portá-los para blockchains baseadas em UTXO, como BTC. Este artigo não pretende discutir a implementação atual em BTC, mas sim discutir as capacidades do Rollup idealizado que tem sido perseguido há muito tempo, o qual depende da capacidade de verificar diretamente a Prova de conhecimento zero (ZKP) em BTC, o que atualmente não é suportado.

A estrutura básica do Roll é a seguinte: uma única conta (chamada UTXO no BTC) armazena o saldo de todos os usuários no Rollup. Essa UTXO contém um compromisso que existe como a raiz de uma á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 gastar fora da cadeia, os usuários ainda precisam assinar algum conteúdo usando a Chave Secreta. Essa parte da estrutura permite que os usuários saiam a qualquer momento sem permissão, apenas provando que sua conta faz parte da árvore de Merkle. Eles podem sair do Rollup unilateralmente, sem a necessidade de permissão do operador.

Os operadores do Rollup devem incluir um ZKP nas transações para atualizar o saldo da conta na cadeia durante o processo de conclusão das transações fora da cadeia. Sem este ZKP, as transações serão inválidas e não podem ser incluídas no bloco. Esta prova permite que as pessoas verifiquem se todas as alterações de saldo fora da cadeia foram devidamente autorizadas pelos titulares das contas e se os operadores não atualizaram os saldos maliciosamente para roubar fundos dos utilizadores ou redistribuí-los desonestamente para outros utilizadores.

O problema é que, se apenas a raiz da árvore de merkle for publicada na cadeia, os utilizadores podem vê-la e aceder-lhe, mas como podem colocar os seus ramos na árvore, de modo a poderem sair quando quiserem sem permissão?

Rollup adequado

Em um Rollup apropriado, cada vez que uma nova transação fora da cadeia é confirmada e o estado da conta do Rollup é alterado, as informações são diretamente colocadas na blockchain. Não é a árvore inteira, o 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 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 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 de Merkle do saldo atual.

Desta forma, é possível poupar uma grande quantidade de despesas e espaço de Bloco (e, portanto, poupar dinheiro), enquanto ainda permite que os utilizadores garantam o acesso às informações necessárias para uma saída unilateral. As regras de rollup exigem que estes dados sejam incluídos no rollup formal fornecido aos utilizadores usando a cadeia de Bloco, ou seja, as transações que não incluem o resumo da conta ou a diferença de conta são consideradas inválidas.

Período de validade

Outra maneira de lidar com problemas de disponibilidade de dados de saque do usuário é colocar os dados em outro lugar fora da cadeia de Bloco. Isso introduz problemas sutis, pois o rollup ainda precisa garantir que os dados estejam disponíveis em outro lugar. Tradicionalmente, outras cadeias de Bloco são usadas para esse fim, projetadas especificamente como uma camada de disponibilidade de dados para sistemas como rollup.

Isso cria um dilema de segurança igualmente forte. Quando os dados são publicados diretamente na cadeia BTCBloco, as regras de consenso podem garantir que estão absolutamente corretos. No entanto, quando eles são publicados em um sistema externo, o melhor que podem fazer é verificar uma prova SPV, ou seja, os dados já foram publicados em outro sistema.

Isso requer uma prova de que os dados existem em outra cadeia além da cadeia de blocos. No final, é um problema de Máquina Oracle. A cadeia de blocos do BTC não pode verificar completamente nada além do que acontece em sua própria cadeia de blocos, o melhor que pode fazer é verificar ZKP. No entanto, ZKP não pode verificar se os blocos que contêm dados de rollup foram realmente divulgados publicamente após a geração. Não pode verificar se as informações externas realmente estão disponíveis para todos.

Isso abriu as portas para ataques de retenção de dados, ou seja, promessas de dados publicados sendo criadas e usadas para impulsionar o rollup, mas os dados não estão realmente disponíveis. Isso faz com que os usuários não possam retirar seus fundos. A única solução real é depender totalmente de valor e estrutura de incentivos fora do BTC.

Em um dilema

Isso coloca rollup em um dilema. Quando se trata de questões de disponibilidade de dados, basicamente existe uma escolha binária entre publicar os dados na cadeia 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 BTC Bloco 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 o número de rollups que podem existir de cada vez e para o número total de transações que todos os rollups podem processar fora da cadeia. Cada atualização de rollup requer um espaço de Bloco proporcional ao número 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 escalabilidade.

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 utilizam BTC para obter 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 em resistir a fraudes e ocultar dados.

Agora, qualquer produtor de Bloco no sistema de disponibilidade de dados externos pode se apropriar dos fundos dos usuários do BTCRollup produzindo Bloco em vez de realmente transmitir o Bloco, tornando os dados disponíveis.

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