Recentemente,Um projeto chamado Redstone se tornou um tema quente.Este recurso especial da Camada 2 para jogos em cadeia lançado pela equipe Lattice foi lançado oficialmente em 15 de novembro e agora está online na rede de teste. Curiosamente, a equipe Lattice declarou “Redstone é uma cadeia Alt-DA inspirada no Plasma”。

Um dia antes do lançamento de Redstone, Vitalik acaba de publicar o artigo “Exit games for EVM validiums: the return of Plasma”. O artigo revisou brevemente a solução técnica “Plasma” que desapareceu do ecossistema Ethereum. E apontou que a prova de validade (confundida com ZK Proof) pode ser introduzida para resolver o problema do Plasma. A este respeito, muitos amigos acreditam que Vitalik publicou este artigo para apoiar Redstone. Algumas pessoas até disseram na comunidade geek Web3 que Vitalik pode ter investido em Redstone. Juntamente com a acalorada “disputa de definição da camada 2 do Ethereum” nesta prequela, as pessoas geralmente acreditavam que isso desencadearia um “renascimento do Plasma” no futuro, e soluções DA fora do ecossistema Ethereum, como Celestia, podem ser suprimidas como resultado. O Plasma não possui requisitos rígidos para DA. Porém, de acordo com a pesquisa do autor deste artigo, Redstone não está em conformidade com a estrutura geral da solução Plasma. Sua afirmação de ser “inspirado no Plasma” pode, na verdade, seguir os tópicos quentes do artigo de Vitalik. Não é que Vitalik realmente queira defender Redstone. Além disso, o plano de desafio DA de Redstone é bastante semelhante ao plano lançado pelo projeto Metis da Camada 2 em abril de 2022, exceto que a ordem das duas etapas de atualização do Stateroot e publicação de dados DA é diferente. Portanto, a situação real é que todos podem ter “interpretado exageradamente” Redstone. A seguir, explicarei aos leitores, por meio de um raciocínio simples, o princípio do Plasma e por que ele não é amigável para contratos inteligentes e Defi, e o que exatamente é Redstone.

Plasma: Retiradas urgentes são necessárias no caso de um ataque de retenção de dados

A história do Plasma remonta ao boom do Ethereum ICO em 2017. Naquela época, a demanda de transações dos usuários do Ethereum explodiu e a ETH, que tinha TPS baixo, ficou sobrecarregada. Nesta conjuntura, foi lançada a primeira versão teórica do Plasma, que propunha um plano de expansão de segunda camada que pode lidar com “quase todos os cenários financeiros do mundo”. Simplificando, o Plasma é uma solução de expansão que publica apenas o cabeçalho do bloco/Raiz Merkle da Camada2 para a Camada1. A parte dos dados (dados DA) que não seja o cabeçalho do bloco/Merkle Root é publicada apenas fora da cadeia. Se a Merkle Root emitida pelo classificador/operador do Plasma em L1 estiver associada a uma transação inválida (erro de assinatura digital, etc.) , o usuário relevante pode enviar um certificado de fraude para provar que a raiz enviada pelo classificador está associada a uma transação inválida. Mas o problema é que para emitir um certificado de fraude é necessário garantir que os dados DA não sejam retidos, mas o Plasma não possui requisitos rígidos na camada DA e não pode garantir que os usuários ou nós L2 possam receber dados. Se o sequenciador for iniciado em um determinado momento, os ataques de retenção de dados (também conhecidos como problemas de disponibilidade de dados) publicam apenas novos cabeçalhos de bloco/raízes Merkle, mas não publicam os corpos de bloco correspondentes. válido, os usuários só podem usar o sequenciador “sem esperança” como padrão e retirar ativos da Camada 2 para a Camada 1 por meio de um mecanismo de saída de emergência chamado “Jogo de Saída”.

Esta etapa exige que o usuário envie a Prova Merkle para provar que realmente possui uma quantidade correspondente de ativos em L2. Podemos chamar isso de “Prova de ativos”. O que é interessante é que o modo Exit Game do Plasma e o modo escape hatch do ZK Rollup são diferentes. Os usuários do ZK Rollup devem enviar a Prova Merkle correspondente ao Stateroot válido mais recente, enquanto os usuários do Plasma podem enviar a Prova correspondente à Raiz Merkle há muito tempo. Por que foi projetado assim? Só porque o Stateroot enviado pelo ZK Rollup será imediatamente julgado pelo contrato na Camada 1 (para determinar se o certificado de validade é válido). Se o Stateroot recém-enviado for válido e legal, o usuário deverá enviar a Prova Merkle correspondente ao Stateroot legal para servir como certificado de ativo. No entanto, o contrato Layer1 não pode determinar se o Merkle Root enviado pelo sequenciador do Plasma é válido. Ele só pode permitir que o nó L2 inicie ativamente um desafio para eliminar raízes inválidas, portanto, haverá um mecanismo de desafio. Isso faz com que o Plasma e o Zk Rollup operem de maneira muito diferente. ataque de retenção de dados para que o nó L2 não possa provar que a raiz nº 101 é inválida. Neste momento, o usuário pode enviar uma Prova Merkle correspondente à raiz nº 100 ou raiz anterior. Retire seus próprios ativos.

Claro, há um problema que precisa ser resolvido aqui, ou seja, um usuário pode enviar um certificado de ativo correspondente à raiz nº 30 ou anterior e solicitar a retirada de ativos para a Camada 1. No entanto, o status patrimonial dessa pessoa pode mudar após a liberação da raiz nº 30. por outras palavras, o que ele apresentou foi uma prova de activos desatualizada, o que é um típico ataque de gasto duplo/gasto duplo.

Neste sentido, o Plasma permite que qualquer pessoa apresente um comprovativo de fraude na situação acima referida, salientando que o “comprovativo de bens” apresentado por um utilizador que iniciou uma declaração de levantamento está desatualizado. Ao introduzir esta “qualquer pessoa pode contestar a reivindicação de retirada de outra pessoa”, o Plasma não precisa lidar com solicitações de retirada de emergência como ZK Rollup.Mas ainda existe uma possibilidade,Ou seja, o sequenciador primeiro transfere os ativos de outras pessoas para sua própria conta L2, e em seguida, lança um ataque de retenção de dados para que estranhos não possam desafiar seu comportamento fraudulento. Posteriormente, o sequenciador iniciou um saque emergencial de sua própria conta e apresentou uma “prova de ativos” alegando que de fato possuía esses ativos em L2. Obviamente, neste momento, porque falta um registo histórico, as pessoas não podem provar directamente que existe um problema com a origem dos activos do classificador. Então, o que você deve fazer nesta situação? As primeiras versões do Plasma, como o Plasma MVP, levaram isso em consideração e propuseram “Prioridade de Retirada”. Se o certificado de activo apresentado por uma pessoa corresponder a uma raiz anterior, o seu pedido de levantamento será processado primeiro.

Se o sequenciador executar o comportamento de trapaça mencionado acima e iniciar uma retirada ao enviar a raiz nº 101, o usuário poderá enviar um certificado de ativo correspondente à raiz nº 99 ou anterior para fazer uma retirada emergencial. Obviamente, desde que o classificador não possa alterar os registros históricos que foram publicados na Camada 1, o usuário terá uma maneira de escapar. Mas o Plasma ainda tem um bug fatal: contanto que o sequenciador inicie a retenção de dados, as pessoas terão que confiar em saques emergenciais (também conhecidos como Exit Game) para garantir a segurança dos ativos. Se um grande número de usuários retirar dinheiro coletivamente em um curto período de tempo, a Camada 1 será facilmente incapaz de lidar com isso;O que é mais sério é: quem deve retirar os ativos registrados no contrato Defi para a Camada 1?Suponha que alguém cobre 100 ETH em o pool de LP do DEX, e então o sequenciador do Plasma falha ou faz algo mal, e as pessoas precisam sacar fundos com urgência. Neste momento, os 100 ETH do usuário ainda são controlados pelo contrato DEX. Neste momento, quais deveriam ser esses ativos? Quem mencionou a Camada1? A melhor maneira é permitir que os usuários resgatem seus ativos do pool DEX primeiro e, em seguida, permitir que os próprios usuários transfiram o dinheiro para L1. No entanto, o problema é que o sequenciador Plasma não funcionou bem/fez o mal e os usuários não podem resgatar ativos. Operação. Mas se permitirmos que o proprietário do contrato DEX eleve os ativos controlados pelo contrato para L1, isso obviamente dará ao proprietário do contrato a propriedade dos ativos. Ele pode levar esses ativos para L1 e fugir a qualquer momento. Isso não seria terrível? Então, no final das contas, como lidar com essas “propriedades públicas” controladas por contratos Defi é uma grande surpresa. Se seguirmos o consenso social, parece possível reconstruir um contrato espelho na Camada 1 que mapeia o contrato DeFi na Camada 2, mas isto introduzirá problemas consideráveis e aumentará os custos de oportunidade. Quem votará para decidir como se desfazer do contrato espelho? Será um grande problema. Na verdade, isso envolve o problema da distribuição do poder público. Os ladrões já haviam dito em entrevista“É difícil criar coisas novas em cadeias públicas de alto desempenho, contratos inteligentes envolvem distribuição de energia”.Isso foi mencionado no artigo.

Claro, Vitalik também apontou isso em seu recente artigo “Jogos de saída para validiums EVM: o retorno do Plasma”,E enfatizou que este é um dos fatores que torna o Plasma hostil aos contratos inteligentes.Variantes de Plasma bem conhecidas no passado , como Plasma MVP e Plasma Cash, usaram UTXO ou modelos semelhantes para substituir o modelo de endereço de conta do Ethereum e não ofereceram suporte a contratos inteligentes, o que pode evitar o problema de “distribuição de propriedade de ativos” mencionado acima. Embora a propriedade de cada UTXO pertença ao próprio usuário, o próprio UTXO também apresenta muitas falhas e não é amigável para contratos inteligentes. Portanto, a solução Plasma é mais adequada para pagamentos simples ou trocas de livros de pedidos. depois disso, com a popularidade do ZK Rollup, o próprio Plasma também saiu do palco da história. Porque o Rollup não tem o problema de retenção de dados do Plasma. Se o sequenciador do ZK Rollup lançar um ataque de retenção de dados e enviar apenas Stateroot, mas nenhum dado DA, para a cadeia ETH, tal raiz será julgada como inválida e diretamente rejeitada pelo contrato do Verificador em L1. Portanto, os dados DA correspondentes ao Stateroot legal do ZK Rollup devem estar disponíveis na cadeia ETH. É isso aíNão existe “apenas publicar o cabeçalho do bloco ou raiz merkle, mas não o corpo do bloco correspondente”, o que significa que pode resolver o problema de disponibilidade de dados/ataque de retenção de dados.Ao mesmo tempo, os dados DA anteriores do Rollup podem ser verificados em Ethereum, e qualquer pessoa pode iniciar nós da Camada 2 por meio dos registros históricos da cadeia ETH, o que reduzirá bastante a dificuldade de soluções sequenciadoras descentralizadas e até mesmo sem permissão. Em contraste, o Plasma não possui requisitos rígidos para DA e é mais difícil implementar um classificador descentralizado (para implementar um classificador descentralizado substituível, devemos primeiro garantir que todos os nós L2 reconheçam o mesmo bloco, o que apresenta requisitos para implementação de DA .). Além disso, se o sequenciador do ZK Rollup tentar incluir transações inválidas em blocos da Camada 2, não terá sucesso. Isto é garantido pelo princípio da prova de validade. Em última análise, o espaço maligno do classificador ZK Rollup é muito menor do que o do Plasma —— No máximo, ele pode paralisar as atualizações do Stateroot, o que equivale a um desligamento no nível UX, ou negar solicitações de determinados usuários, comumente conhecidas como revisão de transação. ao mesmo tempo, se o classificador falhar no esquema de rollup, será mais fácil para outros nós substituí-lo. Um Rollup ideal pode reduzir a probabilidade de acionar o modo de jogo Exit no Plasma para 0 (chamado de saída de emergência no ZK Rollup ).

(A coluna Falha do Proponente em L2BEAT mostra como cada solução L2 responde à falha do sequenciador. Self Propose geralmente se refere a outros nós que podem substituir o sequenciador atualmente inativo)

Hoje, quase nenhuma equipe no ecossistema Ethereum ainda adere à rota do Plasma, e quase todos os projetos do Plasma nasceram mortos.

(Vitalik explica porque o ZK Rollup é superior ao Plasma, mencionando a operação do sequenciador sem permissão e problemas de DA)

O que é Redstone: Não é Plasma, mas uma variante do Optimium

Acima, explicamos brevemente o Plasma e os breves fatores pelos quais ele foi substituído pelo Rollup. Quanto ao Redstone, você também deve ter visto a diferença entre ele e o Plasma: Redstone pode resolver o problema de ataques de retenção de dados, por exemplo, não lançará um novo stateroot imediatamente. Em vez disso, ele primeiro liberará os dados DA originais na cadeia ETH e, em seguida, usará o datahash dos dados DA como um compromisso de credencial associado e os publicará na cadeia ETH, dizendo que os liberou na cadeia. Os dados completos correspondentes ao datahash do segmento.

(Explicação oficial da Redstone sobre seu plano para evitar ataques de retenção de dados)

Qualquer um pode iniciar um desafio, dizendo que o classificador de Redstone não publicou os dados originais correspondentes a este datahash fora da cadeia. neste momento, o sequenciador precisa publicar os dados correspondentes ao datahash na cadeia para enfrentar os desafios dos duvidosos. Se o sequenciador não publicar dados na cadeia ETH a tempo após ser desafiado, o datahash/compromisso publicado anteriormente será ser considerado inválido. Se o classificador responder à solicitação do desafiante a tempo, o desafiante poderá obter os dados DA originais correspondentes ao datahash a tempo.No final, todos os nós L2 podem basicamente obter os dados DA necessários para resolver o problema de ataques de retenção de dados.Of É claro que o próprio desafiante precisa primeiro pagar uma taxa, que é aproximadamente igual ao custo do sequenciador que publica os dados DA originais na cadeia ETH. Esta medida visa evitar que desafiantes maliciosos desafiem o sequenciador sem nenhum custo, fazendo com que este sofra perdas. . por fim, quando o período de desafio do datahash terminar, o classificador liberará a raiz de estado correspondente, ou seja, a raiz obtida após a execução da sequência de transação contida nos dados DA correspondentes ao datahash. Neste ponto, os nós L2 podem usar o sistema à prova de fraude para desafiar essas raízes inválidas. Se o classificador não liberar os dados DA originais correspondentes a tempo após um datahash anterior ser desafiado, mesmo que o classificador libere posteriormente a raiz de estado correspondente a esse datahash, ele será inválido por padrão. PorqueRedstone libera os dados do DA primeiro e, em seguida, libera o Stateroot efetivo correspondente, resolvendo diretamente o problema de ataques de retenção de dados.(O classificador publica apenas dados raiz e não dados DA). Obviamente, este modo é diferente do Optimium comum (OP Rollup que não usa Ethereum para implementar DA, como Arbitrum Nova).O Optimium geralmente depende do comitê DAC fora da cadeia para garantir a disponibilidade dos dados.DAC envia um txn multiassinado ao cadeia em intervalos regulares. Depois que o contrato Rollup na Camada1 receber o txn multiassinado, o padrão será o sequenciador publicando o lote mais recente de dados DA fora da cadeia.

(Fonte: L2beat)

Por exemplo, Metis e Arbitrum Nova enviam Stateroot e datahash ao mesmo tempo. Se alguém pensar que o classificador reteve dados DA, tentará contestá-lo e o classificador enviará os dados DA correspondentes ao datahash para a cadeia. então,A principal diferença entre Redstone e Metis está nesta etapa: O primeiro libera o datahash primeiro e, em seguida, libera o stateroot após o término do período de desafio do DA; Metis lança stateroot e datahash ao mesmo tempo. Se alguém iniciar um desafio, os dados DA são carregados na cadeia.Obviamente, a solução de Redstone é mais segura, porque na solução de Metis, se o classificador nunca responder à solicitação de dados DA do desafiante, o problema do ataque de retenção de dados não poderá ser resolvido rapidamente. Só podemos contar com retiradas de emergência e consenso social, ou deixar que outros nós assumam o controle do classificador atual. ;

Mas em Redstone, se o classificador reter dados, a raiz de estado emitida por ele será diretamente considerada inválida, de modo que a raiz de estado e os dados DA serão vinculados. Isso permite que Redstone obtenha uma garantia de DA mais próxima daquela do Rollup, que é essencialmente um variante do Optimium que é superior ao Arbitrum Nova e Metis.

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [极客web3]. Todos os direitos autorais pertencem ao autor original [Fausto]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.