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

Plasma é uma classe de soluções de escalonamento de blockchain que permite que todos os dados e computação, exceto depósitos, levantamentos e raízes Merkle, sejam mantidos fora da cadeia. Isto abre a porta a ganhos de escalabilidade muito grandes que não são estrangulados pela disponibilidade de dados na cadeia. O Plasma foi inventado pela primeira vez em 2017 e viu muitas iterações em 2018, nomeadamente o Minimal Viable Plasma, o Plasma Cash, o Plasma Cashflow e o Plasma Prime. Infelizmente, o Plasma foi desde então largamente ultrapassado pelos rollups, por razões que se prendem principalmente com (i) grandes custos de armazenamento de dados do 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 para além dos pagamentos.

O advento das provas de validade (também conhecidas como ZK-SNARKs) dá-nos uma razão para repensar esta decisão. O maior desafio para que o Plasma funcione para pagamentos, o armazenamento de dados do lado do cliente, pode ser resolvido de forma eficiente com provas de validade. Além disso, as provas de validade fornecem uma vasta gama de ferramentas que nos permitem criar uma cadeia do tipo Plasma que executa um EVM. As garantias de segurança do Plasma não abrangeriam todos os utilizadores, pois as razões fundamentais da impossibilidade de alargar os jogos de saída ao estilo do Plasma a muitos tipos de aplicações complexas ainda se mantêm. No entanto, uma percentagem muito elevada de activos poderia, na prática, ser mantida em segurança.

Esta publicação descreve como as ideias do Plasma podem ser alargadas para fazer tal coisa.

Descrição geral: como funciona o plasma

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

Suponha que estas são as três últimas árvores de transacções numa cadeia Plasma Cash. Então, assumindo que todas as árvores anteriores são válidas, sabemos que a Eva possui atualmente a moeda 1, o David possui a moeda 4 e o Jorge possui a moeda 6.

O principal risco em qualquer sistema de plasma é o mau comportamento do operador. Isto pode acontecer de duas formas:

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

Se o operador se comportar mal de uma forma que seja relevante para os bens de um utilizador, este tem a responsabilidade de sair imediatamente (especificamente, no prazo de 7 dias). Quando um utilizador ("o exiter") sai, fornece um ramo Merkle que prova a inclusão da transação que transferiu essa moeda do anterior proprietário para ele. Isto dá início a um período de contestação de 7 dias, durante o qual outros podem contestar essa saída fornecendo uma prova Merkle de uma de 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 anterior proprietário para outra pessoa, que foi incluída antes da transação que transferiu a moeda para o anterior 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, a saída falha.

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

Generalização para fichas fungíveis

A conceção acima funciona para os NFT. No entanto, muito mais comuns do que os NFTs são os tokens fungíveis, como o ETH e o USDC. Uma forma de aplicar o Dinheiro de Plasma a fichas fungíveis é simplesmente fazer com que cada pequena denominação de uma moeda (por exemplo. 0,01 ETH) num NFT separado. Infelizmente, os custos de combustível para sair seriam demasiado elevados se o fizéssemos.

Uma solução consiste em otimizar o tratamento de muitas moedas adjacentes como uma única unidade, que pode ser transferida ou retirada de uma só vez. Há duas formas de o fazer:

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, isto não é assim tão difícil de fazer; pode ver uma implementação em python aqui.
2. Utilize o Plasma Cashflow, que representa simplesmente muitas moedas adjacentes como um único objeto.

No entanto, ambas as abordagens esbarram no problema da fragmentação: se receber 0,001 ETH de centenas de pessoas que lhe compram cafés, terá 0,001 ETH em muitos locais da árvore e, por isso, a saída desse ETH exigiria a apresentação 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.

Em alternativa, podemos redesenhar o sistema para ter em conta um modelo mais tradicional de "saída de transação não gasta" (UTXO). Quando sai de uma moeda, tem de fornecer a última semana do historial dessas moedas e qualquer pessoa pode contestar a sua saída provando que essas moedas históricas já saíram.

Uma retirada do UTXO de 0,2 ETH no canto inferior direito pode ser cancelada mostrando uma retirada de qualquer um dos UTXOs no seu histórico, mostrado a verde. Note, em particular, que os UTXOs do meio-esquerdo e da base são ancestrais, mas o UTXO do topo esquerdo não é. Esta abordagem é semelhante às ideias de coloração baseadas na ordem dos protocolos de moedas coloridas por volta de 2013.

Existe uma grande variedade de técnicas para o fazer. Em todos os casos, o objetivo é seguir uma certa conceção do que é "a mesma moeda" em diferentes momentos da história, a fim de evitar que "a mesma moeda" seja retirada duas vezes.

Desafios da generalização à EVM

Infelizmente, é muito mais difícil generalizar para além dos pagamentos para o EVM. Um dos principais desafios é que muitos objectos de estado no EVM não têm um "proprietário" claro. A segurança do Plasma depende de cada objeto ter um proprietário, que tem a responsabilidade de vigiar e garantir que os dados da cadeia estão disponíveis, e de sair desse objeto se alguma coisa correr mal. Muitas aplicações Ethereum, no entanto, não funcionam desta forma. Os pools de liquidez Uniswap, por exemplo, não têm um único proprietário.

Outro desafio é o facto de a EVM não tentar limitar as dependências. O ETH mantido 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 teria de ter um jogo de saída em que, no caso extremo, alguém que desejasse sair utilizando informações do bloco N poderia ter de pagar as taxas para publicar todo o estado do bloco N na cadeia: um custo de gás na ordem dos muitos milhões de dólares. Os esquemas de Plasma baseados em UTXO não têm este problema: cada utilizador pode sair dos seus activos a partir do bloco mais recente para o qual tem os dados.

Um terceiro desafio é o facto de as dependências ilimitadas da EVM tornarem muito mais difícil a existência de incentivos alinhados para provar a validade. A validade de qualquer estado depende de tudo o resto e, por isso, provar qualquer coisa requer provar tudo. Em geral, não é possível compatibilizar as falhas numa situação destas com os incentivos, devido ao problema da disponibilidade dos 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 mudar sem o consentimento do seu proprietário. Esta garantia é extremamente útil, pois significa que o proprietário está sempre ciente do último estado comprovável dos seus activos e simplifica os jogos de saída. Sem ele, a criação de jogos de saída torna-se muito mais difícil.

Como as provas de validade podem aliviar muitos destes problemas

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

Além disso, os levantamentos do estado mais recente (no caso comum em que o operador é honesto, todos os levantamentos seriam do estado mais recente) não estão sujeitos a desafios do não-proprietário mais recente, pelo que, numa cadeia de Plasma com validade comprovada, esses levantamentos não estariam sujeitos a quaisquer desafios. Isto significa que, no caso normal, os levantamentos podem ser imediatos!

Extensão ao EVM: gráficos UTXO paralelos

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

Isto permite-nos contornar muitas das complexidades da EVM. Por exemplo, o facto de, num sistema baseado em contas, alguém poder editar a sua conta sem o seu consentimento (enviando-lhe moedas e aumentando assim o seu saldo) não importa, porque a construção Plasma não é sobre o estado EVM em si, mas sim sobre um estado UTXO que vive em paralelo com o EVM, onde quaisquer moedas que receba seriam objectos separados.

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

Foram propostos esquemas mais simples para criar uma "EVM de plasma", por exemplo. Plasma Free e, antes disso, este post de 2019. Nestes esquemas, qualquer pessoa pode enviar uma mensagem no L1 para forçar o operador a incluir uma transação ou a disponibilizar um determinado ramo do Estado. Se o operador não o fizer, a cadeia começa a reverter blocos. A cadeia deixa de ser revertida quando alguém publica uma cópia completa de todo o estado ou, pelo menos, de todos os dados que os utilizadores assinalaram como estando potencialmente em falta. Para fazer uma retirada pode ser necessário publicar uma recompensa, que pagaria a parte desse utilizador nos custos de gás de alguém que publica uma quantidade tão grande de dados.

Esquemas como este têm a desvantagem de não permitirem levantamentos instantâneos no caso normal, porque existe sempre a possibilidade de a cadeia ter de reverter o estado mais recente.

Limites dos sistemas de plasma EVM

Esquemas como este são poderosos, mas NÃO são capazes de fornecer garantias de segurança completas a todos os utilizadores. O caso em que estas falhas são mais evidentes é o das situações em que um determinado objeto estatal não tem um "proprietário" económico claro.

Consideremos o caso de um CDP (collateralized debt position), um contrato inteligente em que um utilizador tem moedas que estão bloqueadas e só podem ser libertadas quando o utilizador pagar a sua dívida. Suponha que o utilizador tem 1 ETH (~$2000 no momento em que este artigo foi escrito) bloqueado num CDP com 1000 DAI de dívida. Agora, a cadeia Plasma deixa de publicar blocos e o utilizador recusa-se a sair. O utilizador pode simplesmente nunca sair. Agora, o utilizador tem uma opção livre: se o preço do ETH descer abaixo de $1000, vai-se embora e esquece o CDP, e se o preço do ETH se mantiver acima, acaba por reclamá-lo. Em média, um utilizador malicioso ganha dinheiro com isto.

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 oculta a ligação entre o proprietário de uma moeda que entra no sistema e o proprietário da moeda que sai.

Suponha que apenas a laranja se retirou e que, nessa altura, o operador da cadeia Plasma deixa de publicar dados. Suponha também que utilizamos a abordagem do grafo UTXO com uma regra "primeiro a entrar, primeiro a sair", de modo a que cada moeda seja emparelhada com a moeda imediatamente abaixo dela. Depois, a laranja poderia levantar a sua moeda pré-misturada e pós-misturada, e o sistema considerá-la-ia como duas moedas separadas. Se azul tentar retirar a sua moeda pré-misturada, o estado mais recente de laranja substituí-la-á; entretanto, azul não terá a informação para retirar a sua moeda pós-misturada.

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

Existem também outras formas de resolver a questão da privacidade, por exemplo, a abordagem Intmax, que consiste em colocar alguns bytes em cadeia ao estilo rollup, juntamente com um operador do tipo Plasma que transmite informações entre utilizadores individuais.

As posições Uniswap LP têm um problema semelhante: se trocou USDC por ETH numa posição Uniswap, pode tentar retirar o seu USDC pré-negociação e o seu ETH pós-negociação. Se você colidir com o operador da cadeia Plasma, os fornecedores de liquidez e outros utilizadores não terão acesso ao estado pós-negociação, pelo que não poderão retirar os seus USDC pós-negociação. Seria necessária uma lógica especial para evitar situações como esta.

Conclusões

Em 2023, o Plasma é um espaço de design subestimado. Os rollups continuam a ser a norma de ouro e têm propriedades de segurança que não podem ser igualadas. Isto é particularmente verdadeiro do ponto de vista da experiência do programador: nada pode igualar a simplicidade de um programador de aplicações que nem sequer tem de pensar em gráficos de propriedade e fluxos de incentivos dentro da sua aplicação.

No entanto, o Plasma permite-nos contornar completamente a questão da disponibilidade dos dados, reduzindo consideravelmente as taxas de transação. O plasma pode constituir uma melhoria significativa da segurança para as cadeias que, de outro modo, seriam validiums. O facto de os ZK-EVMs estarem finalmente a ser concretizados este ano constitui uma excelente oportunidade para voltar a explorar este espaço de conceção e apresentar construções ainda mais eficazes para simplificar a experiência do programador e proteger os fundos dos utilizadores.

Declaração de exoneração de responsabilidade：

1. Este artigo foi reimpresso de[vitalik], Todos os direitos de autor pertencem ao autor original[Vitalik Buterin]. Se houver objecções a esta reimpressão, contacte a equipa da Gate Learn, que tratará prontamente do assunto.
2. Declaração de exoneração de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são da exclusiva responsabilidade do autor e não constituem um conselho de investimento.
3. As traduções do artigo para outras línguas são efectuadas pela equipa Gate Learn. A menos que seja mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.