Expulsão de Validium? Re-entenda a Layer2 da perspectiva do proponente do Danksharding

Autor: Fausto

Fonte original: Geek Web3

Introdução: Recentemente, Dankrad Feist, criador do Danksharding e pesquisador da Ethereum Foundation, fez alguns comentários controversos no Twitter. Ele apontou claramente que um blockchain modular que não usa ETH como a camada DA (camada de disponibilidade de dados) não é Rollup, nem é Ethereum Layer 2. De acordo com Dankrad, Arbitrum Nova, Immutable X e Mantle serão todos "removidos" da lista da Camada 2 porque eles apenas divulgam dados de transações fora do ETH (eles construíram sua própria rede DA off-chain chamada DAC).

Ao mesmo tempo, Dankrad também disse que soluções como Plasmas e canais de estado que não exigem disponibilidade de dados on-chain (Data Availability) para garantir a segurança ainda são Layer 2, mas Validium (ZKRollup que não usa ETH como a camada DA) não é Camada 2.

Assim que a observação de Dankrad foi divulgada, muitos fundadores ou pesquisadores da área de Rollup a questionaram. Afinal, existem muitos projetos "Layer 2" que não usam ETH como camada DA (Data Availability) para economizar custos. Se esses projetos forem expulsos da lista L2, isso inevitavelmente afetará bastante a expansão redes; ao mesmo tempo, se o validium não for considerado L2, o Plasma também não deve se qualificar como L2.

A esse respeito, Dankrad disse que quando DA não está disponível (ou seja, a rede da camada DA sob a cadeia se envolve na retenção de dados e não divulga dados de transação), os usuários do Plasma ainda podem retirar seus ativos com segurança para L1; mas sob as mesmas circunstâncias , Validium (a maioria dos projetos que usam o esquema StarkEx são validium), mas pode impedir que os usuários retirem fundos para L1 e congelem o dinheiro.

Obviamente, Dankrad pretende definir se um projeto de expansão é Ethereum Layer 2 de "se é seguro ou não". Do ponto de vista da "segurança", o Validium pode de fato congelar os ativos do usuário em L2 e não pode mencionar o L1 no caso extremo de falha do sequenciador + camada DA lançando um ataque de retenção de dados (ocultando novos dados); Diferente do Validium em design, embora a maioria dos o tempo em que a segurança não é tão boa quanto o Validium, mas quando a falha do sequenciador + camada DA lança um ataque de retenção de dados (ocultando novos dados), ele permite que os usuários evacuem ativos com segurança para L1. Portanto, a retórica de Dankrad faz sentido.

Este artigo pretende partir da perspectiva do Dankrad e analisar mais detalhadamente os detalhes da Camada 2 para obter uma compreensão aprofundada de por que o Validium não é estritamente "Camada 2".

Como definir a Camada 2?

De acordo com a definição do site ethereum.org e da maioria dos membros da comunidade Ethereum, a Camada 2 é "uma blockchain independente que expande a capacidade do Ethereum + herda a segurança do Ethereum". Em primeiro lugar, "expandir a capacidade do Ethereum" refere-se a desviar o tráfego que o Ethereum não pode transportar e compartilhar a pressão do TPS. E "herdar a segurança do Ethereum" pode ser traduzido como "proteger sua própria segurança com a ajuda do Ethereum".

Por exemplo, toda transação Tx na Camada 2 deve ser finalizada no ETH, e Tx com dados incorretos não serão liberados; se você deseja reverter o bloco da Camada 2, deve primeiro reverter o bloco Ethereum, desde que o Ethereum Se não houver reversão de bloqueio semelhante ao ataque de 51% na rede Fangzhu, o bloco L2 não será revertido.

Se explorarmos ainda mais a segurança da camada 2, na verdade existem muitos casos extremos a serem considerados. Por exemplo, se a parte do projeto L2 fugir, o sequenciador falhar e a camada DA off-chain desligar, os usuários podem sacar seus fundos com segurança em L2 para L1 quando esses eventos extremos ocorrerem?

Mecanismo de "retirada forçada" da camada 2

Independentemente de fatores como atualizações de contrato L2/perigos ocultos de assinatura múltipla, de fato, como Arbitrum ou StarkEx, existem saídas para os usuários definirem saques obrigatórios. Supondo que o sequenciador de L2 lance um ataque de censura, rejeite intencionalmente a solicitação de transação/retirada do usuário ou simplesmente desligue permanentemente, o usuário Arbitrum pode chamar a função de inclusão forçada do contrato Sequencer Inbox em L1 para enviar diretamente os dados da transação para L1 ; Em 24 horas, o sequenciador não processou a transação/saque que requer "inclusão obrigatória", e a transação será incluída diretamente na sequência de transações do ledger Rollup, que cria um "saque forçado" para usuários L2. exit" .

Em comparação, a solução StarkEx com o mecanismo Escape Hetch não é menos. Se o usuário L2 não obtiver uma resposta do sequenciador quando a solicitação de Retirada Forçada enviada por L1 terminar dentro da janela de 7 dias, o usuário pode chamar a função freeze Request para fazer L2 entrar no período de congelamento. Neste momento, o sequenciador L2 não será capaz de atualizar o estado de L2 em L1, e levará 1 ano para que o estado de L2 seja descongelado após ser congelado.

Depois que o estado L2 é congelado, o usuário pode construir uma Prova Merkle relacionada ao estado atual para provar que ele tem uma quantidade XX de fundos em L2 e sacar dinheiro por meio do contrato relacionado a Escape Hetch em L1. Este é o serviço de "retirada total" fornecido pelo programa StarkEx. Mesmo que a parte do projeto L2 tenha desaparecido e o sequenciador falhe permanentemente, os usuários ainda têm uma maneira de retirar fundos do L2.

Mas há um problema aqui: a maioria dos L2 usando o esquema StarkEx é Validium (como Immutable X e ApeX), e não publicará os dados exigidos pelo DA para ETH, e as informações para construir a árvore de estado L2 atual são armazenadas fora da cadeia. Se o usuário não conseguir obter os dados para construir o Merkle Proof off-chain (por exemplo, a camada DA off-chain lança um ataque de retenção de dados), é impossível sacar dinheiro por meio do pod de escape.

Até agora, a razão pela qual Dankrad mencionou no início do artigo que o Validium não é seguro é realmente muito clara: como o Validium não envia dados DA para a cadeia como o Rollup, os usuários podem não conseguir construir o Merkle necessário para "aplicações forçadas retirada". Prova.

A diferença entre Validium e Plasma no caso de um ataque de retenção de dados

Na verdade, o sequenciador do Validium publica apenas o Stateroot mais recente (a raiz da árvore de estado) de L2 na cadeia L1 e, em seguida, envia uma Prova de Validade (ZK Proof) para provar a transição de estado (mudança de fundos do usuário) envolvida no novo Stateroot processo de geração. , estão todos corretos.

(Fonte: eckoDAO)

No entanto, o stateroot sozinho não pode restaurar a árvore de estado do mundo no momento, e não pode saber o estado específico de cada conta L2 (incluindo o saldo do fundo), e os usuários do L2 não podem construir uma Prova Merkle correspondente ao Stateroot legal atual. É aqui que o Validium está em desvantagem.

(Merkle Proof são, na verdade, os dados necessários no processo de geração da raiz, que é a parte escura da figura. Para construir uma Merkle Proof correspondente a Stateroot, você deve conhecer a estrutura da árvore de estado e precisa dos dados DA)

Aqui devemos enfatizar a coisa DAC. Os dados envolvidos no DA da Validium, como o último lote de transações processadas pelo sequenciador, serão sincronizados com a rede DA exclusiva L2 denominada Comitê de Disponibilidade de Dados (DAC). mas isso é apenas na superfície, de fato, é difícil para o mundo exterior verificar quem são os membros do DAC).

O que é interessante é que os membros DAC da Validium precisam frequentemente enviar assinaturas múltiplas em L1 para provar que o novo Stateroot e Validity Proof enviados pelo sequenciador L2 em L1 podem corresponder aos dados DA sincronizados pelo DAC. Após o envio de várias assinaturas do DAC, o novo Stateroot e a Prova de Validade serão considerados legais.

Atualmente, o DAC do Immutable X adota 5/7 multi-sig. Embora dYdX seja um ZKRollup, ele também possui DAC, que usa 1/2 multi-sig. (dYdX só publica State diff em L1, ou seja, mudanças de estado, não dados completos da transação. No entanto, após obter o State diff no registro histórico, o saldo patrimonial de todos os endereços L2 pode ser restaurado. Nesse momento, o Merkle Proof pode ser construído para retirar na íntegra).

Dankrad tem razão. Se os membros DAC do Validium conspirarem para lançar um ataque de retenção de dados, impedir que outros nós L2 sincronizem os dados mais recentes no momento e atualizar o Stateroot legal do L2 no momento, o usuário não poderá construir a Prova Merkle correspondente ao legal root no momento de sacar dinheiro (porque os dados DA não estão disponíveis, os dados DA anteriores estão disponíveis).

Mas Dankrad considera apenas os extremos teóricos.Na realidade, a maioria dos sequenciadores Validium transmitirá os dados da transação recém-processada para outros nós L2 em tempo real, incluindo muitos nós honestos. Contanto que haja um nó honesto que possa obter dados DA a tempo, o usuário pode escapar de L2.

Teoricamente, o problema existe no Validium, mas por que não existe no Plasma? Isso ocorre porque a forma como o Plasma determina o Stateroot legal é diferente da Validium, porque há um período de janela à prova de fraude. O Plasma é a solução de expansão L2 antes do OPRollup. Assim como o OPR, ele conta com provas de fraude para garantir a segurança do L2.

O Plasma, assim como o OPR, tem um período de janela configurado, o novo stateroot liberado pelo sequenciador não será julgado como legal imediatamente, ele tem que esperar até que o período de janela seja encerrado e nenhum nó L2 emita um certificado de fraude. Portanto, os Stateroots legais atuais de Plasma e OPR foram todos enviados há alguns dias (isso é como a luz das estrelas que vemos, que na verdade foi emitida há muito tempo), e os usuários geralmente podem obter dados DA no passado.

Ao mesmo tempo, o pré-requisito para que o mecanismo à prova de fraude entre em vigor neste momento é que o L2 DA esteja disponível no momento, ou seja, o nó Verificador do Plasma possa obter os dados envolvidos no DA no momento, então que a prova de fraude no momento possa ser gerada (se necessário).

Então tudo é simples: o pré-requisito para que o Plasma funcione corretamente é que os dados DA de L2 estejam disponíveis no momento. Se a partir de agora o DA de L2 estiver indisponível, os usuários podem sacar fundos com segurança?

Este problema não é difícil de analisar, assumindo que o período de janela do Plasma é de 7 dias, se a partir de um certo ponto de tempo T 0, os novos dados DA não estarão disponíveis (DAC lança um ataque de retenção de dados para evitar que nós L2 honestos obtendo T 0 Os dados). Como o Stateroot legal em T 0 e por um período de tempo subsequente foi enviado antes de T 0, e os dados históricos anteriores a T 0 podem ser rastreados, os usuários podem construir a Prova Merkle para forçar a retirada.

Mesmo que muitas pessoas não consigam detectar a anormalidade imediatamente, porque há um período de janela (OP é de 7 dias), desde que o Stateroot enviado no horário T 0 não tenha sido legalizado e os dados DA antes de T 0 sejam rastreáveis, os usuários podem retire seu dinheiro com segurança de L2.

Resumir

Até agora podemos entender aproximadamente a diferença entre Validium e Plasma em termos de segurança:

Depois que o sequenciador do Validium libera o Stateroot, desde que libere imediatamente o Validity Proof e DAC multi-signature, ele pode torná-lo legal e se tornar o Stateroot legal mais recente; se usuários e nós L2 honestos encontrarem ataques de retenção de dados, eles não poderão construir o Merkle correspondente a o Stateroot legal atual. Prova, você não pode sacar dinheiro para L1.

No entanto, após o Plasma enviar um novo Stateroot, ele não pode ser legal até o final do período de janela. Neste momento, o Stateroot legal foi enviado no passado. Como há um período de janela (ARB é de 3 dias, OP é de 7 dias), mesmo que os dados DA do Stateroot recém-enviado não estejam disponíveis, o usuário ainda possui os dados DA do Stateroot legal atual (a raiz legal foi enviada no passado), e há tempo suficiente para forçar a Retirada para L1.

Então, o que Dankrad disse faz sentido. Quando ocorre um ataque de retenção de dados, o Validium pode prender os ativos do usuário em L2, mas o Plasma não tem esse problema.

(O que Dankrad disse na figura abaixo está um pouco errado. O plasma não deve permitir a construção de um Stateroot legal desatualizado correspondente à prova de Merkle para sacar dinheiro, porque isso levará a um pagamento duplo)

Portanto, ataques de retenção de dados na camada DA fora da cadeia podem causar muitos riscos de segurança, mas é exatamente esse problema que a Celestia está tentando resolver. Além disso, como a maioria dos projetos da Camada 2 fornece portas de serviço que mantêm os nós L2 e os sequenciadores off-chain em sincronia, as preocupações de Dankrad geralmente são teóricas e não reais.

Se usarmos uma atitude minuciosa e apresentarmos uma suposição mais extrema: todos os nós fora da cadeia do Plasma estão indisponíveis, então os usuários comuns que não passaram pelos nós L2 não podem forçar retiradas para L1. Mas a probabilidade de tal coisa acontecer é equivalente à probabilidade de que todos os nós de uma cadeia pública sejam coletivamente desativados permanentemente, e isso pode nunca acontecer.

Então, muitas vezes, as pessoas estão apenas falando sobre coisas que nunca aconteceram. Assim como a frase de ouro que o vice-presidente da Rick Gerb disse ao protagonista do drama americano "Chernobyl": "Por que se preocupar com coisas que nunca vão acontecer?"