Agradecimentos especiais a Karl Floersch, Georgios Konstantopoulos e Martin Koppelmann pelo feedback, revisão e discussão.

O Plasma é uma classe de soluções de dimensionamento de blockchain que permite que todos os dados e cálculos, exceto depósitos, retiradas e raízes de Merkle, sejam mantidos fora da cadeia. Isso abre a porta para ganhos de escalabilidade muito grandes que não são prejudicados pela disponibilidade de dados na cadeia. O Plasma foi inventado pela primeira vez em 2017 e teve muitas iterações em 2018, principalmente o Minimal Viable Plasma, o Plasma Cash, o Plasma Cashflow e o Plasma Prime. Infelizmente, desde então, o Plasma foi amplamente substituído pelos rollups, principalmente por motivos relacionados a (i) grandes custos de armazenamento de dados no lado do cliente e (ii) limitações fundamentais do Plasma que o tornam <a href="https://medium.com/@kelvinfichter/why-is-evm-on-plasma-hard-bf2d99c48df7"> difícil de generalizar além dos pagamentos.

O advento das provas de validade (também conhecidas como ZK-SNARKs) nos dá um motivo para repensar essa decisão. O maior desafio de fazer o Plasma funcionar para pagamentos, o armazenamento de dados no lado do cliente, pode ser resolvido de forma eficiente com provas de validade. Além disso, as provas de validade fornecem uma ampla gama de ferramentas que nos permitem criar uma cadeia semelhante à do Plasma que executa um EVM. As garantias de segurança do Plasma não abrangeriam todos os usuários, pois as razões fundamentais por trás da impossibilidade de estender os jogos de saída no estilo do Plasma a muitos tipos de aplicativos complexos ainda permanecem. No entanto, uma porcentagem muito grande de ativos poderia, na prática, ser mantida em segurança.

Esta postagem descreve como as ideias do Plasma podem ser estendidas para fazer isso.

Visão geral: como o Plasma funciona

A versão mais simples do Plasma para entender é o Plasma Cash. O Plasma Cash funciona tratando cada moeda individual como um NFT separado e rastreando um histórico separado para cada moeda. Uma cadeia Plasma tem um operador, que é responsável por criar e publicar blocos regularmente. As transações em cada bloco são armazenadas como uma árvore Merkle esparsa: se uma transação transfere a propriedade da moeda k, ela aparece na posição k da árvore. Quando o operador da cadeia do Plasma cria um novo bloco, ele publica a raiz da árvore de Merkle na cadeia e envia diretamente a cada usuário os ramos de Merkle correspondentes às moedas que esse usuário possui.

Suponha que essas sejam as três últimas árvores de transações em uma cadeia Plasma Cash. Então, supondo que todas as árvores anteriores sejam válidas, sabemos que Eva atualmente possui a moeda 1, David possui a moeda 4 e George possui a moeda 6.

O principal risco em qualquer sistema de plasma é o mau comportamento do operador. Isso pode ocorrer de duas maneiras:

1. Publicação de um bloco inválido (por exemplo, o operador inclui uma transação que envia a moeda 1 de Fred para Hermione, mesmo que Fred não possua a moeda naquele momento)
2. Publicação de um bloco indisponível (por exemplo, o operador não envia a Bob seu ramo Merkle para um dos blocos, impedindo-o de provar a outra pessoa que sua moeda ainda é válida e não foi gasta)

Se a operadora se comportar de maneira inadequada e relevante para os ativos do usuário, ele terá a responsabilidade de sair imediatamente (especificamente, dentro de 7 dias). Quando um usuário ("o exiter") sai, ele fornece um ramo Merkle que comprova a inclusão da transação que transferiu a moeda do proprietário anterior para ele. Isso inicia um período de desafio de 7 dias, durante o qual outras pessoas podem desafiar essa saída fornecendo uma prova de Merkle de uma das três coisas:

1. Não é o último proprietário: uma transação posterior assinada pelo ex-executor que transfere a moeda do ex-executor para outra pessoa
2. Gasto duplo: uma transação que transferiu a moeda do proprietário anterior para outra pessoa, que foi incluída antes da transação que transferiu a moeda para o ex-proprietário
3. Histórico inválido: uma transação que transferiu as moedas anteriormente (nos últimos 7 dias) e que não tem um gasto correspondente. O exiter pode responder fornecendo o gasto correspondente; se não o fizer, o exit falha.

Com essas regras, qualquer pessoa que possua a moeda k precisa ver todos os ramos Merkle da posição k em todas as árvores históricas da última semana para ter certeza de que realmente possui a moeda k e pode sair dela. Eles precisam armazenar todas as filiais que contêm transferências do ativo, para que possam responder aos desafios e sair com segurança com sua moeda.

Generalização para tokens fungíveis

O projeto acima funciona para NFTs. No entanto, muito mais comuns do que os NFTs são os tokens fungíveis, como ETH e USDC. Uma maneira de aplicar o Plasma Cash a tokens fungíveis é simplesmente fazer com que cada pequena denominação de uma moeda (por exemplo, o 0,01 ETH) em um NFT separado. Infelizmente, os custos de gasolina para sair seriam muito altos se fizéssemos isso.

Uma solução é otimizar, tratando muitas moedas adjacentes como uma única unidade, que pode ser transferida ou retirada de uma só vez. Há duas maneiras de fazer isso:

1. Use o Plasma Cash quase como está, mas use algoritmos sofisticados para calcular a árvore de Merkle de um número realmente grande de objetos muito rapidamente se muitos objetos adjacentes forem iguais. Surpreendentemente, isso não é tão difícil de fazer; o senhor pode ver uma implementação em python aqui.
2. Use o Plasma Cashflow, que simplesmente representa várias moedas adjacentes como um único objeto.

No entanto, ambas as abordagens esbarram no problema da fragmentação: se o senhor receber 0,001 ETH de centenas de pessoas que estão comprando cafés do senhor, terá 0,001 ETH em muitos lugares da árvore e, portanto, a saída real desse ETH ainda exigiria o envio de muitas saídas separadas, tornando as taxas de gás proibitivas. Os protocolos de desfragmentação foram desenvolvidos, mas são difíceis de implementar.

Como alternativa, podemos reprojetar o sistema para levar em conta um modelo mais tradicional de "saída de transação não gasta" (UTXO). Ao sair de uma moeda, o senhor precisaria fornecer a última semana do histórico dessas moedas, e qualquer pessoa poderia contestar sua saída provando que essas moedas históricas já haviam saído.

Um saque do UTXO de 0,2 ETH no canto inferior direito pode ser cancelado ao mostrar um saque de qualquer um dos UTXOs em seu histórico, mostrado em verde. Observe especialmente que os UTXOs do meio à esquerda e da parte inferior à esquerda são ancestrais, mas o UTXO da parte superior à esquerda não é. Essa abordagem é semelhante às ideias de coloração baseadas em ordem dos protocolos de moedas coloridas por volta de 2013.

Há uma grande variedade de técnicas para fazer isso. Em todos os casos, o objetivo é rastrear alguma concepção do que é "a mesma moeda" em diferentes momentos da história, a fim de evitar que "a mesma moeda" seja sacada duas vezes.

Desafios da generalização para EVM

Infelizmente, generalizar além dos pagamentos para o EVM é muito mais difícil. Um dos principais desafios é que muitos objetos de estado no EVM não têm um "proprietário" claro. A segurança do Plasma depende do fato de cada objeto ter um proprietário, que tem a responsabilidade de observar e garantir que os dados da cadeia estejam disponíveis e de sair desse objeto se algo der errado. Muitos aplicativos Ethereum, no entanto, não funcionam dessa forma. Os pools de liquidez Uniswap, por exemplo, não têm um único proprietário.

Outro desafio é que o EVM não tenta limitar as dependências. A ETH mantida na conta A no bloco N poderia ter vindo de qualquer lugar no bloco N-1. Para sair de um estado consistente, uma cadeia EVM Plasma precisaria ter um jogo de saída em que, no caso extremo, alguém que desejasse sair usando informações do bloco N poderia precisar pagar as taxas para publicar todo o estado do bloco N na cadeia: um custo de gás de muitos milhões de dólares. Os esquemas de plasma baseados em UTXO não têm esse problema: cada usuário pode sair de seus ativos a partir de qualquer bloco mais recente para o qual tenha os dados.

Um terceiro desafio é que as dependências ilimitadas no EVM tornam muito mais difícil ter incentivos alinhados para provar a validade. A validade de qualquer estado depende de todo o resto e, portanto, provar qualquer coisa requer provar tudo. A classificação de falhas em uma situação como essa geralmente não pode ser compatível com incentivos devido ao problema de disponibilidade de dados. Um problema particularmente incômodo é que perdemos a garantia, presente nos sistemas baseados em UTXO, de que o estado de um objeto não pode ser alterado sem o consentimento de seu proprietário. Essa garantia é incrivelmente útil, pois significa que o proprietário está sempre ciente do último estado comprovado de seus ativos e simplifica os jogos de saída. Sem isso, criar jogos de saída se torna muito mais difícil.

Como as provas de validade podem aliviar muitos desses problemas

A coisa mais básica que as provas de validade podem fazer para melhorar os projetos de cadeias de Plasma é provar a validade de cada bloco de Plasma na cadeia. Isso simplifica muito o espaço de design: significa que o único ataque do operador com o qual temos que nos preocupar são os blocos indisponíveis, e não os blocos inválidos. No Plasma Cash, por exemplo, ele elimina a necessidade de se preocupar com desafios históricos. Isso reduz o estado que um usuário precisa baixar, de uma ramificação por bloco na última semana, para uma ramificação por ativo.

Além disso, as retiradas do estado mais recente (no caso comum em que o operador é honesto, todas as retiradas seriam do estado mais recente) não estão sujeitas a contestações do proprietário não mais recente e, portanto, em uma cadeia de plasma com validade comprovada, essas retiradas não estariam sujeitas a nenhuma contestação. Isso significa que, em casos normais, os saques podem ser instantâneos!

Extensão para o EVM: gráficos UTXO paralelos

No caso do EVM, as provas de validade também nos permitem fazer algo inteligente: elas podem ser usadas para implementar um gráfico UTXO paralelo para tokens ETH e ERC20, e o SNARK prova a equivalência entre o gráfico UTXO e o estado EVM. Quando o senhor tiver isso, poderá implementar um sistema de plasma "regular" sobre o gráfico UTXO.

Isso nos permite contornar muitas das complexidades do EVM. Por exemplo, o fato de que, em um sistema baseado em contas, alguém pode editar sua conta sem o seu consentimento (enviando-lhe moedas e, assim, aumentando seu saldo) não importa, porque a construção do Plasma não é sobre o estado do EVM em si, mas sobre um estado UTXO que vive em paralelo ao EVM, em que todas as moedas que o senhor recebe seriam objetos separados.

Extensão para o EVM: saída total do estado

Já foram propostos esquemas mais simples para criar um "EVM de plasma", por exemplo. Plasma Free e, antes disso, esta postagem de 2019. Nesses esquemas, qualquer pessoa pode enviar uma mensagem no L1 para forçar a operadora a incluir uma transação ou disponibilizar uma determinada agência do estado. Se o operador não fizer isso, a cadeia começará a reverter os blocos. A cadeia para de ser revertida quando alguém publica uma cópia completa de todo o estado ou, pelo menos, de todos os dados que os usuários sinalizaram como potencialmente ausentes. Para fazer uma retirada, pode ser necessário publicar uma recompensa, que pagaria a parte do usuário nos custos de gás de alguém que publica uma quantidade tão grande de dados.

Esquemas como esse têm a desvantagem de não permitir saques instantâneos no caso normal, porque sempre há a possibilidade de a cadeia precisar reverter o estado mais recente.

Limites dos esquemas de plasma EVM

Esquemas como esse são poderosos, mas NÃO são capazes de fornecer garantias de segurança total a todos os usuários. O caso em que eles falham mais claramente é nas situações em que um determinado objeto estatal não tem um "proprietário" econômico claro.

Vamos considerar o caso de um CDP (collateralized debt position), um contrato inteligente em que um usuário tem moedas que são bloqueadas e só podem ser liberadas quando o usuário pagar sua dívida. Suponha que esse usuário tenha 1 ETH (~$ 2.000 no momento em que este artigo foi escrito) preso em um CDP com 1.000 DAI de dívida. Agora, a cadeia Plasma para de publicar blocos e o usuário se recusa a sair. O usuário simplesmente nunca poderia sair. Agora, o usuário tem uma opção livre: se o preço da ETH cair abaixo de US$ 1.000, ele vai embora e esquece a CDP e, se o preço da ETH permanecer acima, ele poderá reivindicá-la. Em média, esse usuário mal-intencionado ganha dinheiro com isso.

Outro exemplo é um sistema de privacidade, por exemplo. Tornado Cash ou Privacy Pools. Considere um sistema de privacidade com cinco depositantes:

Os ZK-SNARKs no sistema de privacidade mantêm oculto o vínculo entre o proprietário de uma moeda que entra no sistema e o proprietário da moeda que sai.

Suponha que apenas a laranja tenha se retirado e que, nesse momento, o operador da cadeia Plasma pare de publicar dados. Suponha também que usemos a abordagem de gráfico UTXO com uma regra de primeiro a entrar, primeiro a sair, de modo que cada moeda seja combinada com a moeda logo abaixo dela. Então, a laranja poderia retirar sua moeda pré-misturada e pós-misturada, e o sistema a perceberia como duas moedas separadas. Se a azul tentar retirar sua moeda pré-misturada, o estado mais recente da laranja a substituirá; enquanto isso, a azul não terá a informação para retirar sua moeda pós-misturada.

Isso pode ser resolvido se o senhor permitir que os outros quatro depositantes retirem o próprio contrato de privacidade (que substituiria os depósitos) e, em seguida, retire as moedas em L1. No entanto, a implementação efetiva desse mecanismo exige um esforço adicional por parte das pessoas que desenvolvem o sistema de privacidade.

Há também outras maneiras de resolver a privacidade, por exemplo, a abordagem Intmax, que envolve a colocação de alguns bytes em cadeia no estilo rollup, juntamente com um operador do tipo Plasma que transmite informações entre usuários individuais.

As posições Uniswap LP têm um problema semelhante: se o senhor trocou USDC por ETH em uma posição Uniswap, poderá tentar retirar seu USDC pré-negociação e seu ETH pós-negociação. Se o senhor for conivente com o operador da cadeia Plasma, os provedores de liquidez e outros usuários não terão acesso ao estado pós-negociação, portanto, não poderão retirar seu USDC pós-negociação. Seria necessária uma lógica especial para evitar situações como essa.

Conclusões

Em 2023, o Plasma é um espaço de design subestimado. Os rollups continuam sendo o padrão ouro e têm propriedades de segurança inigualáveis. Isso é particularmente verdadeiro do ponto de vista da experiência do desenvolvedor: nada se compara à simplicidade de um desenvolvedor de aplicativos que não precisa sequer pensar em gráficos de propriedade e fluxos de incentivo em seu aplicativo.

No entanto, o Plasma nos permite contornar completamente a questão da disponibilidade de dados, reduzindo consideravelmente as taxas de transação. O plasma pode ser uma atualização de segurança significativa para cadeias que, de outra forma, seriam validiums. O fato de os ZK-EVMs estarem finalmente se tornando realidade este ano é uma excelente oportunidade para explorar novamente esse espaço de design e criar construções ainda mais eficazes para simplificar a experiência do desenvolvedor e proteger os fundos dos usuários.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de[vitalik], Todos os direitos autorais pertencem ao autor original[Vitalik Buterin]. Se houver alguma objeção a essa reimpressão, entre em contato com a equipe do Gate Learn, que tratará do assunto imediatamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são de responsabilidade exclusiva do autor e não constituem consultoria de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.