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

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

Rollups têm se tornado o foco da escalabilidade do BTC recentemente, tornando-se a primeira coisa que realmente rouba os holofotes da Rede de iluminação em termos de atenção mais ampla. Rollups visam ser uma segunda camada fora da cadeia que não está sujeita às restrições ou limitações de liquidez do núcleo da Rede de iluminação, ou seja, os usuários finais precisam ter fundos alocados (ou ‘emprestados’) antecipadamente para receber dinheiro, ou nós intermediários precisam ter saldo de canal para facilitar o fluxo total do valor do remetente ao destinatário.

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

A estrutura 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 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 realizar gastos fora da cadeia, os usuários ainda precisam assinar certos conteúdos com Chave Secreta. Essa parte da estrutura permite que os usuários saiam a qualquer momento sem permissão, apenas com a prova de transação de que sua conta faz parte da árvore de Merkle, eles podem sair unilateralmente do Rollup sem a permissão do operador.

O operador do rollup deve incluir um ZKP na transação para atualizar a raiz merkle do saldo na cadeiaconta no processo de conclusão da transação for a cadeia, sem a qual a transação seria inválida e, portanto, não poderia ser incluída na cadeia Bloco. Este atestado permite verificar se todas as alterações ao Fora da Cadeiaconta estão devidamente autorizadas pelo titular da Conta e se o operador não atualizou maliciosamente o saldo para roubar fundos dos utilizadores ou redistribuí-los desonestamente a outros utilizadores.

A questão é, se apenas a raiz da árvore de merkle for publicada na cadeia, os utilizadores podem vê-la e aceder-lhe, mas como poderão eles colocar os seus ramos na árvore de forma a poderem sair quando quiserem sem permissão?

Rollup apropriado

Em 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 colocadas diretamente na blockchain. Não é a árvore inteira, que 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 são apenas adicionadas nas transações de atualização do Rollup.

Em implementações mais avançadas, use diferenças de saldo. Isso essencialmente resume quais contas aumentaram ou diminuíram os fundos durante o processo de atualização. Isso faz com que cada atualização do Rollup contenha apenas 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 chegar ao estado atual do saldo da conta, permitindo-lhes reconstruir a árvore de Merkle do saldo atual.

Isso permite economizar custos e espaço de bloco significativos (economizando assim dinheiro), enquanto ainda 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 formal fornecido aos usuários usando a cadeia de blocos, ou seja, transações que não incluem o resumo da conta ou diferenças de conta são consideradas inválidas.

Prazo de validade

Outra maneira de lidar com a questão da disponibilidade dos dados de retirada do usuário é armazenar os dados em outro lugar fora da cadeia de blocos. Isso traz consigo questões 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.

Isso cria um dilema de segurança igualmente poderoso. 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 em sistemas externos, o melhor que podem fazer é verificar a prova SPV, ou seja, que os dados foram publicados em outro sistema.

Isso requer prova de que os dados estão presentes em outros blocos da cadeia, o que é essencialmente um problema da Máquina Oracle. A cadeia de blocos do BTC não pode verificar completamente nada além do que acontece em seu próprio bloco. O melhor que pode fazer é verificar ZKP. No entanto, ZKP não pode verificar se os dados de rollup em um bloco são realmente divulgados publicamente após a geração. Não pode verificar se as informações externas são realmente públicas para todos.

Isso abriu as portas para ataques de retenção de dados, ou seja, criar compromissos em relação aos 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 os fundos. A única solução real é depender totalmente de sistemas de valor e estruturas de incentivo fora do BTC.

Estar em um dilema

Isso coloca o rollup em um dilema. 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 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 BTC como camada de disponibilidade de dados estabelece um limite máximo para a escalabilidade do rollup. O espaço do bloco é limitado, o que impõe um limite ao número de rollups possíveis e ao número 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 cujo saldo tenha mudado desde a última atualização. A teoria da informação permite apenas a compressão dos dados até certo ponto, a partir do qual não há mais potencial de expansão.

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á novos problemas de segurança e soberania. No Rollup que usa 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á mudar. Com o uso de Validiums, essa garantia depende totalmente da capacidade dos sistemas externos utilizados para resistir à fraude 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 Bloco em vez de realmente transmitir esse Bloco, tornando os dados disponíveis.

Então, se realmente alcançarmos a implementação ideal do Rollup no BTC, com retiradas unilaterais de usuários, como seria isso?