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

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.

Estes sistemas foram inicialmente desenvolvidos para serem executados em Ethereum e outros sistemas Turing Completo, 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 em BTC, mas sim discutir as funcionalidades de rollup ideais, que dependem de capacidades atualmente não suportadas pelo BTC, ou seja, a capacidade de verificar zero prova de conhecimento (ZKP) diretamente no BTC.

A arquitetura básica do Roll é a seguinte: uma única conta (UTXO no BTC) mantém o saldo de todos os usuários no Rollup. Essa UTXO contém um compromisso que existe como raiz de Merkle na árvore de Merkle, comprometendo todos os saldos atuais de conta existentes no Rollup. Todas essas contas são autorizadas por Chave pública/Chave privada, portanto, para gastar fora da cadeia, os usuários ainda devem assinar algum conteúdo com Chave Secreta. Essa parte da estrutura permite que os usuários saiam a qualquer momento sem permissão, simplesmente fazendo uma transação provando que sua conta faz parte da árvore de Merkle, eles podem sair do Rollup unilateralmente, sem permissão do operador.

O operador do Rollup deve incluir uma ZKP nas transações para atualizar a raiz de merkle do saldo da conta na cadeia ao concluir a transação fora da cadeia. Sem essa ZKP, a transação será inválida e não pode ser incluída no bloco da cadeia. Essa 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.

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 quando quiserem, sem permissão?

Rollup adequado

Em um Rollup apropriado, cada nova transação fora da cadeia confirmada e cada mudança de estado da conta Rollup 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á os saldos e as contas serão apenas acrescentadas nas transações de atualização do Rollup.

Em implementações mais avançadas, utiliza-se a diferença de saldo. Isso essencialmente resume quais contas tiveram aumentos ou reduções de fundos durante o processo de atualização. Isso permite 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, o que lhes permite 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 fundos), ao mesmo tempo que permite que os utilizadores garantam o acesso à informação necessária para uma saída unilateral. As regras do rollup exigem que estes dados sejam incluídos no rollup formal fornecido aos utilizadores através da 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.

Período de validade

Outra forma de lidar com problemas de disponibilidade de dados de retirada de usuários é colocar os dados em outro lugar fora da cadeia de bloco. Isso introduz problemas sutis, pois o rollup ainda precisa garantir que os dados sejam acessíveis em outro lugar. Tradicionalmente, outras cadeias de bloco são usadas para esse fim, projetadas especificamente como uma camada de disponibilidade de dados para sistemas como o 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.

Isto requer provas de que os dados estão na cadeia, o que é essencialmente um problema da Máquina Oracle. A cadeia de blocos do Bitcoin não consegue verificar totalmente nada para além do que acontece na sua própria cadeia de blocos, o melhor que pode fazer é verificar ZKP. No entanto, ZKP não consegue verificar se os dados rollup do bloco, após a geração, são verdadeiramente divulgados publicamente. Não consegue verificar se as informações externas são verdadeiramente 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 faz com que os usuários não consigam sacar seus fundos. A única solução real é depender completamente do valor e da estrutura de incentivo de sistemas além do BTC.

Entrar e sair de uma situação difícil

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

Por um lado, usar a cadeia BTCBloco como camada de disponibilidade de dados imporia um limite rígido à escalabilidade do rollup. O espaço Bloco é limitado, 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 requer espaço Bloco proporcional à quantidade de contas que tiveram alterações de saldo desde a última atualização. A teoria da informação só permite comprimir os dados até certo ponto, e nesse sentido não há mais potencial de escalabilidade.

Por outro lado, usar 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. Em um Rollup que utiliza BTC para alcançar a disponibilidade de dados, se os dados que o usuário precisa 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 utilizado para 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 transmitir o Bloco real, tornando os dados disponíveis.

Então, se realmente conseguirmos realizar a implementação ideal do Rollup no BTC, alcançando verdadeiramente saques unilaterais dos usuários, como seria isso?