Quanto ao motivo pelo qual a Plasma foi enterrada por muito tempo e por que o Vitalik apoiará fortemente o Rollup, as pistas apontam principalmente para dois pontos: a implementação de DA sob a cadeia Ethereum é pouco confiável e a retenção de dados é fácil de ocorrer. Uma vez que a retenção de dados ocorre, a prova de fraude é difícil de ser realizada; O design do mecanismo da Plasma em si é extremamente hostil aos contratos inteligentes e é especialmente difícil apoiar a migração do status do contrato para a Camada 1. Esses dois pontos fazem com que a Plasma basicamente só use modelos UTXO ou similares.

Para entender os dois pontos principais acima, vamos começar com as questões de DA e retenção de dados. O nome completo de DA é Disponibilidade de Dados, que é literalmente traduzido como disponibilidade de dados. Atualmente, é mal utilizado por muitas pessoas. Tanto que está seriamente confundido com "dados históricos podem ser verificados". Mas, na verdade, "dados históricos podem ser verificados" e "prova de armazenamento" são problemas que Filecoin e Arweave já resolveram. De acordo com a Ethereum Foundation e a Celestia, a questão do DA explora puramente cenários de retenção de dados.

Árvore de Merkle e Raiz de Merkle e Prova de Merkle

Para explicar o que são os ataques de retenção de dados e os problemas de DA na verdade, precisamos falar brevemente sobre a Raiz de Merkle e a Árvore de Merkle primeiro. No Ethereum ou na maioria das cadeias públicas, é usada uma estrutura de dados em forma de árvore chamada Árvore de Merkle para servir como um resumo/diretório do estado de todas as contas, ou para registrar as transações empacotadas em cada bloco.

O nó folha na parte inferior da Árvore de Merkle é composto por hashes de dados originais, como transações ou estado da conta. Estes hashes são somados em pares e iterados repetidamente, e finalmente uma Raiz de Merkle pode ser calculada.

(O registo na parte inferior da figura é o conjunto de dados original correspondente ao nó folha) A Raiz de Merkle tem uma propriedade: Se um nó folha na parte inferior da Árvore de Merkle mudar, a Raiz de Merkle calculada também mudará. Portanto, Árvores de Merkle correspondentes a diferentes conjuntos de dados originais terão Raízes de Merkle diferentes, assim como pessoas diferentes têm impressões digitais diferentes. A tecnologia de verificação de prova chamada Prova de Merkle aproveita essa propriedade da Árvore de Merkle. Tomando a figura acima como exemplo, se Li Gang apenas conhece o valor da Raiz de Merkle na figura, ele não sabe que dados a Árvore de Merkle completa contém. Queremos provar a Li Gang que o Registo 3 está de facto relacionado com a Raiz na figura, ou em outras palavras, provar que o hash do Registo 3 existe na Árvore de Merkle correspondente à Raiz. Só precisamos submeter o Registo 3 e os três blocos de dados de digestão marcados a cinzento a Li Gang, sem ter de submeter a Árvore de Merkle completa ou todos os seus nós folha. Tal é a simplicidade da Prova de Merkle. Quando os registos subjacentes da Árvore de Merkle contêm muitos nós folha, por exemplo, contém 2 elevado à 20ª potência de blocos de dados (aproximadamente 1 milhão), a Prova de Merkle só precisa conter pelo menos 21 blocos de dados.

(O bloco de dados 30 e H2 na figura podem constituir uma Prova de Merkle, provando que o bloco de dados 30 existe na Árvore de Merkle correspondente a H0) Esta “simplicidade” da Prova de Merkle é frequentemente utilizada no Bitcoin, Ethereum ou pontes inter-cadeias. O nó leve que conhecemos é na verdade Li Gang mencionado acima. Ele apenas recebe o cabeçalho do bloco do nó completo, não o bloco completo. É necessário enfatizar aqui que o Ethereum utiliza uma árvore de Merkle chamada State Trie para servir como resumo de todas as contas. Sempre que o estado de uma conta associada ao State Trie muda, a Raiz de Merkle do State Trie, chamada StateRoot, irá mudar. No cabeçalho do bloco do Ethereum, o StateRoot será registado, e a Raiz de Merkle da árvore de transações (referida como Txn Root) também será registada., uma diferença entre uma árvore de transações e uma árvore de estados é que os dados representados pelas folhas subjacentes são diferentes. Se o bloco nº. 100 contiver 300 transações, as folhas da árvore de transações representam essas 300 Txn. Outra diferença é que o volume global de dados do State Trie é extremamente grande. As suas folhas inferiores correspondem a todos os endereços na cadeia Ethereum (de facto, existem muitos hashes de estado desatualizados), por isso o conjunto original de dados correspondente ao State Trie não será divulgado. No bloco, apenas o StateRoot é registado no cabeçalho do bloco. O conjunto original de dados da árvore de transações são os dados Txn em cada bloco, e o TxnRoot desta árvore será registado no cabeçalho do bloco.

Uma vez que o nó leve apenas recebe o cabeçalho do bloco e apenas conhece o StateRoot e TxnRoot, não pode deduzir a árvore de Merkle completa com base no Root (isto é determinado pelas propriedades da árvore de Merkle e da função hash), por isso os nós leves não podem saber os dados da transação contidos no bloco, nem sabem quais alterações ocorreram na conta correspondente ao State Trie. Se Wang Qiang quiser provar a um nó leve (como Li Gang mencionado anteriormente) que o bloco n.º 100 contém uma determinada transação, e sabe-se que o nó leve conhece o cabeçalho do bloco n.º 100 e conhece o TxnRoot, então o problema acima é transformado em: Provar que esta Txn existe na Árvore de Merkle correspondente ao TxnRoot. Neste momento, Wang Qiang só precisa submeter a Prova de Merkle correspondente.

Em muitas pontes cruzadas baseadas em soluções de cliente leve, o peso leve e a simplicidade dos nós leves e da Prova de Merkle mencionados acima são frequentemente utilizados. Por exemplo, pontes ZK como o Protocolo Map irão estabelecer um contrato na cadeia ETH para receber especificamente cabeçalhos de bloco de outras cadeias (como Polygon). Quando o Relayer submete o cabeçalho do 100º bloco da Polygon ao contrato na cadeia ETH, o contrato verificará a validade do cabeçalho (por exemplo, se coletou as assinaturas de 2/3 dos nós POS na rede Polygon). Se o cabeçalho for válido e um usuário declarar que iniciou uma Txn entre cadeias da Polygon para a ETH, a Txn será empacotada no 100º bloco da Polygon. Ele só precisa usar a Prova de Merkle para provar que a Txn entre cadeias iniciada por ele pode corresponder ao TxnRoot no cabeçalho do bloco nº 100 (ou seja, provar que a Txn entre cadeias iniciada por você está registrada no bloco 100 da Polygon.). No entanto, a Ponte ZK usará prova de conhecimento zero para comprimir a quantidade de cálculo necessária para verificar a Prova de Merkle, reduzindo ainda mais o custo de verificação dos contratos de ponte cruzada.

Questões de Ataque DA e Retenção de Dados

Depois de falar sobre Merkle Tree, Merkle Root e Merkle Proof, vamos voltar à questão do DA e dos ataques de retenção de dados mencionados no início do artigo. Esta questão já foi discutida tão cedo como 2017. O documento original da Celestia tem a origem da questão do DA. Vitalik mencionou ele mesmo num documento de 2017 a 2018 que o produtor de blocos pode deliberadamente ocultar certos fragmentos de dados do bloco e lançar blocos incompletos para o mundo exterior. Como resultado, o nó completo não pode confirmar a correção da execução da transação/transição de estado.

Neste momento, o produtor de blocos pode roubar os ativos do utilizador, como transferir todas as moedas da conta de A para outros endereços, mas o nó completo não pode julgar se A próprio fez isto porque eles não conhecem a transação completa incluída no bloco mais recente. dados.

Nas cadeias públicas da Camada 1, como o Bitcoin ou o Ethereum, os nós completos honestos rejeitarão diretamente os blocos inválidos acima. Mas os nós leves são diferentes. Eles apenas recebem cabeçalhos de bloco da rede. Apenas conhecemos o StateRoot e o TxnRoot, mas não sabemos se o Cabeçalho e os blocos originais correspondentes aos dois Roots são válidos.

No white paper do Bitcoin, há na verdade alguma reflexão sobre esta situação. Satoshi Nakamoto acreditava que a maioria dos utilizadores tenderia a executar nós leves com requisitos de configuração mais baixos, e os nós leves não conseguem julgar se o bloco correspondente ao cabeçalho do bloco é válido. Se um bloco for inválido, os nós completos honestos enviarão um alerta aos nós leves.

No entanto, Satoshi Nakamoto não conduziu uma análise mais detalhada desta solução. Mais tarde, Vitalik e o fundador da Celestia, Mustafa, combinaram esta ideia com os resultados de outros predecessores e introduziram a amostragem de dados DA para garantir que nós completos honestos possam restaurar cada bloco de dados completo e gerar alertas quando necessário.

Nota: A Amostragem de Dados DA (DAS) e a Celestia não são o foco deste artigo. Os leitores interessados podem ler artigos anteriores do “Geek Web3”:“Má compreensão da Disponibilidade de Dados: DA = Lançamento de Dados ≠ Recuperação de Dados Históricos”

Prova de fraude do Plasma

Em termos simples, o Plasma é uma solução de expansão que apenas publica o cabeçalho do bloco da Camada 2 para a Camada 1, e os dados DA fora do cabeçalho do bloco (conjunto de dados de transação completa/mudanças de estado de cada conta) apenas são liberados off-chain. Em outras palavras, o Plasma é como uma ponte cross-chain baseada em clientes leves. Ele usa contratos para implementar clientes leves da Camada 2 na cadeia ETH. Quando os usuários declaram que desejam transferir ativos da L2 para a L1, eles devem apresentar uma Prova de Merkle para comprovar que possuem esses ativos. A lógica de verificação de transferência de ativos da L2 para a L1 é semelhante à ponte ZK mencionada acima, exceto que o modelo de ponte do Plasma é baseado em prova de fraude, não em prova ZK, e está mais próximo do chamado "ponte otimista". Os pedidos de retirada da L2 para a L1 na rede Plasma não serão liberados imediatamente, mas haverá um "período de desafio". Quanto ao objetivo do período de desafio, explicaremos abaixo.

A Plasma não tem requisitos rigorosos para a liberação de dados/DA. O sequenciador/Operador apenas transmite cada bloco L2 off-chain, e os nós que desejam obter blocos L2 podem obtê-los sozinhos. Posteriormente, o classificador publicará o cabeçalho do bloco L2 para a Camada1. Por exemplo, o sequenciador primeiro transmite o bloco nº 100 off-chain e, em seguida, publica o cabeçalho do bloco na cadeia. Se o bloco 100 contiver transações inválidas, qualquer nó Plasma pode enviar a Prova de Merkle para o contrato na ETH antes do fim do “período de desafio”. Provar que o cabeçalho do bloco nº 100 pode estar associado a uma transação inválida. Este é um cenário abrangido pela prova de fraude.

Os cenários de aplicação à prova de fraude do Plasma também incluem o seguinte:1. Suponha que o progresso da rede de Plasma atinge o bloco nº 200. Neste momento, o usuário A inicia uma declaração de retirada, dizendo que quando ele estava no bloco nº 100, ele tinha 10 ETH. Mas, na verdade, o usuário A gastou o ETH em sua conta após o bloqueio 100. Portanto, o comportamento de A é, na verdade: depois de gastar 10 ETH, ele declara que tinha 10 ETH no passado, e tenta retirar esses ETH. Trata-se de um típico "duplo levantamento" e de dois gastos. neste momento, qualquer pessoa pode apresentar o Merkle Proof para provar que o último status de ativo do usuário A não satisfaz sua declaração de retirada, ou seja, para provar que A não retirou o dinheiro declarado após o bloco 100. (Diferentes esquemas de Plasma têm métodos de prova inconsistentes para esta situação, e o modelo de endereço de conta é muito mais problemático do que a prova de gasto duplo da UTXO). 2. Se for uma solução Plasma baseada no modelo UTXO (este foi principalmente o caso no passado), o cabeçalho do bloco não contém StateRoot, apenas TxnRoot (UTXO não suporta o modelo de endereço de conta no estilo Ethereum e não há nenhum estado global como o design State Trie). Em outras palavras, uma cadeia usando o modelo UTXO só tem registros de transação e nenhum registro de status. Neste momento, o próprio sequenciador pode lançar um ataque de gasto duplo, como gastar um UTXO que foi gasto novamente ou emitir UTXO adicional para um usuário do nada. Qualquer usuário pode enviar uma prova Merkle para provar que o registro de uso do UTXO apareceu (foi gasto) em blocos passados, ou para provar que há um problema com a fonte histórica de um determinado UTXO.

1. Para soluções Plasma compatíveis com EVM/Trie de Estado, o classificador pode enviar um StateRoot inválido. Por exemplo, após a execução da transação contida no 100º bloco, o StateRoot deve ser convertido em ST+, mas o classificador vai para a Camada1. O que foi enviado foi ST-. A prova de fraude neste caso é mais complicada e requer a repetição da transação no bloco n.º 100 na cadeia Ethereum. A quantidade de cálculo e os parâmetros de entrada necessários consumirão muitos gases. As equipas que adotaram cedo o Plasma tiveram dificuldade em alcançar provas de fraude tão complexas, por isso a maioria adotou o modelo UTXO. Afinal, as provas de fraude baseadas em UTXO são simples e fáceis de implementar. (Fuel, a primeira solução rollup a fornecer prova de fraude, é baseada em UTXO)

Retenção de Dados e Jogo de Saída Claro, os cenários acima, onde a prova de fraude pode ser eficaz, só são estabelecidos quando a DA/liberação de dados é eficaz. Se o sequenciador se envolver em retenção de dados e não publicar blocos completos off-chain, o nó Plasma não será capaz de confirmar se o cabeçalho do bloco na Camada 1 é válido, e é claro que não poderá emitir fraudes suavemente.

Neste ponto, o sequenciador pode roubar ativos do usuário,Por exemplo, transferir privadamente todas as moedas na conta A para a conta B, em seguida, transferir dinheiro da conta B para a conta C e, finalmente, iniciar um saque em nome de C. As contas B e C são de propriedade do próprio sequenciador. Mesmo que a transferência B->C seja tornada pública, não causará qualquer dano; Mas o classificador pode reter os dados da transferência inválida A->B, e as pessoas não podem provar que há um problema com a origem dos ativos de B e C. (Para provar que a fonte dos ativos de B é suspeita, é necessário salientar que a assinatura digital de "um certo Txn transferido para B" está incorreta). A solução de plasma baseada em UTXO tem medidas direcionadas. Por exemplo, quando alguém inicia um levantamento, deve apresentar todas as fontes históricas dos ativos. É claro que haverá mais medidas de melhoria mais tarde. Mas se for uma solução de plasma compatível com EVM, parecerá fraca nesta área. Porque se Txn relacionado ao contrato estiver envolvido, verificar o processo de transição de estado na cadeia incorrerá em custos enormes, portanto, o Plasma, que suporta modelos de endereço de conta e contratos inteligentes, não pode facilmente implementar um esquema de verificação para a validade dos saques. Além disso, além do tópico acima, se é Plasma baseado em UTXO ou o modelo de endereço de conta, uma vez que a retenção de dados ocorre, basicamente fará com que as pessoas entrem em pânico porque você não sabe quais transações o sequenciador executou. Os nós de plasma descobrirão que algo está errado, mas não poderão emitir provas de fraude porque o sequenciador de plasma não emitiu os dados necessários para as provas de fraude. Neste momento, as pessoas só podem ver o cabeçalho do bloco correspondente, mas não sabem o que está no bloco ou o que se tornou dos ativos da sua conta. Todos iniciarão coletivamente uma declaração de retirada e usarão o cabeçalho do bloco correspondente. Merkle Proof tenta retirar dinheiro,Desencadeando um cenário extremo chamado "Exit Game", esta situação levará a uma "debandada", causando sério congestionamento na Camada 1, e ainda fará com que os bens de algumas pessoas sejam danificados. (As pessoas que não receberam notificações de nó honestas ou não verificam o Twitter não saberão que o sequenciador está roubando moedas).

Portanto, a Plasma é uma solução de expansão da Camada 2 não confiável. Uma vez que ocorre um ataque de retenção de dados, o “Jogo de Saída” será acionado, o que pode facilmente causar perdas aos usuários. Esta é uma das principais razões para o seu abandono. Por que a Plasma tem dificuldade em suportar contratos inteligentes? Após falar sobre o Jogo de Saída e os problemas de retenção de dados, vamos ver por que a Plasma tem dificuldade em suportar contratos inteligentes. Há duas razões principais: Primeiro, se for um ativo de um contrato Defi, quem deve retirá-lo para a Camada 1? Porque essencialmente isto significa migrar o status do contrato da Camada 2 para a Camada 1. Suponhamos que alguém deposite 100 ETH na pool DEX LP e depois o sequenciador da Plasma faça algo malicioso, e as pessoas queiram retirar dinheiro com urgência. Neste momento, os 100 ETH do usuário ainda estão sob controle do contrato DEX. Quem deve possuir estes ativos neste momento? Mencionado na Camada 1? A melhor maneira parece ser permitir que os usuários resgatem os ativos do DEX primeiro e depois permitir que os usuários transfiram o dinheiro para a L1 por si mesmos. Mas o problema é que o classificador da Plasma já fez algo malicioso e pode rejeitar as solicitações do usuário a qualquer momento. Então, e se configurarmos o Proprietário do contrato DEX antecipadamente e permitirmos que ele levante os ativos do contrato para L1 em caso de emergência? Obviamente, isto dará ao proprietário do contrato a propriedade de ativos públicos. Ele pode levantar estes ativos para L1 e fugir a qualquer momento. Isso não é terrível? Obviamente, como lidar com estes “bens públicos” controlados por contratos Defi é uma grande surpresa. Isto envolve na verdade 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 poder”Isto foi mencionado no artigo.

Em segundo lugar, se o contrato não for autorizado a migrar, sofrerá enormes prejuízos; Se o contrato tiver permissão para migrar seu estado para a Camada 1, haverá uma retirada dupla que é difícil de resolver na prova de fraude do Plasma:Por exemplo, assumimos que o Plasma adota o modelo de endereço de conta do Ethereum e suporta contratos inteligentes., há um misturador, atualmente depositado com 100 ETH, e o proprietário do misturador é controlado por Bob; suponha que Bob retira 50 ETH do misturador no bloco 100. Depois, Bob inicia uma declaração de retirada e transfere os 50 ETH para a Camada 1; em seguida, Bob usa o instantâneo de estado do contrato passado (como o bloco 70) para migrar o estado passado do misturador para a Layer1, que será A 100 ETH que o misturador "costumava possuir" também foi transferida para a Layer1; obviamente, esta é uma típica "retirada dupla", ou seja, um gasto duplo.150 ETH foram mencionados por Bob para a Camada 1, mas os usuários da rede da Camada 2 pagaram apenas 100 ETH para o misturador / Bob, e 50 ETH foram retirados do nada. Isso poderia facilmente drenar as reservas de plasma a seco。 Em teoria, poder-se-ia iniciar uma prova de fraude para provar que o estado do contrato da misturadora mudou após o 70º bloco. Mas se após o bloco nº 70, todos os Txn que interagiram com o contrato da misturadora não alteraram o status do contrato, exceto a transação em que Bob tirou 50 ETH; se você quiser mostrar evidências, aponte que o contrato do misturador está em Se houver uma mudança após o bloco nº 70, todos os Txn mencionados acima devem ser executados na cadeia Ethereum e, finalmente, o contrato Plasma pode ser confirmado. O status do contrato misturador realmente mudou (a razão pela qual é tão complicado é porque determinado pela estrutura do próprio plasma). Se o número de Txn neste lote for extremamente grande, a prova de fraude não pode ser publicada na Camada 1. (Excederá o limite de gás de um único bloco de Ethereum).

https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598Teoricamente, no cenário de gasto duplo acima, parece que apenas o instantâneo de estado atual do misturador é enviado (na verdade, a prova de Merkle correspondente a StateRoot), mas, na verdade, como o Plasma não publica dados de transação na cadeia, o contrato não pode determinar se você é válido se o instantâneo de estado enviado é válido. Isso ocorre porque o próprio sequenciador pode iniciar a retenção de dados, enviar instantâneos de estado inválidos e incriminar maliciosamente qualquer retirador. Por exemplo, quando você declara que tem 50 ETH em sua conta e inicia um saque, o sequenciador pode limpar sua conta para 0, em seguida, iniciar a retenção de dados, enviar um StateRoot inválido para a cadeia e enviar o instantâneo de estado correspondente, acusando-o falsamente de ficar sem dinheiro em sua conta. No momento, não podemos provar que o StateRoot e o instantâneo de estado enviados pelo sequenciador são inválidos, porque ele iniciou a retenção de dados e você não pode obter dados suficientes necessários para a prova de fraude. Para evitar isso, quando um nó Plasma apresenta um instantâneo de estado para provar que alguém gastou duas vezes, ele também reproduzirá os registros de transação durante esse período. Isso pode impedir que o sequenciador use a retenção de dados para impedir que outros retirem dinheiro. No Rollup, se você encontrar a retirada dupla acima mencionada, teoricamente não há necessidade de repetir transações históricas, porque o Rollup não tem problemas de retenção de dados e "forçará" o sequenciador a publicar dados DA na cadeia. Se o sequenciador de Rollup enviar um instantâneo StateRoot-state inválido, ele falhará na verificação do contrato (ZK Rollup) ou será desafiado em breve (OP Rollup). Na verdade, além do exemplo do misturador de moedas mencionado acima, cenários como contratos de assinatura múltipla também podem levar a retiradas duplas na rede Plasma. A prova de fraude é muito ineficiente para lidar com este cenário. Esta situação é analisada na ETH Research. Em resumo, uma vez que a solução Plasma não é propícia a contratos inteligentes e basicamente não suporta a migração do status do contrato para a Camada 1, o Plasma convencional tem que usar UTXO ou mecanismos semelhantes. Como a UTXO não tem o problema de conflitos de propriedade de ativos e pode suportar muito bem a prova de fraude (é muito menor em tamanho), o preço é que ela tem um único cenário de aplicação e basicamente só pode suportar transferências ou trocas de livros de ordens. Além disso, como a própria prova de fraude tem uma forte dependência dos dados DA, se a camada DA não for confiável, será difícil implementar um sistema eficiente à prova de fraude. No entanto, a forma como a Plasma lida com o problema do DA é demasiado grosseira e não pode resolver o problema dos ataques de retenção de dados. Com a ascensão do Rollup, o Plasma lentamente desapareceu do palco da história.

Aviso legal：

1. Este artigo é reproduzido a partir de [Conta oficial no WeChat: Geek Web3]. Todos os direitos de autor pertencem ao autor original [Faust]. Se houver objeções a este reenvio, por favor entre em contato com o Gate Learnequipa e eles tratarão disso prontamente.
2. Isenção de Responsabilidade: Os pontos de vista e opiniões 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 Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.