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

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

Rollups recentemente se tornaram o foco da expansão do BTC, sendo a primeira coisa a realmente roubar os holofotes da Rede de iluminação e atrair atenção mais ampla. Rollups têm como objetivo ser uma camada fora da cadeia que não é limitada ou restringida pela liquidez central da Rede de iluminação. Isso significa que os usuários finais precisam ter fundos alocados (ou ‘emprestados’) antecipadamente para receber dinheiro, ou os nós intermediários precisam ter saldo de canal para facilitar o fluxo completo do pagamento do remetente para o destinatário.

Esses sistemas foram originalmente desenvolvidos para serem executados no Ethereum e em outros sistemas Turing Completo, mas recentemente houve um foco em portá-los para blockchains baseadas em UTXO, como o BTC. Este artigo não pretende discutir a implementação atual no BTC, mas sim discutir as funcionalidades idealizadas do Rollup que as pessoas têm buscado há muito tempo, as quais dependem de uma capacidade que o BTC atualmente não suporta, ou seja, a capacidade de verificar diretamente provas de conhecimento zero (ZKP) no BTC.

A estrutura básica do Roll é a seguinte: uma única conta (UTXO em BTC) armazena o saldo de todos os usuários no Rollup. Este UTXO contém um compromisso, que existe na forma de 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, 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 são parte da árvore de Merkle, eles podem sair unilateralmente do Rollup sem permissão do operador.

Os operadores do Rollup devem incluir um ZKP nas transações para atualizar a raiz de merkle do saldo na cadeia ao concluir as transações fora da cadeia. Sem este ZKP, a transação será inválida e não pode ser incluída no bloco. 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 o saldo maliciosamente para roubar fundos dos usuários ou redistribuí-los de forma desonesta para outros usuários.

O problema é que se apenas a raiz da árvore Merkle for publicada na cadeia, os usuários podem visualizá-la e acessá-la, mas como eles colocarão seus ramos na árvore para poderem sair sem permissão quando desejarem?

Rollup apropriado

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, 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á o saldo 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 equilíbrio. 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 inclua 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-lhes reconstruir a árvore de Merkle do saldo atual.

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

Prazo de validade

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

Isto criou um dilema em que a segurança é tão forte. Quando os dados são publicados diretamente na cadeia BTCBloco, as regras de Consenso podem garantir que estejam absolutamente corretos. No entanto, quando são publicados num sistema externo, o melhor que podem fazer é verificar a prova SPV, ou seja, que os dados foram publicados noutro sistema.

Isto requer uma prova de que os dados estão na cadeia de outro, o que é essencialmente um problema de Máquina Oracle. A cadeia de Bloco do BTC não consegue verificar completamente nada para além do que acontece na sua própria cadeia, sendo o melhor que pode fazer verificar ZKP. No entanto, ZKP não consegue verificar se os dados de rollup do Bloco, depois de gerados, são realmente transmitidos publicamente. Não consegue verificar se as informações externas são 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 faz com que os usuários não consigam sacar fundos. A única solução real é depender completamente do valor e da estrutura de incentivos de sistemas além do BTC.

01928374656574839201

Isto coloca o rollup numa situação difícil. Quando se trata de problemas de disponibilidade de dados, basicamente existe uma escolha binária entre publicar os dados na cadeia de blocos BTC ou noutro local. Esta escolha tem um impacto significativo na segurança, soberania e escalabilidade do rollup.

Por um lado, usar a cadeia BTCBloco como camada de disponibilidade de dados irá impor um limite rígido à escalabilidade do rollup. O espaço Bloco é finito, o que define um limite para o número de rollups que podem existir ao mesmo tempo e para a quantidade total de transações que podem ser processadas fora da cadeia. Cada atualização do rollup requer espaço Bloco proporcional à quantidade de contas cujos saldos mudaram desde a última atualização. A teoria da informação só permite a compressão dos dados até certo ponto, o que limita o potencial de escalabilidade.

Por outro lado, o uso de 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 Rollup que usa 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á mudar. Com Validiums, essa garantia depende inteiramente da capacidade dos sistemas externos utilizados para resistir a fraudes e ocultação de dados.

Atualmente, qualquer produtor de Bloco no sistema de disponibilidade de dados externos pode sequestrar os fundos dos usuários de BTCRollup, tornando os dados disponíveis, produzindo Bloco em vez de difundir o Bloco real.

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