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

Fonte: Bitcoin Magazine; tradução: Wu Zhu, Jinse Finance

Rollups recentemente se tornaram o foco da expansão do BTC, tornando-se a primeira coisa a realmente roubar os holofotes da Rede de iluminação, em termos de maior atenção. Rollups têm como objetivo ser uma segunda camada fora da cadeia que não está restrita ou limitada pela Liquidez central da Rede de iluminação, ou seja, os usuários finais precisam ter fundos alocados (ou ‘emprestados’) antecipadamente para receber dinheiro, ou os Nós de roteamento intermediários precisam de saldo de canal para facilitar o fluxo completo do valor do remetente ao destinatário.

Estes sistemas foram inicialmente implementados na Ethereum e em outros sistemas Turing Completo, mas recentemente houve um foco na sua portabilidade para blockchains baseadas em UTXO (como BTC). Não se 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 zero prova de conhecimento (ZKP) diretamente no BTC.

A estrutura básica do Roll é a seguinte: um único conta (UTXO no 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 existentes no Rollup. Todas essas contas são autorizadas por Chave pública/Chave privada, portanto, os usuários ainda precisam assinar certas informações com Chave Secreta para fazer gastos fora da cadeia. Esta parte da estrutura permite que os usuários saiam a qualquer momento sem permissão, basta fazer uma transação provando que sua conta faz parte da árvore de Merkle e eles podem sair do Rollup unilateralmente, sem permissão do operador.

O operador Rollup deve incluir um ZKP na transação para atualizar a raiz de merkle do saldo da conta na cadeia ao concluir a transação fora da cadeia. Sem este ZKP, a transação será inválida e não pode ser incluída no bloco da cadeia. 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 maliciosamente o saldo para roubar fundos dos usuários ou redistribuí-los desonestamente para outros usuários.

O problema é que, se apenas a raiz da árvore de Merkle for publicada na cadeia, os usuários podem visualizá-la e acessá-la, mas como eles podem colocar seus ramos na árvore para poderem sair quando quiserem, sem permissão?

Rollup Apropriado

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, 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á 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 adições ou subtrações de fundos durante o processo de atualização. Isso faz com que cada atualização do Rollup contenha apenas as alterações de saldo da conta que ocorreram. Em seguida, os usuários podem simplesmente escanear a cadeia e ‘calcular’ a partir do início do Rollup para obter o estado atual do saldo da conta, permitindo-lhes reconstruir a árvore de Merkle do saldo atual.

Desta forma, é possível poupar uma grande quantidade de despesas e espaço de Bloco (poupando assim dinheiro), ao mesmo tempo que permite aos utilizadores garantir o acesso às informações necessárias para a saída unilateral. As regras do rollup exigem que estes dados sejam incluídos no rollup oficial fornecido aos utilizadores usando a cadeia de Bloco, ou seja, as transações que não incluem o resumo da conta ou a diferença de contas são consideradas inválidas.

Prazo de validade

Uma outra forma de lidar com a questão da disponibilidade de dados de retirada de utilizador é colocar os dados noutro local fora da cadeia de blocos. Isto introduz uma questão subtil, em que o rollup ainda precisa garantir que os dados estão disponíveis noutro local. Tradicionalmente, outras cadeias de blocos são usadas para este propósito, especificamente projetadas para serem camadas de disponibilidade de dados para sistemas como o rollup.

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

Isto requer uma prova de que os dados estão na cadeia, que é, em última instância, um problema da Máquina Oracle. A cadeia de Bloco do BTC não consegue verificar completamente nada para além do que acontece na sua própria cadeia. A melhor coisa que pode fazer é verificar ZKP. No entanto, ZKP não consegue verificar se os dados de rollup do Bloco, uma vez gerados, são verdadeiramente transmitidos publicamente. Não consegue verificar se a informação externa é verdadeiramente tornada pública para todos.

Isso abre a porta para ataques de retenção de dados, ou seja, criar compromissos para 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 incentivo de sistemas além do BTC.

Conflito

Isso coloca o rollup em um dilema. Quando se trata de problemas de disponibilidade de dados, basicamente existe uma escolha binária entre publicação de 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, o uso da cadeia BTC como camada de disponibilidade de dados imporá um limite rígido à escalabilidade do rollup. O espaço de bloco é limitado, o que estabelece um limite para a quantidade de rollups que podem existir de uma vez e o número total de transações que podem ser tratadas fora da cadeia. Cada atualização do rollup requer um espaço de bloco proporcional à quantidade de contas cujos saldos mudaram desde a última atualização. A teoria da informação só permite que os dados sejam comprimidos até certo ponto, a partir do qual não há mais potencial de escalabilidade.

Por outro lado, usar diferentes camadas para implementar 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 Rollups que utilizam BTC para implementar 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á ser alterado. Com o uso de Validiums, essa garantia depende inteiramente da capacidade dos sistemas externos de 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 um Bloco em vez de realmente transmitir o Bloco, tornando os dados disponíveis.

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