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

Fonte: Bitcoin Magazine; Compilado por: Wu Zhu, Golden Finance

Rollups have recently become the focus of BTC scalability, becoming the first thing that truly steals the spotlight from the Rede de iluminação in terms of wider attention. Rollups aim to be an off-chain second layer that is not constrained or limited by the core liquidity of the Rede de iluminação, which means that end users need someone to allocate (or ‘lend’) funds in advance in order to receive money, or intermediate routing nodes need channel balances to facilitate the smooth flow of payment amounts from sender to receiver.

Estes sistemas foram originalmente implementados em Ethereum e outros sistemas Turing Completo, mas recentemente houve um foco na sua portabilidade para blockchains baseadas em UTXO (por exemplo, BTC). Este artigo não pretende discutir o estado atual da implementação em BTC, mas sim as funcionalidades idealizadas de Rollup que as pessoas têm perseguido a longo prazo, as quais dependem de capacidades que atualmente não são suportadas pelo BTC, ou seja, a capacidade de verificar Prova de conhecimento zero (ZKP) diretamente em BTC.

A arquitetura básica do Roll é a seguinte: uma única conta (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 existentes no Rollup. Todas essas contas são autorizadas usando Chave pública/Chave privada, portanto, os usuários ainda precisam assinar algum conteúdo usando Chave Secreta para fazer transações fora da cadeia. 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 de Rollup devem incluir um ZKP nas transações para atualizar as contas na cadeia durante o processo de conclusão das 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 nas contas fora da cadeia foram devidamente autorizadas pelo titular da conta e se o operador não atualizou os saldos 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, 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 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 incluirá os saldos 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 retirados 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 percorrer a cadeia e “calcular” o saldo da conta atual a partir do início do Rollup, o que lhes permite reconstruir a árvore de Merkel do saldo atual.

Desta forma, pode poupar uma grande quantidade de despesas e espaço de Bloco (economizar fundos), permitindo ainda aos utilizadores garantir o acesso às informações necessárias para sair unilateralmente. As regras do 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 diferenças de conta são consideradas inválidas.

Período de validade

Outra forma de lidar com a questão da disponibilidade dos dados de retirada dos utilizadores é colocar os dados noutros locais fora do Bloco. Isto introduz questões subtis, uma vez que o rollup ainda precisa garantir a disponibilidade dos dados noutros locais. Tradicionalmente, outros blocos são usados para este fim, sendo especialmente concebidos como camada de disponibilidade de dados para sistemas como o rollup.

Isto criou um dilema de segurança igualmente forte. Quando os dados são publicados diretamente na cadeia de blocos BTC, as regras de consenso podem garantir que estejam absolutamente corretos. No entanto, quando são publicados em sistemas externos, o melhor que conseguem fazer é verificar a prova SPV, ou seja, que os dados foram publicados noutro sistema.

Isso requer uma prova de que os dados estão presentes em outras cadeias, o que acaba sendo um problema da Máquina Oracle. A cadeia de blocos do BTC não pode verificar completamente qualquer coisa que aconteça fora de sua própria cadeia de blocos, a melhor coisa que pode fazer é verificar ZKP. No entanto, o ZKP não pode verificar se o bloco do Bloco que contém os dados de rollup é realmente divulgado publicamente após a geração. Não pode verificar se as informações externas estão realmente disponíveis para todos.

Isto 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 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.

Entra em pânico ou recua

Isso cria um dilema para o rollup. Quando se trata de problemas de disponibilidade de dados, basicamente existe uma escolha binária entre publicar os dados na blockchain do Bitcoin ou em outro lugar. Essa escolha tem um impacto significativo na segurança, soberania e escalabilidade do rollup.

Por um lado, o uso da cadeia BTC como camada de disponibilidade de dados estabelecerá 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 simultaneamente e o total de transações que podem ser processadas fora da cadeia. Cada atualização do rollup requer espaço de bloco proporcional à quantidade de contas cujos saldos tenham mudado desde a última atualização. A teoria da informação só permite que os dados sejam comprimidos até certo ponto, então não há mais potencial de expansão nesse aspecto.

Por outro lado, o uso de camadas diferentes para alcançar a disponibilidade de dados eliminará o limite rígido dos ganhos de escalabilidade, mas também trará novas questões de segurança e soberania. Em Rollup que utiliza 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 pode mudar. Com Validiums, essa garantia depende inteiramente da capacidade do sistema externo usado para resistir a fraudes e ocultação de dados.

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

Então, se realmente conseguirmos implementar uma implementação ideal de Rollup no BTC e alcançar retiradas unilaterais de usuários, como seria?