Fonte: Bitcoin Magazine; Compilado por: Wuzhu, Golden Finance

Rollups recentemente se tornaram 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 maior atenção. Rollups pretendem 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 montante do remetente para o destinatário.

Estes sistemas foram originalmente concebidos para correr em blockchains Turing Completo, como Ethereum e outros, 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 no BTC, mas sim as funcionalidades idealizadas de Rollup que as pessoas têm procurado a longo prazo, as quais dependem de capacidades não suportadas atualmente no 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 na forma da raiz de Merkle da árvore de Merkle, comprometendo todos os saldos atuais das contas 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 algum conteúdo com Chave Secreta. Essa parte da estrutura permite que os usuários saiam a qualquer momento sem permissão, apenas apresentando uma prova de transação mostrando 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 o saldo da conta na cadeia quando concluem 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 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 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 adequado

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, que seria absurdo, mas sim as informações necessárias para reconstruir a árvore. Em uma implementação simples, os resumos de todas as contas existentes no Rollup conterão os saldos e as contas são simplesmente adicionadas nas transações de atualização do Rollup.

Em implementações mais avançadas, use a diferença de equilíbrio de contas. Essencialmente, isto resume quais contas tiveram adições ou subtrações de fundos durante o processo de atualização. Isso faz com que cada atualização de Rollup inclua apenas as alterações de equilíbrio de contas 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 equilíbrio de contas, permitindo-lhes reconstruir a árvore de Merkle do equilíbrio atual.

Desta forma, é possível poupar uma grande quantidade de despesas e espaço de Bloco (economizando assim dinheiro), ao mesmo tempo que permite aos utilizadores garantir o acesso às informações necessárias para uma saída unilateral. As regras de 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 o resumo da conta ou as diferenças de conta são consideradas inválidas.

Validade

Outra maneira de lidar com o problema de disponibilidade de dados de retirada do usuário é colocar os dados em outro lugar fora da cadeia de blocos. Isso introduz problemas 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, projetadas especificamente para servir como camadas de disponibilidade de dados para sistemas como o rollup.

Isto cria um dilema de segurança igualmente poderoso. Quando os dados são diretamente publicados na cadeia de blocos Bitcoin (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 noutro sistema.

Esta necessita de provas de que os dados foram validados noutras partes da cadeia, o que acaba por ser um problema da Máquina Oracle. A cadeia do Bloco do BTC não consegue validar completamente nada para além do que acontece na sua própria cadeia, sendo o melhor que consegue fazer a validação ZKP. No entanto, a ZKP não consegue verificar se os dados de rollup do Bloco, após a geração, foram realmente transmitidos publicamente. Não pode verificar se a informação externa foi verdadeiramente tornada pública para todos.

Isto abriu a porta para ataques de retenção de dados, isto é, criar compromissos para a publicação de dados e usá-los para impulsionar rollup, mas os dados não estão realmente disponíveis. Isto faz com que os utilizadores não consigam levantar fundos. A única solução real é depender totalmente do valor e da estrutura de incentivos de sistemas que não sejam o BTC.

Dilema

Isto coloca a rollup numa situação difícil. Quando se trata de questões de disponibilidade de dados, basicamente há uma escolha binária entre publicar os dados na cadeia de blocos BTC ou em outro lugar. Esta 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 imporá um limite rígido à escalabilidade do rollup. O espaço do bloco é limitado, o que impõe um limite ao número de rollups que podem existir ao mesmo tempo e ao 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 só permite que os dados sejam comprimidos até certo ponto, ou seja, não há mais potencial de escalabilidade.

Por outro lado, usar diferentes camadas para alcançar a disponibilidade de dados eliminará o limite máximo 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 deseja extrair não forem publicados automaticamente na blockchain, o estado do Rollup não poderá mudar. Com os Validiums, essa garantia depende inteiramente da capacidade do sistema externo de 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 um Bloco em vez de realmente transmiti-lo, tornando os dados disponíveis.

Então, se realmente conseguirmos implementar uma implementação ideal de Rollup no BTC, permitindo verdadeiramente saques unilaterais dos utilizadores, como seria isso?