Novo artigo de Vitalik: O futuro e os desafios do ZK-EVM

Título original: “Como seria um “ZK-EVM consagrado”?”

Autor original: Vitalik

Compilação original: Luccy, BlockBeats

*Nota do editor: Em 13 de dezembro, Vitalik Buterin, cofundador da ETH Place, publicou um artigo que aprofundou a possível implementação da “ZK-EVM” (Zero-Knowledge Ethereum Virtual Machine) e discutiu o design de diferentes versões da ZK-EVM. *

*O conceito ZK-EVM da Vitalik visa reduzir a duplicação de recursos do protocolo Ethereum por projetos de Camada 2 e melhorar sua eficiência na validação de blocos Ethereum de Camada 1. O artigo aponta que os protocolos EVM de camada 2 atuais (como Optimistic Rollups e ZK Rollups) dependem de mecanismos de verificação EVM, mas isso também significa que eles devem confiar em uma grande base de código. Quando houver uma vulnerabilidade na base de código, essas máquinas virtuais podem correr o risco de serem atacadas. *

*Além disso, ele mencionou o suporte para “quase-EVM”, que permite que VMs L2 usem ZK-EVM dentro do protocolo com apenas pequenas diferenças do EVM, enquanto também fornece flexibilidade para alguma personalização do EVM. *

Os protocolos EVM de camada 2 em ETH, incluindo rollups operacionais e rollups ZK, dependem da validação EVM. No entanto, isso exige que eles confiem em uma grande base de código e, se esse estoque de código estiver na brecha, essas VMs correm o risco de serem hackeadas. Além disso, mesmo os ZK-EVMs, que querem ser totalmente equivalentes ao EVM L1, precisam de alguma forma de governança para replicar as mudanças do EVM L1 em suas próprias implementações de EVM.

Esta situação não é ideal, pois esses projetos estão replicando a funcionalidade que já existe no protocolo ETH Fang, e a governança ETH Fang já é responsável por atualizar e corrigir bugs: ZK-EVM basicamente faz o mesmo trabalho que validar blocos ETH L1! Além disso, nos próximos anos, esperamos que os clientes leves se tornem cada vez mais poderosos e, em breve, validem totalmente a execução do L1 ETH Fang usando ZK-SNARKs. Neste ponto, a rede ETH terá efetivamente um ZK-EVM integrado. Então surge a pergunta: por que não disponibilizar essa localização ZK-EVM para o projeto de rollup?

Este artigo irá descrever várias versões possíveis do “consagrado ZK-EVM” e explorar as compensações e desafios de design, bem como as razões para não escolher uma direção específica. As vantagens da implementação de recursos de protocolo devem ser ponderadas em relação aos benefícios deixados ao ecossistema e aos benefícios de manter o protocolo subjacente simples.

Quais são os principais atributos que podemos esperar do ZK-EVM que está consagrado como padrão?

Função básica: Validar blocos ETH. O recurso de protocolo (que ainda é incerto se é opcode, pré-compilação ou algum outro mecanismo) deve pelo menos aceitar a raiz pré-estado, bloco e raiz pós-estado como entrada, e verificar se a raiz pós-estado é realmente o resultado da execução de um bloco em cima da raiz pré-estado.

Compatibilidade com o conceito multi-cliente ETH. Isso significa que queremos evitar a busca por um único sistema de certificação e, em vez disso, permitir que clientes diferentes usem sistemas de certificação diferentes. Isto, por sua vez, significa alguns pontos:

· Requisitos de disponibilidade de dados: Para qualquer execução de EVM que use as provas ZK-EVM consagradas, queremos ser capazes de garantir que os dados subjacentes sejam utilizáveis para que os provadores que usam um sistema de atestado diferente possam reatestar a execução, e os clientes que confiam nesse sistema de atestado possam validar essas provas recém-geradas.

· A prova existe fora da estrutura de dados do EVM e do bloco: O recurso ZK-EVM não usa diretamente SNARKs como entrada dentro do EVM, pois diferentes clientes esperam diferentes tipos de SNARKs. Em vez disso, pode ser semelhante à validação de blob: as transações podem conter instruções que precisam ser comprovadas (pré-estado, corpo do bloco, pós-estado), cujo conteúdo pode ser acessado por opcodes ou pré-compilações, e as regras de consenso do lado do cliente verificarão a disponibilidade de dados e a existência de provas para cada declaração feita no bloco, respectivamente.

Auditabilidade. Se alguma execução for comprovada, queremos que os dados subjacentes sejam utilizáveis para que, no caso de algo dar errado, os usuários e desenvolvedores possam inspecioná-los. Na prática, isso acrescenta outra razão para a importância dos requisitos de disponibilidade de dados.

Capacidade de atualização. Se encontrarmos uma vulnerabilidade em uma determinada solução ZK-EVM, queremos ser capazes de corrigi-la rapidamente. Isso significa que não há necessidade de um hard fork para consertá-lo. Isso acrescenta outra razão para provar a importância de existir fora do EVM e bloquear estruturas de dados.

Redes que suportam quase EVM. Um dos atrativos do L2 é a capacidade de inovar a camada de execução e escalar o EVM. Se a máquina virtual (VM) de um determinado L2 é apenas ligeiramente diferente do EVM, seria bom se L2 ainda pudesse usar o mesmo protocolo nativo ZK-EVM que o EVM, confiando apenas em seu próprio código para as mesmas partes do EVM e seu próprio código para partes diferentes. Isso pode ser alcançado projetando um recurso ZK-EVM que permite que o chamador especifique alguns opcodes, endereços ou campos de bits que são manipulados por uma tabela fornecida externamente, em vez de pelo EVM em si. Também podemos tornar os custos do gás abertos à personalização até certo ponto.

Sistemas multi-cliente “abertos” e “fechados”

O “conceito multi-cliente” é provavelmente o requisito mais afirmado nesta lista. Há a opção de abandonar essa ideia e se concentrar em uma solução ZK-SNARK, que simplificará o design, mas ao custo de uma “mudança filosófica” maior no ETH Workshop (pois isso seria na verdade um desvio da filosofia multicliente de longo prazo do ETH Workshop) e a introdução de maiores riscos. No futuro a longo prazo, por exemplo, se as técnicas de verificação formal melhorarem, pode ser melhor escolher esse caminho, mas, por enquanto, os riscos parecem muito grandes.

Outra opção é um sistema multicliente fechado onde um conjunto fixo de sistemas de certificação é conhecido dentro do protocolo. Por exemplo, podemos decidir usar três ZK-EVMs: PSE ZK-EVM, Polygon ZK-EVM e Kakarot. Um bloco precisa levar prova de dois desses três para ser considerado válido. Isso é melhor do que um sistema de prova único, mas torna o sistema menos adaptável porque os usuários têm que manter validadores para cada sistema de prova conhecido, é inevitável que haja um processo de governança política para incorporar novos sistemas de prova, e assim por diante.

Isso me levou a preferir um sistema aberto, multi-cliente, onde as provas são colocadas “fora dos blocos” e verificadas separadamente pelos clientes. Os usuários individuais podem validar blocos com o cliente que desejam, desde que haja pelo menos um provador que gere a prova do sistema. O sistema de certificação ganhará influência convencendo os usuários a executá-los, não convencendo o processo de governança do protocolo. No entanto, essa abordagem tem custos mais complexos do que veremos.

Quais são as principais características que queremos que a implementação do ZK-EVM tenha?

Além da funcionalidade básica correta e garantias de segurança, a característica mais importante é a velocidade. Embora seja possível projetar um recurso ZK-EVM dentro de um protocolo que é assíncrono e retorna apenas uma resposta para cada reivindicação após um atraso de N intervalos de tempo, o problema de que tudo o que acontece em cada bloco é autônomo seria mais fácil se pudéssemos garantir de forma confiável que as provas seriam geradas em questão de segundos.

Embora demore muitos minutos ou horas para gerar provas de blocos ETH hoje, sabemos que não há nenhuma razão teórica para evitar a paralelização em massa: sempre podemos combinar GPUs suficientes para provar as diferentes partes da execução do bloco separadamente e, em seguida, usar SNARKs recursivos para juntar essas provas. Além disso, a aceleração de hardware por meio de FPGAs e ASICs pode ajudar a otimizar ainda mais as provas. No entanto, chegar a este ponto é um desafio significativo de engenharia que não deve ser subestimado.

Como seriam os recursos do ZK-EVM dentro do protocolo?

Semelhante às transações de Blob EIP-4844, introduzimos um novo tipo de transação que inclui declarações ZK-EVM:

Semelhante ao EIP-4844, o objeto passado no mempool será uma versão modificada da transação:

Este último pode ser convertido para o primeiro, mas não o contrário. Também expandimos o objeto sidecar de bloco (introduzido no EIP-4844) para incluir uma lista de provas feitas em um bloco.

Observe que, na prática, podemos dividir o sidecar em dois sidecars separados, um para blobs e outro para provas, e configurar uma sub-rede separada para cada tipo de prova (e uma sub-rede adicional para blobs).

Além da camada de consenso, adicionamos uma regra de validação de que um bloco só será aceito se o cliente vir uma prova válida de cada reivindicação no bloco. A prova deve ser uma instrução de atestado ZK-SNARK, ou seja, a concatenação da transação_and_witness_blobs é a serialização do par (Block,Witness), o bloco de execução é válido em pre_state_root usando Witness (i) e (ii) produz o post correto_state_root. Potencialmente, os clientes podem optar por aguardar o M-of-N para vários tipos de atestado.

Há uma nota filosófica aqui que a execução do bloco em si pode ser tratada como algo que só precisa ser verificado junto com um dos triplos (σpre, σpost, Proof) fornecidos no objeto ZKEVMClaimTransaction. Como resultado, a implementação ZK-EVM de um usuário pode substituir seu cliente de execução, que ainda será usado por (i) provadores e construtores de blocos, e (ii) nós que se preocupam com a indexação e armazenamento de dados para uso local.

Verificação e reatestação

Digamos que você tenha dois clientes ETH, um dos quais usa PSE ZK-EVM e o outro usa Polygon ZK-EVM. Suponha que, a esta altura, ambas as implementações tenham evoluído a ponto de poderem provar a execução do bloco ETH em menos de 5 segundos e, para cada sistema de prova, haja voluntários independentes suficientes executando hardware para gerar provas.

Infelizmente, como os sistemas de certificação individual não são formalizados, eles não podem ser incentivados no protocolo, no entanto, antecipamos que o custo de execução de um nó de prova de prova será menor em comparação com o custo de pesquisa e desenvolvimento, então podemos simplesmente financiar nós de prova de prova através de um financiamento de órgão comum para bens públicos.

Digamos que alguém publique um ZKEvmClaimNetworkTransaction, a menos que publique apenas uma prova da versão PSE ZK-EVM. Vendo isso, o nó Prova do Polígono ZK-EVM calcula e republica o objeto com a Prova do Polígono ZK-EVM.

Isso aumenta a latência máxima total entre o nó honesto mais antigo aceitando um bloco e o nó honesto mais recente aceitando o mesmo bloco de δ para 2 δ + Tprove (assumindo que Tprove < 5 segundos aqui).

A boa notícia, no entanto, é que, se tomarmos o determinismo de slot único, quase certamente podemos “canalizar” essa latência extra junto com a latência de consenso multirodada inerente aos SSFs. Por exemplo, nesta proposta de 4 vagas, a etapa “voto na cabeça” pode precisar apenas verificar a validade básica do bloco, mas a etapa “congelar e confirmar” exigirá a existência de uma prova.

Extensão: Suporte “quase-EVM”

Um objetivo desejável do recurso ZK-EVM é suportar “quase-EVM”: EVMs com alguns recursos extras. Isso pode incluir nova pré-compilação, novos opcodes, permitindo que os contratos sejam escritos em EVMs ou VMs completamente diferentes (por exemplo, em Arbitrum Stylus), ou até mesmo vários EVMs paralelos com comunicação cruzada síncrona.

Algumas modificações podem ser suportadas de uma forma simples: podemos definir uma linguagem que permite que ZKEVMClaimTransaction passe a descrição completa das regras EVM modificadas. Isso pode ser usado para:

· Tabela de custos de gás personalizada (os usuários não podem reduzir os custos de gás, mas podem aumentá-los)

· Desativar determinados opcodes

· Defina o número do bloco (isso significa que haverá regras diferentes dependendo do hard fork)

· Defina um sinalizador que ative o conjunto completo de alterações de EVM que foram padronizadas para uso de L2 em vez de uso de L1 ou outras alterações mais simples

Para permitir que os usuários adicionem novas funcionalidades introduzindo novos pré-compilados (ou opcodes) de uma forma mais aberta, podemos adicionar um conteúdo contendo transcrições de entrada/saída pré-compiladas a uma parte do blob do ZKEVMClaimNetworkTransaction:

A execução do EVM será modificada da seguinte forma. As entradas de matriz serão inicializadas como vazias. Cada vez que o endereço em used_precompile_addresses é chamado, acrescentamos o objeto InputsRecord(callee_address, gas, input_calldata) às entradas e definimos RETURNDATA da chamada como saídas[i]。 Finalmente, verificamos se used_precompile_addresses foi chamado len(outputs) um total de vezes, e se inputs_commitments corresponde ao resultado da serialização SSZ dos compromissos de blob gerados para as entradas. O objetivo de expor entradas_commitments é facilitar SNARKs externos para provar a relação entre entradas e saídas.

Observe a assimetria entre a entrada e a saída, onde a entrada é armazenada em um hash e a saída é armazenada nos bytes que devem ser fornecidos. Isso porque a execução precisa ser feita por um cliente que só vê a entrada e entende o EVM. As execuções EVM já geraram entradas para elas, então elas só precisam verificar se as entradas geradas correspondem às entradas declaradas, o que requer apenas verificação de hash. No entanto, os resultados devem ser-lhes fornecidos na íntegra, pelo que devem ser dados disponíveis.

Outro recurso útil pode ser permitir “transações privilegiadas”, ou seja, transações que iniciam chamadas de qualquer conta de remetente. Essas transações podem ser executadas entre duas outras transações ou ao chamar a pré-compilação em outra transação (e possivelmente privilegiada). Isso pode ser usado para permitir que mecanismos não-EVM chamem de volta para o EVM.

Este design pode ser modificado para suportar opcodes novos ou modificados, além de pré-compilação nova ou modificada. Mesmo com apenas pré-compilação, este design é muito poderoso. Por exemplo:

· Ao definir used_precompile_addresses, incluindo uma lista de endereços de conta regulares com determinados sinalizadores definidos em seus objetos de conta no estado, e fazendo um SNARK para provar que foi construído corretamente, você pode oferecer suporte a recursos no estilo Arbitrum Stylus onde o código para o contrato pode ser escrito em EVM ou WASM (ou outras VMs). As transações privilegiadas podem ser usadas para permitir que as contas WASM sejam chamadas de volta ao EVM.

· Ao adicionar uma verificação externa para garantir que as transcrições de entrada/saída e as transações privilegiadas realizadas por vários EVMs sejam correspondidas da maneira correta, você pode demonstrar um sistema paralelo de vários EVMs se comunicando entre si através de um canal de sincronização.

· O quarto tipo de ZK-EVM pode funcionar com várias implementações: uma que converte o Solidity ou outras linguagens de alto nível diretamente em VMs amigáveis ao SNARK, e outra que o compila em código EVM e o executa no consagrado ZK-EVM. A segunda implementação (e inevitavelmente mais lenta) só é executada se o provador de erros enviar uma transação informando que há um erro, e se eles forem capazes de fornecer uma transação que é tratada de forma diferente pelos dois, eles podem ser recompensados.

· Uma VM puramente assíncrona pode ser obtida fazendo com que todas as chamadas retornem zero e mapeando as chamadas para transações privilegiadas que são adicionadas ao final do bloco.

Extensão: Suporte para atestados com estado

Um dos desafios com o design acima é que ele é completamente sem estado, o que o torna menos eficiente em termos de utilização de dados. Ao suportar a compressão com monitoração de estado, os envios ERC 20 podem economizar até 3x mais espaço do que quando se usa apenas a compactação sem estado, usando a compactação de dados ideal.

Além disso, EVMs com estado não precisam fornecer dados de testemunhas. Em ambos os casos, o princípio é o mesmo: é um desperdício pedir que os dados estejam disponíveis, porque já sabemos que os dados são utilizáveis porque foram introduzidos ou produzidos por uma execução anterior do EVM.

Se quisermos que o recurso ZK-EVM seja stateful, então temos duas opções:

1. Exija que σpre esteja vazio, ou uma lista de dados disponíveis para um par chave-valor pré-declarado, ou algum σpost previamente executado.

2. Adicione o compromisso de blob de um recibo gerado em bloco R à tupla (σpre,σpost, Proof). Quaisquer promessas de blob geradas ou usadas anteriormente, incluindo aquelas que representam blocos, testemunhas, recibos ou até mesmo transações regulares de blob EIP-4844, que podem ter algum limite de tempo, podem ser referenciadas em ZKEVMClaimTransaction e acessadas durante sua execução (possivelmente através de uma série de instruções: "Insira o byte N de compromisso i na posição j do bloco + dados de testemunha… N+k− 1 」)。

(1) Basicamente dizendo: em vez de solidificar a verificação de EVM apátrida, vamos solidificar cadeias filhas de EVM. (2) Essencialmente criando um algoritmo de compressão stateful mínimo embutido que usa um blob usado ou gerado anteriormente como um dicionário. Ambos acrescentam o ónus de armazenar mais informações ao nó de prova, que é apenas o nó de prova, e no caso (2), é mais fácil limitar este ónus a um determinado período de tempo do que no caso (1).

O debate entre sistemas fechados multi-proof e dados off-chain

Um sistema multi-provador fechado evita muitas das complexidades acima, fixando um certo número de provas em uma estrutura M-of-N. Em particular, os sistemas multi-provadores fechados não precisam se preocupar em garantir que os dados estejam on-chain. Além disso, um sistema multi-attester fechado permitirá que as provas ZK-EVM sejam executadas off-chain, tornando-as compatíveis com soluções de plasma EVM.

No entanto, os sistemas multiprover fechados aumentam a complexidade da governança e reduzem a auditabilidade, o que é um trade-off entre o alto custo e esses benefícios.

Se estabelecermos o ZK-EVM como um recurso de protocolo, qual será o papel contínuo do “projeto L2”?

O protocolo lidará com os recursos de verificação EVM que as equipes L2 implementam atualmente, mas o projeto L2 ainda será responsável por uma série de características importantes:

Pré-confirmação rápida: A finalização de um único slot pode tornar os slots L1 mais lentos, e os projetos L2 já estão fornecendo aos seus usuários uma “pré-confirmação” apoiada pela própria segurança do L2, com latência muito menor do que um slot. Este serviço continuará a ser um passivo L2 puro.

Estratégias de mitigação de MEV: Isso pode incluir mempools criptografados, seleção sequencial baseada em reputação e outros recursos que os L1s relutam em implementar.

Extensões do EVM: Os projetos L2 podem incorporar extensões substanciais ao EVM para fornecer um valor significativo aos seus utilizadores. Isso inclui “quase-EVMs” e abordagens fundamentalmente diferentes, como o suporte WASM da Arbitrum Stylus e a linguagem amigável do Cairo da SNARK.

Conveniência para usuários e desenvolvedores: as equipes L2 fazem muito trabalho para atrair usuários e projetos para seu ecossistema e fazê-los se sentir bem-vindos, e eles são compensados com a aquisição de MEV e taxas de congestionamento dentro de sua rede. Esta relação veio para ficar.

Link para o artigo original