A primeira parte da série zkEVM: a arquitetura geral e o processo de execução de transações do Polygon zkEVM

Autor: 0xhhh, Ethstorage(Twitter:@hhh69251498 )

Editor:Red One

Em 27 de março, a versão beta do Polygon zkEVM mainnet foi oficialmente lançada, e Vitalik completou sua primeira transação nele.

Este artigo é o primeiro de uma série de artigos sobre Polygon zkEVM, que descreve brevemente a arquitetura geral e o processo de execução de transações do Polygon zkEVM, e analisa como o Polygon zkEVM alcança escalonamento computacional enquanto herda a segurança do Ethereum.

Nos próximos dois artigos, também detalharemos os detalhes de design da ponte zkEVM e zkEVM da Polygon zkEVM, bem como o roteiro para o próximo sequenciador descentralizado da Polygon zkEVM.

Primeiro, o Rollup é para alcançar o escalonamento computacional para Ethereum

Primeiro, precisamos ser claros sobre como os Rollups funcionam. O surgimento do Rollup é escalar o cálculo do Ethereum, o método de implementação específico é terceirizar a execução de transações para o Rollup e, em seguida, armazenar a transação e o estado (Estado) após a execução da transação no contrato Ethereum.

Rollup otimista

Otimistamente, a Transação de Rollup e o Estado de Rollup correspondente enviado para Ethereum estão corretos, e qualquer pessoa pode desafiar um Estado de Rollup que ainda está no período de desafio fornecendo uma Prova de Fraude.

Pacote cumulativo de conhecimento zero

ZK fornecerá uma prova de validade para a transação de rollup enviada para Ethereum e o estado de rollup correspondente (verificado pelo contrato no Ethereum para provar que o rollup está no estado correto após a execução da transação correspondente).

Consulte a definição oficial de Ethereum:

A maior diferença entre o Zero-knowledge Rollup e o Optimistic Rollup é que o tempo para chegar à finalidade é diferente devido às diferentes formas de verificar a validade do estado.

O Rollup Otimista está otimista de que as transações e status enviados ao Ethereum estão corretos, então há um período de desafio de 7 dias (o tempo para chegar ao fim é de 7 dias), durante o qual qualquer pessoa que achar que o estado correspondente de uma transação no Ethereum está incorreto pode contestar enviando o status correto.

O tempo que leva para um Pacote Cumulativo de Conhecimento Zero (zk-Rollup) chegar ao fim depende do tempo que leva para que a Prova de Validade da transação seja enviada ao Ethereum e verificada. Atualmente, pode ser em torno de 1 hora para o final (devido à necessidade de considerar o custo do gás).

Em segundo lugar, o processo de execução do Polygon zkEVM

Vamos dar uma olhada em como o Polygon zkEVM funciona com um processo simples de confirmação de transação, de modo a ter uma compreensão concreta do protocolo geral, e todo o seu processo pode ser dividido em três etapas principais:

1. O Sequencer empacota várias transações do usuário em lotes e as submete ao contrato L1.

2. O Prover gera uma Prova de Validade para cada transação e agrega as provas de validade de várias transações em uma única Prova de Validade.

3. O agregador apresenta uma prova de validade das múltiplas transações agregadas do agregador no contrato L1.

1 O Sequencer empacota as transações do usuário em lotes e as submete ao contrato L1.

1. O usuário envia a transação para o Sequencer, e o Sequencer processará a transação localmente na ordem de recebimento (FRFS), quando o Sequencer executa a transação localmente, se o usuário acredita que o Sequencer é honesto, então ele pode considerar que a transação chegou ao fim. É importante notar aqui que a maioria dos Mempools dentro do Sequencer são atualmente privados, então há relativamente poucos MEVs que podem ser obtidos por enquanto.

2. O Sequencer irá empacotar várias transações em um lote (atualmente apenas uma transação em um lote) e, em seguida, enviar vários lotes juntos para a transação Calldata de L1 através da função SequenceBatch() de PolygonZKEvm.sol em L1.

(Deve-se notar que vários lotes são submetidos de uma só vez, a fim de reduzir o consumo de gás de L1 tanto quanto possível.)

3. Quando PolygonZkEvm.sol recebe os Lotes fornecidos pelo Sequencer, ele calculará o hash de cada lote no contrato por sua vez e, em seguida, registrará o hash do lote anterior no próximo lote, para que obtenhamos a estrutura do Lote na figura a seguir.

4) A ordem das transações em cada lote também é determinada, portanto, quando a ordem do lote é determinada, consideramos que a ordem de todas as transações que estão incluídas no lote a ser submetida ao contrato L1 Polygon zkEVM foram determinadas.

O processo real acima também é o trabalho que L1 precisa concluir como a camada DA do Rollup (nenhum trabalho de verificação de estado ou avanço foi concluído no momento).

**2. O agregador gera prova de validade para vários lotes de transações

1. Quando o Agregador ouve o envio bem-sucedido de novos lotes no contrato PolyonZKEVM.sol em L1, ele sincroniza esses lotes com seu nó e envia essas transações para zkProver.

2. Depois de receber essas transações, o zkProver gerará uma Prova de Validade para cada transação e, em seguida, agregará a Prova de Validade das transações contidas em vários lotes em uma Prova de Validade.

3. zkProver envia a Prova de Validade de agregação de várias transações para o Agregador.

3. O agregador submete o contrato para provas agregadas a L1

O Agregador enviará esta Prova de Validade ao contrato Polygon zkEvm.sol em L1, juntamente com o estado correspondente da execução do lote, chamando o seguinte método:

As seguintes ações são então executadas dentro do contrato para verificar se a transição de estado está correta.

Quando esta etapa é executada com sucesso no contrato L1, todas as transações incluídas nesta parte do lote atingirão verdadeiramente a Finalidade (correspondente ao final do período de desafio de 7 dias do OP).

3. O papel do Ethereum no Polygon-zkEVM

Agora que analisamos o processo geral do Polygon zkEVM, vamos analisar o que o Ethereum fez para o Rollup:

Na primeira etapa, o Sequencer coleta as transações de rollup e as empacota em lotes, que são então submetidos ao contrato L1. L1 não só fornece a funcionalidade da camada DA, mas também realmente completa algumas das funções de ordenação de transações, quando você envia uma transação para o Sequencer, a transação não é realmente ordenada, porque o Sequencer tem o poder de alterar a ordem das transações à vontade, mas quando a transação é incluída no Lote e submetida ao contrato L1, ninguém tem o direito de alterar a ordem das transações.

Na segunda etapa, o Agregador traz a Prova de Validade para o contrato L1 para alcançar o novo estado, o Agregador é uma função semelhante à do Proponente, e o contrato é semelhante à função de Validador, e o Agregador fornece uma Prova de Validade para provar que o novo estado está correto e informa ao Validador a Validade que eu forneço Quais lotes de transação estão envolvidos na Prova e onde estão em L1.

Em seguida, o validador extrai o lote correspondente do contrato e o combina com a Prova de Validade para verificar a legitimidade da transição de estado e, se a verificação for bem-sucedida, o contrato será realmente atualizado para o novo estado da Prova de Validade correspondente.

Em quarto lugar, estruture o Smart Contract Rollup a partir da perspetiva da modularidade

Se do ponto de vista da modularidade, o Polygon zkEVM pertence ao tipo Smart Contract Rollup, podemos tentar desconstruir seus módulos, e a partir do diagrama dado pelo Delphi, também podemos ver que o Polygon ZkEVM é na verdade a Camada de Consenso, Camada DA e Liquidação do Smart Contrat Rollup As camadas são realmente acopladas ao contrato PolygonZkEVM.sol, que não é bem distinto. Mas vamos tentar desconstruir os módulos:

Camada de disponibilidade de dados: onde as transações de rollup são armazenadas e, no caso do Polygon-zkEVM, quando o Sequencer chama o método SequenceBatch(), ele realmente inclui o envio de dados de transação para a camada DA.

Camada de liquidação: Refere-se especificamente ao mecanismo de fluxo de dinheiro entre Rollup e L1, especificamente a ponte oficial do Polygon-zkEVM (mais sobre isso no próximo artigo).

Camada de Consenso: Contém a ordenação das transações e como determinar o próximo estado válido (seleção de bifurcação), o Sequencer conclui a ordenação das transações quando chama SequenceBatch() no contrato L1 e confirma o próximo estado legal quando o Agregador chama TustedVerifyBatches() no contrato L1.

Camada de Execução: O processo pelo qual uma transação é executada e um novo estado mundial é obtido, quando o usuário envia uma transação para o Sequencer, e o novo estado é obtido depois que o Sequencer é executado ( É por isso que costumamos dizer que os Rollups são escalonamentos computacionais, porque o L1 terceiriza o processo de execução de transações para obter um novo estado para os Rollups, e o Sequencer delega o zkProver para ajudar a gerar a Prova de Validade através do Agregador.

5. Por que Polygon-zkEVM herda a segurança de L1

A julgar pelo processo geral descrito acima, o Sequencer realmente faz algo semelhante ao Ethereum Proposer, propondo que um lote de transações são transações válidas, e dando o novo estado desse lote de transações após a execução, e a lógica de verificação do contrato L1 é equivalente a todos os validadores L1 serão executados em seus próprios clientes Ethereum, na verdade, todos os validadores Ethereum atuam como validadores de Rollup, então pensamos que o Polygon zkEVM Herdeu a segurança do Ethereum.

Por outro lado, como todas as transações e o estado dos Rollups são armazenados no Ethereum, mesmo que a equipe do Polygon zkEVM fuja, qualquer pessoa ainda terá a capacidade de recuperar toda a rede Rollup com base nos dados armazenados no Ethereum.

6. Mecanismo de incentivo do Polygon zkEVM

Os incentivos de rollup são principalmente sobre como tornar o Sequencer e o Aggregator lucrativos e, assim, manter o trabalho em andamento?

Em primeiro lugar, os usuários precisam pagar suas próprias taxas de transação no Rollup, que são denominadas em ETH e pagas em Bridged ETH.

O Sequencer precisará pagar o custo de carregar o Lote contendo a transação Rollup para os Calldata da transação L1 (o custo de chamar SequenceBatch(batches()), e o Matic precisará pagar uma certa quantia de Matic para o contrato L1 ao mesmo tempo em que o lote é carregado, que mais tarde pagará o custo do Agregador fornecer Prova de Validade para esses Lotes.

Enquanto o Agregador chama VerifyBatches confiáveis para fornecer Prova de Validade para Lotes no contrato L1 que ainda não foram finalizados, o Sequencer também pode retirar os tokens MATIC pagos antecipadamente pelo Sequencer no contrato como recompensa por fornecer Prova de Validade.

Receita do sequenciador = taxas de gás para todas as transações no rollup - taxas de gás de rede L1 gastas carregando lotes para L1 - taxas de atestado pagas ao agregador (denominação MATIC).

Receita do agregador = recompensas MATIC pagas pelo Sequencer - Taxas de gás submetidas à prova de validade para L1 - Taxas de hardware gastas gerando provas de validade.

Ajuste a taxa de atestado paga ao Agregador e, a fim de evitar que o Sequencer não seja lucrativo para atacar, o seguinte mecanismo é fornecido para ajustar a taxa de atestado paga pelo Sequencer ao Agregador.

Existe um método no contrato que ajusta o custo de fornecimento de provas para lotes:

função _updateBatchFee(uint64 newLastVerifiedBatch) interna

Ele altera uma variável no contrato chamada BatchFee, que determina a quantidade de tokens MATIC que o Sequencer paga por cada lote.

O mecanismo de mudança é o seguinte:

O contrato mantém uma variável VeryBatchTimeTarget que representa o estado esperado de cada lote a ser validado dentro desse tempo depois de ser confirmado com L1 pelo Sequencer.

O contrato registrará todos os lotes que não foram validados depois de exceder o VeryBatchTimeTarget, e o número total desses lotes será registrado como DiffBatches.

Portanto, quando um Batches está atrasado, o BatchFee será ajustado com a seguinte fórmula:

MultiplierBatchFee é um número limitado ao intervalo de 1000~1024, que pode ser alterado pelo administrador do contrato através da função setMultiplierBatchFee():

FunctionsetMultiplier BatchFee(uint16newMultiplierBatchFee) somente públicoAdmin

Deve-se notar que o uso de MultiplierBatchFee e 10^3 aqui é para alcançar a precisão de ajuste após 3 casas decimais.

Da mesma forma, se os lotes forem antecipados, o mecanismo de ajuste batchFee correspondente será acionado: DiffBatches indica o número de lotes no estado de verificação antecipada.

Resumo

Neste artigo, separamos o mecanismo central do Polygon zkEVM e analisamos sua viabilidade de alcançar o escalonamento computacional Ethereum. Com um esboço geral, nos próximos artigos vamos mergulhar no interior do protocolo, analisando os detalhes do projeto da ponte zkEVM, a rota de descentralização do Sequencer, a implementação do zkProver e os princípios de design do zkEVM.

——A continuar——