Porque é que a declaração de Vitalik Buterin sobre "questões de AD e retiradas resistentes à censura" não é rigorosa?

Título original: “Corrigindo as observações laxistas de Vitalik Buterin sobre questões de DA e retiradas resistentes à censura”

Autor original: Fausto

Fonte original: Geek Web3

Em 16 de janeiro de 2024, em um tweet iniciado por DanielWang, fundador do projeto Ethereum Layer 2 Taiko, e interagindo com Zeng Jiajun, fundador da AA Wallet Soul Wallet, Vitalik disse: "A chave para o Rollup é a segurança incondicional: mesmo que você seja alvo de todos, você ainda pode retirar seus ativos. Isso não pode ser feito se o DA depender de sistemas externos (fora do Ethereum). 」**

Escape Pod: Viatlik’s “Retirada segura sem condições”

Desde que Vitalik falou sobre suas opiniões sobre o Validium na segunda metade deste tweet (Validium se refere à ZK Layer 2 que não usa Ethereum para implementar a publicação de dados DA), ele recebeu muita atenção (rumores anteriores de que a Fundação Ethereum acredita que a Camada 2 = Rollup).

(Deve-se enfatizar que o conceito de DA sobre o qual a comunidade Ethereum fala se refere a se você pode acessar os dados recém-gerados da Camada 2, não se você pode recuperar dados históricos de muito tempo atrás.) **Se novos dados não forem publicados na cadeia Ethereum, o Nó de Camada 2 pode não ser capaz de resolver o Bloco L2 mais recente sem problemas)

No entanto, a “Controvérsia da Definição da Camada 2 do Ethereum” e a “Guerra DA” têm sido ouvidas há muito tempo por inúmeras pessoas, e este artigo não vai entrar em nenhuma discussão sobre tais tópicos, mas focar mais energia na primeira metade do discurso de Vitalik, que é a abordada no início deste artigo.

Vitalik mostra aqui que os rollups podem permitir retiradas resistentes à censura sem confiança, permitindo que você retire seus ativos mesmo que todos os Nós da Camada 2 não cooperem com você da Camada 2 e, ele aponta, apenas os rollups podem alcançar tais “retiradas incondicionais e seguras”, o que não pode ser feito pela Camada 2 que depende de outros métodos de publicação de dados DA. **

Mas, na realidade, as palavras de Vitalik não são rigorosas. **

Em primeiro lugar, apenas os ativos que são ponteados para a Camada 2 podem cruzar de volta para a cadeia ETH, e os ativos nativos puros da Camada 2 não podem cruzar para a Camada 1 (a menos que o ativo nativo da Camada 2 implante um contrato de ativo de ponte na Camada 1).

Se, como Vitalik disse, “todo mundo está mirando em você”, você pode retirar os ativos da ponte L1-L2 no máximo, mas você não pode retirar seu próprio “token nativo da Camada 2”, neste momento, se você fizer retirada comum, retirada forçada ou Escape Hatch, é inútil.

Em segundo lugar, os “levantamentos seguros sem condições” não têm de depender do sistema DA. **Soluções de Camada 2 Inicial antes do Rollup, Plasma que implementa a publicação de dados DA sob a cadeia Ethereum e falhas do sistema DA (ou seja, a retenção de dados ocorre, e ninguém além do sequenciador/comitê pode receber novos dados de transação/informações de transição de estado), também permite que os usuários enviem provas de ativos por meio de dados históricos e escapem com segurança da Camada 2.

Em outras palavras, as retiradas seguras do Plasma não dependem do sistema DA, e as retiradas resistentes à censura não precisam depender do sistema DA (mas para garantir que os dados históricos estejam disponíveis), além disso, essa afirmação foi feita por Dankrad (proponente de Danksharding) da Fundação Ethereum, e também é axiomática em todos os lugares.

Consulte os artigos anteriores do Geek Web3: “Data Withholding and Fraud Proof: Why Plasma Doesn’t Support Smart Contracts” (Retenção de dados e à prova de fraude: por que o Plasma não suporta contratos inteligentes)

Em segundo lugar, Celestia e Blobstream à parte, o problema de retenção de dados/falha de DA pode ser resolvido mesmo se ETH não for usado como a camada DA. Vamos apenas falar sobre o “desafio de disponibilidade de dados” em que a equipe do Arbitrum e a equipe Redstone estão trabalhando, permitindo que o sequenciador publique apenas um Compromisso de DA (na verdade, datahash) on-chain, afirmando que os dados foram publicados off-chain. Se alguém não conseguir obter os dados recém-gerados fora da cadeia, poderá desafiar o Compromisso de DA on-chain e pedir ao sequenciador que divulgue os dados on-chain.

O design desse mecanismo é muito simples, e ele não precisa depender de DAs de terceiros, como Celestia, Avail ou EigenDA, mas só precisa do grupo do projeto de Camada 2 para configurar seu próprio nó de DAC off-chain, que pode ser chamado de assassino Celestia. **

A seguir, o autor pretende interpretar as “retiradas seguras incondicionais” de Vitalik e os “desafios de disponibilidade de dados” que ele não mencionou, tentando dizer-lhe: Por que projetos de DA de terceiros, como Celestia e Avail e EigenDA, não são necessários para DA offchain e Camada 2 de busca de segurança?

Além disso, em nosso artigo anterior sobre os “Indicadores de Avaliação de Risco da Camada 2 do Bitcoin”, falamos sobre o fato de que os saques resistentes à censura são mais básicos e críticos do que os sistemas DA, e o artigo de hoje explicará melhor esse ponto. **

Na verdade, as palavras de Vitalik não são difíceis de deduzir, ** está falando sobre o pod de fuga do ZK Rollup. **O Escape Pod também conhecido como Escape Hatch é um modo de retirada que é acionado diretamente na Camada 1. Assim que esse modo for acionado, o contrato de Rollup entrará em um estado congelado, rejeitará novos dados enviados pelo Sequencer e permitirá que qualquer pessoa mostre a Merkle Proof para provar seu saldo de ativos na Camada 2 e transferir seus ativos do endereço oficial de depósito de ponte da Camada 2. **

Além disso, o modo pod de escape ** é um “Mecanismo de Retirada Sem Confiança” que pode ser acionado manualmente pelas partes na Camada 1 após a transação do usuário ter sido rejeitada pelo sequenciador da Camada 2 por um longo tempo. **

No entanto, antes de ativar o modo de pod de escape, os usuários rejeitados pelo sequenciador precisam chamar a função de retirada forçada no contrato de Rollup na Camada 1 para iniciar uma solicitação de retirada forçada e lançar um evento para informar o Nó da Camada 2 de que alguém iniciou uma solicitação de retirada forçada.

Como o nó de camada 2 executará o cliente geth Ethereum e receberá o EthereumBlock, ele será capaz de ouvir o acionamento de eventos de retirada forçada

Se a solicitação de retirada forçada for ignorada por um longo tempo, o usuário pode acionar ativamente o modo pod de escape (o período de espera padrão é de 15 dias para o protocolo Loopring e 7 dias para a solução StarkEx). Em seguida, conforme discutido no início deste artigo, os usuários enviam a Prova Merkle correspondente aos seus ativos, comprovam seu status de ativos na Camada 2 e, em seguida, retiram os ativos do contrato relacionado ao Rollup.

Mas para construir Merkle Proof, você precisa saber o estado L2 completo primeiro, e você precisa encontrar um L2 Full Node para pedir dados. Se o tipo de situação extrema de que Vitalik está falando acontecer, e não houver nenhum Nó de Camada 2 para cooperar com você, você pode iniciar um Nó Completo de Camada 2 sozinho, obter os dados históricos publicados pelo sequenciador L2 para o Ethereum através da rede Ethereum e sincronizar um a um do Bloco Genesis da Camada 2 até que o estado final seja calculado, e a Prova de Merkle seja construída, e você pode retirar dinheiro com segurança através do pod de escape.

**Obviamente, a “resistência à censura” neste momento é equivalente ao próprio Ethereum/Camada 1. **Desde que haja um EthereumFull Node para lhe fornecer dados históricos de muito tempo atrás, ele está perto de Trustless.

**No entanto, após o EIP-4844, o EthereumFull Node perderá automaticamente parte dos dados históricos, de modo que os dados históricos da Camada 2 por mais de 18 dias não serão mais copiados pela rede ETH Node, e a resistência à censura de retiradas de cabine de escape não será mais tão próxima do Trustless como é hoje. **

Depois do 4844, precisamos confiar, um número relativamente limitado de EthereumNode que armazenam todos os dados históricos, dispostos a fornecer dados para você (o nó nativo da camada 2 geralmente é muito pequeno, então não os considere por enquanto). Naquele momento, a suposição de confiança de que os dados históricos da Camada 1 são recuperáveis/retiradas do pod de escape da Camada 2 mudará de confiáveis ou 0 hoje para 1/N, ou seja, assumindo que 1 dos N Nós possa fornecer dados. **

A equipe do EthStorage parece estar comprometida em escalar esse N, incentivando mais nós a armazenar dados históricos de muito tempo atrás. Se o denominador de 1/N for grande o suficiente, a fração ainda está próxima de 0, o que está perto de não introduzir a hipótese de confiança. Esta pode ser uma solução apropriada para o problema da recuperação de dados históricos pós-4844.

Relação do pod de fuga com DA – Ataque de resgate de Validium

Aqui resumimos novamente: **O pod de escape é uma retirada que permite que você prove seu status de ativo da Camada 2 através de retiradas à prova de Merkle e sem confiança na camada 1. **

A razão pela qual Vitalik mencionou que a segurança dos ativos envolvidos em saques precisa ter DA como premissa, principalmente significa que o esquema de validium não pode ser retirado devido a "ataques de retenção de dados. (Somente stateroot é publicado, não os dados de transação correspondentes).

O princípio específico é que o sequenciador pode reter os dados da transação, apenas liberar uma Raiz Merkle (Stateroot) para a cadeia Ethereum e, em seguida, conseguir fazer a nova verificação de passagem Stateroot e se tornar a Stateroot legítima atual através da prova de validade.

Neste momento, você não sabe o estado completo correspondente ao Stateroot legítimo e não pode construir a Prova Merkle correspondente para iniciar a retirada do pod de escape. Você não pode retirar até que o sequenciador esteja disposto a liberar os dados para você, que é o que um dos líderes de tecnologia da Arbitrum se refere como um “problema de resgate” (eu pessoalmente prefiro chamá-lo de ataque de resgate). **

No entanto, a razão pela qual o validium off-chain da DA é propenso a “ataques de ransomware” é que seu próprio design de mecanismo não é perfeito, e se um mecanismo de desafio relacionado ao comportamento de retirada for introduzido, ou um desafio de disponibilidade de dados for introduzido, o problema do ataque de ransomware pode teoricamente ser resolvido.

A propósito, como mencionado anteriormente, o Plasma, que permite que os usuários retirem através de dados históricos de muito tempo atrás, não terá um “ataque de ransomware”, como validiums, e o Plasma também é DA off-chain (off-chain DA+ on-chain verification fraud proof).

Referência: Retenção de dados e à prova de fraude: por que o Plasma não suporta contratos inteligentes

Portanto, os pods de retirada/escape resistentes à censura não precisam depender de DA, tudo depende do design do mecanismo do processo de retirada. A razão pela qual Vitalik acredita que as retiradas resistentes à censura estão ligadas ao DA é porque ele tem uma mentalidade preconcebida em sua mente baseada em soluções existentes, como Validium e Smart Contract Rollup.

Mas isso não significa que todos os DA offchain Layer 2 do mundo estejam enfrentando os mesmos problemas que os validiums, e não significa que os Smart Contract Rollups sejam o fim de tudo, e a inovação pode acontecer a qualquer momento (como os desafios de disponibilidade de dados mencionados mais tarde).

**Por outro lado, se sua solução de Camada 2 não considerar o design de pods de escape e retiradas resistentes à censura desde o início, sua Camada 2 definitivamente não será confiável/segura o suficiente. Em outras palavras, um bom sistema de DA e atestado é uma condição suficiente para uma retirada resistente à censura, mas não necessária.

Então, em nosso artigo anterior, mencionamos que, no efeito barril da Camada 2, as retiradas resistentes à censura são uma deficiência mais básica do que o DA e os sistemas de prova, e há uma razão.

Referência: “Dismantling Bitcoin / Ethereum Layer 2 Safety Models and Risk Indicators with Barrel Theory”

Celestia Killer: Desafios de disponibilidade de dados para Arbitrum e Redstone

Depois de falar sobre a relação entre o pod de escape e o DA, vamos olhar para trás no próprio DA: a Camada 2 não precisa publicar dados DA no Ethereum para evitar que o sequenciador se envolva em “retenção de dados”.

Redstone, Arbitrum, Metis e outros estão trabalhando em um mecanismo de “desafio de disponibilidade de dados” que permite que sequenciadores publiquem apenas DA Commitment(datahash)+Stateroot on-chain, declarando que os parâmetros de transição de estado (dados de transação) foram publicados off-chain. Se alguém não conseguir obter os dados recém-gerados off-chain, pode desafiar o Compromisso de DA on-chain e pedir ao sequenciador que divulgue os dados on-chain. **

Se o sequenciador for desafiado e não publicar dados na cadeia ETH em tempo hábil, seu datahash/compromisso publicado anteriormente será considerado inválido, e a raiz de estado associada também será inválida. Obviamente, isso resolve diretamente o problema de retenção de dados (apenas a raiz do estado é publicada, não os dados de transação correspondentes). **

Obviamente, este é mais um “desafio de disponibilidade de dados” do que a Camada 2 de offchains de DA, como Validium e Optimium. Mas um design tão simples é suficiente para criar uma forte concorrência com Celestia e Avail, EigenDA, etc. Configure seu próprio DAC para introduzir desafios de disponibilidade de dados e não confie mais no Celestia.

Inversamente, porém, os desafios em matéria de disponibilidade de dados também suscitam questões económicas que têm de ser abordadas. Em uma batalha com o líder técnico da Arbitrum, o fundador do ZkSync apontou que os desafios de disponibilidade de dados são teoricamente suscetíveis a ataques Dos. Por exemplo, o sequenciador publica rapidamente milhares de compromissos de DA na cadeia e, em seguida, retém os dados completos correspondentes e não os publica. Desta forma, ele pode drenar todos os fundos dos desafiantes e, em seguida, publicar um bloco inválido para roubar ativos do usuário.

É claro que essa suposição é muito extrema, é essencialmente um problema de teoria dos jogos tanto para o lado ofensivo quanto para o defensivo, e na verdade, o sequenciador tem mais probabilidade de ser atacado por desafiantes mal-intencionados, e ele regride para um rollup depois de ser desafiado continuamente. O jogo entre o atacante e o defensor em torno do desafio de disponibilidade de dados é realmente muito interessante, e o design mecânico correspondente testará totalmente a sabedoria de Arbitrum e Redstone, bem como a equipe do projeto Metis (este tópico pode ser escrito separadamente).

De qualquer forma, o desafio de disponibilidade de dados trará mais inovação para o design de DA da Camada 2, o que também fará uma grande diferença para o ecossistema da Camada 2 do Bitcoin.

Link para o artigo original