Recentemente, um projeto chamado Redstone tornou-se um tema quente. Esta instalação especial de Camada 2 para jogos de cadeia lançada pela equipa Lattice foi lançada oficialmente a 15 de novembro e agora está online na rede de teste. Curiosamente, a equipa do Lattice afirmou “Redstone é uma cadeia Alt-DA inspirada no Plasma”.

Um dia antes do lançamento do Redstone, Vitalik acaba de publicar o artigo “Jogos de saída para os validiums EVM: o retorno do Plasma”. O artigo reviu 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 poderia ter investido no Redstone. Juntamente com a acalorada “disputa de definição de Ethereum Layer 2" neste prequel, as pessoas geralmente acreditavam que isso desencadearia um “renascimento do Plasma” no futuro, e as soluções da fora do ecossistema Ethereum, como o Celestia, podem ser suprimidas como resultado. Porque o Plasma não tem requisitos rígidos para a DA. No entanto, de acordo com a pesquisa do autor deste artigo, o Redstone não está em conformidade com o quadro geral do Solução de plasma. A sua alegação de ser “inspirado pelo Plasma” pode realmente seguir os tópicos quentes do artigo do Vitalik. Não é que o Vitalik queira realmente defender Redstone. Além disso, o plano de desafio da DA da 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. Então, a situação real é que toda a gente pode ter “interpretado exageradamente” o Redstone. O seguinte explicará aos leitores através de alguns raciocínios simplesO princípio do Plasma e porque é que não é amigável com contratos inteligentes e Defi, e o que exatamente é Redstone.

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

A história do Plasma remonta ao boom da ICO da Ethereum em 2017. Naquela altura, a procura de transações dos utilizadores do Ethereum explodiu e a ETH, que tinha TPS baixo, estava 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 só publica o cabeçalho de bloco/Merkle Root of Layer2 para Layer1. A parte dos dados (dados DA) que não o cabeçalho do bloco/Raiz de Merkle só é publicada fora da cadeia.Se a raiz Merkle emitida pelo classificador/operador do Plasma em L1 estiver associada a uma transação inválida (erro de assinatura digital, etc.), o utilizador relevante pode apresentar 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 tem requisitos rigorosos na camada DA e não pode garantir que os utilizadores ou nós L2 possam receber dados. Se o sequenciador for lançado num determinado momento dos ataques de retenção de dados (também conhecidos como problemas de disponibilidade de dados) apenas publique novos cabeçalhos de bloco/raízes Merkle mas não publique os corpos de bloco correspondentes. Sem a capacidade de verificar se o cabeçalho/raiz do bloco é válido, os utilizadores só podem usar o sequenciador “sem esperança” e retirar ativos da Camada 2 para a Camada 1 através de um mecanismo de saída de emergência chamado “Sair do Jogo”.

Esta etapa exige que o utilizador apresente o Merkle Proof para provar que realmente tem uma quantidade correspondente de ativos em L2. Podemos chamar isso de “Prova de ativos”. O interessante é que o Exit Game do Plasma e o modo escape hatch do ZK Rollup são diferentes. Os utilizadores do ZK Rollup devem apresentar a Prova Merkle correspondente à Stateroot válida mais recente, enquanto os utilizadores do Plasma podem submeter a Prova correspondente à Raiz Merkle há muito tempo. Porque é que foi concebido assim? Só porque o Stateroot apresentado pela ZK Rollup será imediatamente julgado pelo contrato na Camada1 (para determinar se o certificado de validade é válido). Se o Stateroot recentemente apresentado for válido e legal, o utilizador deve apresentar a Prova Merkle correspondente ao Stateroot legal para servir como um certificado de ativo. No entanto, o contrato Layer1 não pode determinar se a Raiz Merkle submetida pelo sequenciador do Plasma é válida. Só pode permitir que o nó L2 inicie ativamente um desafio para eliminar Raízes inválidas, então haverá um mecanismo de desafio.Isso faz com que o Plasma e o Zk Rollup funcionem de forma muito diferente.Suponha que o sequenciador acaba de emitir um Merkle Root 101 inválido e lançou um 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 utilizador pode enviar uma prova merkle correspondente à raiz nº 100 ou raiz anterior. Retirar os seus próprios bens.

Claro, há um problema que precisa ser resolvido aqui, ou seja, um utilizador pode apresentar um certificado de activo correspondente à raiz nº 30 ou anterior e solicitar a retirada de ativos para a Camada 1. No entanto, o estado dos ativos desta pessoa pode mudar depois de a raiz nº 30 ser liberada. por outras palavras, o que ele apresentou foi uma prova desatualizada de ativos, que é um típico ataque de gastos dupla/gastos duplos.

A este respeito, o Plasma permite que qualquer pessoa apresente uma prova de fraude na situação acima, salientando que a “prova de ativos” apresentada por um utilizador que iniciou uma declaração de levantamento está desatualizada. Ao introduzir este “qualquer um pode contestar o pedido de levantamento de outra pessoa”, o Plasma não precisa de lidar com pedidos de levantamento de emergência como o ZK Rollup.Mas ainda existe a possibilidade, ou seja, o sequenciador primeiro transfere os ativos de outras pessoas para a sua própria conta L2 e, em seguida, lança um ataque de retenção de dados para que estranhos não possam desafiar o seu comportamento de trapaça. Posteriormente, o sequenciador iniciou uma retirada de emergência da sua própria conta e apresentou uma “prova de ativos” alegando que realmente possuía esses ativos em L2. Obviamente, neste momento, porque falta um registo histórico, as pessoas não podem provar diretamente que há um problema com a origem dos ativos do classificador. Então, o que 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 realizar o comportamento de trapaça acima mencionado e iniciar uma retirada ao enviar a raiz nº 101, o utilizador poderá enviar um certificado de ativo correspondente à raiz nº 99 ou anterior para fazer uma retirada de emergência. Obviamente, desde que o classificador não possa adulterar os registos históricos que foram publicados na Camada1, o utilizador terá uma maneira de escapar. Mas o Plasma ainda tem um bug fatal: Enquanto o sequenciador iniciar a retenção de dados, as pessoas têm de confiar em retiradas de emergência (também conhecido como Jogo de Saída) para garantir a segurança dos ativos. Se um grande número de utilizadores retirar dinheiro coletivamente num curto período de tempo, a Camada1 será facilmente incapaz de lidar com isso; O que é mais sério é, quem deve retirar os ativos registados no contrato Defi para a Camada 1? Suponha que alguém coloque 100 ETH no pool LP do DEX, e então o sequenciador do Plasma falha ou faz algo mau, e as pessoas precisam retirar fundos com urgência. Neste momento, os 100 ETH do utilizador ainda são controlados pelo contrato DEX. Neste momento, quais devem ser esses ativos? Quem mencionou a Camada 1? A melhor maneira é permitir que os utilizadores resgatem primeiro os seus ativos do pool DEX e depois deixar que os próprios utilizadores transfiram o dinheiro para o L1. No entanto, o problema é que o sequenciador do Plasma não funcionou/fez mal e os utilizadores não podem resgatar ativos. operação. Mas se permitirmos que o proprietário do contrato DEX levante os ativos controlados pelo contrato para L1, obviamente dará ao proprietário do contrato a propriedade do ativo. Ele pode elevar esses ativos para L1 e fugir a qualquer momento. Isso não seria terrível? Então, no final, 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 isso irá introduzir problemas consideráveis e aumentar os custos de oportunidade. Quem vai votar para decidir como alienar o contrato do espelho? Vai ser um grande problema. Isto envolve realmente o problema da distribuição do poder público. Os ladrões tinham dito anteriormente numa entrevista“É difícil criar coisas novas em cadeias públicas de alto desempenho, contratos inteligentes envolvem distribuição de energia”Isto foi mencionado no artigo.

Claro, Vitalik também apontou isso no seu recente artigo “Exit games for EVM validums: the return of Plasma”, e enfatizou que este é um dos fatores que torna o Plasma não amigável a contratos inteligentes.Variantes conhecidas do Plasma no passado, como Plasma MVP e Plasma Cash, usaram UTXO ou modelos semelhantes para substituir o modelo de endereço de conta da Ethereum e não suportavam contratos inteligentes, o que pode evitar Problema de “distribuição de propriedade de ativos” mencionado acima. Embora a propriedade de cada UTXO pertença ao próprio utilizador, o próprio UTXO também tem 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 encomendas. depois disso, com a popularidade do ZK Rollup, o próprio Plasma também se retirou da fase 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 apenas enviar Stateroot mas nenhum dado DA para a cadeia ETH, essa raiz será julgada inválida e diretamente rejeitada pelo contrato do Verificador em L1. Portanto, os dados da correspondentes à base legal do ZK Rollup devem estar disponíveis na cadeia ETH. É isso issoNão existe “apenas publicar o cabeçalho do bloco ou a raiz do 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 anteriores da AD do Rollup podem ser verificados no Ethereum, e qualquer pessoa pode iniciar os nós da Camada 2 através dos registos históricos na cadeia ETH, o que reduzirá muito a dificuldade da sequência descentralizada e até sem permissão soluções. Em contraste, o Plasma não tem 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 a 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, pode travar as atualizações da Stateroot, o que equivale a um encerramento no nível de UX, ou negar os pedidos de certos utilizadores, vulgarmente conhecidos como revisão de transações. 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 desencadear o modo de jogo Sair no Plasma para 0 (chamado de escape hatch no ZK Rollup).

(A coluna Proposer Failure no L2BEAT mostra como cada solução L2 responde à falha do sequenciador. A auto-proposta refere-se frequentemente a outros nós que podem substituir o sequenciador atualmente inactivo)

Hoje, quase nenhuma equipa no ecossistema Ethereum continua a aderir à rota do Plasma e quase todos os projetos do Plasma nasceram mortos.

(Vitalik explica porque é que 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 por que foi substituído pelo Rollup. Quanto ao Redstone, também deve ter visto a diferença entre ele e o Plasma:O Redstone pode resolver o problema dos ataques de retenção de dados, por exemplo, não vai libertar uma nova base imediatamente. Em vez disso, primeiro divulgará os dados originais da sob a cadeia ETH e, em seguida, usará o datahash dos dados DA como um compromisso de credencial associado e publicá-lo-á na cadeia ETH, dizendo que lançou isso sob a cadeia. Os dados completos correspondentes ao segmento datahash.

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

Qualquer pessoa pode iniciar um desafio, dizendo que o classificador do Redstone não publicou os dados originais correspondentes a este datahash off-chain. neste momento, o sequenciador precisa publicar os dados correspondentes ao datahash na cadeia para enfrentar os desafios dos duvidores.Se o sequenciador não publicar dados na cadeia ETH a tempo depois de ser contestado, o datahash/compromisso publicado anteriormente será considerado inválido. Se o classificador responder ao pedido do desafiante a tempo, o desafiante pode obter os dados originais da 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. Claro, o próprio desafiante precisa pagar uma taxa primeiro, que é aproximadamente igual ao custo do sequenciador ETH que publica os dados da originais no cadeia. Esta medida é para evitar que desafiadores mal-intencionados desafiem o sequenciador sem nenhum custo, fazendo com que este último sofra perdas. finalmente, quando o período de desafio para o datahash terminar, o classificador libertará o stateroot 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 libertar os dados da originais correspondentes a tempo após um datahash anterior ser contestado, mesmo que o classificador libere posteriormente o stateroot correspondente a este datahash, será inválido por defeito. Porque a Redstone libera primeiro os dados da e depois liberta o Stateroot efetivo correspondente, resolvendo diretamente o problema dos ataques de retenção de dados. (O o classificar só publica dados raiz e não da). Obviamente, este modo é diferente do Optimium (OP Rollup comum que não usa Ethereum para implementar DA, como o Arbitrum Nova) .O Optimium geralmente depende do comité DAC fora da cadeia para garantir a disponibilidade dos dados.O DAC submete um txn multi-assinado à cadeia em intervalos regulares. Depois que o contrato Rollup na Camada 1 receber o txn com vários assinaturas, o sequenciador deixará de publicar o último lote de dados DA fora da cadeia.

(Fonte: L2beat)

Por exemplo, o Metis e o Arbitrum Nova enviam Stateroot e datahash ao mesmo tempo. Se alguém pensar que o classificador ocultou os 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 o Redstone e o Metis está nesta passa:O primeiro lança o datahash primeiro e depois libera o stateroot após o término do período de desafio da; o 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 do Redstone é mais segura, porque sob a solução da Metis, se o classificador nunca responder ao pedido de dados DA do desafiante, o problema de retenção de dados não pode ser resolvido rapidamente. Só podemos confiar em retiradas de emergência e consenso social, ou deixar outros nós assumirem o classificador atual. ;

Mas em Redstone, se o classificador se envolver na retenção de dados, a base emitida por ele será diretamente considerada inválida, então os dados da base e da estão limitados. Isso permite que o Redstone obtenha uma garantia DA mais próxima da do Rollup, que é essencialmente uma variante do Optimium que é superior ao Arbitrum Nova e Metis.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de [web3]. Todos os direitos de autor pertencem ao autor original [Faust]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.