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

robot
Geração do resumo em andamento

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

Rollups têm sido o foco da escalabilidade do BTC recentemente, tornando-se a primeira coisa a realmente roubar o centro das atenções da Rede de Iluminação e ter uma atenção mais ampla. Rollups pretendem 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 alguém alocar (ou ‘emprestar’) fundos com antecedência para receber dinheiro, ou Nós intermediários precisam de saldo de canal para facilitar o fluxo total de pagamentos do remetente para o destinatário.

Esses sistemas foram originalmente executados em Ethereum e outros sistemas Turing Completo, mas recentemente houve um foco em 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 funcionalidades do Rollup idealizado, que depende de recursos não suportados atualmente pelo BTC, como a capacidade de verificar provas de conhecimento zero (ZKP) diretamente 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 certos conteúdos com 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 necessidade de permissão do operador.

Os operadores de Rollup devem incluir um ZKP nas transações para atualizar o saldo da conta na cadeia quando concluírem 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.

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 colocam seus ramos na árvore para 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 Rollup sofre alterações, 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á os saldos e as contas serã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 economiza muito dinheiro e espaço de bloco (economizando dinheiro), permitindo ao usuário 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 por meio da cadeia de bloco, e as transações que não incluem resumos ou diferenças de conta são consideradas inválidas.

Prazo de validade

Uma outra abordagem para lidar com a questão da disponibilidade dos dados de retirada do usuário é colocar os dados em outros lugares além da cadeia de Bloco. Isso introduz uma questão sutil, pois o rollup ainda precisa garantir que os dados estejam disponíveis em outros locais. Tradicionalmente, outras cadeias de Bloco são usadas para esse fim, especialmente projetadas como camada de disponibilidade de dados para sistemas como o rollup.

Isto cria um dilema em que a segurança é igualmente forte. Quando os dados são publicados diretamente na cadeia de blocos Bitcoin, 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 noutro sistema.

Isto requer provas de que os dados existem em outros na cadeia, este é essencialmente um problema de Máquina Oracle. A cadeia de Bloco do BTC não consegue verificar totalmente qualquer coisa que aconteça fora do seu próprio bloco na cadeia, o melhor que pode fazer é verificar ZKP. No entanto, ZKP não consegue verificar se os dados de rollup contidos no bloco, após a geração, foram realmente transmitidos publicamente. Não consegue verificar se a informação externa foi verdadeiramente tornada pública para todos.

Isso abriu as portas 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 seus fundos. A única solução real é depender totalmente do valor e da estrutura de incentivos de sistemas além do BTC.

Entre a espada e a parede

Isto trouxe um dilema para a rollup. 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 da rollup.

Por um lado, o uso da cadeia de blocos BTC como camada de disponibilidade de dados estabelecerá um limite máximo para a escalabilidade do rollup. O espaço do bloco é limitado, o que estabelece um limite para a quantidade de rollups que podem existir ao mesmo tempo e para o total de transações que podem ser processadas fora da cadeia. Cada atualização do rollup requer espaço de bloco proporcional ao número de contas cujos saldos mudaram desde a última atualização. A teoria da informação permite apenas uma certa quantidade de compressão de dados, 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 rígido dos ganhos de escalabilidade, mas também trará novos problemas 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 do sistema externo de resistir a fraudes e ocultação de dados.

Agora, qualquer produtor de Bloco no sistema de disponibilidade externa de dados pode assumir os fundos do usuário BTCRollup produzindo um Bloco em vez de transmitir efetivamente esse Bloco, tornando os dados disponíveis.

Então, como seria se realmente conseguíssemos a implementação ideal do Rollup no BTC e realmente permitíssemos retiradas unilaterais de usuários?

BTC-0.02%
ETH-0.13%
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
  • Recompensa
  • Comentário
  • Repostar
  • Compartilhar
Comentário
0/400
Sem comentários
  • Marcar
Negocie criptomoedas a qualquer hora e em qualquer lugar
qrCode
Escaneie o código para baixar o app da Gate
Comunidade
Português (Brasil)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)