Retenção de dados e à prova de fraude: por que o Plasma não suporta contratos inteligentes

Autor: Fausto, geek web3

Quanto ao motivo pelo qual o Plasma está enterrado há muito tempo, e por que o Vitalik apoiará fortemente o Rollup, as pistas apontam principalmente para dois pontos: implementar DA off-chain na cadeia Ethereum não é confiável, e a retenção de dados é fácil de ocorrer, e uma vez que a retenção de dados ocorre, a prova de fraude é difícil de desenvolver; **Estes dois pontos tornam o Plasma basicamente apenas UTXO ou modelos aproximados.

Para entender esses dois pontos principais, vamos começar com DA e retenção de dados. DA significa Data Disponibilibility, que literalmente se traduz em disponibilidade de dados, e agora é usado indevidamente por muitas pessoas, tanto que é seriamente confundido com “dados históricos podem ser verificados”. Mas, na realidade, “dados históricos” e “prova de armazenamento” são problemas de longa data que foram resolvidos por empresas como Filecoin e Arweave. De acordo com a Fundação Ethereum e Celestia, a questão do DA é puramente sobre cenários de retenção de dados. **

Merkle Tree & Raiz Merkle & Merkle Proof

Para ilustrar o que os ataques de retenção de dados e problemas de DA significam, precisamos primeiro falar brevemente sobre Merkle Root e Merkle Tree. **No Ethereum, ou na maioria das cadeias públicas, uma estrutura de dados semelhante a uma árvore chamada Merkle Tree é usada para atuar como um resumo/diretório do estado de toda a conta, ou para registrar as transações empacotadas dentro de cada bloco.

**O nó folha na parte inferior da Árvore Merkle é composto por hashes de dados brutos, como transações ou status da conta, **Esses hashes são somados em pares e iterações, e uma Raiz Merkle pode finalmente ser calculada.

(O registo na parte inferior do diagrama é o conjunto de dados original correspondente ao nó da folha)

A 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 mudará. Portanto, Merkle Trees correspondentes a diferentes conjuntos de dados originais terão diferentes Merkle Roots, assim como pessoas diferentes têm impressões digitais diferentes. A tecnologia de verificação de provas, conhecida como Merkle Proof, tira partido desta propriedade da Merkle Tree.

Por exemplo, se Li Gang só sabe o valor da Raiz de Merkle na figura, ele não sabe quais dados a Árvore Merkle completa contém. Precisamos provar a Li Gang que o Registro 3 está realmente relacionado à raiz na imagem, ou que o hash do Registro 3 existe na árvore Merkle correspondente à raiz.

Só precisamos enviar o Record3 e os 3 blocos de digest marcados como cinza para Li Gang, em vez de comprometer toda a Merkle Tree ou todos os seus nós de folha, que é a simplicidade de Merkle Proof. Quando o registro subjacente da Merkle Tree tem um grande número de folhas, como 2 para a potência de 2 blocos de dados (cerca de 1 milhão), Merkle Proof só precisa conter pelo menos 21 blocos de dados.

(Os blocos 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)**

Em Bitcoin, Ethereum ou pontes de cadeia cruzada, essa “simplicidade” do Merkle Proof é frequentemente usada. O nó de luz que conhecemos é, na verdade, o Li Gang acima mencionado, que só recebe o cabeçalho do bloco do nó completo, não o bloco completo. É importante enfatizar aqui que o Ethereum usa uma árvore Merkle chamada State Trie, que funciona como um resumo de toda a conta. A Raiz Merkle do Trie do Estado, chamada StateRoot, muda sempre que o estado de uma das contas associadas ao Trie do Estado muda.

No cabeçalho do bloco do Ethereum, StateRoot será gravado, e a Raiz Merkle (referida como Txn Root) da árvore de transações também será registrada. Se o bloco 100 contém 300 transações, então as folhas da árvore de negociação representam esses 300 Txn.

Outra diferença é que a quantidade total de dados no State Trie é particularmente grande, e sua folha subjacente corresponde a todos os endereços na cadeia Ethereum (na verdade, existem muitos hashes de estado obsoletos), então o conjunto de dados original correspondente ao State Trie não será publicado no bloco, apenas o StateRoot será 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 da árvore será registrado no cabeçalho do bloco.

Como o nó light recebe apenas o cabeçalho do bloco, só conhece o StateRoot e o TxnRoot, e não pode deduzir a Merkle Tree completa com base na raiz (isso é determinado pela natureza da Merkle Tree e da função hash), o nó light não pode conhecer os dados de transação contidos no bloco, nem sabe quais alterações ocorreram na conta correspondente ao State Trie. **

Se Wang Qiang quiser provar a um nó de luz (Li Gang mencionado anteriormente) que o bloco 100 contém uma determinada transação, e sabe-se que o nó de luz conhece o cabeçalho do bloco 100 e conhece TxnRoot, então o problema acima se traduz em: provar que este Txn existe na árvore Merkle correspondente a TxnRoot. Neste momento, Wang Qiang só precisa apresentar a Prova Merkle correspondente.

Em muitas pontes de cadeia cruzada baseadas em soluções de cliente leve, a leveza e simplicidade dos nós de luz e Merkle Proof mencionados acima são frequentemente usadas. Por exemplo, pontes ZK, como Map Protocol, configurarão um contrato na cadeia ETH para receber cabeçalhos de bloco de outras cadeias (como Polygon). Quando o Relayer envia o cabeçalho do 100º bloco do Polygon para o contrato na cadeia ETH, o contrato verificará a validade do cabeçalho (como se ele tem assinaturas suficientes de 2/3 nós POS na rede Polygon).

Se o cabeçalho for válido e um usuário declarar que iniciou uma cadeia cruzada Txn de Polygon para ETH, o Txn será compactado no 100º bloco de Polygon. Ele só precisa provar através do Merkle Proof que o Txn de cadeia cruzada que ele iniciou pode corresponder ao TxnRoot do cabeçalho do bloco 100 (em outras palavras, ele prova que o Txn de cadeia cruzada que ele iniciou tem um registro no bloco 100 do Polygon). No entanto, a ponte ZK usará provas de conhecimento zero para comprimir a quantidade de computação necessária para verificar o Merkle Proof, reduzindo ainda mais o custo de verificação de contratos de ponte entre cadeias.

Problemas de ataque de retenção de dados e DA

Depois de falar sobre Merkle Tree e Merkle Root e Merkle Proof, vamos voltar ao problema de ataque de retenção de dados e DA mencionado no início do artigo, que foi explorado antes de 2017, e o artigo original de Celestia arqueologizou a origem do problema de DA. Em um documento de 2017~18, o próprio Vitalik falou sobre como os bloqueadores podem deliberadamente ocultar certos fragmentos de dados do bloco e publicar blocos incompletos, de modo que nós completos não possam confirmar a correção da execução da transação/transições de estado.

Neste ponto, o produtor do bloco pode roubar os ativos do usuário, como transferir todas as moedas da conta A para outro endereço, e o nó completo não pode determinar se o próprio A fez isso, porque eles não sabem os dados completos da transação contidos no bloco mais recente.

Em cadeias públicas de Camada 1, como Bitcoin ou Ethereum, nós completos honestos rejeitarão diretamente os blocos inválidos acima. Mas nós leves são diferentes, eles só recebem o cabeçalho de bloco da rede, eles só conhecem o StateRoot e TxnRoot, e eles não sabem se o bloco original correspondente ao cabeçalho e as duas raízes é válido.

No white paper do Bitcoin, há realmente um buraco cerebral para esta situação, Satoshi Nakamoto uma vez acreditou que a maioria dos usuários tenderá 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, e se um bloco for inválido, o nó completo honesto enviará um alarme para o nó de luz.

Mas Satoshi Nakamoto não fez uma análise mais detalhada desta solução, e mais tarde Vitalik e o fundador da Celestia, Mustafa, construíram essa ideia, combinada com o trabalho de outros antecessores, para introduzir a amostragem de dados DA para garantir que nós completos honestos possam restaurar os dados completos de cada bloco e disparar um alarme quando necessário.

Nota: DA Data Sampling (DAS) e Celestia não são o foco deste artigo, os leitores interessados podem ler o artigo anterior do Geek Web3: “Misconceptions about Data Availability: DA= Data Publishing ≠ Historical Data Retrieval”

À prova de fraude da Plasma

Para simplificar, o Plasma é uma solução de dimensionamento que publica apenas cabeçalhos de bloco da Camada 2 na Camada 1, e os dados DA fora do cabeçalho do bloco (conjunto completo de dados de transação/alteração de estado por conta) só são publicados fora da cadeia. Em outras palavras, o Plasma é como uma ponte de cadeia cruzada baseada em clientes leves, implementando um cliente leve de Camada 2 com um contrato na cadeia ETH, e quando um usuário declara que deseja cruzar ativos de L2 para L1, ele deve enviar uma Prova Merkle para provar que realmente possui os ativos.

**A lógica de verificação para ativos que vão de L2 a L1 é semelhante à ponte ZK mencionada acima, exceto que o modelo de ponte Plasma é baseado em provas de fraude em vez de provas ZK, que é mais próximo da chamada “ponte otimista”. **Os pedidos de retirada de L2 para L1 na rede Plasma não são liberados imediatamente, mas têm um “período de desafio”, como para o propósito do período de desafio, explicaremos abaixo.

O plasma não tem requisitos rigorosos para liberação de dados/DA, o sequenciador/operador apenas transmite cada bloco L2 off-chain, e os nós que estão dispostos a obter o bloco L2 o fazem por conta própria. Depois disso, o sequenciador publicará o cabeçalho do bloco L2 na Camada 1. Por exemplo, o sequenciador transmite o bloco 100 off-chain e, em seguida, publica o cabeçalho do bloco on-chain. Se o bloco 100 contiver transações inválidas, qualquer nó de plasma pode enviar uma prova Merkle para o contrato em ETH antes do final do “período de desafio” para provar que o cabeçalho do bloco 100 pode ser associado a uma transação inválida, que é um cenário coberto por provas de fraude.

Os casos de uso à prova de fraude do Plasma também incluem o seguinte:

1. Suponha que o progresso da rede Plasma atinja o bloco 200, e o usuário A inicie uma declaração de retirada, dizendo que ele tem 10 ETH no bloco 100. Mas, na verdade, o usuário A gastou o ETH na conta após o bloqueio 100.

Então, o comportamento de A é, na verdade, gastar 10 ETH, declarar que ele tinha 10 ETH no passado e tentar retirar o ETH. Trata-se do clássico “saque duplo”, gasto duplo. Neste momento, qualquer pessoa pode enviar uma Prova Merkle para provar o status de ativo mais recente do usuário A, e não atende à sua declaração de retirada, ou seja, para provar que A não tinha uma declaração de retirada após o bloco 100 (diferentes esquemas de Plasma têm métodos de prova inconsistentes para essa 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 um esquema Plasma baseado no modelo UTXO (que foi principalmente o caso no passado), não há StateRoot no cabeçalho do bloco, apenas TxnRoot (UTXO não suporta o modelo de endereço de conta no estilo Ethereum, nem tem um design de estado global como State Trie). Em outras palavras, uma cadeia que adota o modelo UTXO tem apenas registros de transações, não registros de estado.

Nesse caso, o próprio sequenciador pode lançar um ataque de gasto duplo, como gastar um UTXO que já foi gasto ou emitir UTXOs adicionais para um usuário do nada. Qualquer usuário pode enviar uma Prova Merkle para provar que o histórico de uso do UTXO apareceu (foi gasto) em blocos anteriores, ou para provar que a origem histórica de um UTXO é questionável. **

3. Para esquemas de Plasma compatíveis com EVM/State-Trie, é possível que o sequenciador envie um StateRoot inválido, por exemplo, depois de executar a transação contida no bloco 100, o StateRoot deve ser convertido para ST+, mas o sequenciador envia ST- para a Camada 1.

Neste caso, a prova de fraude é mais complexa e exige que a transação no bloco 100 seja repetida na cadeia Ethereum, que consome muito gás com a quantidade de parâmetros de cálculo e entrada necessários. É difícil para as primeiras equipes de adoção do Plasma conseguir provas de fraude tão complexas, então a maioria delas usa o modelo UTXO, afinal, as provas de fraude baseadas em UTXO são muito simples e fáceis de implementar (Fuel, o primeiro esquema de Rollup para lançar provas de fraude, é baseado em UTXO)

Retenção de dados e saída do jogo****

É claro que os cenários acima mencionados em que as provas de fraude podem entrar em vigor só são estabelecidos quando a liberação de DA/dados é válida. Se o sequenciador retiver dados e não publicar o bloco completo off-chain, o nó Plasma não poderá confirmar se o cabeçalho do bloco na Camada 1 é válido e, claro, não poderá publicar a prova de fraude sem problemas.

Neste momento, o sequenciador pode roubar os ativos do usuário, como transferir todas as moedas da conta A para a conta B, transferir dinheiro da conta B para C e, finalmente, iniciar um saque em nome de C. As contas B e C são propriedade do sequenciador, e a transferência de B->C é inócua, mesmo que seja divulgada ao público.** Mas o sequenciador pode reter os dados da transferência inválida de A->B, e as pessoas não podem provar que há um problema com a fonte dos ativos de B e C** (para provar que a fonte dos ativos de B é problemática, é necessário salientar que a assinatura digital de “um certo Txn transferido para B” está incorreta).

A solução Plasma baseada em UTXO é alvo do fato de que qualquer pessoa que inicie uma retirada deve enviar o histórico completo do ativo, embora haja mais melhorias mais tarde. No entanto, se for uma solução de plasma compatível com EVM, será fraca nesta área. Porque se o Txn relacionado ao contrato estiver envolvido, haverá um custo enorme na verificação do processo de transição de estado na cadeia, então é difícil implementar um esquema de verificação para a validade dos saques suportando o modelo de endereço de conta e contrato inteligente Plasma.

Além disso, além do tópico acima, seja o Plasma baseado em UTXO ou baseado em modelo de endereço de conta, a retenção de dados pode causar pânico porque você não sabe quais transações o sequenciador está realizando. **Os nós de plasma encontrarão algo errado, mas não poderão publicar provas de fraude porque o sequenciador de plasma não enviará os dados necessários para 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 e não sabem o que os ativos da sua conta se tornaram, então iniciarão coletivamente uma declaração de retirada e tentarão retirar com a Prova Merkle correspondente ao bloqueio histórico, desencadeando um cenário extremo chamado “Exit Game”, que levará a uma “debandada”, que deixará a Camada 1 seriamente congestionada, e ainda fará com que os ativos de algumas pessoas sejam danificados** (As pessoas que não recebem notificações de nó honestas ou não deslizam o Twitter não saberão que o sequenciador está roubando moedas.)

Portanto, o Plasma é uma solução de escalonamento Layer2 não confiável, e uma vez que um ataque de retenção de dados ocorre, ele desencadeará um “Jogo de Saída”, que é fácil para os usuários sofrerem perdas, o que é uma das principais razões para seu abandono. **

Razões pelas quais o plasma é difícil de suportar contratos inteligentes****

Depois de falar sobre o Exit Game e problemas de retenção de dados, vamos ver por que o Plasma é difícil de suportar contratos inteligentes, principalmente por dois motivos:

Primeiro, se for um ativo de um contrato Defi, quem deve retirá-lo para a Camada 1? Porque isso é essencialmente migrar o estado do contrato da Camada 2 para a Camada 1, suponha que alguém cobra 100 ETH para o pool de LP do DEX, e então o sequenciador de Plasma faz o mal, e as pessoas querem 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 parece ser deixar o usuário resgatar os ativos da DEX primeiro, e então o usuário vai retirar o dinheiro para L1 sozinho, mas o problema é que o sequenciador Plasma fez algo ruim e pode rejeitar o pedido do usuário a qualquer momento.

Então, e se configurarmos um proprietário para o contrato DEX com antecedência, permitindo que ele coloque os ativos do contrato em L1 em caso de emergência? Obviamente, isso dará ao proprietário do contrato a propriedade dos bens públicos, e ele pode colocar esses ativos em L1 a qualquer momento e fugir, não seria terrível?

Obviamente, o que fazer com esses “bens públicos” dominados por contratos Defi é um enorme trovão. **Na verdade, isso envolve o problema da distribuição do poder público, sobre o qual Xiangma já falou em entrevista ao “É difícil para as cadeias públicas de alto desempenho fazerem coisas novas, e os contratos inteligentes envolvem a distribuição de energia”.

Em segundo lugar, se o contrato não for autorizado a migrar seu estado, ele sofrerá uma enorme perda, e se o contrato for autorizado a migrar seu estado para a Camada 1, haverá retiradas duplas que são difíceis de resolver com a prova de fraude do Plasma:

Por exemplo, vamos supor que o Plasma adote o modelo de endereço de conta do Ethereum, suporte contratos inteligentes, tenha um misturador de moedas, atualmente deposite 100 ETH e o proprietário do misturador de moedas seja controlado por Bob;

Digamos que Bob retire 50 ETH do misturador no bloco 100. Depois disso, Bob iniciou uma declaração de retirada e cruzou os 50 ETH para a Camada 1;

Depois disso, Bob usa um instantâneo do estado do contrato passado (por exemplo, bloco 70) para migrar o estado passado do misturador para a Camada 1, que também cruzará os 100 ETH que o misturador “já teve” para a Camada 1.

Obviamente, trata-se de um típico “rebaixamento duplo”, que é um gasto duplo. 150 ETH foi mencionado 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. Isto pode facilmente drenar as reservas de plasma. Teoricamente, poder-se-ia iniciar uma prova de fraude para provar que o estado do contrato misturador mudou após o bloco 70.

Mas se você quiser mostrar evidências de que o contrato do Mixer mudou após o Bloco 70, você tem que executar todos os Txn mencionados acima na cadeia Ethereum para finalmente deixar o contrato do Plasma determinar que o estado do contrato do Mixer realmente mudou (a razão pela qual ele é tão complexo é determinada pela própria estrutura do Plasma). Se a quantidade de Txn for tão grande, a prova de fraude não será publicada na Camada 1 (excederá o limite de gás para um único bloco de Ethereum).

Teoricamente, no cenário de gasto duplo acima, parece que você só precisa enviar um instantâneo do estado atual do misturador (que na verdade é a prova Merkle correspondente ao 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 do estado que você envia é válido. **Isso ocorre porque o próprio sequenciador pode iniciar a retenção de dados, enviar instantâneos de status inválidos e apontar maliciosamente qualquer retirada. **

Por exemplo, quando você declara que tem 50 ETH em sua conta e inicia um saque, o sequenciador pode limpar sua conta para 0 e, em seguida, iniciar a retenção de dados, enviar um StateRoot inválido para a cadeia e enviar um instantâneo de estado correspondente para acusá-lo falsamente de ficar sem dinheiro em sua conta. Neste ponto, você não pode provar que o StateRoot e o State Snapshot enviados pelo sequenciador são inválidos, porque ele iniciou a retenção de dados e você não obtém os dados suficientes necessários para provar fraude. **

Para evitar isso, o nó Plasma também reproduz o histórico de transações durante esse período ao apresentar um instantâneo do estado para provar que alguém gastou duas vezes, o que impede que o sequenciador retenha dados para impedir que outros retirem. No Rollup, se você encontrar a retirada dupla acima mencionada, você não precisa repetir a transação histórica em teoria, porque o Rollup não tem o problema de retenção de dados e “forçará” o sequenciador a publicar dados DA na cadeia. **Os sequenciadores de rollup que enviarem um instantâneo StateRoot-state inválido falharão na validação do contrato (ZK Rollup) ou em breve serão desafiados (OP Rollup).

De facto, para além do exemplo do misturador de moedas mencionado acima, cenários como os contratos multi-assinatura também podem levar a levantamentos duplos na rede Plasma. As provas de fraude são ineficientes no tratamento de tais cenários. **Esta situação é analisada na ETH Research.

Resumindo, porque o esquema Plasma não é propício a contratos inteligentes e basicamente não suporta a migração do estado do contrato para a Camada 1, o Plasma convencional tem que escolher UTXO ou mecanismos semelhantes, porque UTXO não tem o problema de conflito de propriedade de ativos, e pode muito bem suportar a prova de fraude (muito menor em tamanho), mas ao custo de um único cenário de aplicação, ele basicamente só pode suportar transferências ou trocas de livro de ordens.

Além disso, como a própria prova de fraude tem uma forte dependência dos dados DA, será difícil obter um sistema eficiente à prova de fraude se a camada DA não for confiável. No entanto, a forma como o Plasma lida com os problemas de DA é muito rudimentar para resolver o problema dos ataques de retenção de dados, e com a ascensão do Rollup, o Plasma lentamente desapareceu da história. **