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

Fonte: Bitcoin Magazine; Tradução: Wuzhu, Financeiro Dourado

Rollups recentemente se tornou o foco da expansão do BTC, tornando-se a primeira coisa a realmente roubar o protagonismo da Rede de iluminação, em termos de atenção mais ampla. Rollups tem como objetivo ser uma segunda camada fora da cadeia, não limitada ou restringida pela Liquidez central da Rede de iluminação, ou seja, os usuários finais precisam que alguém aloque (ou ‘empreste’) fundos com antecedência para receber dinheiro, ou os Nós intermediários precisam de saldo de canal para facilitar o fluxo total do valor do remetente para o destinatário.

Esses sistemas foram inicialmente executados no Ethereum e em outros sistemas Turing Completo, mas recentemente o foco mudou para portá-los para blockchains baseadas em UTXO (por exemplo, BTC). Este artigo não pretende discutir o estado atual da implementação no BTC, mas sim as funcionalidades do Rollup idealizado que as pessoas têm buscado há muito tempo, que depende da capacidade de verificação direta de Prova de Conhecimento Zero (ZKP) no BTC, o que não é suportado atualmente.

A arquitetura básica do Roll é a seguinte: uma única conta (UTXO no BTC) que armazena o saldo de todos os usuários no Rollup. Essa UTXO contém um compromisso na forma da raiz de uma árvore de Merkle, comprometendo todos os saldos atuais das contas no Rollup. Todas essas contas são autorizadas com uma chave pública/privada, portanto, para realizar transações fora da cadeia, os usuários ainda precisam assinar algum conteúdo com uma 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 de Rollup devem incluir um ZKP nas transações para atualizar os saldos das contas 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 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 utilizadores ou redistribuí-los desonestamente para outros utilizadores.

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 sem permissão quando quiserem?

Rollup apropriado

Em um Rollup apropriado, cada vez que uma nova transação fora da cadeia é confirmada e o estado da conta 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 adicionadas apenas em transações de atualização do Rollup.

Em implementações mais avançadas, utiliza-se a diferença de equilíbrio de contas. Isto 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 as alterações de saldo de conta que ocorreram. Em seguida, os usuários podem simplesmente varrer a cadeia e ‘calcular’ a partir do início do Rollup para obter o estado atual do equilíbrio de contas, permitindo-lhes reconstruir a árvore de Merkle do saldo atual.

Isso permite economizar custos e espaço de bloco (economizando dinheiro), ao mesmo tempo em que permite que os usuários garantam o acesso às informações necessárias para sair unilateralmente. As regras do rollup exigem que esses dados sejam incluídos no rollup oficial fornecido aos usuários 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 abordagem para lidar com a questão da disponibilidade de dados de retirada do usuário é colocar os dados em outro lugar que não seja na cadeia de Bloco. Isso levanta questões sutis, rollup ainda precisa garantir a disponibilidade dos dados em outro lugar. Tradicionalmente, outras cadeias de Bloco são usadas para esse fim, especialmente projetadas para servir como camada de disponibilidade de dados para sistemas como rollup.

Isto cria um dilema de segurança igualmente poderoso. Quando os dados são diretamente enviados para a cadeia de blocos do Bitcoin, as regras de consenso podem garantir que estejam absolutamente corretos. No entanto, quando são enviados para sistemas externos, o melhor que podem fazer é verificar a prova SPV, ou seja, que os dados foram enviados para outro sistema.

Isso requer verificar se os dados existem em outras cadeias, o que acaba sendo um problema da Máquina Oracle. A cadeia Bloco do BTC não pode verificar totalmente nada além do que aconteceu com sua própria cadeia Blocona, e o melhor que pode fazer é verificar o ZKP. No entanto, o ZKP não consegue verificar se os blocos que contêm dados cumulativos são realmente transmitidos publicamente depois de serem gerados. Ele não pode verificar se as informações externas estão realmente abertas a todos.

Isto abriu a porta para ataques de retenção de dados, ou seja, criando compromissos em relação aos dados publicados e usá-los para impulsionar 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 estrutura de incentivos de sistemas além do BTC.

Estar entre a espada e a parede

Isso coloca 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 do Bitcoin como camada de disponibilidade de dados define um limite rígido para a escalabilidade do rollup. O espaço de bloco é limitado, o que define um limite para a quantidade 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 de bloco proporcional à quantidade de contas cujos saldos mudaram desde a última atualização. A teoria da informação permite apenas uma compressão de dados até certo ponto, e nesse sentido, não há mais potencial de escalabilidade.

Por outro lado, o uso de diferentes camadas 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. No Rollup que utiliza BTC para alcançar a disponibilidade de dados, se os dados que o usuário precisa 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 do sistema externo utilizado para resistir a fraudes e ocultação de dados.

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

Então, se realmente conseguirmos implementar o Rollup ideal no BTC, realizando verdadeiramente saques unilaterais dos utilizadores, como seria isso?