Corrija os comentários soltos de Vitalik sobre questões de DA e retiradas resistentes à censura

Vitalik perdeu o “desafio de disponibilidade de dados” de Arbitrum e Redstone, que pode ser chamado de assassino de Celestia.

Escrito por: Faust, geek web3

Em 16 de janeiro de 2024, sob um tweet iniciado por Daniel Wang, fundador do projeto Ethereum Layer 2 Taiko, e interagindo com Zeng Jiajun, fundador da carteira AA Soul Wallet, Vitalik disse: "A chave para Rollup é a segurança incondicional: mesmo "

Escape Pod: “Retiradas seguras sem condições” nas palavras de Viatlik

Como Vitalik falou sobre suas opiniões sobre o Validium na segunda metade deste tweet (Validium se refere à segunda camada do ZK que não usa Ethereum para implementar a liberação de dados DA), isso atraiu muita atenção (anteriormente havia rumores de que o Ethereum O Fundo pensará em Layer2=Rollup).

(É preciso enfatizar: **O conceito de DA discutido na comunidade Ethereum refere-se a se você pode obter dados recém-gerados da Camada 2, e não se você pode recuperar dados históricos há muito tempo. ** Se não for publicado no Ethereum cadeia Novos dados, os nós da camada 2 podem não conseguir analisar com êxito o bloco L2 mais recente)

No entanto, o “Debate sobre a definição da camada 2 do Ethereum” e a “Guerra DA” têm sido ouvidos há muito tempo por inúmeras pessoas. Este artigo não pretende fazer nenhuma discussão sobre tais tópicos. O objetivo é concentrar mais energia na primeira metade de Discurso de Vitalik, também São as palavras mencionadas no início deste artigo.

Vitalik afirmou aqui que o Rollup pode obter retiradas confiáveis e resistentes à censura. Mesmo que todos os nós da Camada 2 não cooperem com você, você ainda pode retirar seus ativos da Camada 2; e ** ele apontou que apenas o rollup pode conseguir isso " “Seguro incondicional retirada”, enquanto a Camada 2, que depende de outros métodos de liberação de dados DA, não pode fazer isso. **

Mas, na verdade, o que Vitalik disse não é rigoroso. **

Em primeiro lugar, apenas os ativos que são interligados da Camada 1 para a Camada 2 podem ser cruzados de volta para a cadeia ETH. Os ativos nativos puros da Camada 2 não podem ser cruzados para a Camada 1 (a menos que os ativos nativos da Camada 2 implementem um contrato de ativos de ponte na Camada 1).

**Se, como Vitalik disse, “todo mundo está mirando em você”, **você pode retirar no máximo os ativos de ponte L1-L2, **mas você não pode retirar seu “Token nativo da Camada2”, **neste momento Isso não acontece não importa se você usa uma retirada normal, uma retirada forçada ou uma escotilha de fuga.

Em segundo lugar, “**Retirada segura sem condições” não depende necessariamente do sistema DA. **A solução Layer2 inicial antes do Rollup, Plasma que implementa a liberação de dados DA na cadeia Ethereum, quando o sistema DA falha (ou seja, ocorre retenção de dados, além do sequenciador/comitê, ninguém mais pode receber novos dados de transação/Estado informações de transição), também permite que os usuários enviem certificados de ativos por meio de dados históricos e escapem da Camada 2 com segurança.

Em outras palavras, **as retiradas seguras do Plasma não dependem do sistema DA, e **as retiradas anticensura não precisam depender do sistema DA (mas os dados históricos devem estar disponíveis); além disso, **esta declaração é de Ethereum Dankrad da Fundação (o criador do Danksharding) disse ele mesmo, ** também é universalmente aceito.

Consulte os artigos anteriores do Geek Web3: “Retenção de dados e prova de fraude: razões pelas quais o Plasma não oferece suporte a contratos inteligentes”

Em segundo lugar, deixando de lado Celestia e Blobstream, o problema de retenção de dados/falha de DA pode ser resolvido mesmo sem usar ETH como camada de DA. Vamos apenas falar sobre o “desafio de disponibilidade de dados” que a equipe Arbitrum e a equipe Redstone estão implementando, permitindo ao sequenciador publicar apenas um Compromisso DA (na verdade, um datahash) na cadeia, informando que os dados foram liberados da cadeia. Se alguém não conseguir obter os dados recém-gerados fora da cadeia, poderá desafiar o Compromisso DA na cadeia e exigir que o sequenciador divulgue os dados à cadeia.

Este mecanismo tem um design muito simples e não precisa depender de DAs de terceiros, como Celestia, Avail ou EigenDA. Ele requer apenas que a parte do projeto Layer2 configure o próprio nó DAC fora da cadeia. pode ser chamado de assassino de Celestia. **

A seguir, o autor pretende interpretar a “retirada segura sem condições” mencionada por Vitalik e o “desafio de disponibilidade de dados” que ele não mencionou, e tentar dizer a todos: **Por que projetos DA de terceiros como Celestia, Avail , e EigenDA não são uma opção obrigatória para a Camada 2 que é DA offchain e busca segurança? **

Além disso, em nosso artigo anterior explicando "Indicadores de avaliação de risco da camada 2 do Bitcoin", falamos sobre as retiradas resistentes à censura serem mais básicas e críticas do que o sistema DA. O artigo de hoje também discutirá esse ponto de vista. fornecer mais informações explicação. **

Na verdade, não é difícil deduzir o que Vitalik disse: ele estava falando sobre a cabine de fuga de ZK Rollup. Escape Hatch, também conhecido como Escape Hatch, é um modo de retirada acionado diretamente na Camada1. Assim que este modo for acionado, o contrato Rollup entrará em um estado congelado, rejeitará novos dados enviados pelo Sequenciador e permitirá que qualquer pessoa mostre Merkle Proof para provar seu saldo de ativos na Camada 2 e transfira seus próprios ativos de Transferência oficial do endereço de depósito da ponte Layer2. **

Além disso, o modo de saída de emergência é 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 período. **

No entanto, antes de ativar o modo de saída de emergência, os usuários rejeitados pelo sequenciador devem primeiro chamar a função de retirada forçada no contrato Rollup na Camada1, iniciar uma solicitação de retirada forçada e lançar um evento para informar o nó da Camada2: alguém iniciou uma retirada forçada.Solicitação de retirada.

Como todos os nós da camada 2 executarão o cliente Ethereum geth e receberão blocos Ethereum, eles poderão monitorar o acionamento do evento de retirada forçada

Se a solicitação de retirada forçada for ignorada por um longo período, o usuário poderá acionar ativamente o modo de saída de emergência (o período de espera padrão do protocolo Loopring é de 15 dias e o plano StarkEx é de 7 dias). Em seguida, o processo de operação é discutido no início deste artigo: o usuário envia a Prova Merkle correspondente aos seus próprios ativos para comprovar o status de seu ativo na Camada 2 e, em seguida, retira os ativos do contrato relacionado ao Rollup.

**Mas para construir a Prova Merkle, você precisa primeiro saber o status L2 completo e **você precisa encontrar um nó completo L2 para solicitar dados. Se a situação extrema mencionada por Vitalik ocorrer e não houver nenhum nó da Camada 2 para cooperar com você, ** você mesmo pode iniciar um nó completo da Camada 2 e obter os dados históricos publicados pelo classificador L2 para Ethereum através da rede Ethereum, ** da Camada 2 Os blocos de gênese começam a ser sincronizados um por um até que o estado final seja calculado e a Prova Merkle seja construída, e então os fundos podem ser retirados com segurança através da escotilha de fuga.

**Obviamente, a “resistência à censura” neste momento é equivalente à própria Ethereum/Layer1. **Enquanto o nó completo do Ethereum fornecer dados históricos de muito tempo atrás, ele estará próximo da falta de confiança.

**No entanto, após o EIP-4844, todos os nós Ethereum perderão automaticamente alguns dados históricos, de modo que os dados históricos da Camada 2 por mais de 18 dias não serão mais apoiados por todo o nó ETH. Nesse momento, a resistência à censura das retiradas das saídas de emergência não serão mais tão boas quanto Hoje está tão perto do Trustless. **

Depois de 4844, precisamos confiar que um número relativamente limitado de nós Ethereum que armazenam todos os dados históricos estão dispostos a fornecer dados a você (os nós nativos da camada 2 geralmente são muito poucos, portanto, não os consideraremos por enquanto). Até então, a suposição de confiança de ** os dados históricos da camada 1 podem ser recuperados/a retirada da escotilha de escape da camada 2 mudará do Trustless de hoje ou de 0 para 1/N, ou seja, presume-se que 1 em cada N nós pode fornecer dados. **

A equipe EthStorage parece estar empenhada em expandir este N para encorajar mais nós a armazenar dados históricos de muito tempo atrás. Se o denominador de 1/N for grande o suficiente, a pontuação ainda estará próxima de 0, o que significa que nenhuma suposição de confiança foi introduzida. Esta pode ser uma solução apropriada para o problema de recuperação de dados históricos após 4844.

A relação entre cápsulas de fuga e DA – ataque de ransomware da Validium

Aqui vamos resumir novamente: **A saída de emergência permite que você comprove o status de seu ativo da Camada 2 por meio do Merkle Proof e faça retiradas confiáveis na Camada 1. **

A razão pela qual Vitalik mencionou que a segurança dos ativos envolvidos em retiradas requer DA como pré-requisito é que a solução Validium pode evitar retiradas devido a “ataques de retenção de dados”. (Apenas stateroot é liberado e os dados de transação correspondentes não são liberados).

O princípio específico é: o sequenciador pode reter os dados da transação e publicar apenas uma Merkle Root (Stateroot) na cadeia Ethereum e, então, por meio de prova de validade, tentar fazer com que a nova Stateroot passe na verificação e se torne a atual Stateroot legal.

Neste momento, todos não sabem o status completo correspondente ao Stateroot legal e não podem construir a Prova Merkle correspondente para iniciar a retirada da escotilha de fuga. **Você não pode sacar dinheiro a menos que o classificador esteja disposto a liberar os dados para você. Isso é vividamente chamado de “problema de resgate” por um diretor técnico da Arbitrum (eu pessoalmente prefiro chamar isso de ataque de resgate). **

**Mas a razão pela qual o DA é propenso a “ataques de resgate” no Validium fora da cadeia é porque o design de seu próprio mecanismo não é perfeito o suficiente. **Se um mecanismo de desafio relacionado ao comportamento de retirada for introduzido ou um desafio de disponibilidade de dados for introduzido , teoricamente pode resolver o problema dos ataques de ransomware.

A propósito, como mencionado anteriormente, o Plasma, que permite aos usuários sacar dinheiro por meio de dados históricos de muito tempo atrás, não terá “ataques de resgate” como o Validium, e o Plasma também é DA off-chain (off-chain DA+ verificação on-chain à prova de fraude).

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

**Portanto, retiradas/saídas de fuga resistentes à censura não dependem necessariamente do DA, tudo depende do desenho do mecanismo do processo de retirada. **A razão pela qual Vitalik acredita que as retiradas resistentes à censura estão vinculadas ao DA é porque ele partiu de soluções existentes, como Validium e Rollup de contrato inteligente, e já tinha uma mentalidade fixa em mente.

**Mas isso não significa que toda a camada 2 do DA offchain no mundo enfrente os mesmos problemas que o Validium. **Isso não significa que o tipo de contrato inteligente Rollup seja o fim de tudo. A inovação pode acontecer a qualquer momento (como os desafios de disponibilidade de dados mencionados posteriormente).

Por outro lado, se a sua solução de Camada 2 não considerar projetos como escotilhas de fuga e retiradas anticensura desde o início, sua Camada 2 definitivamente não será confiável/segura o suficiente. **Em outras palavras, um bom sistema de AD e de prova são condições suficientes para conseguir retiradas resistentes à censura, mas não são uma condição necessária.

Portanto, em nosso artigo anterior, mencionamos que no efeito barril da Camada 2, a retirada resistente à censura é uma deficiência mais básica do que os sistemas DA e de prova, e há uma razão.

*Material de referência: *“Usando a teoria do barril para desmantelar o modelo de segurança e indicadores de risco Bitcoin/Ethereum Layer 2”

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

Depois de falar sobre a relação entre a saída de emergência e o DA, vamos olhar para o próprio DA: a camada 2 não precisa publicar dados do DA no Ethereum para evitar a “retenção de dados” pelo sequenciador.

estão todos desenvolvendo um mecanismo de “desafio de disponibilidade de dados”, que permite ao sequenciador publicar apenas Compromisso DA (datahash) + Stateroot na cadeia, informando que os parâmetros de transição de estado (dados de transação) foram publicados fora da cadeia. **Se alguém não conseguir obter os dados recém-gerados fora da cadeia, poderá desafiar o Compromisso DA na cadeia e exigir que o sequenciador divulgue os dados à cadeia. **

Se o sequenciador não publicar dados na cadeia ETH a tempo após ser desafiado, o 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 stateroot é liberado e os dados de transação correspondentes não são liberados). **

Obviamente, isso representa um “desafio de disponibilidade de dados” adicional em comparação com a Camada 2 de offchains de DA, como Validium e Optimium. **Mas um design tão simples é suficiente para criar uma forte concorrência contra Celestia, Avail, EigenDA, etc. **Configure você mesmo um DAC e apresente desafios de disponibilidade de dados, para que você não precise mais depender do Celestia.

Mas, em contraste, **os desafios de disponibilidade de dados também têm questões económicas que precisam de ser resolvidas. **O fundador do ZkSync apontou durante uma batalha com o diretor técnico da Arbitrum que **os desafios de disponibilidade de dados são teoricamente suscetíveis a ataques DoS. **Por exemplo, o sequenciador libera rapidamente milhares de compromissos de DA na cadeia e, em seguida, retém os dados completos correspondentes sem liberá-los. Ele pode drenar todos os fundos do desafiante dessa forma e então emitir um bloqueio inválido, roubando os ativos do usuário.

Claro, essa suposição é muito extrema. É essencialmente um problema de teoria dos jogos entre o atacante e o defensor. Na verdade, é mais provável que o sequenciador seja atacado por desafiantes maliciosos e degenere em um Rollup após ser desafiado continuamente. A situação do jogo entre os lados ofensivo e defensivo em torno do desafio da disponibilidade de dados é realmente muito interessante, e o design do mecanismo correspondente também testará completamente a sabedoria de Arbitrum, Redstone e da equipe do projeto Metis (este tópico pode ser escrito separadamente).

Mas, em qualquer caso, o desafio da disponibilidade de dados trará mais inovação ao design da solução DA da Camada 2, que também dará uma contribuição significativa ao ecossistema Bitcoin da Camada 2.