Vitalik: Discuta os vários tipos de versão "built-in ZK-EVM" e desafios de design

Palavras: Vitalik Buterin

Compilação: 1912212.eth, Foresight News

Os protocolos EVM de camada 2 em cima do ETH, incluindo rollups otimistas e rollups ZK, dependem da validação do EVM. No entanto, isso exige que eles confiem em uma enorme base de código e, se houver bugs nessa base de código, essas VMs correm o risco de serem hackeadas. Além disso, isso significa que mesmo os ZK-EVMs, que querem ser totalmente equivalentes ao EVM L1, precisam de alguma forma de governança para replicar as mudanças no EVM L1 em suas próprias práticas de EVM.

Esta situação não é ideal, pois esses projetos estão replicando funcionalidades que já existem no protocolo ETH Workshop, e a ETH Governance já é responsável por atualizar e corrigir bugs: ZK-EVM é essencialmente o mesmo trabalho que validar blocos ETH Workshop de Camada 1!Além disso, nos próximos anos, esperamos que os clientes leves se tornem cada vez mais poderosos e, em breve, cheguem ao ponto em que os ZK-SNARKs sejam usados para validar totalmente a execução do EVM da Camada 1. Nesse ponto, a rede ETH construirá efetivamente o ZK-EVM integrado. Então, surge a pergunta: por que não tornar o próprio ZK-EVM adequado para rollups também?

Neste artigo, veremos algumas das versões “integradas do ZK-EVM” que podem ser implementadas e discutiremos as compensações e os desafios de design, bem como as razões para não ir em uma direção específica. Os benefícios da implementação de recursos de protocolo devem ser ponderados em relação aos benefícios de deixar as coisas para o ecossistema e manter o protocolo subjacente simples.

Quais são as principais características que queremos do ZK-EVM integrado?

• Função básica: Validar blocos ETH. A função de protocolo (que ainda não está clara se é opcode, pré-compilação ou outro mecanismo) deve aceitar pelo menos uma raiz de pré-estado, um bloco e uma raiz de pós-estado como entrada, e verificar se a raiz pós-estado é realmente o resultado da execução do bloco.
• Compatível com múltiplos clientes da ETH Square. Isso significa que queremos evitar apenas um sistema de atestado e, em vez disso, permitir que diferentes clientes usem diferentes sistemas de atestado. Isto conduz aos seguintes pontos:
• Requisitos de disponibilidade de dados: Para qualquer execução de EVM que use o ZK-EVM integrado para provas, queremos garantir a disponibilidade dos dados subjacentes para que os provadores que usam um sistema de atestado diferente possam reatestar a execução e permitir que os clientes que confiam nesse sistema de atestado validem as provas recém-geradas.
• Existem provas fora do EVM e estruturas de dados de blocos: O recurso ZK-EVM integrado não usa SNARKs como entrada dentro do EVM, pois diferentes clientes esperarão diferentes tipos de SNARKs. Em vez disso, pode ser semelhante à validação de blob: uma transação pode incluir declarações (pré-estado, corpo de bloco, pós-estado) que precisam ser atestadas, cujo conteúdo pode ser acessado por um opcode ou pré-compilador, e as regras de consenso do lado do cliente verificarão a disponibilidade de dados e a prova de existência para cada declaração separadamente.
• Auditabilidade. Se alguma execução for comprovada, queremos que os dados subjacentes sejam utilizáveis para que, no caso de um problema, os usuários e desenvolvedores possam examiná-los. Na verdade, isso acrescenta outra razão pela qual os requisitos de disponibilidade de dados são tão importantes.
• Capacidade de atualização. Se uma solução ZK-EVM for encontrada com um bug, queremos ser capazes de corrigi-lo rapidamente. Isso significa que não há necessidade de um hard fork para consertar. Isso aumenta o motivo pelo qual as provas existem fora do EVM e estruturas de dados de bloco.
• Suporta quase todos os EVMs. Um dos atrativos do L2 é inovar na camada de execução e escalar o EVM. Se a VM para um determinado L2 é apenas um pouco diferente do EVM, então seria bom se L2 ainda pudesse usar o ZK-EVM dentro do protocolo nativo nas mesmas partes que o EVM, e confiar apenas em seu próprio código em diferentes partes. Isso pode ser alcançado projetando uma função ZK-EVM que permite ao chamador especificar campos de bits ou listas de opcode ou endereços que são manipulados por tabelas fornecidas externamente em vez do EVM em si. Também podemos tornar o custo do gás aberto à edição até certo ponto.

Sistemas multi-cliente “abertos” e “fechados”

A “filosofia multi-cliente” é provavelmente o requisito mais subjetivo desta lista. Há uma opção para abandoná-lo e se concentrar no esquema ZK-SNARK, que simplificará o design, mas ao custo de ser um “ponto de virada filosófico” maior para o ETH Workshop (uma vez que está efetivamente abandonando a filosofia multicliente de longa data do ETH Workshop) e introduzindo maiores riscos. No futuro, quando a tecnologia de verificação formal se tornar melhor, pode ser melhor escolher esse caminho, mas agora parece que o risco é muito grande.

Outra opção é um sistema multicliente fechado onde um conjunto fixo de sistemas de certificação é conhecido no protocolo. Por exemplo, podemos decidir usar três ZK-EVM: PSE ZK-EVM, Polygon ZK-EVM e Kakarot. Um bloco requer prova fornecida por dois desses três para ser 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 que existe, e inevitavelmente haverá processos de governança política para incorporar novos sistemas de prova, etc.

Isso me motiva a preferir um sistema multicliente aberto, onde as provas são colocadas “fora do bloco” e verificadas pelo cliente individualmente. Os usuários individuais podem usar qualquer cliente que desejem validar blocos, desde que pelo menos um provador crie uma prova para esse sistema de atestado. 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, esta abordagem tem um custo de complexidade mais elevado, como veremos.

Que propriedades chave queremos ganhar com a implementação do ZK-EVM?

Além da correção funcional básica e garantias de segurança, o atributo mais importante é a velocidade. Embora possamos projetar o recurso ZK-EVM dentro do protocolo, que é assíncrono e só retorna cada resposta declarada após um atraso de N slots, o problema se torna muito mais fácil se pudermos garantir de forma confiável que uma prova será gerada em questão de segundos, não importa o que aconteça em cada bloco é independente.

Embora hoje demore muitos minutos ou horas para gerar provas para blocos ETH, sabemos que não há nenhuma razão teórica para impedir a paralelização em massa: sempre podemos combinar GPUs suficientes para provar as partes individuais da execução de um bloco separadamente e, em seguida, juntar as provas usando SNARKs recursivos. 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 enorme desafio de engenharia que não deve ser subestimado.

Como seria o recurso ZK-EVM dentro do protocolo?

Semelhante às transações de blob EIP-4844, introduzimos um novo tipo de transação que contém declarações ZK-EVM:

É importante notar que, na prática, podemos querer dividir o sideload em dois sideloads 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).

Na camada de consenso, adicionamos uma regra de validação que só aceita um bloco se o cliente vir uma prova válida de cada reivindicação no bloco. A prova deve ser um ZK-SNARK, provar que a concatenação da transação_and_witness_blobs é a serialização do par (Bloco, Testemunha) e que o bloco é executado com pre_state_root na Testemunha

i) é válida, e

(ii) Saída do post correto_state_root. Possivelmente, o cliente pode optar por esperar por vários tipos de prova de M-of-N.

É importante notar aqui que a execução do bloco em si pode simplesmente ser pensada como um dos triplos que precisam ser verificados juntamente com os triplos fornecidos no objeto ZKEVMClaimTransaction (σpre, σpost, Proof). Como resultado, a implementação ZK-EVM do usuário pode substituir seu cliente de execução, o cliente de execução ainda será executado

i) Promotores e construtores de blocos e:

e (ii) nós que se preocupam com a indexação e armazenamento de dados para uso local.

Além disso, como essa arquitetura separa a execução da validação, ela pode fornecer mais flexibilidade e eficiência para diferentes funções no ecossistema ETH. Por exemplo, um provador pode se concentrar em gerar provas sem se preocupar com as especificidades da execução, enquanto os clientes de execução podem ser otimizados para atender às necessidades de usuários específicos, como sincronização rápida ou recursos avançados de indexação.

Verificação e reatestação

Suponha que existam dois clientes ETH, um usando o PSE ZK-EVM e outro usando o Polygon ZK-EVM, neste ponto, ambas as implementações evoluíram até o ponto em que podem provar a execução do bloco ETH em menos de 5 segundos, e para cada sistema de prova, há voluntários independentes suficientes executando o hardware para gerar provas.

Infelizmente, como os sistemas individuais de prova de caixa não são formalizados, eles não podem ser incentivados no protocolo, no entanto, prevemos que o custo de executar provas será menor em comparação com pesquisa e desenvolvimento, para que possamos facilmente financiar provadores através de instituições financiadas para bens públicos.

Digamos que alguém publique um ZKEvmClaimNetworkTransaction, mas publique apenas uma prova da versão PSE ZK-EVM. O Nó de Prova do Polígono ZK-EVM vê isso, calcula e republica o objeto, juntamente com a Prova do Polígono ZK-EVM.

Isso aumentará o atraso máximo 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 Tprove<5s aqui).

A boa notícia, no entanto, é que, se adotarmos a finalidade de slot único, podemos quase certamente “canalizar” esse atraso adicional, juntamente com a latência de consenso de várias rodadas inerente ao SSF. Por exemplo, nesta proposta de 4 vagas, a etapa “voto na cabeça” pode precisar apenas verificar a validade do bloco base, mas a etapa “congelar e confirmar” exigiria a presença de uma prova.

Extensão: Suporte para “quase-EVMs”

O objetivo desejável para o recurso ZK-EVM é suportar “quase-EVMs”: EVMs com recursos adicionais. Isso pode incluir nova pré-compilação, novos opcodes, contratos que podem ser EVM ou VMs completamente diferentes (por exemplo, no Arbitrum Stylus), ou até mesmo vários EVMs paralelos com comunicação cruzada síncrona.

Algumas modificações podem ser suportadas de forma simples: podemos definir uma linguagem que permita que ZKEVMClaimTransaction passe a descrição completa da regra EVM modificada. Isso pode ser usado nas seguintes situações:

1. Tabela de custos de gás personalizada (os usuários não podem reduzir os custos de gás, mas podem aumentá-los)
2. Desative certos opcodes
3. Defina o número do bloco (isso significa que existem regras diferentes dependendo do hard fork)
4. Defina o sinalizador para ativar o conjunto completo de alterações EVM que já estão padronizadas para L2, mas não para uso L1, ou outras alterações mais simples

Para permitir que os usuários adicionem novas funcionalidades de uma forma mais aberta, por exemplo, introduzindo um novo pré-compilado (ou opcode), podemos adicionar uma maneira de incluir os registros de entrada/saída pré-compilados na seção blob do ZKEVMClaimNetworkTransaction:

classe PrecompileInputOutputTran(Container):used_precompile_addresses: Lista[Address][VersionedHash]entradas_commitments: Lista[Bytes]saídas: Lista

A execução do EVM será modificada da seguinte forma. Uma matriz chamada inputs será inicializada como vazia. Sempre que o endereço em used_precompile_addresses é chamado, adicionamos um objeto InputsRecord(callee_address, Gas, input_calldata) às entradas e definimos o chamado RETURNDATA como saídas[i]。 Finalmente, verificamos que used_precompile_addresses foi chamado len(outputs) um total de vezes, e que inputs_commitments corresponde ao resultado do compromisso do blob resultante com a serialização SSZ de entradas. O objetivo de expor entradas_commitments é permitir que o SNARK externo prove a relação entre entradas e saídas.

Observe a assimetria entre entradas e saídas, onde as entradas são armazenadas em hashes e as saídas são armazenadas em bytes que devem ser fornecidos. Isso ocorre porque a execução precisa ser realizada por um cliente que só vê a entrada e entende o EVM. As execuções EVM já geraram entradas para eles, então eles só precisam verificar se a entrada gerada corresponde à entrada declarada, o que requer apenas verificação de hash. No entanto, a saída deve ser-lhes totalmente fornecida, pelo que a disponibilidade dos dados deve estar disponível.

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

O design pode ser modificado para suportar opcodes novos ou modificados, além de pré-compilações novas ou modificadas. Mesmo com apenas pré-compilação, o design é muito poderoso. Por exemplo:

Funcionalidades como o Arbitrum Stylus podem ser suportadas definindo used_precompile_addresses para incluir uma lista de endereços de conta regulares com um determinado sinalizador definido em seu objeto de conta no estado, e gerando SNARKs que provam que eles são construídos corretamente, onde um contrato pode escrever seu código em um EVM ou WASM (ou outra VM). As transações privilegiadas podem ser usadas para permitir que as contas WASM chamem de volta o EVM.

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

UM ZK-EVM do tipo 4 pode funcionar com várias implementações: uma que converte o Solidity ou outra linguagem de nível superior diretamente em uma VM amigável para SNARK e outra que o compila em código EVM e o executa no ZK-EVM prescrito. A segunda implementação (e inevitavelmente mais lenta) só pode ser executada se o provador de falha enviar uma transação alegando ter um erro, e se eles forem capazes de oferecer que os dois lidam com transações diferentes, a recompensa pode ser coletada.

Você pode implementar uma VM assíncrona pura retornando zero para todas as chamadas e mapeando as chamadas para transações privilegiadas que são adicionadas ao final do bloco.

Extensão: Suporte para Prova de Estado

O desafio com o design acima é que ele é completamente apátrida, o que o torna pobre em termos de eficiência de dados. Com a compactação de dados ideal, a compactação com estado pode tornar os envios ERC20 mais eficientes em termos de espaço em até 3x em comparação com a compactação sem estado sozinha.

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

Se quisermos tornar o recurso ZK-EVM stateful, temos duas opções:

Requer σpre para ser nulo, ou uma lista pré-declarada de chaves e valores para os quais os dados estão disponíveis, ou algum σpost executado anteriormente.

Adicione um compromisso de blob à tupla (σpre, σpost, proof) para o recibo R gerado pelo bloco. Quaisquer compromissos de blob gerados ou usados anteriormente que possam ser referenciados no ZKEVMClaimTransaction e acessados durante sua execução, incluindo compromissos que representam blocos, testemunhas, recibos ou até mesmo transações regulares de blob EIP-4844 (pode haver alguns limites de tempo, que podem ser referenciados por uma série de instruções: “Inserir byte N de compromisso i na posição j do bloco + dados de testemunha… N+k-1”)

(1) O significado básico é: em vez de estabelecer a verificação EVM apátrida, vamos estabelecer uma cadeia infantil EVM.

e (2) essencialmente cria um algoritmo de compressão stateful minimamente integrado que usa um blob usado ou gerado anteriormente como um dicionário. Ambos colocam uma carga sobre o nó provador, e apenas o nó provador para armazenar mais informações;

No caso (2), é mais fácil limitar este encargo no tempo, enquanto no caso (1) é mais difícil.

Argumentos para sistemas multi-provadores fechados e dados off-chain

Um sistema multi-provador fechado, no qual há um número fixo de provas na estrutura M-of-N, evita grande parte da complexidade descrita acima. Em particular, um sistema multi-attester fechado não precisa se preocupar em garantir que os dados existam 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 fechados multi-attester aumentam a complexidade da governança e enfraquecem a auditabilidade, que é um custo alto que precisa ser ponderado em relação a essas vantagens.

Se construirmos no ZK-EVM e o tornarmos um recurso de protocolo, qual é o papel contínuo do projeto L2?

As funções de validação EVM que são atualmente implementadas pela própria equipe L2 serão tratadas pelo protocolo, mas o projeto L2 ainda será responsável por uma série de funções importantes:

• Pré-confirmação rápida: A finalização de slot único pode tornar os slots L1 mais lentos, enquanto o L2 já fornece aos usuários um serviço de pré-confirmação com sua própria segurança, com latência muito menor do que um slot. Este serviço continuará a ser da exclusiva responsabilidade da L2.
• Estratégias de mitigação de MEV: Isso pode incluir recursos como mempools criptografados, seleção sequencial baseada em reputação, etc., que L1 está relutante em implementar.
• Extensões do EVM: os projetos de nível 2 podem introduzir extensões significativas ao EVM que proporcionem um valor significativo aos seus utilizadores. Isso inclui “quase-EVMs” e abordagens completamente 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 de nível 2 se esforçam muito para atrair usuários e projetos para seu ecossistema e fazê-los se sentir bem-vindos, eles são pagos capturando MEV e taxas de congestionamento dentro de sua rede. Esta relação veio para ficar.