V Shen Xinwen: Depois do ETH Fang built-in ZK, para onde vai a Layer2?

Produzido | Odiariamente

Compilar | Lu Loopy

Hoje, Vitalik Buterin publicou um novo artigo na comunidade ETH intitulado “O que pode ser um ZK-EVM integrado?”. Este artigo explora como o ETH Workshop terá seu próprio ZK-EVM incorporado em futuras atualizações de rede.

Como todos sabemos, no contexto do lento desenvolvimento da ETH, quase toda a Camada 2 mainstream já tem ZK-EVM, mas quando a mainnet da oficina ETH encapsula seu próprio ZK-EVM, haverá um conflito entre o posicionamento de papel da mainnet e a Camada 2?

Neste artigo, Vitalik Buterin enfatiza a importância da compatibilidade, disponibilidade de dados e auditabilidade, e explora as possibilidades de implementação de atestados eficientes e com estado. Além disso, o artigo explora a possibilidade de implementar provas stateful para eficiência e discute o papel dos projetos de Camada 2 no fornecimento de pré-confirmação rápida e estratégias de mitigação MEV. Este artigo reflete o equilíbrio do avanço do desenvolvimento da rede ETH através de ZK-EVMs, mantendo sua flexibilidade.

Odaily Planet Daily compilou o artigo original, e o texto completo do artigo é o seguinte:

rollups otimistas e rollups ZK, como protocolos EVM de camada 2 em cima de ETH, dependem da verificação EVM. No entanto, isso exige que eles confiem em uma base de código grande e, se houver bugs nessa base de código, essas VMs correm o risco de serem hackeadas. Isso também significa que os ZK-EVMs, mesmo que queiram ser totalmente equivalentes ao EVM L1, precisarão de alguma forma de governança para replicar as mudanças do EVM L1 em suas próprias implementações de EVM.

Esta não é uma situação ideal. Como esses projetos estão replicando a funcionalidade que já existe no ETH Workshop Protocol para si mesmos - a Governança ETH já é responsável por atualizar e corrigir bugs, e o que o ZK-EVM basicamente faz é validar blocos ETH de Camada 1. Nos próximos anos, esperamos que os clientes leves se tornem cada vez mais poderosos e, em breve, poderão usar ZK-SNARKs para validar totalmente as execuções de EVM L1. Nesse ponto, a rede ETH realmente terá um ZK-EVM em um pacote. Então, surge a pergunta: por que não disponibilizar este ZK-EVM nativamente para rollups também?

Este artigo irá descrever várias versões do “ZK-EVM encapsulado”, analisando suas compensações, desafios de design e razões para não ir em determinadas direções. Os benefícios da implementação da funcionalidade de um protocolo devem ser comparados com os benefícios de permitir que o ecossistema lide com transações e manter o protocolo subjacente simples.

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

Quais são os principais atributos que podemos esperar do ZK-EVM embalado?

Função básica: Validar blocos ETH. A função de protocolo (que ainda não foi determinada se é opcode, pré-compilação ou algum outro mecanismo) deve ser capaz de aceitar pelo menos uma raiz pré-estado, um bloco e uma raiz pós-estado como entrada, e verificar se a raiz pós-estado é realmente o resultado da execução desse bloco em cima da raiz pré-estado. Compatível com o multi-cliente da ETH Workshop. Isso significa que queremos evitar um único sistema de atestado embutido e, em vez disso, permitir que diferentes clientes usem diferentes sistemas de atestado.

Isso também significa algumas coisas:

Requisitos de disponibilidade de dados: Para qualquer execução de EVM que use provas ZK-EVM encapsuladas, queremos 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 dependem desse sistema de atestado possam validar essas provas recém-geradas.

As provas residem fora do EVM e das estruturas de dados de blocos:* A funcionalidade ZK-EVM realmente 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 do bloco, pós-estado) que precisam ser provadas, cujo conteúdo pode ser acessado por opcodes ou pré-compilações, e as regras de consenso do lado do cliente verificam a disponibilidade de dados e a prova de declarações feitas no bloco, respectivamente.

Auditabilidade: Se qualquer execução for comprovada, queremos que os dados subjacentes sejam utilizáveis para que, se algo der errado, usuários e desenvolvedores possam inspecioná-los. Na verdade, isso acrescenta mais uma razão pela qual os requisitos de disponibilidade de dados são importantes.

Capacidade de atualização: Se encontrarmos um bug em uma determinada solução ZK-EVM, queremos ser capazes de corrigi-lo rapidamente. Isso significa que não há necessidade de um hard fork para corrigir o problema. Isso adiciona outra razão pela qual as provas fora do EVM e estruturas de dados de bloco são importantes.

Uma das atrações de suportar “EVM aproximado” :**L2s é a capacidade de inovar na camada de execução e escalar o EVM. Se uma VM L2 é apenas ligeiramente diferente do EVM, então seria bom se L2 pudesse usar o protocolo nativo ZK-EVM para as mesmas partes que o EVM, e confiar apenas em seu próprio código para lidar com as diferentes partes. Isso pode ser conseguido projetando uma função ZK-EVM que permite ao chamador especificar um campo de bit ou opcode ou lista de endereços, que será manipulado por um formulário fornecido externamente em vez do EVM em si. Também podemos tornar o custo do gás personalizável até certo ponto.

Sistemas multicliente “abertos” vs. “fechados”

A “mentalidade multi-cliente” é provavelmente o requisito mais controverso desta lista. Uma opção seria abandonar o multicliente e se concentrar em um esquema ZK-SNARK, o que simplificaria o design. Mas à custa de uma “mudança filosófica” maior no ETH Workshop (pois isso está efetivamente abandonando a mentalidade multicliente de longa data do ETH Workshop) e introduzindo maior risco. Num futuro a longo prazo, por exemplo, quando as técnicas de verificação formal melhorarem, poderá ser melhor seguir este caminho, mas, por enquanto, parece demasiado arriscado.

Outra opção é um sistema multicliente fechado com um conjunto fixo de sistemas de certificação que é conhecido dentro do protocolo. Por exemplo, podemos decidir usar três ZK-EVMs: PSE ZK-EVM, Polygon ZK-EVM e Kakarot. Um bloco precisa de provas de pelo menos dois desses três para ser válido. Isso é melhor do que um sistema de prova único, mas torna o sistema menos adaptável devido ao fato de que os usuários têm que manter validadores para cada sistema de prova que existe, haverá um processo de governança inevitável para incorporar novos sistemas de prova, etc.

Isso me leva a preferir um sistema multicliente aberto onde as provas são colocadas “fora do bloco” e verificadas separadamente pelos clientes. Os usuários individuais usarão qualquer cliente que desejem validar um bloco, e poderão fazê-lo 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, essa abordagem tem um custo mais complexo, como veremos.

Quais são as principais características que queremos na 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 seja possível projetar um protocolo assíncrono com a funcionalidade ZK-EVM integrada, onde cada declaração só retorna resultados após 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, de modo que o que acontece em cada bloco é autossuficiente.

Embora leve minutos ou horas para gerar uma prova para um bloco ETH hoje, sabemos que não há nenhuma razão teórica para impedir a paralelização em massa: sempre podemos montar 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, o processo de prova pode ser otimizado ainda mais através da aceleração de hardware de FPGAs e ASICs. Na verdade, chegar lá, no entanto, é um desafio de engenharia que não deve ser subestimado.

Qual é exatamente a aparência da função ZK-EVM no protocolo?

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

classe ZKEVMClaimTransaction(Container):
pré_state_root: bytes 32
post_state_root: bytes 32
transação_and_witness_blob_pointers: Lista[VersionedHash]
…

Assim como no EIP-4844, o objeto passado no mempool é uma versão modificada da transação:

classe ZKEvmClaimNetworkTransaction(Container):
pré_state_root: bytes 32
post_state_root: bytes 32
prova: bytes
transação_and_witness_blobs: List[Bytes[FIELD_ELEMENTS_PER_BLOB * 31 ]]

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

Observe que, na prática, podemos dividir o sidecar em dois sidecars separados, um para blobs e outro para atestado, 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ó aceitará um bloco se o cliente vir uma prova válida de cada reivindicação no bloco. A prova deve ser uma concatenação da prova ZK-SNARK, serializada como um par de transação_and_witness_blobs e pre_state_root válida com (i) e Witness (ii) saída do post correto_state_root. (Bloquear, testemunhar) Potencialmente, os clientes podem optar por esperar por M-of-N para vários tipos de provas.

Uma observação aqui é que a execução do bloco em si pode simplesmente ser pensada como um triplo que precisa ser verificado junto com os triplos fornecidos no objeto ZKEVMClaimTransaction (σpre, σpost, Proof).

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.

Validação e revalidação

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

Infelizmente, uma vez que os sistemas de certificação independentes não estão incorporados, não podem ser incentivados no protocolo, no entanto, antecipamos que o custo de funcionamento de um provador é menor em comparação com o custo de I&D, pelo que podemos simplesmente utilizar um organismo genérico para financiar bens públicos para provadores.

Digamos que alguém libere um ZKEvmClaimNetworkTransaction, mas libere apenas uma versão da prova PSE ZK-EVM. O nó de prova do Polygon ZK-EVM vê isso e usa a prova do Polygon ZK-EVM para calcular e republicar o objeto.

Isso aumenta o atraso máximo total entre o nó honesto mais antigo aceitando um bloco e o nó honesto mais recente aceitando o mesmo bloco δ: 2 δ+Tprove (assumindo Tprove<5 s).

A boa notícia, no entanto, é que, se tomarmos a finalidade do slot, podemos quase certamente “canalizar” essa latência extra juntamente com a latência de consenso multi-round inerente ao SSF. Por exemplo, em uma proposta de 4 vagas, a etapa “voto na cabeça” pode precisar apenas verificar a validade do bloco base, mas então a etapa “congelar e confirmar” exigirá prova de existência.

Extensão: Suporte para “EVM aproximado”

Um objetivo ideal para o recurso ZK-EVM é suportar “EVM aproximado”: ou seja, um EVM com alguma funcionalidade extra incorporada. Isso pode incluir nova pré-compilação, novos opcodes, ou até mesmo opções onde o contrato pode ser escrito em um EVM ou uma máquina virtual completamente diferente (por exemplo, como 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. Isto pode ser feito:

• Tabela de gás personalizada (os usuários não podem reduzir os custos de gás, mas podem aumentá-los)
• Desativar certos opcodes
• Defina o número do bloco (isso implicará regras diferentes, dependendo do hard fork)
• Defina um sinalizador que ative um conjunto completo de alterações EVM que foram normalizadas para uso L2 em vez de uso L1, ou outras alterações mais simples

Para permitir que os usuários adicionem novos recursos de uma forma mais aberta, introduzindo uma nova pré-compilação (ou opcode), podemos incluir um registro de entrada/saída pré-compilado no blob do ZKEVMClaimNetworkTransaction:

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

A execução do EVM será modificada da seguinte forma. Inicialize uma matriz de entrada vazia. Sempre que o endereço em used_precompile_addresses é chamado, adicionamos um 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 prometido pela serialização do SSZ na entrada. O objetivo de expor entradas_commitments é tornar mais fácil para 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 ocorre porque a execução precisa ser feita por um cliente que só vê a entrada e entende o EVM. A execução do EVM já gerou a entrada para eles, então eles só precisam verificar se a entrada gerada corresponde à entrada reivindicada, o que requer apenas uma verificação de hash. No entanto, os resultados devem ser-lhes fornecidos na íntegra e, por conseguinte, devem ser dados utilizáveis.

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

Este 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, este design é bastante poderoso. Por exemplo:

• Ao definir usado_precompile_addresses para incluir uma lista de endereços de conta normais com determinados sinalizadores no estado, e fazendo um SNARK para provar que ele foi construído corretamente, você pode suportar recursos no estilo Arbitrum Stylus, onde o contrato pode ser escrito em EVM ou WASM (ou outra VM). As transações privilegiadas podem ser usadas para permitir que as contas WASM sejam chamadas de volta para o EVM.
• Ao adicionar uma verificação externa para garantir que os registros de entrada/saída e transações privilegiadas realizadas por vários EVMs sejam correspondidos da maneira correta, você pode demonstrar um sistema paralelo de vários EVMs conversando entre si através de um canal de sincronização.
• Um ZK-EVM Tipo 4 pode ser operado com várias implementações: uma que converte diretamente o Solidity ou outra linguagem de alto nível em uma VM amigável para SNARK, e outra que o compila em código EVM e o executa no ZK-EVM integrado. A segunda implementação (e inevitavelmente mais lenta) só pode ser executada se o provador de falhas enviar uma transação que afirma que há um bug e coletar uma recompensa se puder oferecer que os dois lidem com transações diferentes. Uma VM assíncrona pura pode ser alcançada retornando zero para todas as chamadas e mapeando as chamadas para transações privilegiadas adicionadas ao final do bloco.

Extensão: Suporte para certificadores stateful

Um dos desafios com o design acima é que ele é completamente apátrida, o que o torna ineficiente em termos de dados. No caso da compactação de dados ideal, os envios ERC 20 usando compactação stateful podem ser até 3x mais eficientes em termos de espaço do que a compactação somente state.

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

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

1. Requisitos σpré Ou está vazio, é uma lista de dados disponíveis com as chaves e valores declarados, ou é executado antes de um determinado tempo σpost 。

2. Rumo a ( σpré, σposto, Prova ) Triplo para adicionar um recibo gerado para o bloco R de compromissos de blob. Quaisquer compromissos de blob gerados ou usados anteriormente, incluindo aqueles que representam blocos, testemunhas, recibos ou até mesmo transações de blob EIP-4844 simples, podem ter algumas restrições de tempo que podem ser referenciadas no ZKEVMClaimTransaction e acessadas durante sua execução (possivelmente por meio de uma série de instruções: "Será comprometido eu Os bytes de N… N+k-1 é inserido no bloco + dados testemunha J "）。

A opção 1 significa que, em vez de ter a verificação EVM sem estado integrada, é melhor ter uma cadeia filha EVM integrada. A opção dois essencialmente cria um algoritmo de compactação stateful interno mínimo que usa um blob usado ou gerado anteriormente como um dicionário. Ambas as abordagens colocam um fardo no nó provador, que é o único que precisa armazenar mais informações e, no caso dois, é mais fácil ter um limite de tempo para esse encargo do que no caso um.

Parâmetros para multi-cerversers fechados e dados off-chain

Um sistema multi-provador fechado com um número fixo de provas em uma estrutura M-of-N evita grande parte da complexidade acima. Em particular, um sistema multi-provador fechado não precisa 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 as soluções EVM Plasma.

No entanto, um sistema multiprover fechado adiciona complexidade de governança e elimina a auditabilidade, que são custos altos que precisam ser ponderados em relação a esses benefícios.

Se construíssemos o ZK-EVM nele e o fizéssemos um recurso de protocolo, qual seria o papel de um “projeto de camada 2”?

As funções de verificação EVM atualmente implementadas pelas próprias equipes da Camada 2 serão tratadas pelo protocolo, mas o projeto da Camada 2 ainda é responsável por uma série de características importantes:

• Pré-confirmação rápida: A finalidade de um único slot pode tornar os slots de Camada 1 mais lentos, enquanto os projetos de Camada 2 já estão fornecendo aos seus usuários “pré-confirmações” que são apoiadas pela própria segurança da Camada 2 com latência muito menor do que um único slot. Este serviço continuará totalmente sob a responsabilidade da Camada 2.
• Estratégias de mitigação de MEV (Miner Extractable Value): Isso pode incluir mempools criptografados, seleção de sequenciadores baseada em reputação e outros recursos que os Layer 1s relutam em implementar.
• Extensões para o EVM: Os projetos de camada 2 podem fornecer extensões significativas para o EVM para seus usuários. Isso inclui “EVM aproximado” e abordagens fundamentalmente diferentes, como o suporte WASM da Arbitrum Stylus e a linguagem do Cairo amigável para SNARK.
• Conveniência para usuários e desenvolvedores: as equipes de camada 2 têm feito muito para atrair usuários e projetos para seu ecossistema e fazê-los se sentir bem-vindos, eles são compensados pela captura de MEV e taxas de congestionamento dentro de sua rede. Esta relação veio para ficar.