Fonte: Bitcoin Magazine; Tradução: Wu Zhu, Golden Finance
Rollups tornou-se recentemente o foco da expansão do BTC, tornando-se a primeira coisa a realmente roubar o protagonismo da Rede de iluminação e atrair uma atenção mais ampla. Rollups têm como objetivo ser uma segunda camada fora da cadeia que não é restrita ou limitada pela Liquidez central da Rede de iluminação, ou seja, os usuários finais precisam ter fundos alocados antecipadamente (ou ‘emprestados’) para receber dinheiro, ou os Nós intermediários precisam ter saldo de canal para facilitar o fluxo total do valor do remetente ao destinatário.
Esses sistemas foram originalmente executados em Ethereum e outros sistemas Turing Completo, mas recentemente o foco mudou para portá-los para blockchains baseadas em UTXO (como BTC). Este artigo não pretende discutir o estado atual da implementação em BTC, mas sim as funcionalidades do Rollup idealizado que as pessoas têm buscado a longo prazo, o que depende 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 em BTC) guarda o saldo de todos os usuários no Rollup. Este 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 com Chave pública/Chave privada, portanto, para gastar fora da cadeia, os usuários ainda precisam assinar algumas coisas com Chave Secreta. Esta parte da estrutura permite que os usuários saiam a qualquer momento sem permissão, simplesmente provando que suas contas são parte da árvore de Merkle, eles podem sair unilateralmente do Rollup sem permissão do operador.
Os operadores de Rollup devem incluir um ZKP nas transações para atualizar o saldo da conta na cadeia após a conclusão das transações fora da cadeia, se o ZKP não estiver presente, a transação será inválida e não pode ser incluída no bloco. Essa prova permite que as pessoas verifiquem se todas as alterações de saldo fora da cadeia estão 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, como é que os utilizadores colocam os seus ramos na árvore de modo a poderem sair quando quiserem sem permissão?
Rollup apropriado
Em um Rollup apropriado, toda 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, o 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, utiliza-se a diferença de saldo. Isso essencialmente resume quais contas tiveram adições ou subtrações de fundos durante o processo de atualização. Isso permite que cada atualização 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 da conta, permitindo que eles reconstruam 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), permitindo ainda que os utilizadores garantam o acesso às informações necessárias para a saída unilateral. As regras do 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 um resumo de conta ou diferenças de conta são consideradas inválidas.
Prazo de validade
Outra abordagem para lidar com a questão da disponibilidade de dados para retirada de usuários é colocar os dados em outros lugares fora do Bloco. Isso introduz problemas sutis, pois o rollup ainda precisa garantir que os dados estejam disponíveis em outros lugares. Tradicionalmente, outros blocos são usados para esse fim, especialmente projetados para servir como camada de disponibilidade de dados para sistemas como rollup.
Isso 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 uma prova SPV, ou seja, que os dados foram publicados em outro sistema.
Isso requer uma prova de que os dados estão presentes em outras cadeias, o que acaba sendo um problema para a Máquina Oracle. A cadeia de blocos do BTC não pode verificar completamente qualquer coisa que aconteça fora de sua própria cadeia de blocos, exceto validar ZKP. No entanto, o ZKP não pode verificar se o bloco que contém os dados do rollup foi realmente divulgado publicamente após a geração. Não pode verificar se as informações externas estão realmente disponíveis 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 avançar com o rollup, mas os dados não estão realmente disponíveis. Isso resulta na incapacidade dos usuários de retirar fundos. A única solução real é depender totalmente de sistemas de valor e estruturas de incentivo fora do BTC.
Estar entre a espada e a parede
Isto coloca o rollup numa situação difícil. 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 noutro local. 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 impõe um limite rígido à escalabilidade do rollup. O espaço do bloco é limitado, o que define um limite para a quantidade de rollups que podem existir de uma só vez e a quantidade total de transações que podem ser processadas fora da cadeia em todos os rollups. 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 permite apenas a compressão dos dados até certo ponto, depois disso não há mais potencial de escalabilidade.
Por outro lado, usar diferentes camadas 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. No Rollup que utiliza BTC para alcançar a disponibilidade de dados, se os dados que os usuários precisam extrair não forem automaticamente publicados na blockchain, o estado do Rollup não poderá ser alterado. Com o uso do Validiums, essa garantia depende inteiramente da capacidade dos sistemas externos 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 ao produzir o Bloco em vez de transmitir o Bloco real, tornando os dados disponíveis.
Então, se realmente conseguirmos alcançar uma implementação Rollup ideal no BTC, permitindo verdadeiramente retiradas unilaterais dos usuários, como seria isso?
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
Bitcoin Magazine: Quais são os desafios enfrentados pelo Rollup?
Fonte: Bitcoin Magazine; Tradução: Wu Zhu, Golden Finance
Rollups tornou-se recentemente o foco da expansão do BTC, tornando-se a primeira coisa a realmente roubar o protagonismo da Rede de iluminação e atrair uma atenção mais ampla. Rollups têm como objetivo ser uma segunda camada fora da cadeia que não é restrita ou limitada pela Liquidez central da Rede de iluminação, ou seja, os usuários finais precisam ter fundos alocados antecipadamente (ou ‘emprestados’) para receber dinheiro, ou os Nós intermediários precisam ter saldo de canal para facilitar o fluxo total do valor do remetente ao destinatário.
Esses sistemas foram originalmente executados em Ethereum e outros sistemas Turing Completo, mas recentemente o foco mudou para portá-los para blockchains baseadas em UTXO (como BTC). Este artigo não pretende discutir o estado atual da implementação em BTC, mas sim as funcionalidades do Rollup idealizado que as pessoas têm buscado a longo prazo, o que depende 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 em BTC) guarda o saldo de todos os usuários no Rollup. Este 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 com Chave pública/Chave privada, portanto, para gastar fora da cadeia, os usuários ainda precisam assinar algumas coisas com Chave Secreta. Esta parte da estrutura permite que os usuários saiam a qualquer momento sem permissão, simplesmente provando que suas contas são parte da árvore de Merkle, eles podem sair unilateralmente do Rollup sem permissão do operador.
Os operadores de Rollup devem incluir um ZKP nas transações para atualizar o saldo da conta na cadeia após a conclusão das transações fora da cadeia, se o ZKP não estiver presente, a transação será inválida e não pode ser incluída no bloco. Essa prova permite que as pessoas verifiquem se todas as alterações de saldo fora da cadeia estão 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, como é que os utilizadores colocam os seus ramos na árvore de modo a poderem sair quando quiserem sem permissão?
Rollup apropriado
Em um Rollup apropriado, toda 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, o 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, utiliza-se a diferença de saldo. Isso essencialmente resume quais contas tiveram adições ou subtrações de fundos durante o processo de atualização. Isso permite que cada atualização 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 da conta, permitindo que eles reconstruam 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), permitindo ainda que os utilizadores garantam o acesso às informações necessárias para a saída unilateral. As regras do 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 um resumo de conta ou diferenças de conta são consideradas inválidas.
Prazo de validade
Outra abordagem para lidar com a questão da disponibilidade de dados para retirada de usuários é colocar os dados em outros lugares fora do Bloco. Isso introduz problemas sutis, pois o rollup ainda precisa garantir que os dados estejam disponíveis em outros lugares. Tradicionalmente, outros blocos são usados para esse fim, especialmente projetados para servir como camada de disponibilidade de dados para sistemas como rollup.
Isso 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 uma prova SPV, ou seja, que os dados foram publicados em outro sistema.
Isso requer uma prova de que os dados estão presentes em outras cadeias, o que acaba sendo um problema para a Máquina Oracle. A cadeia de blocos do BTC não pode verificar completamente qualquer coisa que aconteça fora de sua própria cadeia de blocos, exceto validar ZKP. No entanto, o ZKP não pode verificar se o bloco que contém os dados do rollup foi realmente divulgado publicamente após a geração. Não pode verificar se as informações externas estão realmente disponíveis 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 avançar com o rollup, mas os dados não estão realmente disponíveis. Isso resulta na incapacidade dos usuários de retirar fundos. A única solução real é depender totalmente de sistemas de valor e estruturas de incentivo fora do BTC.
Estar entre a espada e a parede
Isto coloca o rollup numa situação difícil. 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 noutro local. 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 impõe um limite rígido à escalabilidade do rollup. O espaço do bloco é limitado, o que define um limite para a quantidade de rollups que podem existir de uma só vez e a quantidade total de transações que podem ser processadas fora da cadeia em todos os rollups. 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 permite apenas a compressão dos dados até certo ponto, depois disso não há mais potencial de escalabilidade.
Por outro lado, usar diferentes camadas 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. No Rollup que utiliza BTC para alcançar a disponibilidade de dados, se os dados que os usuários precisam extrair não forem automaticamente publicados na blockchain, o estado do Rollup não poderá ser alterado. Com o uso do Validiums, essa garantia depende inteiramente da capacidade dos sistemas externos 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 ao produzir o Bloco em vez de transmitir o Bloco real, tornando os dados disponíveis.
Então, se realmente conseguirmos alcançar uma implementação Rollup ideal no BTC, permitindo verdadeiramente retiradas unilaterais dos usuários, como seria isso?