Fonte: Bitcoin Magazine; Tradução: Cinco Li, 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 executados em sistemas Turing Completo como Ethereum e outros, mas recentemente o foco mudou para portá-los para blockchain baseados em UTXO, como BTC. Este artigo não pretende discutir o estado atual da implementação em BTC, mas sim as funcionalidades do idealizado Rollup que são buscadas há muito tempo, que dependem da capacidade de verificar diretamente a Prova de conhecimento zero (ZKP) no BTC, o que atualmente não é suportado.

A estrutura básica do Roll é a seguinte: uma única conta (UTXO em BTC) contém o saldo de todos os usuários no Rollup. Esta 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, então, para gastar fora da cadeia, os usuários ainda precisam assinar algo com a Chave Secreta. Esta parte da estrutura permite que os usuários saiam a qualquer momento sem permissão, apenas provando que suas contas são parte da árvore de Merkle, eles podem sair do Rollup unilateralmente, sem permissão do operador.

O operador do Rollup deve incluir uma Prova de Conhecimento Zero (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 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 maliciosamente o saldo para roubar os fundos dos usuários ou redistribuí-los desonestamente para outros usuários.

A questão é, se apenas a raiz da árvore de merkle for publicada na cadeia, como é que os utilizadores podem colocar os seus ramos na árvore de forma a poderem sair quando quiserem sem permissão?

Rollup adequado

Em um Rollup apropriado, toda 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 cadeia. 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á saldos e as contas serão apenas adicionadas nas transações de atualização do Rollup.

Em implementações mais avançadas, utilize diferenças de saldo. Isto 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 as alterações de saldo da conta que ocorreram. 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 saldo da conta, o que lhes permite reconstruir a árvore de Merkel do saldo atual.

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

Prazo de validade

Uma outra forma de lidar com a questão da disponibilidade dos dados de retirada do utilizador é colocar os dados noutro local fora da cadeia de blocos. Isto introduz questões subtis, em que o rollup ainda precisa de garantir que os dados estão disponíveis noutro local. Tradicionalmente, outras cadeias de blocos são usadas para este propósito, especialmente concebidas como uma camada de disponibilidade de dados para sistemas como o rollup.

Isto cria um dilema em que a segurança é tão forte. Quando os dados são publicados diretamente na cadeia de blocos BTC, as regras de consenso podem garantir que esteja absolutamente correto. No entanto, quando é publicado em sistemas externos, a melhor coisa que pode fazer é verificar a prova SPV, ou seja, os dados foram publicados noutro sistema.

Isto requer provas de que os dados estão na cadeia de bloco de outra forma, é essencialmente um problema da Máquina Oracle. A cadeia de blocos do BTC não pode verificar plenamente nada para além do que acontece na sua própria cadeia de bloco, a melhor coisa que pode fazer é verificar ZKP. No entanto, ZKP não pode verificar se os dados de rollup do bloco foram realmente transmitidos publicamente após a sua geração. Não pode verificar se as informações externas foram realmente tornadas públicas para todos.

Isso abre as portas para ataques de retenção de dados, ou seja, criar 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 do valor e da estrutura de incentivos de sistemas fora do BTC.

Impasse

Isto colocou o rollup em um dilema. Quando se trata de problemas de disponibilidade de dados, basicamente existe uma escolha binária de 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 de blocos BTC como uma camada de disponibilidade de dados definirá um limite rígido para a escalabilidade do rollup. O espaço do bloco é limitado, o que define 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 ao número de contas cujo saldo mudou desde a última atualização. A teoria da informação permite apenas que os dados sejam comprimidos até certo ponto, e nesse ponto não há mais potencial de expansão.

Por outro lado, usar camadas diferentes para alcançar 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. No Rollup que usa 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 Rollup não pode mudar. Em Validiums, essa garantia depende inteiramente da capacidade do sistema externo usado de resistir à fraude 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 Bloco em vez de transmitir o Bloco real, tornando os dados disponíveis.

Então, como seria se realmente conseguíssemos implementar uma implementação Rollup ideal no BTC, alcançando verdadeiramente saques unilaterais dos usuários?