Artigo longo de Vitalik: O jogo de saída dos EVM Validiums e o retorno do Plasma

Plasma nos permite contornar completamente o problema de disponibilidade de dados, reduzindo significativamente as taxas de transação.

Autor: Vitalik Buterin

Tradução: jk, Odaily

 

Plasma é uma classe de soluções de escalabilidade para blockchain que permite que todos os dados e computações (exceto depósitos, saques e raízes de Merkle) permaneçam off-chain. Isso abre caminho para uma escalabilidade massiva que não é limitada pela disponibilidade de dados on-chain. Plasma foi proposto pela primeira vez em 2017 e passou por várias iterações em 2018, especialmente o Plasma mínimo viável, Plasma Cash, Plasma Cashflow e Plasma Prime. Infelizmente, devido a (i) altos custos de armazenamento de dados do lado do cliente e (ii) limitações fundamentais do Plasma que dificultam sua aplicação além de pagamentos, o Plasma foi amplamente substituído pelos rollups.

 

O surgimento das provas de validade (também conhecidas como ZK-SNARKs) nos dá motivos para reconsiderar essa decisão. O maior desafio para o Plasma funcionar em pagamentos, o armazenamento de dados do lado do cliente, pode ser efetivamente resolvido com provas de validade. Além disso, as provas de validade fornecem uma série de ferramentas que nos permitem criar cadeias tipo Plasma que executam EVM. As garantias de segurança do Plasma não cobrem todos os usuários, pois as razões fundamentais que dificultam a extensão do mecanismo de saída do Plasma para muitos aplicativos complexos ainda existem. No entanto, na prática, ainda é possível proteger uma proporção muito grande de ativos.

 

A seguir, detalharei como o Plasma consegue isso.

 

Visão geral: Como o Plasma funciona

A versão mais simples do Plasma a ser entendida é o Plasma Cash. O Plasma Cash funciona tratando cada token individual como um NFT independente e rastreando um histórico separado para cada token. A cadeia Plasma tem um operador responsável por criar e publicar blocos periodicamente. As transações em cada bloco são armazenadas como uma árvore Merkle esparsa: se uma transação transfere a propriedade do token k, ela aparece na posição k da árvore. Quando o operador da cadeia Plasma cria um novo bloco, ele publica a raiz da árvore Merkle na cadeia e envia diretamente para cada usuário o ramo Merkle correspondente aos tokens que eles possuem.

 

 

Suponha que estas sejam as três últimas árvores de transações na cadeia Plasma Cash. Então, assumindo que todas as árvores anteriores são válidas, sabemos que Eve atualmente possui o token 1, David possui o token 4 e George possui o token 6.

 

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

 

1. Publicar um bloco inválido (por exemplo, o operador inclui uma transação que transfere o token 1 de Fred para Hermione, mesmo que Fred não possua mais esse token);

 

2. Publicar um bloco indisponível (por exemplo, o operador não envia um dos ramos Merkle para Bob, impedindo-o de provar a outros que seu token ainda é válido e não foi gasto).

 

Se o comportamento do operador estiver relacionado aos ativos do usuário, cabe ao usuário sair imediatamente (especificamente, dentro de 7 dias). Quando um usuário ("exiting") faz uma saída, ele fornece um ramo Merkle que prova a inclusão da transação que transferiu o token do proprietário anterior para ele. Isso inicia um período de desafio de 7 dias, durante o qual outros podem desafiar a saída fornecendo uma das três provas Merkle:

 

1. Não é o proprietário mais recente: uma transação subsequente assinada pelo exiting transferindo o token para outra pessoa;

 

2. Duplo gasto: uma transação transferindo o token do proprietário anterior para outra pessoa, incluída antes da transação que transferiu o token para o exiting;

 

3. Histórico inválido: uma transação transferindo o token nos últimos 7 dias sem o gasto correspondente. O exiting pode responder fornecendo o gasto correspondente; se não o fizer, a saída falha.

 

 

De acordo com essas regras, qualquer pessoa que possua o token k precisa ver todos os ramos Merkle na posição k de todas as árvores históricas da última semana para garantir que realmente possui o token k e pode sair com ele. Eles precisam armazenar todos os ramos que contêm transferências de ativos para que possam responder a desafios e sair com segurança de seus tokens.

 

Expandindo para tokens fungíveis

O design acima funciona para tokens não fungíveis (NFTs). No entanto, tokens fungíveis como ETH e USDC são mais comuns do que NFTs. Uma maneira de aplicar Plasma Cash a tokens fungíveis é tratar cada pequena denominação de token (por exemplo, 0,01 ETH) como um NFT separado. Infelizmente, se fizermos isso, as taxas de gas para saída serão muito altas.

 

Uma solução é otimizar o processamento de muitos tokens adjacentes como uma unidade, permitindo transferências ou saídas em lote. Existem duas maneiras de fazer isso:

 

1. Usar o Plasma Cash quase como está, mas com algoritmos complexos para calcular rapidamente a árvore Merkle de muitos objetos, se muitos objetos adjacentes forem iguais. Surpreendentemente, isso não é tão difícil; você pode ver uma implementação em Python aqui.

 

2. Usar o Plasma Cashflow, que simplesmente representa muitos tokens adjacentes como um único objeto.

 

No entanto, ambas as abordagens enfrentam o problema de fragmentação: se você receber 0,001 ETH de centenas de pessoas ao comprar café, terá 0,001 ETH em muitos lugares da árvore, então sair com esses ETH ainda exigirá muitas saídas separadas, tornando o custo de gas muito alto. Protocolos de defragmentação já foram desenvolvidos, mas são difíceis de implementar.

 

Outra abordagem é redesenhar o sistema considerando o modelo tradicional de "saída de transação não gasta" (UTXO). Ao sair com um token, você precisa fornecer o histórico desse token da última semana, e qualquer pessoa pode desafiar sua saída provando que esses tokens já foram retirados.

 

 

O saque do UTXO de 0,2 ETH no canto inferior direito pode ser cancelado mostrando o saque de qualquer um dos UTXOs em seu histórico, como mostrado em verde. Observe especialmente que os UTXOs do meio esquerdo e inferior esquerdo são ancestrais, mas o UTXO superior esquerdo não é. Essa abordagem é semelhante à ideia de coloração baseada em ordem dos protocolos de colored coins por volta de 2013.

 

Existem várias técnicas para alcançar isso. Em todos os casos, o objetivo é rastrear algum conceito de "mesmo token" em diferentes pontos da história para evitar que o "mesmo token" seja retirado duas vezes.

 

Desafios para expandir ao EVM

Infelizmente, expandir isso para o EVM além de pagamentos é muito mais difícil. Um desafio fundamental é que muitos objetos 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 responsável por monitorar e garantir a disponibilidade dos dados on-chain e sair com o objeto em caso de problemas. No entanto, muitos aplicativos Ethereum não funcionam assim. Por exemplo, pools de liquidez Uniswap não têm um único proprietário.

 

Outro desafio é que o EVM não tenta restringir dependências. No bloco N, o ETH mantido na conta A pode vir de qualquer lugar do bloco N-1. Para sair de um estado consistente, uma cadeia Plasma EVM precisaria de um mecanismo de saída em que, no caso extremo, alguém que queira sair com informações do bloco N pode ter que pagar para publicar todo o estado do bloco N na cadeia: um custo de milhões de dólares. Os esquemas Plasma baseados em UTXO não têm esse problema: cada usuário pode sair com seus ativos do bloco mais recente para o qual possui dados.

 

O terceiro desafio é que as dependências infinitas no EVM dificultam a existência de incentivos consistentes para provar a validade. A validade de qualquer estado depende de tudo o mais, então provar qualquer coisa requer provar tudo. Nessa situação, devido ao problema de disponibilidade de dados, geralmente não é possível tornar a resolução de falhas compatível com incentivos. Um problema particularmente irritante é 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 do proprietário. Essa garantia é muito útil porque significa que o proprietário sempre sabe o estado mais recente comprovável de seus ativos e simplifica o mecanismo de saída. Sem ela, criar um mecanismo de saída se torna muito mais difícil.

 

Como as provas de validade aliviam esses problemas

A função mais básica das provas de validade é provar on-chain a validade de cada bloco Plasma. Isso simplifica muito o espaço de design: significa que só precisamos nos preocupar com ataques de blocos indisponíveis do operador, não com blocos inválidos. Por exemplo, no Plasma Cash, isso elimina preocupações com desafios históricos. Isso reduz o estado que os usuários precisam baixar de um ramo por bloco da última semana para um ramo por ativo.

 

Além disso, saques do estado mais recente (no caso comum de operadores honestos, todos os saques serão do estado mais recente) não estão sujeitos a desafios de não proprietário mais recente, então em uma cadeia Plasma com provas de validade, esses saques não terão nenhum desafio. Isso significa que, em condições normais, os saques podem ser feitos imediatamente.

 

Expandindo para EVM: gráfico UTXO paralelo

No caso do EVM, as provas de validade também nos permitem fazer coisas inteligentes: elas podem ser usadas para implementar gráficos UTXO paralelos para ETH e tokens ERC 20, e provar com SNARK a equivalência entre o gráfico UTXO e o estado EVM. Uma vez que você tem isso, pode implementar um sistema Plasma "convencional" no gráfico UTXO.

 

 

Isso nos permite contornar muitas das complexidades do EVM. Por exemplo, em sistemas baseados em contas, alguém pode editar sua conta sem seu consentimento (enviando tokens para você e aumentando seu saldo), mas isso não importa porque a construção do Plasma não é feita no estado EVM em si, mas sim no estado UTXO paralelo ao EVM, onde qualquer token que você receber será um objeto independente.

 

Expandindo para EVM: saída de estado completo

Já existem propostas mais simples para criar um "Plasma EVM", como o Plasma Free, e antes disso, este artigo de 2019. Nesses esquemas, qualquer pessoa pode enviar uma mensagem no L1 forçando o operador a incluir uma transação ou tornar um ramo de estado específico disponível. Se o operador não fizer isso, a cadeia começa a reverter blocos. Assim que alguém publica uma cópia completa do estado, ou pelo menos todos os dados que os usuários marcaram como possivelmente ausentes, a cadeia para de reverter. Realizar saques pode exigir a publicação de recompensas, que pagam a parte do usuário nas taxas de gas para publicar tantos dados.

 

Esquemas como esse têm uma fraqueza: eles não permitem saques instantâneos em condições normais, pois sempre pode ser necessário reverter o estado mais recente.

 

Limitações dos esquemas Plasma EVM

Esses esquemas são poderosos, mas não podem fornecer garantias de segurança completas para todos os usuários. O caso de falha mais óbvio é quando objetos de estado específicos não têm um "proprietário" econômico claro.

 

Vamos considerar o caso de um CDP (posição de dívida colateralizada), um contrato inteligente onde os usuários bloqueiam tokens que só podem ser liberados após o pagamento da dívida. Suponha que um usuário bloqueie 1 ETH em um CDP (cerca de 2.000 dólares no momento da redação deste texto) e tenha uma dívida de 1.000 DAI. Agora, a cadeia Plasma para de publicar blocos e o usuário se recusa a sair. O usuário pode simplesmente nunca sair. Agora, o usuário tem uma opção gratuita: se o preço do ETH cair abaixo de 1.000 dólares, ele abandona o CDP; se o preço do ETH permanecer acima de 1.000 dólares, eventualmente ele reivindica. Em média, um usuário malicioso lucraria com isso.

 

Outro exemplo são sistemas de privacidade, como Tornado Cash ou Privacy Pools. Considere um sistema de privacidade com cinco depositantes:

 

 

Os ZK-SNARKs em sistemas de privacidade mantêm oculta a ligação entre o proprietário dos tokens que entram e o proprietário dos tokens que saem do sistema.

 

Suponha que apenas o laranja já tenha sacado, e então o operador da cadeia Plasma para de publicar dados. Suponha que usamos o método do gráfico UTXO com regra FIFO, então cada token corresponde ao token abaixo dele. O laranja pode sacar seus tokens pré-mix e pós-mix, e o sistema os tratará como dois tokens independentes. Se o azul tentar sacar seus tokens pré-mix, o estado atualizado do laranja irá substituí-los; ao mesmo tempo, o azul não terá informações para sacar seus tokens pós-mix.

 

Se você permitir que os outros quatro depositantes saquem do próprio contrato de privacidade (o que substituiria o depósito) e depois retirem os tokens no L1, esse problema pode ser resolvido. No entanto, implementar tal mecanismo na prática exige esforço adicional dos desenvolvedores do sistema de privacidade.

 

Existem outras maneiras de resolver o problema de privacidade, como o método Intmax, que envolve colocar alguns bytes on-chain no estilo rollup e um operador tipo Plasma transmitindo informações entre os usuários.

 

As posições de LP da Uniswap têm problemas semelhantes: se você negociou ETH por USDC em uma posição Uniswap, pode tentar sacar seu USDC antes da negociação e o ETH após a negociação. Se você conspirar 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, então não poderão sacar seu USDC pós-negociação. Lógica especial é necessária para evitar esse tipo de situação.

 

Conclusão

Mesmo em 2023, Plasma ainda é um design subestimado. Os rollups continuam sendo o padrão ouro e possuem propriedades de segurança incomparáveis. Isso é especialmente verdadeiro do ponto de vista da experiência do desenvolvedor: nada supera a simplicidade de o desenvolvedor de aplicativos nem precisar considerar o gráfico de propriedade e o fluxo de incentivos em seu aplicativo.

 

No entanto, Plasma nos permite contornar completamente o problema de disponibilidade de dados, reduzindo significativamente as taxas de transação. Para cadeias que seriam validiums, Plasma pode ser uma grande atualização de segurança. ZK-EVMs finalmente se tornaram realidade este ano, o que nos dá uma excelente oportunidade para reexplorar esse espaço de design e propor maneiras mais eficientes de construir, simplificando a experiência do desenvolvedor e protegendo os fundos dos usuários.

Agradecimentos especiais a Karl Floersch, Georgios Konstantopoulos e Martin Koppelmann pelas contribuições em feedback, revisão e discussões.