Recentemente, um projeto chamado Redstone tornou-se um tópico quente. **Esta instalação Layer2 lançada pela equipe Lattice foi lançada oficialmente em 15 de novembro e agora foi lançada na testnet. Curiosamente, a equipe da Lattice afirma que "Redstone é uma cadeia Alt-DA inspirada no plasma".
Apenas um dia antes do lançamento de Redstone, Vitalik publicou o artigo "Exit games for EVM validiums: the return of Plasma", no qual ele revisou brevemente a solução técnica "Plasma" que havia desaparecido do ecossistema Ethereum, e apontou que provas de validade (confundidas com ZK Proof) poderiam ser introduzidas para resolver o problema do Plasma.
A este respeito, muitos amigos acreditam que Vitalik publicou este artigo a fim de dar Redstone uma plataforma, e mesmo na comunidade geek Web3, algumas pessoas dizem que Vitalik não investiu em Redstone. Juntamente com a fervura "Ethereum Layer 2 definition dispute" no rumor anterior, acreditava-se amplamente que o próximo "Plasma revival" seria acionado, e soluções DA fora do ecossistema Ethereum como Celestia podem ser suprimidas, porque o Plasma não tem requisitos estritos para DA. **
No entanto, de acordo com a pesquisa do autor deste artigo, Redstone não se encaixa no quadro geral da solução de Plasma, e sua alegação de ser "inspirado pelo Plasma" tem a possibilidade de esfregar o calor do artigo de Vitalik, em vez de que Vitalik realmente quer representar Redstone. Além disso, o desafio DA da Redstone é semelhante ao projeto Metis de camada 2 lançado em abril de 2022, exceto que a ordem de atualização do Stateroot e publicação dos dados DA é diferente.
Então, a situação real é que você pode ter "super-interpretado" Redstone. O seguinte é um raciocínio simples para explicar como o Plasma funciona, por que não é amigável para contratos inteligentes e Defi, e o que exatamente Redstone é. **
Plasma: Retirada urgente em caso de ataque de retenção de dados
A história do plasma pode ser rastreada até o boom do Ethereum IC0 em 2017, quando a demanda de transações dos usuários do Ethereum explodiu e o ETH com TPS baixo foi sobrecarregado. Nesta conjuntura, foi lançada a primeira versão teórica do Plasma, que propunha um esquema de escalonamento de camada 2 que poderia lidar com "quase todos os cenários financeiros do mundo".
Para simplificar, o Plasma é uma solução de dimensionamento que publica apenas o cabeçalho de bloco da Camada 2/raiz Merkle na Camada 1, e a parte dos dados fora do cabeçalho do bloco/raiz Merkle (dados DA) só é publicada fora da cadeia. **Se a Raiz Merkle publicada pelo sequenciador/Operador de Plasma em L1 estiver associada a uma transação inválida (por exemplo, um erro de assinatura digital), o usuário pode enviar um certificado de fraude para provar que a Raiz enviada pelo sequenciador está associada a uma transação inválida.
O problema é que, para emitir provas de fraude, é necessário garantir que os dados DA não sejam retidos, mas o Plasma não tem requisitos rigorosos para a camada DA e não pode garantir que os usuários ou nós L2 possam receber dados. Se o sequenciador iniciar um ataque de retenção de dados (também conhecido como um problema de disponibilidade de dados) em um determinado momento, e publicar apenas um novo cabeçalho de bloco/raiz Merkle, mas não publicar o corpo do bloco correspondente, tornando impossível verificar se o cabeçalho/raiz do bloco é válido, o usuário só pode padronizar o sequenciador como "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 "Exit Game".
Esta etapa exige que o usuário envie uma Prova Merkle para provar que tem uma quantidade correspondente de ativos em L2, que podemos chamar de "Prova de Ativos". Curiosamente, o Jogo de Saída do Plasma não é o mesmo que o modo Escape Pod do ZK Rollup, onde os usuários do ZK Rollup devem enviar uma Prova Merkle correspondente à Stateroot válida mais recente, enquanto os usuários do Plasma podem enviar uma Prova correspondente a uma Raiz Merkle de muito tempo atrás.
Porque é que foi concebido desta forma? É apenas que o Stateroot enviado pelo ZK Rollup será imediatamente julgado pelo contrato na Camada 1 (para determinar se a prova de validade é válida). Se o Stateroot recém-enviado for válido e legítimo, o usuário deve enviar a Prova Merkle correspondente ao Stateroot válido como prova de ativos.
No entanto, o Merkle Root submetido pelo sequenciador de Plasma, o contrato Layer1 não pode julgar se é válido ou não, e só pode deixar o nó L2 tomar a iniciativa de desafiar para excluir a Raiz inválida, então haverá um mecanismo de desafio, o que torna o funcionamento do Plasma e Zk Rollup muito diferente. **
Suponha que o sequenciador acabou de lançar uma raiz Merkle 101 inválida e lançou um ataque de retenção de dados, de modo que o nó L2 não pode provar que a raiz 101 é inválida, então o usuário pode enviar a prova merkle correspondente à raiz 100 ou raiz anterior e retirar seus ativos.
Claro, há um problema que precisa ser resolvido aqui, ou seja, um usuário pode enviar um certificado de ativo correspondente à raiz 30 ou anterior, e solicitar a retirada do ativo para a Camada 1, mas o status do ativo dessa pessoa pode mudar após o lançamento da raiz 30. Em outras palavras, ele apresenta uma prova desatualizada de ativos, que é um típico ataque de gasto duplo/gasto duplo. **
Em resposta, o Plasma permite que qualquer pessoa envie um certificado de fraude para os casos acima, afirmando que a "prova de equidade" enviada por um usuário que iniciou uma reivindicação de retirada está desatualizada. Ao introduzir este "qualquer pessoa pode contestar a declaração de retirada de outra pessoa", o Plasma não precisa lidar com solicitações de retirada de emergência como o ZK Rollup.
Mas ainda há uma possibilidade de que o classificador transfira os ativos de outra pessoa para sua própria conta L2 antes de lançar um ataque de retenção de dados que torna impossível para pessoas de fora desafiar sua trapaça. Depois disso, a própria conta do sequenciador inicia um saque de emergência, apresentando uma "prova de ativos" alegando que realmente possui os ativos em L2.
Obviamente, devido à falta de um pedaço de história, não há como provar diretamente que a fonte de ativos do sequenciador é problemática. Versões anteriores do Plasma, como o Plasma MVP, levaram isso em conta e criaram uma "prioridade de retirada". Se uma pessoa enviar uma prova de ativo correspondente ao root anteriormente, sua solicitação de retirada será priorizada.
Se o sequenciador trapacear e iniciar uma retirada ao enviar o número de raiz 101, o usuário pode enviar uma prova de ativos correspondentes ao número de raiz 99 ou anterior para fazer uma retirada de emergência. Obviamente, desde que o sequenciador não possa adulterar o histórico que foi postado na Camada 1, o usuário tem uma maneira de escapar.
Mas o Plasma ainda tem um bug fatal: desde que o sequenciador inicie a retenção de dados, as pessoas têm que confiar em saques de emergência (também conhecidos como Exit Game) para garantir a segurança dos ativos, e se um grande número de usuários retirar coletivamente em um curto período de tempo, a Camada 1 é fácil de manusear;
Suponha que alguém recarregue 100 ETH para o pool de LP do DEX, e então o sequenciador do Plasma falhe ou faça o mal, e as pessoas precisem retirar urgentemente, neste momento, os 100 ETH do usuário ainda são controlados pelo contrato DEX, quem deve mencionar esses ativos para a Camada 1 neste momento?
A melhor maneira de fazer isso é permitir que os usuários resgatem seus ativos do pool DEX primeiro e, em seguida, permitir que os usuários retirem seu dinheiro para L1, mas o problema é que o sequenciador Plasma está funcionando mal/corruptível, e os usuários não podem resgatar seus ativos. Mas não seria terrível se permitíssemos que o proprietário do contrato DEX trouxesse os ativos controlados pelo contrato para L1, o que obviamente deu ao proprietário do contrato a propriedade dos ativos, e ele poderia elevar esses ativos para L1 a qualquer momento e fugir?
Então, no final, como lidar com esses "bens públicos" suportados por contratos Defi é um grande trovão. **Se você seguir o consenso social, parece que não há problema em reconstruir um contrato espelho na Camada 1 que espelhe o contrato de desafio na Camada 2, mas isso introduzirá um problema enorme, aumentará o custo de oportunidade, e quem votará sobre o descarte do contrato espelho também será um grande problema. Na verdade, isso envolve o problema da distribuição do poder público, sobre o qual Xiangma já falou em uma entrevista "É difícil para as cadeias públicas de alto desempenho fazerem coisas novas, e os contratos inteligentes envolvem distribuição de energia.
Claro, Vitalik também aponta isso em seu recente artigo "Exit games for EVM validiums: the return of Plasma", e destaca isso como um dos fatores que tornam o Plasma hostil aos contratos inteligentes. **No passado, variantes de Plasma bem conhecidas, como Plasma MVP e Plasma Cash, usavam UTXO ou modelos semelhantes para substituir o modelo de endereço de conta do Ethereum e não suportavam 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 usuário, mas a própria UTXO 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 pedidos.
Mais tarde, com a popularidade do ZK Rollup, o próprio Plasma também se retirou do palco da história, porque o Rollup não tinha o problema de retenção de dados do Plasma. Se o sequenciador do ZK Rollup iniciar um ataque de retenção de dados e enviar apenas a Stateroot para a cadeia ETH sem dados DA, essa raiz será considerada inválida e rejeitada pelo contrato do Verificador em L1. Portanto, os dados DA correspondentes à Stateroot legal do ZK Rollup devem estar disponíveis na cadeia ETH. Desta forma, não há "apenas publicar o cabeçalho do bloco ou raiz merkle, mas não o corpo do bloco correspondente", ou seja, o problema de disponibilidade de dados / ataque de retenção de dados pode ser resolvido. **
Ao mesmo tempo, os dados DA anteriores de Rollups estão disponíveis no Ethereum, e qualquer pessoa pode iniciar nós de Camada 2 através do histórico da cadeia ETH, o que reduz muito a dificuldade de esquemas sequenciadores descentralizados ou até mesmo sem permissão. Em contraste, o Plasma não tem requisitos rigorosos para DA, e é mais difícil implementar um sequenciador descentralizado (para implementar um sequenciador descentralizado substituível, você deve 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 no bloco da Camada 2, ele não terá sucesso, o que é garantido pelo princípio da prova de validade.
No final do dia, o sequenciador ZK Rollup tem um espaço de ação muito menor do que o Plasma — ele pode, na melhor das hipóteses, interromper atualizações Stateroot, ser o equivalente a tempo de inatividade no nível UX ou negar certas solicitações do usuário, coloquialmente conhecido como censura de transações. Ao mesmo tempo, se o sequenciador falhar no esquema de Rollup, será mais fácil para outros nós substituí-lo. **Idealmente, a probabilidade de acionar o modo de jogo Exit no Plasma pode ser reduzida para 0 (chamado de escape pod no ZK Rollup).
(A coluna Proposer Failure no L2BEAT mostra como cada solução L2 pode lidar com falhas do sequenciador, Self Pose geralmente se refere a outros nós que podem substituir o sequenciador que está atualmente inativo)**
Hoje, quase não há equipes no ecossistema Ethereum que ainda estejam aderindo à rota do Plasma, e quase todos os projetos do Plasma são natimortos.
(Vitalik explica por 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, é uma variante do Optimium****
Acima explicamos brevemente o Plasma e as razões pelas quais ele é substituído pelo Rollup, e quanto ao Redstone, você também deve ter visto a diferença entre ele e o Plasma: Redstone pode resolver o problema dos ataques de retenção de dados,** Por exemplo, ele não lançará imediatamente uma nova raiz de estado, mas primeiro publicará os dados DA originais off-chain e, em seguida, publicará o datahash dos dados DA na cadeia ETH como um compromisso de credencial associado, dizendo que publicou os dados completos correspondentes a esse datahash off-chain.
(Explicação oficial da Redstone sobre seu próprio plano para evitar ataques de retenção de dados)**
Qualquer um pode desafiar o sequenciador de Redstone a dizer que ele não publica os dados brutos para esse datahash off-chain. Neste ponto, o sequenciador precisa publicar os dados correspondentes ao datahash on-chain para enfrentar o desafio do questionador. **Se o sequenciador não publicar dados sobre a cadeia ETH em tempo hábil após ser contestado, seu datahash/compromisso publicado anteriormente será considerado inválido.
Se o sequenciador responder à solicitação do desafiante em tempo hábil, o desafiante poderá obter os dados DA originais correspondentes ao datahash no tempo. Eventualmente, todos os nós L2 podem obter os dados DA necessários para resolver o problema de ataques de retenção de dados. É claro que o próprio desafiante precisa pagar uma taxa que é aproximadamente igual ao custo do sequenciador publicar os dados brutos de DA na cadeia ETH, a fim de evitar que desafiadores mal-intencionados desafiem o sequenciador sem nenhum custo e façam com que este último incorra em perdas.
Finalmente, quando o período de desafio para datahash terminar, o sequenciador publicará a raiz stateroot correspondente, que é a raiz obtida após a execução da sequência de transações contida nos dados DA correspondentes ao datahash. Neste ponto, o nó L2 pode usar o sistema à prova de fraude para desafiar essas raízes inválidas. Se o sequenciador não publicar os dados DA originais correspondentes no tempo depois que um datahash for desafiado, o sequenciador será inválido por padrão, mesmo que a raiz de estado correspondente ao datahash seja publicada posteriormente.
Como Redstone publica dados DA primeiro e, em seguida, publica o Stateroot válido correspondente, ele resolve diretamente o problema de ataques de retenção de dados (o sequenciador publica apenas dados root, mas não DA).
Obviamente, este modelo é diferente do Optimium comum (OP Rollup de DA sem Ethereum, como o Arbitrum Nova), o Optimium geralmente depende de comitês de DAC off-chain para garantir a disponibilidade de dados, o DAC envia um txn multi-Sig para a cadeia de vez em quando, e o contrato de Rollup na Camada 1 será padrão para o sequenciador que lançou o último lote de dados DA off-chain depois de receber o multi-Sig txn.
(图源:L2beat)
Enquanto Metis e Arbitrum Nova enviam Stateroot e datahash ao mesmo tempo, se alguém pensa que o sequenciador retém dados DA, eles tentarão lançar um desafio, e o sequenciador enviará os dados DA correspondentes ao datahash para a cadeia.
Portanto, a principal diferença entre Redstone e Metis é esta: o primeiro publica o datahash primeiro e aguarda o final do período de desafio do DA antes de liberar o stateroot, enquanto o Metis publica tanto o stateroot quanto o datahash, e se alguém iniciar um desafio, os dados do DA são carregados na cadeia. Obviamente, a solução de Redstone é mais segura, porque sob o esquema de Metis, se o sequenciador não responder à solicitação do desafiante para dados DA, o problema de ataque de retenção de dados não pode ser resolvido rapidamente, e a única maneira de confiar em retiradas de emergência e consenso social é deixar que outros nós assumam o sequenciador atual;
No entanto, no caso de Redstone, se o sequenciador se envolver em retenção de dados, a stateroot liberada por ele é diretamente considerada inválida, então os dados stateroot e DA são vinculados, o que permite que Redstone obtenha garantias DA mais próximas do Rollup, que é essencialmente uma variante Optimium superior ao Arbitrum Nova e Metis.
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
Restone: Não é Plasma, mas a variante Optimium
Autor: Fausto, geek web3***
Recentemente, um projeto chamado Redstone tornou-se um tópico quente. **Esta instalação Layer2 lançada pela equipe Lattice foi lançada oficialmente em 15 de novembro e agora foi lançada na testnet. Curiosamente, a equipe da Lattice afirma que "Redstone é uma cadeia Alt-DA inspirada no plasma".
Apenas um dia antes do lançamento de Redstone, Vitalik publicou o artigo "Exit games for EVM validiums: the return of Plasma", no qual ele revisou brevemente a solução técnica "Plasma" que havia desaparecido do ecossistema Ethereum, e apontou que provas de validade (confundidas com ZK Proof) poderiam ser introduzidas para resolver o problema do Plasma.
A este respeito, muitos amigos acreditam que Vitalik publicou este artigo a fim de dar Redstone uma plataforma, e mesmo na comunidade geek Web3, algumas pessoas dizem que Vitalik não investiu em Redstone. Juntamente com a fervura "Ethereum Layer 2 definition dispute" no rumor anterior, acreditava-se amplamente que o próximo "Plasma revival" seria acionado, e soluções DA fora do ecossistema Ethereum como Celestia podem ser suprimidas, porque o Plasma não tem requisitos estritos para DA. **
No entanto, de acordo com a pesquisa do autor deste artigo, Redstone não se encaixa no quadro geral da solução de Plasma, e sua alegação de ser "inspirado pelo Plasma" tem a possibilidade de esfregar o calor do artigo de Vitalik, em vez de que Vitalik realmente quer representar Redstone. Além disso, o desafio DA da Redstone é semelhante ao projeto Metis de camada 2 lançado em abril de 2022, exceto que a ordem de atualização do Stateroot e publicação dos dados DA é diferente.
Então, a situação real é que você pode ter "super-interpretado" Redstone. O seguinte é um raciocínio simples para explicar como o Plasma funciona, por que não é amigável para contratos inteligentes e Defi, e o que exatamente Redstone é. **
Plasma: Retirada urgente em caso de ataque de retenção de dados
A história do plasma pode ser rastreada até o boom do Ethereum IC0 em 2017, quando a demanda de transações dos usuários do Ethereum explodiu e o ETH com TPS baixo foi sobrecarregado. Nesta conjuntura, foi lançada a primeira versão teórica do Plasma, que propunha um esquema de escalonamento de camada 2 que poderia lidar com "quase todos os cenários financeiros do mundo".
Para simplificar, o Plasma é uma solução de dimensionamento que publica apenas o cabeçalho de bloco da Camada 2/raiz Merkle na Camada 1, e a parte dos dados fora do cabeçalho do bloco/raiz Merkle (dados DA) só é publicada fora da cadeia. **Se a Raiz Merkle publicada pelo sequenciador/Operador de Plasma em L1 estiver associada a uma transação inválida (por exemplo, um erro de assinatura digital), o usuário pode enviar um certificado de fraude para provar que a Raiz enviada pelo sequenciador está associada a uma transação inválida.
O problema é que, para emitir provas de fraude, é necessário garantir que os dados DA não sejam retidos, mas o Plasma não tem requisitos rigorosos para a camada DA e não pode garantir que os usuários ou nós L2 possam receber dados. Se o sequenciador iniciar um ataque de retenção de dados (também conhecido como um problema de disponibilidade de dados) em um determinado momento, e publicar apenas um novo cabeçalho de bloco/raiz Merkle, mas não publicar o corpo do bloco correspondente, tornando impossível verificar se o cabeçalho/raiz do bloco é válido, o usuário só pode padronizar o sequenciador como "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 "Exit Game".
Esta etapa exige que o usuário envie uma Prova Merkle para provar que tem uma quantidade correspondente de ativos em L2, que podemos chamar de "Prova de Ativos". Curiosamente, o Jogo de Saída do Plasma não é o mesmo que o modo Escape Pod do ZK Rollup, onde os usuários do ZK Rollup devem enviar uma Prova Merkle correspondente à Stateroot válida mais recente, enquanto os usuários do Plasma podem enviar uma Prova correspondente a uma Raiz Merkle de muito tempo atrás.
Porque é que foi concebido desta forma? É apenas que o Stateroot enviado pelo ZK Rollup será imediatamente julgado pelo contrato na Camada 1 (para determinar se a prova de validade é válida). Se o Stateroot recém-enviado for válido e legítimo, o usuário deve enviar a Prova Merkle correspondente ao Stateroot válido como prova de ativos.
No entanto, o Merkle Root submetido pelo sequenciador de Plasma, o contrato Layer1 não pode julgar se é válido ou não, e só pode deixar o nó L2 tomar a iniciativa de desafiar para excluir a Raiz inválida, então haverá um mecanismo de desafio, o que torna o funcionamento do Plasma e Zk Rollup muito diferente. **
Suponha que o sequenciador acabou de lançar uma raiz Merkle 101 inválida e lançou um ataque de retenção de dados, de modo que o nó L2 não pode provar que a raiz 101 é inválida, então o usuário pode enviar a prova merkle correspondente à raiz 100 ou raiz anterior e retirar seus ativos.
Claro, há um problema que precisa ser resolvido aqui, ou seja, um usuário pode enviar um certificado de ativo correspondente à raiz 30 ou anterior, e solicitar a retirada do ativo para a Camada 1, mas o status do ativo dessa pessoa pode mudar após o lançamento da raiz 30. Em outras palavras, ele apresenta uma prova desatualizada de ativos, que é um típico ataque de gasto duplo/gasto duplo. **
Em resposta, o Plasma permite que qualquer pessoa envie um certificado de fraude para os casos acima, afirmando que a "prova de equidade" enviada por um usuário que iniciou uma reivindicação de retirada está desatualizada. Ao introduzir este "qualquer pessoa pode contestar a declaração de retirada de outra pessoa", o Plasma não precisa lidar com solicitações de retirada de emergência como o ZK Rollup.
Mas ainda há uma possibilidade de que o classificador transfira os ativos de outra pessoa para sua própria conta L2 antes de lançar um ataque de retenção de dados que torna impossível para pessoas de fora desafiar sua trapaça. Depois disso, a própria conta do sequenciador inicia um saque de emergência, apresentando uma "prova de ativos" alegando que realmente possui os ativos em L2.
Obviamente, devido à falta de um pedaço de história, não há como provar diretamente que a fonte de ativos do sequenciador é problemática. Versões anteriores do Plasma, como o Plasma MVP, levaram isso em conta e criaram uma "prioridade de retirada". Se uma pessoa enviar uma prova de ativo correspondente ao root anteriormente, sua solicitação de retirada será priorizada.
Se o sequenciador trapacear e iniciar uma retirada ao enviar o número de raiz 101, o usuário pode enviar uma prova de ativos correspondentes ao número de raiz 99 ou anterior para fazer uma retirada de emergência. Obviamente, desde que o sequenciador não possa adulterar o histórico que foi postado na Camada 1, o usuário tem uma maneira de escapar.
Mas o Plasma ainda tem um bug fatal: desde que o sequenciador inicie a retenção de dados, as pessoas têm que confiar em saques de emergência (também conhecidos como Exit Game) para garantir a segurança dos ativos, e se um grande número de usuários retirar coletivamente em um curto período de tempo, a Camada 1 é fácil de manusear;
Suponha que alguém recarregue 100 ETH para o pool de LP do DEX, e então o sequenciador do Plasma falhe ou faça o mal, e as pessoas precisem retirar urgentemente, neste momento, os 100 ETH do usuário ainda são controlados pelo contrato DEX, quem deve mencionar esses ativos para a Camada 1 neste momento?
A melhor maneira de fazer isso é permitir que os usuários resgatem seus ativos do pool DEX primeiro e, em seguida, permitir que os usuários retirem seu dinheiro para L1, mas o problema é que o sequenciador Plasma está funcionando mal/corruptível, e os usuários não podem resgatar seus ativos. Mas não seria terrível se permitíssemos que o proprietário do contrato DEX trouxesse os ativos controlados pelo contrato para L1, o que obviamente deu ao proprietário do contrato a propriedade dos ativos, e ele poderia elevar esses ativos para L1 a qualquer momento e fugir?
Então, no final, como lidar com esses "bens públicos" suportados por contratos Defi é um grande trovão. **Se você seguir o consenso social, parece que não há problema em reconstruir um contrato espelho na Camada 1 que espelhe o contrato de desafio na Camada 2, mas isso introduzirá um problema enorme, aumentará o custo de oportunidade, e quem votará sobre o descarte do contrato espelho também será um grande problema. Na verdade, isso envolve o problema da distribuição do poder público, sobre o qual Xiangma já falou em uma entrevista "É difícil para as cadeias públicas de alto desempenho fazerem coisas novas, e os contratos inteligentes envolvem distribuição de energia.
Claro, Vitalik também aponta isso em seu recente artigo "Exit games for EVM validiums: the return of Plasma", e destaca isso como um dos fatores que tornam o Plasma hostil aos contratos inteligentes. **No passado, variantes de Plasma bem conhecidas, como Plasma MVP e Plasma Cash, usavam UTXO ou modelos semelhantes para substituir o modelo de endereço de conta do Ethereum e não suportavam 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 usuário, mas a própria UTXO 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 pedidos.
Mais tarde, com a popularidade do ZK Rollup, o próprio Plasma também se retirou do palco da história, porque o Rollup não tinha o problema de retenção de dados do Plasma. Se o sequenciador do ZK Rollup iniciar um ataque de retenção de dados e enviar apenas a Stateroot para a cadeia ETH sem dados DA, essa raiz será considerada inválida e rejeitada pelo contrato do Verificador em L1. Portanto, os dados DA correspondentes à Stateroot legal do ZK Rollup devem estar disponíveis na cadeia ETH. Desta forma, não há "apenas publicar o cabeçalho do bloco ou raiz merkle, mas não o corpo do bloco correspondente", ou seja, o problema de disponibilidade de dados / ataque de retenção de dados pode ser resolvido. **
Ao mesmo tempo, os dados DA anteriores de Rollups estão disponíveis no Ethereum, e qualquer pessoa pode iniciar nós de Camada 2 através do histórico da cadeia ETH, o que reduz muito a dificuldade de esquemas sequenciadores descentralizados ou até mesmo sem permissão. Em contraste, o Plasma não tem requisitos rigorosos para DA, e é mais difícil implementar um sequenciador descentralizado (para implementar um sequenciador descentralizado substituível, você deve 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 no bloco da Camada 2, ele não terá sucesso, o que é garantido pelo princípio da prova de validade.
No final do dia, o sequenciador ZK Rollup tem um espaço de ação muito menor do que o Plasma — ele pode, na melhor das hipóteses, interromper atualizações Stateroot, ser o equivalente a tempo de inatividade no nível UX ou negar certas solicitações do usuário, coloquialmente conhecido como censura de transações. Ao mesmo tempo, se o sequenciador falhar no esquema de Rollup, será mais fácil para outros nós substituí-lo. **Idealmente, a probabilidade de acionar o modo de jogo Exit no Plasma pode ser reduzida para 0 (chamado de escape pod no ZK Rollup).
(A coluna Proposer Failure no L2BEAT mostra como cada solução L2 pode lidar com falhas do sequenciador, Self Pose geralmente se refere a outros nós que podem substituir o sequenciador que está atualmente inativo)**
Hoje, quase não há equipes no ecossistema Ethereum que ainda estejam aderindo à rota do Plasma, e quase todos os projetos do Plasma são natimortos.
(Vitalik explica por 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, é uma variante do Optimium****
Acima explicamos brevemente o Plasma e as razões pelas quais ele é substituído pelo Rollup, e quanto ao Redstone, você também deve ter visto a diferença entre ele e o Plasma: Redstone pode resolver o problema dos ataques de retenção de dados,** Por exemplo, ele não lançará imediatamente uma nova raiz de estado, mas primeiro publicará os dados DA originais off-chain e, em seguida, publicará o datahash dos dados DA na cadeia ETH como um compromisso de credencial associado, dizendo que publicou os dados completos correspondentes a esse datahash off-chain.
(Explicação oficial da Redstone sobre seu próprio plano para evitar ataques de retenção de dados)**
Qualquer um pode desafiar o sequenciador de Redstone a dizer que ele não publica os dados brutos para esse datahash off-chain. Neste ponto, o sequenciador precisa publicar os dados correspondentes ao datahash on-chain para enfrentar o desafio do questionador. **Se o sequenciador não publicar dados sobre a cadeia ETH em tempo hábil após ser contestado, seu datahash/compromisso publicado anteriormente será considerado inválido.
Se o sequenciador responder à solicitação do desafiante em tempo hábil, o desafiante poderá obter os dados DA originais correspondentes ao datahash no tempo. Eventualmente, todos os nós L2 podem obter os dados DA necessários para resolver o problema de ataques de retenção de dados. É claro que o próprio desafiante precisa pagar uma taxa que é aproximadamente igual ao custo do sequenciador publicar os dados brutos de DA na cadeia ETH, a fim de evitar que desafiadores mal-intencionados desafiem o sequenciador sem nenhum custo e façam com que este último incorra em perdas.
Finalmente, quando o período de desafio para datahash terminar, o sequenciador publicará a raiz stateroot correspondente, que é a raiz obtida após a execução da sequência de transações contida nos dados DA correspondentes ao datahash. Neste ponto, o nó L2 pode usar o sistema à prova de fraude para desafiar essas raízes inválidas. Se o sequenciador não publicar os dados DA originais correspondentes no tempo depois que um datahash for desafiado, o sequenciador será inválido por padrão, mesmo que a raiz de estado correspondente ao datahash seja publicada posteriormente.
Como Redstone publica dados DA primeiro e, em seguida, publica o Stateroot válido correspondente, ele resolve diretamente o problema de ataques de retenção de dados (o sequenciador publica apenas dados root, mas não DA).
Obviamente, este modelo é diferente do Optimium comum (OP Rollup de DA sem Ethereum, como o Arbitrum Nova), o Optimium geralmente depende de comitês de DAC off-chain para garantir a disponibilidade de dados, o DAC envia um txn multi-Sig para a cadeia de vez em quando, e o contrato de Rollup na Camada 1 será padrão para o sequenciador que lançou o último lote de dados DA off-chain depois de receber o multi-Sig txn.
(图源:L2beat)
Enquanto Metis e Arbitrum Nova enviam Stateroot e datahash ao mesmo tempo, se alguém pensa que o sequenciador retém dados DA, eles tentarão lançar um desafio, e o sequenciador enviará os dados DA correspondentes ao datahash para a cadeia.
Portanto, a principal diferença entre Redstone e Metis é esta: o primeiro publica o datahash primeiro e aguarda o final do período de desafio do DA antes de liberar o stateroot, enquanto o Metis publica tanto o stateroot quanto o datahash, e se alguém iniciar um desafio, os dados do DA são carregados na cadeia. Obviamente, a solução de Redstone é mais segura, porque sob o esquema de Metis, se o sequenciador não responder à solicitação do desafiante para dados DA, o problema de ataque de retenção de dados não pode ser resolvido rapidamente, e a única maneira de confiar em retiradas de emergência e consenso social é deixar que outros nós assumam o sequenciador atual;
No entanto, no caso de Redstone, se o sequenciador se envolver em retenção de dados, a stateroot liberada por ele é diretamente considerada inválida, então os dados stateroot e DA são vinculados, o que permite que Redstone obtenha garantias DA mais próximas do Rollup, que é essencialmente uma variante Optimium superior ao Arbitrum Nova e Metis.