Quanto ao motivo pelo qual a Plasma foi enterrada por muito tempo e por que 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ó utilize 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. Agora, está sendo 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 realmente significam os ataques de retenção de dados e os problemas de DA, precisamos falar brevemente sobre a Raiz de Merkle e a Árvore de Merkle primeiro. No Ethereum ou na maioria das blockchains públicas, uma estrutura de dados em forma de árvore chamada Árvore de Merkle é usada 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 status de conta. Esses hashes são somados em pares e iterados repetidamente, e finalmente uma Raiz de Merkle pode ser calculada.

(O registro na parte inferior da figura é o conjunto de dados original correspondente ao nó da folha)Raiz de Merkle tem uma propriedade:Se um nó de folha na parte inferior da Árvore de Merkle mudar, a Raiz de Merkle calculada também será alterada. Portanto, as árvores Merkle correspondentes a diferentes conjuntos de dados originais terão raízes Merkle diferentes, assim como pessoas diferentes têm impressões digitais diferentes. A tecnologia de verificação de prova chamada Merkle Proof tira proveito dessa propriedade da Merkle Tree. Tomando a foto acima como exemplo, se Li Gang só sabe o valor de Merkle Root na imagem, ele não sabe quais dados a Merkle Tree completa contém. Queremos provar a Li Gang que o Record 3 está realmente relacionado com a Raiz na imagem, ou em outras palavras, provar que o hash do Record 3 existe na Merkle Tree correspondente à Raiz. Só precisamos enviar o Record3 e os três blocos de dados de resumo marcados em cinza para Li Gang, sem ter que enviar toda a Merkle Tree ou todos os seus nós de folha. Tal é a simplicidade da Merkle Proof.Quando os registros subjacentes da Merkle Tree contêm muitas folhas, por exemplo, ela contém de 2 a 20 blocos de dados (aproximadamente 1 milhão), a Merkle Proof só precisa conter pelo menos 21 blocos de dados.

(O bloco de dados 30 e H2 na figura podem constituir a Prova de Merkle, provando que o bloco de dados 30 existe na Árvore de Merkle correspondente a H0) Essa 'simplicidade' da Prova de Merkle é frequentemente utilizada no Bitcoin, Ethereum ou pontes entre cadeias. O nó leve que conhecemos na verdade é o 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 Trie de Estado para servir como um resumo de todas as contas. Sempre que o status de uma conta associada ao Trie de Estado muda, a Raiz de Merkle do Trie de Estado, chamada StateRoot, mudará. No cabeçalho do bloco do Ethereum, o StateRoot será registrado, e a Raiz de Merkle da árvore de transações (referida como Raiz Txn) também será registrada. Uma diferença entre uma árvore de transações e uma árvore de estado é que os dados representados pelas folhas subjacentes são diferentes. Se o bloco nº 100 contém 300 transações, as folhas da árvore de transações representam essas 300 Txn. Outra diferença é que o volume geral de dados do Trie de Estado é extremamente grande. Suas folhas inferiores correspondem a todos os endereços na cadeia do Ethereum (na verdade, existem muitos hashes de estado desatualizados), então o conjunto de dados original correspondente ao Trie de Estado não será divulgado. No bloco, apenas o StateRoot é registrado no cabeçalho do bloco. O conjunto de dados original da árvore de transações são os dados Txn em cada bloco, e o TxnRoot desta árvore será registrado 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 (isso é determinado pelas propriedades da Árvore de Merkle e da função de hash), então os nós leves não podem saber os dados da transação contidos no bloco, nem sabem quais mudanças ocorreram na conta correspondente ao State Trie.Se Wang Qiang quiser provar a um nó leve (Li Gang mencionado anteriormente) que o bloco Nº 100 contém uma determinada transação, e é sabido que o nó leve conhece o cabeçalho do bloco Nº 100 e conhece o TxnRoot, então o problema acima se transforma em:Provar que esta Txn existe na Árvore de Merkle correspondente ao TxnRoot.Neste momento, Wang Qiang só precisa enviar a Prova de Merkle correspondente.

Em muitas pontes interligadas 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 Mapa irão configurar um contrato na cadeia ETH para receber especificamente cabeçalhos de bloco de outras cadeias (como a Polygon). Quando o Relayer envia o cabeçalho do 100º bloco da Polygon para o contrato na cadeia ETH, o contrato irá 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 transação intercadeias da Polygon para a ETH, a transação será incluída no 100º bloco da Polygon. Ele só precisa usar a Prova de Merkle para provar que a transação intercadeias iniciada por ele pode corresponder ao TxnRoot no cabeçalho do bloco nº 100 (ou seja, provar que a transação intercadeias iniciada por você está registrada no bloco 100 da Polygon). No entanto, a Ponte ZK usará uma 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 interligada.

Questões de ataque DA e de retenção de dados

Depois de falar sobre Merkle Tree, Merkle Root e Merkle Proof, voltemos à questão do DA e dos ataques de retenção de dados mencionados no início do artigo. Esta questão já foi discutida em 2017. O artigo original da Celestia tem a fonte do problema do DA. Realize arqueologia. Vitalik mencionou em um documento de 2017 a 2018 que o produtor de bloco pode deliberadamente ocultar certos fragmentos de dados do bloco e liberar 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 usuário, como transferir todas as moedas na conta de A para outros endereços, mas o nó completo não pode julgar se A mesmo fez isso porque não sabem a transação completa incluída no último bloco de dados.

Nas cadeias públicas da Camada 1, como Bitcoin ou Ethereum, nós 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. Nós apenas conhecemos o StateRoot e 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, na verdade, há alguma reflexão sobre essa situação. Satoshi Nakamoto uma vez acreditou que a maioria dos usuários tenderia a executar nós leves com requisitos de configuração mais baixos, e nós leves não podem julgar se o bloco correspondente ao cabeçalho do bloco é válido. Se um bloco for inválido, nós completos honestos enviarão um alerta para os nós leves.

No entanto, Satoshi Nakamoto não realizou uma análise mais detalhada dessa solução. Posteriormente, Vitalik e o fundador da Celestia, Mustafa, combinaram essa 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 Celestia não são o foco deste artigo. Os leitores interessados podem ler artigos anteriores do “Geek Web3”:“Mal-entendido sobre a Disponibilidade de Dados: DA = Liberação 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 completo de dados de transação/mudanças de estado de cada conta) são apenas 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 enviar uma Prova de Merkle para comprovar que possuem esses ativos. A lógica de verificação de ativos que cruzam 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 é 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 propósito do período de desafio, explicaremos abaixo.

O 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 por si mesmos. 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 final do “período de desafio”. Provar que o cabeçalho do bloco Nº 100 pode ser associado a uma transação inválida, este é um cenário coberto pela prova de fraude.

Os cenários de aplicação de prova de fraude do Plasma também incluem o seguinte:1. Suponha que o progresso da rede Plasma alcance o bloco nº 200. Neste momento, o usuário A inicia uma declaração de saque, 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 bloco 100. Portanto, o comportamento de A é na verdade: depois de gastar 10 ETH, ele declara que tinha 10 ETH no passado e tenta sacar esses ETH. Este é um típico “saque duplo” e gasto duplo. Neste momento, qualquer pessoa pode apresentar uma Prova de Merkle para provar que o estado mais recente dos ativos do usuário A não corresponde à sua declaração de saque, ou seja, para provar que A não sacou o dinheiro declarado após o bloco 100. (Esquemas de Plasma diferentes têm métodos de prova inconsistentes para essa situação, e o modelo de endereço da conta é muito mais problemático do que a prova de gasto duplo de UTXO). 2. Se for uma solução Plasma baseada no modelo UTXO (esse era 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á estado global como o State Trie) design). Em outras palavras, uma cadeia usando o modelo UTXO tem apenas registros de transação e nenhum registro de status. Neste momento, o sequenciador em si 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 apresentar uma Prova de Merkle para provar que o registro de uso do UTXO apareceu (foi gasto) em blocos anteriores, ou para provar que há um problema com a origem histórica de determinado UTXO.

1. Para soluções Plasma compatíveis com EVM/State Trie, o classificador pode enviar um StateRoot inválido. Por exemplo, após a execução da transação contida no 100º bloco, o StateRoot deveria ser convertido para 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 reexecução da transação no bloco nº 100 na cadeia Ethereum. O valor do cálculo e os parâmetros de entrada necessários consumirão muito gás. As equipes que adotaram o Plasma cedo tiveram dificuldade em alcançar provas de fraude tão complexas, então a maioria delas 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ão estabelecidos apenas quando a liberação de dados/DA é eficaz. Se o sequenciador se envolve em retenção de dados e não publica 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, não será capaz de emitir provas de fraude suavemente.

Neste ponto, o sequenciador pode roubar ativos do usuário,Por exemplo, transferir privadamente todas as moedas da conta A para a conta B, em seguida, transferir dinheiro da conta B para a conta C e, finalmente, iniciar um saque no 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, ela não causará nenhum 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 é falsa, é necessário ressaltar 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 saque, 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 o 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, seja o Plasma baseado em UTXO ou o modelo de endereço de conta, uma vez que a retenção de dados ocorra, basicamente causará pânico nas pessoas, 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 provas de fraude. Neste momento, as pessoas só podem ver o cabeçalho de bloco correspondente, mas não sabem o que está no bloco ou o que se tornou de seus ativos de conta. Todos iniciarão coletivamente uma declaração de retirada e usarão o cabeçalho de bloco correspondente. Merkle Proof tenta retirar dinheiro,Desencadeando um cenário extremo chamado "Exit Game", esta situação levará a uma "debandada", causando sérios congestionamentos na Camada 1, e ainda fará com que os bens de algumas pessoas sejam danificados. (As pessoas que não receberam notificações honestas de nó ou não verificam o Twitter não saberão que o sequenciador está roubando moedas).

assim, o plasma é uma solução de expansão de camada 2 não confiável. Uma vez que um ataque de retenção de dados ocorre, o "Exit Game" será acionado, o que pode facilmente fazer com que os usuários sofram perdas. Esta é uma das principais razões para o seu abandono. Por que o Plasma tem dificuldade em suportar contratos inteligentes Depois de falar sobre o Exit Game e os problemas de retenção de dados, vamos ver por que o Plasma tem dificuldade em suportar contratos inteligentes. Existem dois motivos principais: Primeiro, se for um ativo de um contrato Defi, quem deve retirá-lo para a Layer1? Porque isso é essencialmente migrar o status do contrato de Layer2 para Layer1.Suponha que alguém deposite 100 ETH no pool DEX LP e, em seguida, o sequenciador de Plasma faça algo ruim e as pessoas queiram sacar dinheiro urgentemente. No momento, os 100 ETH do usuário ainda são controlados pelo contrato DEX. Quem deve possuir esses ativos neste momento? Mencionado na Layer1? A melhor maneira parece ser permitir que os usuários resgatem ativos da DEX primeiro e, em seguida, permitir que os usuários transfiram o dinheiro para a própria L1. Mas o problema é que o classificador de Plasma fez mal e pode rejeitar solicitações de usuários a qualquer momento. Então, e se configurarmos o proprietário para o contrato DEX com antecedência e permitirmos que ele levante os ativos do contrato para L1 em uma emergência? Obviamente, isso dará ao proprietário do contrato a propriedade do patrimônio público. Ele pode levantar esses ativos para L1 e fugir a qualquer momento. Isso não é terrível? Obviamente, como lidar com esses "bens públicos" controlados por contratos Defi é uma grande surpresa. Trata-se, na verdade, do 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 poder”Isso 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 mixer, atualmente depositado com 100 ETH, e o proprietário do mixer é controlado por Bob; Suponha que Bob retire 50 ETH do mixer no bloco 100. Depois, Bob inicia uma declaração de retirada e transfere os 50 ETH para a Layer1; em seguida, Bob usa o instantâneo do estado do contrato anterior (como o bloco 70) para migrar o estado passado do mixer para a Layer1, que será A 100 ETH que o mixer "costumava possuir" também foi transferida para a Layer1; obviamente, este é um típico "saque duplo", 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 mixer/Bob, e 50 ETH foram retirados do ar. Isso poderia facilmente drenar as reservas de Plasma secas. Em tese, poder-se-ia iniciar uma prova de fraude para provar que o estado do contrato do misturador mudou após o bloco 70. Mas se após o bloco nº 70, todos os Txn que interagiram com o contrato do mixer não alteraram o status do contrato, exceto a transação em que Bob levou 50 ETH; se você quiser mostrar evidências, aponte que o contrato do mixer 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 do misturador realmente mudou (a razão pela qual é tão complicado é porque determinado pela própria estrutura do Plasma). Se o número de Txn neste lote for extremamente grande, a prova de fraude não poderá ser publicada na Layer1. (Ele excederá o limite de gás de um único bloco de Ethereum).

https://ethresear.ch/t/por-que-os-contratos-inteligentes-nao-sao-viaveis-no-plasma/2598Teoricamente, no cenário de gasto duplo acima, parece que apenas o instantâneo de estado atual do mixer é 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 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 de forma privada 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ó do 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 outras pessoas retirem dinheiro. No Rollup, se você encontrar a retirada dupla mencionada acima, teoricamente não há necessidade de reproduzir 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 de contrato (ZK Rollup) ou será desafiado em breve (OP Rollup). Na verdade, além do exemplo de 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 esse cenário. Essa situação é analisada na ETH Research. Em resumo, uma vez que a solução de 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 o 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 ele tem um único cenário de aplicação e basicamente só pode suportar transferências ou trocas de carteira de pedidos. 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 é muito 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 estágio da história.

Aviso Legal：

1. Este artigo foi reproduzido de [Conta oficial do WeChat: Geek Web3]. Todos os direitos autorais pertencem ao autor original [Faust]. Se houver objeções a esta reimpressão, entre em contato com o Portão Aprenderequipe e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As 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 outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.