O paradoxo do triângulo da escalabilidade argumenta que existe uma contradição entre as três características da descentralização, escalabilidade e segurança do blockchain. Não se trata de um teorema rigoroso, mas sim de um argumento matemático heurístico: se um nó amigável à descentralização pode verificar N transações por segundo, e você tem uma cadeia que processa k*N transações por segundo, então ou cada transação só pode ser vista por 1/k dos nós, o que significa que um atacante só precisa comprometer alguns poucos nós para efetuar uma transação maliciosa; ou seus nós se tornarão poderosos, enquanto sua cadeia não se descentraliza.
Durante anos, algumas cadeias de alto desempenho afirmam ter resolvido o triângulo das bermudas sem mudar fundamentalmente a arquitetura, geralmente otimizando nós por meio de técnicas de engenharia de software. Isso é sempre enganoso, pois executar nós nessas cadeias é muito mais difícil do que executar nós no Ethereum.
No entanto, a combinação de amostragem de disponibilidade de dados com SNARKs realmente resolve o paradoxo triangular: permite que os clientes verifiquem que uma certa quantidade de dados está disponível e que uma certa quantidade de etapas de cálculo foi executada corretamente, baixando apenas uma pequena quantidade de dados e realizando um número muito reduzido de cálculos. Os SNARKs são sem necessidade de confiança. A amostragem de disponibilidade de dados possui um modelo de confiança sutil de few-of-N, mas preserva as características fundamentais das cadeias não escaláveis, ou seja, mesmo um ataque de 51% não pode forçar que blocos inválidos sejam aceitos pela rede.
Outra forma de resolver o dilema da trindade é a arquitetura Plasma, que utiliza tecnologia engenhosa para transferir a responsabilidade pela disponibilidade de dados monitorados para os usuários de uma forma compatível com incentivos. Com a popularização dos SNARKs, a arquitetura Plasma tornou-se mais viável para cenários de uso mais amplos do que nunca.
Avanços adicionais na amostragem de disponibilidade de dados
Estamos a resolver que problema?
Em 13 de março de 2024, quando a atualização Dencun for lançada, a blockchain Ethereum terá 3 blobs de aproximadamente 125 kB a cada 12 segundos, ou uma largura de banda de dados disponível de aproximadamente 375 kB por slot. Supondo que os dados das transações sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, o máximo de TPS do Rollup na Ethereum é: 375000 / 12 / 180 = 173,6 TPS.
Se adicionarmos o calldata do Ethereum, isso se torna 607 TPS. Usando PeerDAS, o número de blobs pode aumentar para 8-16, o que proporcionará 463-926 TPS para o calldata.
Esta é uma melhoria significativa para o Ethereum L1, mas não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é de 16 MB por slot, que, se combinado com melhorias na compressão de dados Rollup, resultará em ~58000 TPS.
O que é? Como funciona?
PeerDAS é uma implementação relativamente simples de "1D sampling". No Ethereum, cada blob é um polinômio de grau 4096 sobre um campo primo de 253 bits. Nós transmitimos as partes do polinômio, onde cada parte contém 16 valores de avaliação de 16 coordenadas adjacentes entre um total de 8192 coordenadas. Dentre esses 8192 valores de avaliação, quaisquer 4096 podem recuperar o blob.
O funcionamento do PeerDAS é permitir que cada cliente escute uma pequena quantidade de sub-redes, onde a iésima sub-rede transmite a iésima amostra de qualquer blob e solicita aos pares na rede p2p global os blobs que precisa nas outras sub-redes. A versão mais conservadora, SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais à camada de pares. A proposta atual é que os nós que participam da prova de participação utilizem o SubnetDAS, enquanto os outros nós utilizem o PeerDAS.
Teoricamente, podemos escalar o "1D sampling" para um tamanho considerável: se aumentarmos o número máximo de blobs para 256, conseguiremos atingir a meta de 16MB, onde a amostragem de disponibilidade de dados tem 16 amostras por nó * 128 blobs * 512 bytes por amostra por blob = 1 MB de largura de banda de dados por slot. Isso está apenas dentro do nosso limite de tolerância: é viável, mas significa que clientes com largura de banda limitada não conseguem amostrar. Podemos otimizar isso até certo ponto reduzindo o número de blobs e aumentando o tamanho dos blobs, mas isso aumentará o custo de reconstrução.
Portanto, queremos avançar ainda mais e realizar amostragem 2D, um método que não apenas realiza amostragem aleatória dentro de um blob, mas também entre blobs. Usando as propriedades lineares do compromisso KZG, expandimos o conjunto de blobs em um bloco através de um conjunto de novos blobs virtuais, que codificam redundantemente as mesmas informações.
É crucial que a expansão do compromisso de cálculo não necessite de blob, portanto, essa abordagem é fundamentalmente amigável à construção de blocos distribuídos. Os nós que realmente constroem os blocos só precisam possuir o compromisso KZG do blob, e eles podem confiar na amostragem de disponibilidade de dados para verificar a disponibilidade dos blocos de dados. A amostragem de disponibilidade de dados unidimensional é essencialmente também amigável à construção de blocos distribuídos.
O que mais precisa ser feito? Quais são as compensações?
A próxima etapa é a implementação e lançamento do PeerDAS. Em seguida, aumentar constantemente o número de blobs no PeerDAS, enquanto se observa cuidadosamente a rede e se melhora o software para garantir a segurança, é um processo gradual. Ao mesmo tempo, esperamos que haja mais trabalho acadêmico para regulamentar o PeerDAS e outras versões do DAS, bem como suas interações com questões de segurança, como regras de seleção de forks.
Em estágios mais distantes no futuro, precisamos fazer mais trabalho para determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Também esperamos eventualmente conseguir mudar do KZG para uma alternativa que seja segura contra quântica e não exija uma configuração confiável. Atualmente, ainda não está claro quais candidatos são amigáveis à construção de blocos distribuídos. Mesmo utilizando a cara técnica de "força bruta", ou seja, usando STARK recursivo para gerar provas de validade para a reconstrução de linhas e colunas, não é suficiente para atender à demanda, pois, embora tecnicamente o tamanho de um STARK seja O(log(n) * log(log(n)) hash, na prática, o STARK é quase tão grande quanto todo o blob.
Eu acredito que o caminho de realidade a longo prazo é:
Implementar um DAS 2D ideal;
Continuar a usar 1D DAS, sacrificando a eficiência da largura de banda de amostragem, aceitando um limite inferior de dados em prol da simplicidade e robustez.
Abandonar o DA e aceitar completamente o Plasma como a nossa principal arquitetura Layer2 de foco.
Por favor, note que, mesmo que decidamos expandir diretamente na camada L1, essa opção ainda existe. Isso porque, se a camada L1 tiver que lidar com um grande volume de TPS, os blocos L1 se tornarão muito grandes, e os clientes desejarão ter uma maneira eficiente de verificar sua correção, portanto, teremos que usar a mesma tecnologia que o Rollup na camada L1.
Como interagir com outras partes do roteiro?
Se a compressão de dados for realizada, a demanda por 2D DAS será reduzida, ou pelo menos adiada; se o Plasma for amplamente utilizado, a demanda diminuirá ainda mais. O DAS também apresenta desafios para protocolos e mecanismos de construção de blocos distribuídos: embora o DAS seja teoricamente amigável à reconstrução distribuída, na prática isso necessita ser combinado com a proposta da lista de inclusão de pacotes e seus mecanismos de escolha de bifurcações.
Compressão de Dados
Que problema estamos a resolver?
Cada transação em um Rollup ocupa uma grande quantidade de espaço de dados na cadeia: uma transferência ERC20 requer cerca de 180 bytes. Mesmo com a amostragem ideal de disponibilidade de dados, isso limita a escalabilidade dos protocolos Layer. Cada slot 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se conseguíssemos resolver não apenas o problema do numerador, mas também o problema do denominador, fazendo com que cada transação no Rollup ocupasse menos bytes na cadeia?
O que é, como funciona?
Na minha opinião, a melhor explicação é esta imagem de dois anos atrás:
Na compressão de zeros, substituímos cada sequência longa de zeros por dois bytes que indicam quantos zeros existem. Além disso, aproveitamos as propriedades específicas das transações:
Agregação de Assinaturas: Estamos passando de assinaturas ECDSA para assinaturas BLS. A característica das assinaturas BLS é que várias assinaturas podem ser combinadas em uma única assinatura, que pode provar a validade de todas as assinaturas originais. No nível L1, devido ao alto custo computacional da verificação mesmo com agregação, o uso de assinaturas BLS não é considerado. Mas em um ambiente L2, onde os dados são escassos, faz sentido usar assinaturas BLS. A característica de agregação do ERC-4337 fornece um caminho para implementar essa funcionalidade.
Substituir endereços por ponteiros: se já utilizou um determinado endereço, podemos substituir o endereço de 20 bytes por um ponteiro de 4 bytes que aponta para uma posição na história.
Serialização personalizada de valores de transação------A maioria dos valores de transação tem poucos dígitos, por exemplo, 0,25 ETH é representado como 250.000.000.000.000.000 wei. A taxa base máxima e a taxa de prioridade também são semelhantes. Assim, podemos usar um formato de ponto flutuante decimal personalizado para representar a maioria dos valores monetários.
O que mais precisa ser feito, quais são as compensações?
O próximo passo é implementar a solução acima. As principais compensações incluem:
Mudar para a assinatura BLS requer um grande esforço e diminuirá a compatibilidade com chips de hardware confiáveis que podem aumentar a segurança. Pode-se usar um encapsulamento ZK-SNARK de outros esquemas de assinatura como substituto.
2, compressão dinâmica ( por exemplo, substituir endereços ) por pointers tornará o código do cliente mais complexo.
Publicar as diferenças de estado na cadeia em vez de transações reduzirá a auditabilidade e fará com que muitos softwares (, como exploradores de blocos ), não funcionem.
Como interagir com outras partes do roteiro?
A adoção do ERC-4337 e a inclusão de parte de seu conteúdo no EVM do L2 podem acelerar significativamente a implementação da tecnologia de agregação. Colocar parte do conteúdo do ERC-4337 no L1 pode acelerar sua implementação no L2.
Plasma Generalizado
Estamos a resolver que problema?
Mesmo com blobs de 16 MB e compressão de dados, 58.000 TPS pode não ser suficiente para atender completamente às necessidades de pagamentos dos consumidores, redes sociais descentralizadas ou outras áreas de alta largura de banda, especialmente quando começamos a considerar fatores de privacidade, o que pode reduzir a escalabilidade em 3 a 8 vezes. Para cenários de aplicações com alto volume de transações e baixo valor, uma opção atualmente é usar Validium, que mantém os dados fora da cadeia e adota um modelo de segurança interessante: os operadores não podem roubar os fundos dos usuários, mas podem congelar temporariamente ou permanentemente os fundos de todos os usuários. Mas podemos fazer melhor.
O que é, como funciona?
Plasma é uma solução de escalabilidade que envolve um operador publicando blocos fora da cadeia e colocando as raízes Merkle desses blocos na cadeia. Para cada bloco, o operador enviará um ramo Merkle a cada usuário para provar o que aconteceu ou não aconteceu com os ativos desse usuário. Os usuários podem retirar seus ativos fornecendo o ramo Merkle. É importante que esse ramo não precise ter como raiz o estado mais recente. Portanto, mesmo que haja problemas de disponibilidade de dados, os usuários ainda podem recuperar seus ativos retirando seu estado mais recente disponível. Se um usuário enviar um ramo inválido, a legitimidade da propriedade dos ativos pode ser determinada pelo mecanismo de desafio na cadeia.
As versões iniciais do Plasma só conseguiam lidar com casos de pagamento, não podendo ser efetivamente ampliadas. No entanto, se exigirmos que cada raiz seja verificada com SNARK, então o Plasma se tornará muito mais poderoso. Cada jogo de desafio pode ser significativamente simplificado,
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
6 Curtidas
Recompensa
6
6
Repostar
Compartilhar
Comentário
0/400
AltcoinMarathoner
· 9h atrás
estou no crypto desde 2016... escalar não é uma corrida rápida, é uma ultra maratona. eth ainda principal do grupo fr
Ver originalResponder0
BoredApeResistance
· 15h atrás
Quando é que o Layer 2 vai ser implementado, ai?
Ver originalResponder0
NeverVoteOnDAO
· 08-10 19:10
Outra vez a falar dessas baboseiras, o nó não consegue funcionar.
Ver originalResponder0
FancyResearchLab
· 08-10 18:58
Valor académico bombear, fui fazer um pequeno experimento.
Ver originalResponder0
BlockchainThinkTank
· 08-10 18:51
Não importa o quão elaborado seja, os dados nunca mentem, sugiro que os idiotas fiquem a observar as mudanças.
Ver originalResponder0
FudVaccinator
· 08-10 18:44
O paradoxo tríplice não pode ser evitado, devemos enfrentá-lo.
Ethereum The Surge: superar os limites de escalabilidade
O futuro do Ethereum: The Surge
Paradoxo da Tríade da Escalabilidade
O paradoxo do triângulo da escalabilidade argumenta que existe uma contradição entre as três características da descentralização, escalabilidade e segurança do blockchain. Não se trata de um teorema rigoroso, mas sim de um argumento matemático heurístico: se um nó amigável à descentralização pode verificar N transações por segundo, e você tem uma cadeia que processa k*N transações por segundo, então ou cada transação só pode ser vista por 1/k dos nós, o que significa que um atacante só precisa comprometer alguns poucos nós para efetuar uma transação maliciosa; ou seus nós se tornarão poderosos, enquanto sua cadeia não se descentraliza.
Durante anos, algumas cadeias de alto desempenho afirmam ter resolvido o triângulo das bermudas sem mudar fundamentalmente a arquitetura, geralmente otimizando nós por meio de técnicas de engenharia de software. Isso é sempre enganoso, pois executar nós nessas cadeias é muito mais difícil do que executar nós no Ethereum.
No entanto, a combinação de amostragem de disponibilidade de dados com SNARKs realmente resolve o paradoxo triangular: permite que os clientes verifiquem que uma certa quantidade de dados está disponível e que uma certa quantidade de etapas de cálculo foi executada corretamente, baixando apenas uma pequena quantidade de dados e realizando um número muito reduzido de cálculos. Os SNARKs são sem necessidade de confiança. A amostragem de disponibilidade de dados possui um modelo de confiança sutil de few-of-N, mas preserva as características fundamentais das cadeias não escaláveis, ou seja, mesmo um ataque de 51% não pode forçar que blocos inválidos sejam aceitos pela rede.
Outra forma de resolver o dilema da trindade é a arquitetura Plasma, que utiliza tecnologia engenhosa para transferir a responsabilidade pela disponibilidade de dados monitorados para os usuários de uma forma compatível com incentivos. Com a popularização dos SNARKs, a arquitetura Plasma tornou-se mais viável para cenários de uso mais amplos do que nunca.
Avanços adicionais na amostragem de disponibilidade de dados
Estamos a resolver que problema?
Em 13 de março de 2024, quando a atualização Dencun for lançada, a blockchain Ethereum terá 3 blobs de aproximadamente 125 kB a cada 12 segundos, ou uma largura de banda de dados disponível de aproximadamente 375 kB por slot. Supondo que os dados das transações sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, o máximo de TPS do Rollup na Ethereum é: 375000 / 12 / 180 = 173,6 TPS.
Se adicionarmos o calldata do Ethereum, isso se torna 607 TPS. Usando PeerDAS, o número de blobs pode aumentar para 8-16, o que proporcionará 463-926 TPS para o calldata.
Esta é uma melhoria significativa para o Ethereum L1, mas não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é de 16 MB por slot, que, se combinado com melhorias na compressão de dados Rollup, resultará em ~58000 TPS.
O que é? Como funciona?
PeerDAS é uma implementação relativamente simples de "1D sampling". No Ethereum, cada blob é um polinômio de grau 4096 sobre um campo primo de 253 bits. Nós transmitimos as partes do polinômio, onde cada parte contém 16 valores de avaliação de 16 coordenadas adjacentes entre um total de 8192 coordenadas. Dentre esses 8192 valores de avaliação, quaisquer 4096 podem recuperar o blob.
O funcionamento do PeerDAS é permitir que cada cliente escute uma pequena quantidade de sub-redes, onde a iésima sub-rede transmite a iésima amostra de qualquer blob e solicita aos pares na rede p2p global os blobs que precisa nas outras sub-redes. A versão mais conservadora, SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais à camada de pares. A proposta atual é que os nós que participam da prova de participação utilizem o SubnetDAS, enquanto os outros nós utilizem o PeerDAS.
Teoricamente, podemos escalar o "1D sampling" para um tamanho considerável: se aumentarmos o número máximo de blobs para 256, conseguiremos atingir a meta de 16MB, onde a amostragem de disponibilidade de dados tem 16 amostras por nó * 128 blobs * 512 bytes por amostra por blob = 1 MB de largura de banda de dados por slot. Isso está apenas dentro do nosso limite de tolerância: é viável, mas significa que clientes com largura de banda limitada não conseguem amostrar. Podemos otimizar isso até certo ponto reduzindo o número de blobs e aumentando o tamanho dos blobs, mas isso aumentará o custo de reconstrução.
Portanto, queremos avançar ainda mais e realizar amostragem 2D, um método que não apenas realiza amostragem aleatória dentro de um blob, mas também entre blobs. Usando as propriedades lineares do compromisso KZG, expandimos o conjunto de blobs em um bloco através de um conjunto de novos blobs virtuais, que codificam redundantemente as mesmas informações.
É crucial que a expansão do compromisso de cálculo não necessite de blob, portanto, essa abordagem é fundamentalmente amigável à construção de blocos distribuídos. Os nós que realmente constroem os blocos só precisam possuir o compromisso KZG do blob, e eles podem confiar na amostragem de disponibilidade de dados para verificar a disponibilidade dos blocos de dados. A amostragem de disponibilidade de dados unidimensional é essencialmente também amigável à construção de blocos distribuídos.
O que mais precisa ser feito? Quais são as compensações?
A próxima etapa é a implementação e lançamento do PeerDAS. Em seguida, aumentar constantemente o número de blobs no PeerDAS, enquanto se observa cuidadosamente a rede e se melhora o software para garantir a segurança, é um processo gradual. Ao mesmo tempo, esperamos que haja mais trabalho acadêmico para regulamentar o PeerDAS e outras versões do DAS, bem como suas interações com questões de segurança, como regras de seleção de forks.
Em estágios mais distantes no futuro, precisamos fazer mais trabalho para determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Também esperamos eventualmente conseguir mudar do KZG para uma alternativa que seja segura contra quântica e não exija uma configuração confiável. Atualmente, ainda não está claro quais candidatos são amigáveis à construção de blocos distribuídos. Mesmo utilizando a cara técnica de "força bruta", ou seja, usando STARK recursivo para gerar provas de validade para a reconstrução de linhas e colunas, não é suficiente para atender à demanda, pois, embora tecnicamente o tamanho de um STARK seja O(log(n) * log(log(n)) hash, na prática, o STARK é quase tão grande quanto todo o blob.
Eu acredito que o caminho de realidade a longo prazo é:
Por favor, note que, mesmo que decidamos expandir diretamente na camada L1, essa opção ainda existe. Isso porque, se a camada L1 tiver que lidar com um grande volume de TPS, os blocos L1 se tornarão muito grandes, e os clientes desejarão ter uma maneira eficiente de verificar sua correção, portanto, teremos que usar a mesma tecnologia que o Rollup na camada L1.
Como interagir com outras partes do roteiro?
Se a compressão de dados for realizada, a demanda por 2D DAS será reduzida, ou pelo menos adiada; se o Plasma for amplamente utilizado, a demanda diminuirá ainda mais. O DAS também apresenta desafios para protocolos e mecanismos de construção de blocos distribuídos: embora o DAS seja teoricamente amigável à reconstrução distribuída, na prática isso necessita ser combinado com a proposta da lista de inclusão de pacotes e seus mecanismos de escolha de bifurcações.
Compressão de Dados
Que problema estamos a resolver?
Cada transação em um Rollup ocupa uma grande quantidade de espaço de dados na cadeia: uma transferência ERC20 requer cerca de 180 bytes. Mesmo com a amostragem ideal de disponibilidade de dados, isso limita a escalabilidade dos protocolos Layer. Cada slot 16 MB, obtemos:
16000000 / 12 / 180 = 7407 TPS
E se conseguíssemos resolver não apenas o problema do numerador, mas também o problema do denominador, fazendo com que cada transação no Rollup ocupasse menos bytes na cadeia?
O que é, como funciona?
Na minha opinião, a melhor explicação é esta imagem de dois anos atrás:
Na compressão de zeros, substituímos cada sequência longa de zeros por dois bytes que indicam quantos zeros existem. Além disso, aproveitamos as propriedades específicas das transações:
Agregação de Assinaturas: Estamos passando de assinaturas ECDSA para assinaturas BLS. A característica das assinaturas BLS é que várias assinaturas podem ser combinadas em uma única assinatura, que pode provar a validade de todas as assinaturas originais. No nível L1, devido ao alto custo computacional da verificação mesmo com agregação, o uso de assinaturas BLS não é considerado. Mas em um ambiente L2, onde os dados são escassos, faz sentido usar assinaturas BLS. A característica de agregação do ERC-4337 fornece um caminho para implementar essa funcionalidade.
Substituir endereços por ponteiros: se já utilizou um determinado endereço, podemos substituir o endereço de 20 bytes por um ponteiro de 4 bytes que aponta para uma posição na história.
Serialização personalizada de valores de transação------A maioria dos valores de transação tem poucos dígitos, por exemplo, 0,25 ETH é representado como 250.000.000.000.000.000 wei. A taxa base máxima e a taxa de prioridade também são semelhantes. Assim, podemos usar um formato de ponto flutuante decimal personalizado para representar a maioria dos valores monetários.
O que mais precisa ser feito, quais são as compensações?
O próximo passo é implementar a solução acima. As principais compensações incluem:
2, compressão dinâmica ( por exemplo, substituir endereços ) por pointers tornará o código do cliente mais complexo.
Como interagir com outras partes do roteiro?
A adoção do ERC-4337 e a inclusão de parte de seu conteúdo no EVM do L2 podem acelerar significativamente a implementação da tecnologia de agregação. Colocar parte do conteúdo do ERC-4337 no L1 pode acelerar sua implementação no L2.
Plasma Generalizado
Estamos a resolver que problema?
Mesmo com blobs de 16 MB e compressão de dados, 58.000 TPS pode não ser suficiente para atender completamente às necessidades de pagamentos dos consumidores, redes sociais descentralizadas ou outras áreas de alta largura de banda, especialmente quando começamos a considerar fatores de privacidade, o que pode reduzir a escalabilidade em 3 a 8 vezes. Para cenários de aplicações com alto volume de transações e baixo valor, uma opção atualmente é usar Validium, que mantém os dados fora da cadeia e adota um modelo de segurança interessante: os operadores não podem roubar os fundos dos usuários, mas podem congelar temporariamente ou permanentemente os fundos de todos os usuários. Mas podemos fazer melhor.
O que é, como funciona?
Plasma é uma solução de escalabilidade que envolve um operador publicando blocos fora da cadeia e colocando as raízes Merkle desses blocos na cadeia. Para cada bloco, o operador enviará um ramo Merkle a cada usuário para provar o que aconteceu ou não aconteceu com os ativos desse usuário. Os usuários podem retirar seus ativos fornecendo o ramo Merkle. É importante que esse ramo não precise ter como raiz o estado mais recente. Portanto, mesmo que haja problemas de disponibilidade de dados, os usuários ainda podem recuperar seus ativos retirando seu estado mais recente disponível. Se um usuário enviar um ramo inválido, a legitimidade da propriedade dos ativos pode ser determinada pelo mecanismo de desafio na cadeia.
As versões iniciais do Plasma só conseguiam lidar com casos de pagamento, não podendo ser efetivamente ampliadas. No entanto, se exigirmos que cada raiz seja verificada com SNARK, então o Plasma se tornará muito mais poderoso. Cada jogo de desafio pode ser significativamente simplificado,