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 implementados no Ethereum e em outros sistemas Turing Completo, mas recentemente houve um foco em portá-los para blockchains baseadas em UTXO, como o BTC. Este artigo não pretende discutir o estado atual da implementação no BTC, mas sim discutir as funcionalidades ideais do Rollup que as pessoas têm buscado há muito tempo, que dependem da capacidade de verificar diretamente a prova de conhecimento zero (ZKP) no BTC, que atualmente não é suportada.
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 de uma á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 certos conteúdos com Chave Secreta. Essa parte da estrutura permite que os usuários saiam a qualquer momento sem permissão, apenas provando que sua conta faz parte da árvore de Merkle, eles podem sair unilateralmente do Rollup sem permissão do operador.
Os operadores 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 o saldo maliciosamente para roubar fundos dos usuários ou realocá-los desonestamente para outros usuários.
A questão é, se apenas a raiz da árvore de Merkle for publicada na cadeia, os usuários podem visualizá-la e acessá-la, como eles podem colocar seus ramos na árvore para que eles possam sair sem permissão quando quiserem?
Rollup apropriado
Em um Rollup apropriado, toda vez que uma nova transação fora da cadeia é confirmada e o estado da conta do Rollup sofre alterações, as informações são colocadas diretamente 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, usa-se uma diferença de equilíbrio de contas. Isso essencialmente resume quais contas tiveram fundos adicionados ou retirados durante o processo de atualização. Isso permite que cada atualização do Rollup contenha apenas as alterações de saldo de 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 de contas, o que lhes permite reconstruir a árvore de Merkle do saldo atual.
Dessa forma, é possível economizar custos significativos e espaço de blocos (economizando assim fundos), ao mesmo tempo que permite que os usuários garantam o acesso às informações necessárias para sair unilateralmente. As regras do rollup exigem que esses dados sejam incluídos no rollup formal fornecido aos usuários usando a cadeia de blocos, ou seja, transações que não incluem resumos de conta ou diferenças de conta são consideradas inválidas.
Prazo de validade
Outra maneira de lidar com problemas de disponibilidade de dados de retirada do usuário é colocar os dados em outro lugar fora da cadeia Bloco. Isso introduz problemas sutis, pois o rollup ainda precisa garantir que os dados estejam disponíveis em outro lugar. Tradicionalmente, outras cadeias Bloco são usadas para esse fim, especialmente projetadas para servir como camada de disponibilidade de dados para sistemas como o rollup.
Isto cria um dilema de segurança igualmente poderoso. Quando os dados são publicados diretamente na cadeia de blocos BTC, 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.
Isto requer provas de que os dados estão na verdade na cadeia, o que acaba por ser um problema de 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 de bloco, sendo o melhor que consegue fazer a verificação ZKP. No entanto, a ZKP não consegue verificar se os dados de rollup do bloco, após a sua geração, foram verdadeiramente divulgados publicamente. Não consegue verificar se a informação externa foi verdadeiramente tornada pública para todos.
Isto abriu a porta 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 na realidade não estão disponíveis. Isso faz com que os utilizadores não consigam levantar fundos. A única solução real é depender totalmente do valor e estrutura de incentivos fora do BTC.
Entra ou sai do labirinto
Isto coloca o rollup em um dilema. Quando se trata de problemas de disponibilidade de dados, basicamente existe uma escolha binária entre publicar os dados na cadeia de blocos BTC ou em outro lugar. Esta escolha tem um grande impacto na segurança, soberania e escalabilidade do rollup.
Por um lado, o uso da cadeia BTC como camada de disponibilidade de dados estabelecerá um limite rígido na escalabilidade do rollup. O espaço do Bloco é limitado, o que estabelece um limite para o número de rollups possíveis e a quantidade total de transações que podem ser processadas fora da cadeia. A cada atualização do rollup, o espaço do Bloco é proporcional ao número de contas cujos saldos mudaram desde a última atualização. A teoria da informação permite apenas que os dados sejam comprimidos até certo ponto, e não há mais potencial de expansão nesse sentido.
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á 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 inteiramente da capacidade do sistema externo utilizado em 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 Blocos em vez de transmitir o Bloco real, tornando os dados disponíveis.
Então, se realmente conseguirmos implementar a solução ideal de Rollup no BTC, alcançando verdadeiramente levantamentos unilaterais dos utilizadores, como seria isso?
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
Revista Bitcoin: Quais são os desafios enfrentados pelo Rollup?
Fonte: Bitcoin Magazine; Tradução: Wuzhu, Jinse 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 implementados no Ethereum e em outros sistemas Turing Completo, mas recentemente houve um foco em portá-los para blockchains baseadas em UTXO, como o BTC. Este artigo não pretende discutir o estado atual da implementação no BTC, mas sim discutir as funcionalidades ideais do Rollup que as pessoas têm buscado há muito tempo, que dependem da capacidade de verificar diretamente a prova de conhecimento zero (ZKP) no BTC, que atualmente não é suportada.
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 de uma á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 certos conteúdos com Chave Secreta. Essa parte da estrutura permite que os usuários saiam a qualquer momento sem permissão, apenas provando que sua conta faz parte da árvore de Merkle, eles podem sair unilateralmente do Rollup sem permissão do operador.
Os operadores 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 o saldo maliciosamente para roubar fundos dos usuários ou realocá-los desonestamente para outros usuários.
A questão é, se apenas a raiz da árvore de Merkle for publicada na cadeia, os usuários podem visualizá-la e acessá-la, como eles podem colocar seus ramos na árvore para que eles possam sair sem permissão quando quiserem?
Rollup apropriado
Em um Rollup apropriado, toda vez que uma nova transação fora da cadeia é confirmada e o estado da conta do Rollup sofre alterações, as informações são colocadas diretamente 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, usa-se uma diferença de equilíbrio de contas. Isso essencialmente resume quais contas tiveram fundos adicionados ou retirados durante o processo de atualização. Isso permite que cada atualização do Rollup contenha apenas as alterações de saldo de 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 de contas, o que lhes permite reconstruir a árvore de Merkle do saldo atual.
Dessa forma, é possível economizar custos significativos e espaço de blocos (economizando assim fundos), ao mesmo tempo que permite que os usuários garantam o acesso às informações necessárias para sair unilateralmente. As regras do rollup exigem que esses dados sejam incluídos no rollup formal fornecido aos usuários usando a cadeia de blocos, ou seja, transações que não incluem resumos de conta ou diferenças de conta são consideradas inválidas.
Prazo de validade
Outra maneira de lidar com problemas de disponibilidade de dados de retirada do usuário é colocar os dados em outro lugar fora da cadeia Bloco. Isso introduz problemas sutis, pois o rollup ainda precisa garantir que os dados estejam disponíveis em outro lugar. Tradicionalmente, outras cadeias Bloco são usadas para esse fim, especialmente projetadas para servir como camada de disponibilidade de dados para sistemas como o rollup.
Isto cria um dilema de segurança igualmente poderoso. Quando os dados são publicados diretamente na cadeia de blocos BTC, 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.
Isto requer provas de que os dados estão na verdade na cadeia, o que acaba por ser um problema de 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 de bloco, sendo o melhor que consegue fazer a verificação ZKP. No entanto, a ZKP não consegue verificar se os dados de rollup do bloco, após a sua geração, foram verdadeiramente divulgados publicamente. Não consegue verificar se a informação externa foi verdadeiramente tornada pública para todos.
Isto abriu a porta 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 na realidade não estão disponíveis. Isso faz com que os utilizadores não consigam levantar fundos. A única solução real é depender totalmente do valor e estrutura de incentivos fora do BTC.
Entra ou sai do labirinto
Isto coloca o rollup em um dilema. Quando se trata de problemas de disponibilidade de dados, basicamente existe uma escolha binária entre publicar os dados na cadeia de blocos BTC ou em outro lugar. Esta escolha tem um grande impacto na segurança, soberania e escalabilidade do rollup.
Por um lado, o uso da cadeia BTC como camada de disponibilidade de dados estabelecerá um limite rígido na escalabilidade do rollup. O espaço do Bloco é limitado, o que estabelece um limite para o número de rollups possíveis e a quantidade total de transações que podem ser processadas fora da cadeia. A cada atualização do rollup, o espaço do Bloco é proporcional ao número de contas cujos saldos mudaram desde a última atualização. A teoria da informação permite apenas que os dados sejam comprimidos até certo ponto, e não há mais potencial de expansão nesse sentido.
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á 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 inteiramente da capacidade do sistema externo utilizado em 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 Blocos em vez de transmitir o Bloco real, tornando os dados disponíveis.
Então, se realmente conseguirmos implementar a solução ideal de Rollup no BTC, alcançando verdadeiramente levantamentos unilaterais dos utilizadores, como seria isso?