Não conta como um Rollup se você não usar o Ethereum como uma camada DA? Compreendendo a Camada 2 da perspectiva do proponente do Danksharding

Autor: Faust, 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, ApeX e Metis podem ser "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 contado como 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 do Layer2 para entender porque o Validium não é estritamente "Layer2".

Como definir Layer2?

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 os blocos L2 da rede principal não serão revertidos sem uma reversão de bloco semelhante a um ataque de 51%.

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. Assumindo que o sequenciador de L2 lança um ataque de censura, rejeita deliberadamente a solicitação de transação/retirada do usuário ou simplesmente desliga 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 precisa ser "incluído obrigatoriamente", e a transação será incluída diretamente na sequência de transações do ledger Rollup, que cria um "saque obrigatório" para usuários L2. saída".

Em contraste, o esquema StarkEx com o mecanismo Escape Hetch da cápsula de escape é ainda pior. Se o usuário L2 não receber 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 de solicitação de congelamento para permitir que L2 entre no período de congelamento. Neste momento, o sequenciador L2 não será capaz de atualizar o estado L2 no L1 e levará 1 ano após o estado L2 ser congelado para ser descongelado.

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 retirar fundos por meio do pod de escape.

Até agora, a razão pela qual Dankrad mencionou no início do artigo acredita 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.

No entanto, o stateroot sozinho não pode restaurar a árvore de estado do mundo no momento, e é impossível 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.

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 Data Availability Committee (DAC). E os membros da comunidade ou outras unidades são responsáveis pela operação e supervisão (mas isso é apenas na superfície, na verdade, é difícil para o mundo exterior verificar quem são os membros do DAC).

O interessante é que os membros do DAC da Validium precisam enviar com frequência em L1 Multi-signature, o que prova que o novo Stateroot e Validity Proof enviados pelo sequenciador L2 em L1 podem ser combinados com os 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 assinatura múltipla 5/7. Embora dYdX seja ZKRollup, ele também possui DAC, que usa assinatura múltipla 1/2. (dYdX publica apenas State diffs em L1, ou seja, mudanças de estado, em vez de dados completos da transação. No entanto, após obter os State diffs nos registros históricos, o saldo patrimonial de todos os endereços L2 pode ser restaurado. Neste momento, 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 atuais não estão mais 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, os usuários podem escapar do L2.

Mas o problema que teoricamente existe no Validium, 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 enviados há alguns dias (é como a luz das estrelas que vemos, que na verdade foi emitida há muito tempo), e os usuários geralmente podem obter dados DA em momentos anteriores.

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 pode 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 é muito simples: a premissa do Plasma funcionar normalmente é que os dados DA do L2 estejam disponíveis neste 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 começar a partir de um certo ponto de tempo T0, 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 obtenham dados após T0 ). Como o Stateroot legal em T0 e por um período de tempo subsequente foi enviado antes de T0, e os dados históricos antes de T0 podem ser rastreados, os usuários podem construir a Prova Merkle para forçar a retirada.

Embora 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 em T0 não tenha sido legalizado e os dados DA antes de T0 possam ser rastreados, os usuários podem retirar com segurança dinheiro 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 mais recente Stateroot legal; 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 Stateroot DA recém-enviados não estejam disponíveis, o usuário ainda possui os dados Stateroot DA legais atuais (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.

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

Se usarmos uma atitude minuciosa e apresentarmos uma hipótese 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 poderão 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?"