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

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

Rollups recentemente se tornaram o foco da escalabilidade do BTC, tornando-se a primeira coisa a realmente roubar o holofote da Rede de iluminação em termos de atenção mais ampla. Rollups têm como objetivo ser uma 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 ter fundos alocados antecipadamente (ou ‘emprestados’) para receber dinheiro, ou os nós intermediários precisam ter saldo de canal para facilitar o fluxo total do valor do remetente para o destinatário.

Esses sistemas foram originalmente projetados 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 ideais do Rollup que as pessoas têm buscado há muito tempo, as quais dependem da capacidade de verificar diretamente a prova de conhecimento zero (ZKP) no BTC, recurso que não é suportado atualmente.

A estrutura básica do Roll é a seguinte: uma única conta (UTXO no Bitcoin) mantém o saldo de todos os usuários no Rollup. Essa UTXO contém um compromisso, na forma da raiz de Merkle da á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, para gastar fora da cadeia, os usuários ainda precisam assinar alguns conteúdos com Chave Secreta. Essa parte da estrutura permite aos usuários sair 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 da transação 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 os fundos dos usuários ou redistribuí-los desonestamente para outros usuários.

Rollup adequado

Em um Rollup apropriado, cada nova transação fora da cadeia confirmada e cada vez que o estado da conta Rollup sofre alterações, as informações são diretamente colocadas na cadeia de blocos. 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 apenas são adicionadas nas transações de atualização do Rollup.

Em implementações mais avançadas, o saldo diferencial é usado. 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 as alterações de saldo da conta ocorridas. Em seguida, os usuários podem simplesmente percorrer a cadeia e ‘calcular’ a partir do início do Rollup para obter o estado atual do saldo da conta, o que lhes permite reconstruir a árvore de Merkle do saldo atual.

Isso pode economizar muito dinheiro e espaço de bloco (economizando assim fundos), ao mesmo tempo em que permite que os usuários garantam 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 usando a cadeia de blocos, ou seja, transações que não incluem o resumo ou diferença da conta são consideradas inválidas.

Prazo 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 além da cadeia de blocos. Isso introduz uma questão sutil, em que 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, especialmente projetadas para servir como uma camada de disponibilidade de dados para sistemas como rollup.

Isso cria o dilema de ter uma segurança igualmente forte. Quando os dados são publicados diretamente na cadeia BTCBloco, as regras de consenso garantem que eles são absolutamente corretos. No entanto, quando são publicados em sistemas externos, o melhor que podem fazer é verificar a prova SPV, isto é, que os dados foram publicados em outro sistema.

Isto requer provas de que os dados existem em outras na cadeia, o que é essencialmente um problema de Máquina Oracle. O Bloco da BTC não consegue verificar completamente qualquer coisa que aconteça fora da sua própria cadeia, exceto através de verificação de conhecimento zero. No entanto, a ZKP não consegue verificar se os dados rollup do Bloco, após a geração, são realmente transmitidos publicamente. Não consegue verificar se as informações externas são realmente tornadas públicas 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 rollup, mas os dados não estão realmente disponíveis. Isso impede que os usuários retirem seus fundos. A única solução real é depender completamente de sistemas de valor e incentivo fora do BTC.

Encontrar-se numa situação difícil

Isso coloca o rollup em um dilema. Quando se trata de problemas de disponibilidade de dados, basicamente há uma escolha binária entre publicar os dados na cadeia de blocos 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 BTC como camada de disponibilidade de dados imporia um limite rígido à escalabilidade do rollup. O espaço do bloco é finito, o que impõe um limite ao número de rollups que podem existir ao mesmo tempo e ao número total de transações que podem ser processadas fora da cadeia. Cada atualização do rollup exige um 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, 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 elimina o limite rígido dos ganhos de escalabilidade, mas também traz novas questões de segurança e soberania. Dentro do 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 poderá mudar. Com o uso de Validiums, essa garantia depende inteiramente da capacidade do sistema externo utilizado para resistir a fraudes e ocultação de dados.

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

Então, se conseguirmos realmente implementar o ideal Rollup no BTC, alcançando verdadeiramente levantamentos unilaterais dos usuários, como seria isso?