La primera parte de la serie zkEVM: la arquitectura general y el proceso de ejecución de transacciones de Polygon zkEVM

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

Editor:Red One

El 27 de marzo, se lanzó oficialmente la versión beta de la red principal de Polygon zkEVM, y Vitalik completó su primera transacción en ella.

Este artículo es el primero de una serie de artículos sobre Polygon zkEVM, que describe brevemente la arquitectura general y el proceso de ejecución de transacciones de Polygon zkEVM, y analiza cómo Polygon zkEVM logra el escalado computacional mientras hereda la seguridad de Ethereum.

En los próximos dos artículos, también detallaremos los detalles de diseño de zkEVM Bridge y zkEVM de Polygon zkEVM, así como la hoja de ruta para el próximo secuenciador descentralizado de Polygon zkEVM.

En primer lugar, Rollup es para lograr el escalado computacional para Ethereum

En primer lugar, tenemos que tener claro cómo funcionan los Rollups. La aparición de Rollup es para escalar el cálculo de Ethereum, el método de implementación específico es externalizar la ejecución de transacciones a Rollup, y luego almacenar la transacción y el estado (Estado) después de la ejecución de la transacción en el contrato de Ethereum.

Rollup optimista

Siendo optimistas, la transacción de acumulación y el estado de acumulación correspondiente enviado a Ethereum son correctos, y cualquiera puede impugnar un estado de acumulación que aún se encuentra en el período de impugnación proporcionando una prueba de fraude.

Rollup de conocimiento cero

ZK proporcionará una prueba de validez para la transacción de rollup enviada a Ethereum y el estado de rollup correspondiente (verificado por el contrato en Ethereum para demostrar que el rollup está en el estado correcto después de la ejecución de la transacción correspondiente).

Consulte la definición oficial de Ethereum:

La mayor diferencia entre el paquete acumulativo de conocimiento cero y el paquete acumulativo optimista es que el tiempo para alcanzar la finalidad es diferente debido a las diferentes formas de verificar la validez del estado.

Optimistic Rollup es optimista de que las transacciones y los estados enviados a Ethereum son correctos, por lo que existe un período de desafío de 7 días (el tiempo para llegar a la finalidad es de 7 días), durante el cual cualquier persona que encuentre que el estado correspondiente de una transacción en Ethereum es incorrecto puede impugnar enviando el estado correcto.

El tiempo que tarda un Zero-knowledge Rollup (zk-Rollup) en llegar a la finalidad depende del tiempo que tarda la prueba de validez de la transacción en enviarse a Ethereum y verificarse. En la actualidad, puede ser alrededor de 1 hora para la finalización (debido a la necesidad de considerar el costo del gas).

En segundo lugar, proceso de ejecución de Polygon zkEVM

Echemos un vistazo a cómo funciona Polygon zkEVM con un proceso simple de confirmación de transacciones, para tener una comprensión concreta del protocolo general, y todo su proceso se puede dividir en tres pasos principales:

1. El secuenciador empaqueta varias transacciones de usuario en lotes y las envía al contrato L1.

2. Prover genera una prueba de validez para cada transacción y agrega las pruebas de validez de múltiples transacciones en una sola prueba de validez.

3. El agregador presenta una prueba de validez de las múltiples transacciones agregadas del agregador en el contrato L1.

1 El secuenciador empaqueta las transacciones de los usuarios en lotes y las envía al contrato L1.

1. El usuario envía la transacción al secuenciador, y el secuenciador procesará la transacción localmente en el orden de recepción (FRFS), cuando el secuenciador ejecuta la transacción localmente, si el usuario cree que el secuenciador es honesto, entonces puede considerar que la transacción ha alcanzado la finalidad. Es importante tener en cuenta aquí que la mayoría de los Mempools dentro de Sequencer son actualmente privados, por lo que hay relativamente pocos MEV que se pueden obtener por el momento.

2. El secuenciador empaquetará múltiples transacciones en un lote (actualmente solo una transacción en un lote) y luego enviará varios lotes juntos a los datos de llamada de transacción de L1 a través de la función SequenceBatch() de PolygonZKEvm.sol en L1.

(Cabe señalar que se envían varios lotes a la vez para reducir al máximo el consumo de gas de L1).

3. Cuando PolygonZkEvm.sol reciba los lotes proporcionados por Sequencer, calculará el hash de cada lote en el contrato a su vez, y luego registrará el hash del lote anterior en el siguiente lote, por lo que obtenemos la estructura de lotes en la siguiente figura.

4) También se determina el orden de las transacciones en cada lote, por lo que cuando se determina el orden del lote, consideramos que se ha determinado el orden de todas las transacciones que se incluyen en el lote que se enviará al contrato L1 Polygon zkEVM.

El proceso real anterior también es el trabajo que L1 debe completar como capa DA consolidada (no se ha completado ningún trabajo de verificación o avance de estado en este momento).

**2. El agregador genera una prueba de validez para varios lotes de transacciones

1. Cuando el agregador escucha el envío exitoso de nuevos lotes en el contrato PolyonZKEVM.sol en L1, sincroniza estos lotes con su nodo y envía estas transacciones a zkProver.

2. Después de recibir estas transacciones, zkProver generará una prueba de validez para cada transacción y luego agregará la prueba de validez de las transacciones contenidas en múltiples lotes en una prueba de validez.

3. zkProver envía la prueba de validez de la agregación de múltiples transacciones al agregador.

3. El agregador presenta el contrato de pruebas agregadas a L1

El agregador enviará esta prueba de validez al contrato de Polygon zkEvm.sol en L1 junto con el estado correspondiente de la ejecución por lotes llamando al siguiente método:

A continuación, se realizan las siguientes acciones dentro del contrato para comprobar que la transición de estado es correcta.

Cuando este paso se ejecuta con éxito en el contrato L1, todas las transacciones incluidas en esta parte del lote alcanzarán realmente la finalidad (correspondiente al final del período de desafío de 7 días de OP).

3. El papel de Ethereum en Polygon-zkEVM

Ahora que hemos visto el proceso general de Polygon zkEVM, revisemos lo que Ethereum ha hecho por Rollup:

En el primer paso, Sequencer recopila las transacciones consolidadas y las empaqueta en lotes, que luego se envían al contrato L1. L1 no solo proporciona la funcionalidad de la capa DA, sino que también completa algunas de las funciones de ordenación de transacciones, cuando envía una transacción al secuenciador, la transacción no se ordena realmente, porque el secuenciador tiene el poder de cambiar el orden de las transacciones a voluntad, pero cuando la transacción se incluye en el lote y se envía al contrato L1, nadie tiene derecho a cambiar el orden de las transacciones.

En el segundo paso, el Agregador lleva la Prueba de Validez al contrato L1 para alcanzar el nuevo estado, el Agregador es un rol similar al Proponente, y el contrato es similar al rol de Validador, y el Agregador proporciona una Prueba de Validez para demostrar que el nuevo estado es correcto y le dice al Validador la Validez que proporciono Qué lotes de transacciones están implicados en Proof y dónde están en L1.

A continuación, el validador extrae el lote correspondiente del contrato y lo combina con la prueba de validez para verificar la legitimidad de la transición de estado y, si la verificación tiene éxito, el contrato se actualizará al nuevo estado de la prueba de validez correspondiente.

En cuarto lugar, estructurar el Smart Contract Rollup desde la perspectiva de la modularidad

Si desde el punto de vista de la modularidad, Polygon zkEVM pertenece al tipo Smart Contract Rollup, podemos intentar deconstruir sus módulos, y a partir del diagrama dado por Delphi, también podemos ver que Polygon ZkEVM es en realidad la Capa de Consenso, la Capa DA y la Liquidación de Smart Contrat Rollup En realidad, las capas están acopladas al contrato PolygonZkEVM.sol, que no se distingue bien. Pero intentemos deconstruir los módulos:

Capa de disponibilidad de datos: Donde se almacenan las transacciones de acumulación, y en el caso de Polygon-zkEVM, cuando Sequencer llama al método SequenceBatch(), en realidad incluye el envío de datos de transacciones a la capa DA.

Capa de liquidación: Se refiere específicamente al mecanismo de flujo de dinero entre Rollup y L1, específicamente el puente oficial de Polygon-zkEVM (más sobre esto en el próximo artículo).

Capa de consenso: contiene el orden de las transacciones y cómo determinar el siguiente estado válido (selección de bifurcación), Sequencer completa el orden de las transacciones cuando llama a SequenceBatch() en el contrato L1 y confirma el siguiente estado legal cuando Aggregator llama a TustedVerifyBatches() en el contrato L1.

Capa de ejecución: El proceso mediante el cual se ejecuta una transacción y se obtiene un nuevo estado mundial, cuando el usuario envía una transacción al secuenciador, y el nuevo estado se obtiene después de que se ejecuta el secuenciador ( Es por eso que tendemos a decir que los Rollups son escalado computacional, porque L1 externaliza el proceso de ejecución de transacciones para obtener un nuevo estado a los Rollups, y Sequencer delega zkProver para ayudar a generar Validity Proof a través del agregador.

5. Por qué Polygon-zkEVM hereda la seguridad de L1

A juzgar por el proceso general descrito anteriormente, Sequencer en realidad hace algo similar a Ethereum Proposer, proponiendo que un lote de transacciones son transacciones válidas, y dando el nuevo estado de este lote de transacciones después de la ejecución, y la lógica de verificación del contrato L1 es equivalente a que todos los validadores L1 se ejecutarán en sus propios clientes de Ethereum, de hecho, todos los validadores de Ethereum actúan como validadores de Rollup, por lo que creemos que Polygon zkEVM Heredó la seguridad de Ethereum.

Por otro lado, debido a que todas las transacciones y el estado de los Rollups se almacenan en Ethereum, incluso si el equipo de Polygon zkEVM huye, cualquiera seguirá teniendo la capacidad de recuperar toda la red de Rollups en función de los datos almacenados en Ethereum.

6. Mecanismo de incentivos de Polygon zkEVM

Los incentivos acumulativos se refieren principalmente a cómo hacer que Sequencer y Aggregator sean rentables y, por lo tanto, mantener el trabajo en marcha.

En primer lugar, los usuarios deben pagar sus propias tarifas de transacción en Rollup, que están denominadas en ETH y pagadas en ETH puenteado.

El secuenciador deberá pagar el costo de cargar el lote que contiene la transacción Rollup a los datos de llamada de la transacción L1 (el costo de llamar a SequenceBatch(batches()), y el Matic deberá pagar una cierta cantidad de Matic al contrato L1 al mismo tiempo que se carga el lote, que luego pagará el costo del agregador que proporciona la prueba de validez para estos lotes.

Mientras que el agregador llama a los VerifyBatches de confianza para proporcionar una prueba de validez para los lotes en el contrato L1 que aún no han sido definitivos, Sequencer también puede sacar los tokens MATIC pagados por adelantado por Sequencer en el contrato como recompensa por proporcionar una prueba de validez.

Ingresos del secuenciador = tarifas de gas para todas las transacciones en el rollup - tarifas de gas de red L1 gastadas en cargar lotes a L1 - tarifas de certificación pagadas al agregador (denominación MATIC).

Ingresos del agregador = Recompensas MATIC pagadas por el secuenciador - Tarifas de gas enviadas a prueba de validez a L1 - Tarifas de hardware gastadas en generar pruebas de validez.

Ajuste la tarifa de atestación pagada al Agregador y, para evitar que el Secuenciador no sea rentable de golpear, se proporciona el siguiente mecanismo para ajustar la tarifa de certificación pagada por el Secuenciador al Agregador.

Hay un método en el contrato que ajusta el costo de proporcionar pruebas para lotes:

function _updateBatchFee(uint64 newLastVerifiedBatch) internal

Cambia una variable en el contrato llamada BatchFee, que determina la cantidad de tokens MATIC que Sequencer paga por cada lote.

El mecanismo de cambio es el siguiente:

El contrato mantiene una variable VeryBatchTimeTarget que representa el estado esperado de cada lote que se va a validar dentro de ese tiempo después de que Sequencer lo confirme en L1.

El contrato registrará todos los lotes que no se hayan validado después de superar el VeryBatchTimeTarget, y el número total de estos lotes se registrará como DiffBatches.

Por lo tanto, cuando un Batches se retrasa, el BatchFee se ajustará con la siguiente fórmula:

MultiplierBatchFee es un número que está limitado al rango de 1000~1024, que puede ser cambiado por el administrador del contrato a través de la función setMultiplierBatchFee():

FunctionsetMultiplier BatchFee(uint16newMultiplierBatchFee) public onlyAdmin

Cabe señalar que el uso de MultiplierBatchFee y 10^3 aquí es para lograr la precisión del ajuste después de 3 puntos decimales.

Del mismo modo, si los lotes son por adelantado, se activará el mecanismo de ajuste batchFee correspondiente: DiffBatches indica el número de lotes en el estado de verificación temprana.

Resumen

En este artículo, resolvemos el mecanismo central de Polygon zkEVM y analizamos su viabilidad de lograr el escalado computacional de Ethereum. Con un esquema general, en los siguientes artículos nos sumergiremos en el interior del protocolo, analizando los detalles de diseño del zkEVM Bridge, la ruta de descentralización de Sequencer, la implementación de zkProver y los principios de diseño de zkEVM.

——Continuará——