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

Plasma permite-nos contornar completamente o problema da 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, levantamentos e raízes de Merkle) permaneçam fora da cadeia. Isto abre a porta para uma escalabilidade massiva 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) elevados custos de armazenamento de dados do lado do cliente e (ii) limitações fundamentais do Plasma que dificultam a sua aplicação para além de pagamentos, o Plasma foi em grande parte substituído pelos rollups.

 

O surgimento das provas de validade (também conhecidas como ZK-SNARKs) dá-nos motivos para reconsiderar esta decisão. O maior desafio para que o Plasma funcione em pagamentos, o armazenamento de dados do lado do cliente, pode ser resolvido de forma eficaz com provas de validade. Além disso, as provas de validade fornecem um conjunto de ferramentas que nos permitem criar cadeias tipo Plasma que executam EVM. As garantias de segurança do Plasma não cobrem todos os utilizadores, pois as razões fundamentais que dificultam a extensão do mecanismo de saída do Plasma para muitas aplicações complexas ainda persistem. No entanto, na prática, ainda é possível proteger uma proporção muito grande de ativos.

 

Abaixo, detalharei como o Plasma consegue isso.

 

Visão geral: Como funciona o Plasma

A versão mais simples do Plasma a compreender é 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 de 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, publica a raiz da árvore de Merkle na cadeia e envia diretamente a cada utilizador o ramo de Merkle correspondente aos tokens que 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 comportamento impróprio do operador. Isto pode acontecer de duas formas:

 

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 esse token naquele momento);

 

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

 

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

 

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

 

2. Duplo gasto: uma transação que transfere o token do proprietário anterior para outra pessoa, incluída antes da transação que transfere o token para o utilizador que está a sair;

 

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

 

 

De acordo com estas regras, qualquer pessoa que possua o token k precisa de ver todos os ramos de 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. Precisa de armazenar todos os ramos que contêm transferências de ativos, para poder responder a desafios e sair com segurança dos seus tokens.

 

Extensão para tokens fungíveis

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

 

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

 

1. Usar o Plasma Cash quase como está, mas calcular rapidamente a árvore de Merkle de muitos objetos usando algoritmos complexos, se muitos objetos adjacentes forem iguais. Surpreendentemente, isto não é difícil de fazer; 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, ambos os métodos enfrentam o problema da fragmentação: se receber 0,001 ETH de centenas de pessoas ao comprar café, terá 0,001 ETH em muitos lugares diferentes na árvore, pelo que sair efetivamente desses ETH ainda exigirá muitas saídas separadas, tornando as taxas de gás demasiado altas. 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ídas de transações não gastas" (UTXO). Ao sair com um token, é necessário fornecer o histórico desse token da última semana, e qualquer pessoa pode desafiar a sua saída provando que esses tokens já foram retirados.

 

 

O levantamento do UTXO de 0,2 ETH no canto inferior direito pode ser cancelado mostrando o levantamento de qualquer um dos UTXOs no seu histórico, como indicado a verde na imagem. Note-se especialmente que os UTXOs do meio-esquerda e do fundo-esquerda são ancestrais, mas o do topo-esquerda não é. Este método é semelhante à ideia de coloração baseada em sequência dos protocolos de colored coins por volta de 2013.

 

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

 

Desafios para generalizar ao EVM

Infelizmente, generalizar isto para além de pagamentos no EVM é 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, que é responsável por monitorizar e garantir a disponibilidade dos dados na cadeia, e sair desse objeto se houver algum problema. No entanto, muitas aplicações 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 limitar dependências. No bloco N, o ETH detido 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 onde, no caso extremo, alguém que queira sair com informações do bloco N pode ter de pagar para publicar todo o estado do bloco N na cadeia: um custo de até vários milhões de dólares. Os esquemas Plasma baseados em UTXO não têm este problema: cada utilizador pode sair com os seus ativos a partir 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 resto, por isso provar qualquer coisa requer provar tudo. Neste cenário, devido ao problema da disponibilidade de dados, normalmente não é possível tornar a resolução de falhas compatível com incentivos. Um problema particularmente irritante é que perdemos a garantia existente nos sistemas baseados em UTXO de que o estado de um objeto não pode ser alterado sem o consentimento do proprietário. Esta garantia é muito útil porque significa que o proprietário sabe sempre o estado mais recente comprovável dos seus ativos, simplificando o mecanismo de saída. Sem ela, criar um mecanismo de saída torna-se muito mais difícil.

 

Como as provas de validade mitigam estes problemas

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

 

Além disso, levantamentos do estado mais recente (no caso comum de operadores honestos, todos os levantamentos serão do estado mais recente) não estão sujeitos a desafios de não ser o proprietário mais recente, por isso, em cadeias Plasma com provas de validade, tais levantamentos não são desafiados de todo. Isto significa que, em condições normais, os levantamentos podem ser feitos imediatamente.

 

Generalização para EVM: Gráfico UTXO paralelo

No caso do EVM, as provas de validade também nos permitem fazer coisas inteligentes: podem ser usadas para implementar um gráfico UTXO paralelo 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 se tenha isto, pode-se implementar um sistema Plasma "convencional" sobre o gráfico UTXO.

 

 

Isto permite-nos contornar muitas das complexidades do EVM. Por exemplo, num sistema baseado em contas, alguém pode editar a sua conta sem o seu consentimento (enviando tokens para si, aumentando o saldo), mas isto não importa porque o Plasma não é construído sobre o estado EVM em si, mas sim sobre um estado UTXO paralelo ao EVM, onde qualquer token que receba será um objeto independente.

 

Generalização para EVM: Saída de estado completo

Já foram propostas soluções mais simples para criar um "Plasma EVM", como o Plasma Free e, antes disso, este artigo de 2019. Nestes esquemas, qualquer pessoa pode enviar uma mensagem na 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 o fizer, 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 utilizadores marcaram como possivelmente em falta, a cadeia para de reverter. Para realizar levantamentos, pode ser necessário publicar uma recompensa, que pagará a parte do gás de cada utilizador para publicar tantos dados.

 

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

 

Limitações dos esquemas Plasma EVM

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

 

Vejamos o caso de um CDP (posição de dívida colateralizada), um contrato inteligente onde os utilizadores bloqueiam tokens que só podem ser libertados após o reembolso da dívida. Suponha que um utilizador bloqueou 1 ETH num CDP (cerca de 2000 dólares à data deste artigo) e tem uma dívida de 1000 DAI. Agora, a cadeia Plasma para de publicar blocos e o utilizador recusa-se a sair. O utilizador pode simplesmente nunca sair. Agora, o utilizador tem uma opção gratuita: se o preço do ETH cair abaixo de 1000 dólares, ele abandona o CDP; se o preço do ETH se mantiver acima de 1000 dólares, eventualmente ele reclama. Em média, um utilizador malicioso lucraria com isto.

 

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á levantou, e então o operador da cadeia Plasma para de publicar dados. Supondo que usamos o método do gráfico UTXO com regra FIFO, cada token corresponde ao token abaixo. Assim, o laranja pode levantar os seus tokens pré-mixados e pós-mixados, e o sistema tratará ambos como tokens independentes. Se o azul tentar levantar o seu token pré-mixado, o estado atualizado do laranja irá substituí-lo; ao mesmo tempo, o azul não terá informação para levantar o seu token pós-mixado.

 

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

 

Existem outras formas de resolver problemas de privacidade, como o método Intmax, que envolve colocar alguns bytes na cadeia ao estilo rollup, e um operador tipo Plasma que transmite informações entre os utilizadores.

 

As posições de LP da Uniswap têm problemas semelhantes: se trocar ETH por USDC numa posição Uniswap, pode tentar levantar o seu USDC antes da troca e o ETH depois da troca. Se conspirar com o operador da cadeia Plasma, os provedores de liquidez e outros utilizadores não terão acesso ao estado pós-troca, pelo que não poderão levantar o seu USDC pós-troca. É necessária lógica especial para evitar que isto aconteça.

 

Conclusão

Mesmo em 2023, Plasma continua a ser um design subestimado. Os rollups continuam a ser o padrão de ouro e possuem propriedades de segurança inigualáveis. Isto é especialmente verdade do ponto de vista da experiência do desenvolvedor: nada supera a simplicidade de o desenvolvedor da aplicação nem sequer precisar de pensar no grafo de propriedade e nos fluxos de incentivos da sua aplicação.

 

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

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