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

Rollups recentemente se tornaram o foco do escalonamento BTC, tornando-se a primeira coisa a realmente "roubar a cena" da Rede de iluminação, em termos de atenção mais ampla. Os rollups destinam-se a ser uma segunda camada de foro da cadeia que não está sujeita ou limitada pelas restrições do núcleo Liquidez da Rede de iluminação, ou seja, o usuário final precisa de alguém para alocar (ou "emprestar") os fundos antecipadamente para receber o dinheiro, ou a rota intermediária Nó precisa do saldo do canal para facilitar o fluxo total do valor do pagamento do remetente para o destinatário.

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

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 Merkle da árvore 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 a Chave Secreta. Essa parte da estrutura permite que os usuários saiam a qualquer momento sem permissão, precisando apenas provar através de transações que suas contas fazem parte da árvore Merkle, permitindo que eles saiam 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 completam transações fora da cadeia. Sem este ZKP, a transação é 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 os saldos de forma maliciosa para roubar fundos dos usuários ou redistribuí-los desonestamente para outros usuários.

A questão é, se apenas a raiz da árvore 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 desejarem?

Rollup adequado

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

Em implementações mais avançadas, use a diferença de equilíbrio de contas. Isso essencialmente resume quais contas tiveram fundos adicionados ou removidos durante o processo de atualização. Isso faz com que cada atualização do Rollup contenha apenas alterações no equilíbrio de contas 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 equilíbrio de contas, permitindo-lhes reconstruir a árvore de Merkel do equilíbrio atual.

Dessa forma, é possível economizar uma grande quantidade de despesas e espaço de Bloco (e, portanto, economizar fundos), ao mesmo tempo que permite aos usuários garantir acesso às informações necessárias para a saída unilateral. As regras de rollup exigem que esses dados sejam incluídos no rollup formal fornecido aos usuários usando a cadeia de Bloco, ou seja, as transações que não incluem um resumo de conta ou diferença de conta são consideradas inválidas.

Prazo de validade

Outra forma de lidar com o problema de disponibilidade de dados de retirada do usuário é colocar os dados em outro lugar que não seja na cadeia de blocos. Isso traz consigo 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, especificamente projetadas como camadas de disponibilidade de dados para sistemas como o rollup.

Isto cria um dilema de segurança igualmente forte. Quando os dados são diretamente publicados na cadeia BTCBloco, as regras de Consenso podem garantir que ele esteja absolutamente correto. No entanto, quando é publicado em um sistema externo, o melhor que pode fazer é verificar a prova SPV, ou seja, que os dados foram publicados em outro sistema.

Isto requer uma prova de que os dados existem em outros na cadeia, o que é essencialmente um problema de Máquina Oracle. A cadeia de Bloco do BTC não consegue verificar completamente qualquer coisa que aconteça fora do seu próprio Bloco, sendo o melhor que consegue fazer é verificar ZKP. No entanto, ZKP não consegue verificar se os dados de rollup do Bloco, após a geração, foram realmente transmitidos publicamente. Não consegue verificar se as informações externas foram verdadeiramente tornadas públicas para todos.

Isso abriu as portas para ataques de retenção de dados, ou seja, criando compromissos para publicar dados 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 de sistemas de valor e incentivo fora do BTC.

Encruzilhada

Isso coloca rollup em um dilema. Quando se trata de problemas de disponibilidade de dados, existe basicamente uma escolha binária entre publicar dados na cadeia de blocos BTC ou em outro lugar. Essa escolha tem um impacto significativo na segurança e soberania do rollup, bem como em sua escalabilidade.

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 estabelece 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 só permite que os dados sejam comprimidos até certo ponto, o que significa que 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 superior rígido do ganho de escalabilidade, mas também traz novos problemas de segurança e soberania. Em um Rollup que utiliza BTC para alcançar a disponibilidade de dados, se os dados que o usuário deseja 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 totalmente 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 Bloco em vez de transmitir o Bloco real, tornando os dados disponíveis.

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