Series Polygon zkEVM 2/2

¡Hola comunidad! 👋

¡Bienvenidos a la segunda parte de la serie Polygon zkEVM! En la primera parte, hicimos una introducción general sobre la arquitectura y componentes de esta tecnología, así como su pensamiento en cuanto a la compatibilidad/equivalencia con ETH, junto con su ética y valores fundamentales (Ethos).

En este artículo, explicaremos cómo se llega a un consenso a través de un Smart Contract y cómo funciona este mecanismo de incentivación económica.

También exploraremos cómo funcionan los estados de las transacciones y cómo se simulan y controlan varios estados para garantizar la validez de las transacciones con la seguridad en la capa de ETH, así como una parte de exploración de transacciones para aprender a visualizar esta información.

En la Parte 1 introducimos PoD (Proof of Donation) como un mecanismo de consenso utilizado en la blockchain. A diferencia de resolver problemas matemáticos complejos para validar transacciones y crear nuevos bloques, PoD funciona como una subasta descentralizada.

El modelo de implementación del Contrato de Consenso PolygonZkEVM.sol, emplea una técnica más sencilla y eficiente que el PoD para resolver los desafíos del consenso. Múltiples coordinadores producen batch en L2 y estos batch se crean a partir de las transacciones enrolladas de L1, este nuevo modelo es conocido como PoE (Proof of Efficiency)

La implementación estratégica del consenso basado en contratos tiene como objetivo garantizar que la red:

• 🌐 - Alcance un nivel aceptable de descentralización.

• 🔐 - Mantenga su característica Permissionless para producir batches L2.

• ⚡️ - Sea altamente eficiente, lo que es fundamental para el rendimiento general de la red.

• 🛡️ - Esté protegida de ataques malintencionados, especialmente por parte de los validadores.

• ⚖️ - Mantenga un equilibrio justo entre el esfuerzo global de validación y el valor de la red.

El contrato de Consenso PolygonZkEVM.sol desplegado en L1, se utiliza para garantizar que las transiciones de estado en el protocolo zkEVM se realizan de manera correcta, siguiendo un conjunto de reglas predefinidas. Este protocolo emplea una prueba de validez para asegurar la corrección de las transiciones de estado.

Para verificar que cada transición se completa correctamente, se utiliza un contrato inteligente que emplea circuitos zk-SNARK. El proceso se realiza en dos pasos, transacciones por batches y validación de transacciones.

En zkEVM, se utilizan dos tipos de participantes, Secuenciadores y Agregadores, para llevar a cabo los procedimientos.

• Los Secuenciadores: proponen batch de transacciones enrolladas en el Contrato de Consenso.

• Los Agregadores: verifican la validez de los batch y proporcionan pruebas de validez.

El contrato inteligente realiza dos llamadas, una para recibir los batch de los Secuenciadores y otra para validarlos con los Agregadores. Cualquier Agregador sin permisos puede enviar la prueba para demostrar la exactitud del cálculo de transición de estado.

El contrato inteligente de Consenso PolygonZkEVM.sol, establece los siguientes requisitos para los Secuenciadores y Agregadores:

Secuenciadores: actualmente, solo existe una entidad controladora que actúa como Secuenciador, aunque en el futuro se espera descentralizar este mecanismo. Por el momento, el contrato garantiza que solo el poseedor de la clave privada puede enviar secuencias. Sin embargo, veremos como habilitado en cierto casos prácticos el mecanismo forcebatch se consigue evitar la censura.

Para obtener el derecho a crear y proponer batches, el Secuenciador debe pagar una tarifa en forma de token MATIC. Si el Secuenciador propone batches válidos (que consisten en transacciones válidas), será incentivado con la tarifa pagada por los solicitantes de transacciones o los usuarios de la red.

Agregadores: son los responsable de recopilar todos los datos necesarios para una transacción y enviarlos al probador. El probador realizará cálculos polinómicos complejos para proporcionar una prueba zk que el contrato inteligente verificará para validar la transacción.

El Agregador también recibe la salida del proveedor y envía la información completa al contrato inteligente para su validación final.

Para poder proporcionar pruebas de validez para transacciones de capa 2, los Agregadores deben tener hardware especializado y ejecutar el software zkNode de zkEVM. Además, deben competir para producir pruebas de validez lo antes posible y el primer Agregador en presentar una prueba de validez gana la tarifa MATIC que paga el Secuenciador para ese batch específico.

En resumen, la tarea principal de un Agregador es proporcionar pruebas de validez para las transacciones propuestas por los Secuenciadores y competir para producir la primera prueba de validez y así ganar la tarifa MATIC. En cuanto a las tarifas y los incentivos, se ha diseñado una estructura adecuada para ellos, que se describe a continuación más detallada.

Como ya hemos visto en la arquitectura de zkEVM, la red cuenta con dos tipos de participantes: Secuenciadores y Agregadores. Es importante destacar que se han diseñado estructuras de incentivos adecuadas para cada uno de ellos con el fin de mantener la red rápida y segura. A continuación, se presenta un resumen de la estructura de tarifas para ambos.

El Secuenciador se encarga de recoger transacciones y publicarlas en batches. A cambio, recibe comisiones de las transacciones publicadas.

• Recoge transacciones y publica batches: el Secuenciador es responsable de recoger transacciones y agruparlas en batches para su procesamiento en la red zkEVM.

• Recibe comisiones: el Secuenciador recibe una comisión por cada transacción publicada en su batch.

• Paga las tarifas de transacción: el Secuenciador debe pagar las tarifas de transacción de L1 y MATIC (dependiendo de los batches pendientes).

• MATIC va a los Agregadores: parte de las tarifas de transacción pagadas por el Secuenciador se destinan a los Agregadores como incentivo para su participación.

• Es rentable si: las comisiones de las transacciones en el batch son mayores que la llamada L1 más la tarifa MATIC.

Los Agregadores son responsables de procesar las transacciones publicadas por los Secuenciadores, construir la prueba zk Proof y recibir MATIC como incentivo.

• Procesa las transacciones: los Agregadores procesan las transacciones publicadas por los Secuenciadores.

• Construyen zk Proof: los Agregadores deben construir la prueba zk Proof que valida la integridad de los batches de transacciones procesadas.

• Reciben MATIC: los Agregadores reciben MATIC como incentivo por su participación en la red zkEVM.

• Costo estático: los Agregadores deben pagar el costo de la llamada L1 y el costo del servidor para construir la prueba zk Proof.

• Es rentable si: la tarifa MATIC recibida es mayor que la llamada L1 más el costo del servidor.

Con estas estructuras de incentivos, zkEVM se mantiene rápido y seguro para sus participantes.

Para garantizar la sostenibilidad del sistema, los actores deben ser compensados por desempeñar correctamente sus roles y dar la finalidad del protocolo.

A menos que se especifique lo contrario, las medidas y reglas presentadas aquí se aplican a los casos en que los roles de Secuenciador y Agregador están descentralizados (es decir, cuando no haya Secuenciador de Confianza ni Agregador de Confianza), aunque veremos como aún esto no es el del todo posible, dado a la Confianza del Secuenciador.

La moneda nativa utilizada en L2 es Bridged Ether, que se origina en L1. Esta es la moneda que se utiliza para pagar las tarifas de transacción L2. Se puede transferir a una relación de intercambio 1: 1 de L1 a L2 y viceversa.

El Secuenciador gana las tarifas de transacción pagadas por los usuarios de L2 por enviar transacciones y, por lo tanto, se paga directamente en Bridged Ether. El monto de las tarifas pagadas depende del precio del gas, que es establecido por los usuarios en función de cuánto están dispuestos a pagar por la ejecución de sus transacciones.

Para incentivar al Agregador para cada batch secuenciado, el Secuenciador debe bloquear una serie de tokens MATIC en el Contrato de L1 PolygonZkEVM.sol proporcional al número de batches en la secuencia. El número de tokens MATIC bloqueados por batch secuenciado se guarda en la variable batchFee.

Para maximizar sus ingresos, el Secuenciador prioriza las transacciones con precios más altos de gas. Además, hay un umbral por debajo del cual no es rentable para el Secuenciador ejecutar transacciones porque las tarifas ganadas por los usuarios de L2 son menores que las tarifas pagadas por las tarifas de secuenciación (más la transacción de secuenciación y fee en L1).

Los usuarios deben asegurarse de que sus tarifas de transacción sean mayores que esto umbral para que el Secuenciador sea incentivado a procesar sus transacciones.

El valor neto de Ether obtenido por el Secuenciador para secuenciar una secuencia de batch está representado por la siguiente expresión:

• totalL2TxGasFeeses: es la suma total de las tarifas recaudadas de todas las transacciones L2 incluidas en la secuencia de lotes.

• L1SeqTxGasFeees: es la tarifa de gas de transacción de secuenciación pagada en L1.

• batchFee: es la variable de almacenamiento en el SC PolygonZkEVM.sol

• nBatcheses: es el número de batch en la secuencia.

• MATIC/ETH: es el precio de la ficha MATIC expresada en ETH.

El Agregador también necesita una compensación por cumplir correctamente su función.

El número de tokens MATIC que gana el Agregador cada vez que agrega una secuencia, denominado como batchReward, está determinado por el balance total del contrato MATIC y el número de batches agregados.

El MATIC ganado por batch agregado se calcula por el contrato L1 PolygonZkEVM.sol antes de la agregación de la secuencia utilizando la siguiente expresión:

La siguiente expresión representa la cantidad total de valor ETH que el Agregador ganará por la agregación de una secuencia de batches:

• L1AggTxGasFee: es la tarifa de gas de transacción de agregación pagada en L1.

• batchReward: es la cantidad de MATIC ganado por lote agregado.

• nBatches: es el número de batches en la secuencia

• MATIC/ETH: es el precio del token MATIC expresado en ETH.

Ahora procedamos a analizar en el explorador filtrado por la dirección del proxy con el token MATIC, para observar las entradas y salidas. De esta manera, podremos entender cómo el Secuenciador brinda un incentivo para el Agregador y cómo se retira una vez que el verificador ha realizado la prueba y se ha consolidado el estado.

En este caso, es importante destacar que la suma de las entradas de MATIC de los Sequence Batches debe ser igual a la salida de MATIC por los Verify Batches Trusted Aggregator, la cual indicará el estado ya consolidado con la prueba en L1 en la que vemos también un intervalo de tiempo entre Sequence Batches de 10 min entre ellos. Si en alguna ocasión estas sumas no coinciden, se debe revisar las transacciones y verificar que todo sea correcto, ya que a veces la visualización en el explorador puede ser engañosa y coincidir con la anterior “IN” y luego procesar una salida anterior.

Además, como aprendimos estos batches deben tener al menos 1 batch. En la imagen superior se aprecia que hay hasta 5 batches. En el ejemplo que estamos analizando, las sumas de "IN" coinciden con las de "OUT" de 2.8 y 2.2 MATIC, respectivamente.

Ahora explicaremos cómo el Protocolo Polygon zkEVM gestiona los estados del Rollup L2 al tiempo que proporciona verificabilidad y seguridad de transición estatal.

El Secuenciador de Confianza genera batches, pero para lograr una finalidad rápida de las transacciones L2 y evitar la necesidad de esperar el próximo bloque L1, se comparten con los nodos de red L2 a través de un canal de transmisión. Cada nodo ejecutará los batches para calcular el estado L2 resultante localmente.

Una vez el Secuenciador ha comprometido las secuencias de batches obtenidos directamente de los nodos de red L1, L2 los ejecutarán nuevamente, y ya no tendrán que confiar en ellos.

La ejecución fuera de cadena de los batches eventualmente se verificará en cadena a través de una zk Proof, y se comprometerá la raíz resultante del Estado L2. A medida que avanza el protocolo zkEVM, las nuevas raíces de estado L2 se sincronizarán directamente desde los nodos de red L1 en L2.

Tanto la disponibilidad de los datos como la verificación de la ejecución de las transacciones dependen únicamente de los supuestos de seguridad de L1 y, en la fase final del protocolo, los nodos sólo dependerán de los datos presentes en L1 para mantenerse sincronizados con cada transición de estado de L2.

Los nodos L2 pueden recibir datos de batches de tres maneras diferentes:

• Directamente desde el Secuenciador antes de que los batches estén comprometidos con L1, o bien.

• Directamente desde L1 después de que los batches hayan sido secuenciados.

• O sólo después de que el Agregador haya probado la corrección de la ejecución y verificado por el contrato PolygonZkEVM.sol

Vale la pena señalar que los tres formatos de datos de batch son recibidos por los nodos L2 en orden cronológico enumerado anteriormente.

Hay tres etapas del estado L2, cada una correspondiente a las tres formas diferentes en que los nodos L2 pueden actualizar su estado. Los tres casos dependen del formato de los datos del batch utilizados para actualizar el estado L2.

En el primera instancia, la actualización se basa únicamente en la información (i.e., batches que consisten en transacciones ordenadas) que provienen directamente del Secuenciador de Confianza, antes de cualquier disponibilidad de datos en L1. El estado L2 resultante se llama Estado de Confianza “Trusted State”.

En el segundo caso, la actualización se basa en información recuperada de la red L1 por nodos L2. Es decir, después de que los batches hayan sido secuenciados y los datos se hayan puesto a disposición en L1. El estado L2 se conoce como el Estado virtual “Virtual State”.

La información utilizada para actualizar el estado L2 en el último caso incluye zk Proof verificadas de integridad computacional. Es decir, después de que la zk Proof se haya verificado con éxito en los nodos L1, L2 sincronizan su raíz local del estado “State root” L2 con el cometido en L1 por el Agregador de Confianza “Trusted Aggregator”. Como resultado, dicho Estado L2 se conoce como el Estado Consolidado “Consolidated State”.

La siguiente figura muestra la línea de tiempo de las etapas del estado L2 desde una perspectiva de un batch, así como las acciones que desencadenan la progresión de una etapa a la siguiente.

Las transacciones en la red Polygon zkEVM se crean en las billeteras de los usuarios y se firman con sus claves privadas.

Una vez generado y firmado, las transacciones se envían al nodo del Secuenciador de Confianza a través de su interfaz JSON-RPC. Las transacciones se almacenan en el grupo de transacciones pendientes, donde esperan la selección del Secuenciador para su ejecución o descarte.

Los usuarios y el zkEVM se comunican utilizando JSON-RPC, que es totalmente compatible con Ethereum RPC. Este enfoque permite que cualquier aplicación compatible con EVM, como el software de billetera, funcione y se sienta como usuarios reales de la red Ethereum.

En el diseño actual, una sola transacción es equivalente a un bloque.

Esta estrategia de diseño no solo mejora la comunicación RPC y P2P entre nodos, sino que también mejora la compatibilidad con las herramientas existentes y facilita la finalidad rápida en L2. También simplifica el proceso de localización de transacciones de usuarios.

El Secuenciador de Confianza ”Trusted Sequencer “, lee las transacciones del grupo y decide si descartar ellos u ordenar y ejecutar ellos. Las transacciones que se han ejecutado se agregan a un batch de transacciones, y se actualiza el estado local de L2 del Secuenciador.

Una vez que se agrega una transacción al estado L2, se transmite a todos los demás nodos zkEVM a través de un servicio de transmisión. Vale la pena señalar que confiando en el Secuenciador de Confianza, podemos lograr una finalidad de transacción rápida (más rápida que en L1). Sin embargo, el Estado L2 resultante estará en un estado confiable hasta que el batch se comprometa en el Contrato de Consenso.

Los usuarios suelen interactuar con el Estado L2 de Confianza. Sin embargo, debido a determinadas características del protocolo, el proceso de verificación de las transacciones L2 (en la capa 1 para permitir las retiradas) puede llevar mucho tiempo, normalmente unos 30 minutos, pero hasta 2 semanas en casos excepcionales. En consecuencia, los usuarios deben ser conscientes de los riesgos potenciales asociados a las transacciones de alto valor, en particular las que no pueden anularse, como las retiradas, las transacciones en ventanilla y los puentes alternativos.

El Secuenciador de Confianza debe procesar las transacciones por batches utilizando la siguiente estructura BatchData especificada en el contrato PolygonZkEVM.sol.

  struct BatchData {
     bytes transactions;
     bytes32 globalExitRoot;
     uint64 timestamp;
     uint64 minForcedTimestamp;
}

Son arrays de bytes (estructura de datos con elementos homogéneos, del mismo tipo, numérico o alfanumérico) que contienen las transacciones por batches concatenados.

Cada transacción se codifica según los formatos Ethereum pre-EIP-155 o EIP-155 utilizando el estándar RLP (prefijo de longitud recursiva), pero los valores de firma, v, r y s, se concatenan como se muestra a continuación;

1. EIP-155: RLP (nonce,gasprice,gasLimit,to,value,data,chainid,0,0,)#v#r#s

2. pre-EIP-155: RLP (nonce,gasprice,gasLimit,to,value,data)#v#r#s.

Es la raíz del árbol Merkle de salida global del puente, que se sincronizará en el estado L2 al inicio de la ejecución por batches.

El puente transporta activos entre L1 y L2, y una transacción de reclamación desbloquea el activo en la red de destino.

Al igual que los bloques de Ethereum tienen marcas de tiempo, cada batch tiene una marca de tiempo.

Hay dos restricciones que cada marca de tiempo debe satisfacer para asegurar que los batches están ordenados en el tiempo y sincronizados con los bloques L1:

1. La marca de tiempo de un batch determinado debe ser mayor o igual que la marca de tiempo del último batch secuenciado.

2. La marca de tiempo máxima que un Secuenciador de Confianza puede asignar a un batch es la marca de tiempo del bloque en el que se ejecuta la transacción L1 de secuenciación.

Si un batch es de los denominados forzados, este parámetro debe ser mayor que cero. La censura se contrarresta utilizando batches forzados.

Los batches deben secuenciarse y validarse antes de que puedan formar parte del Estado Virtual L2.

El Secuenciador de Confianza añade con éxito un lote a una secuencia de batches utilizando el mapeo sequencedBatches del contrato L1 PolygonZkEVM.sol, que es básicamente una estructura de almacenamiento que contiene la cola de secuencias que definen el Estado Virtual.

// SequenceBatchNum --> SequencedBatchData
mapping(uint64 => SequencedBatchData) public sequencedBatches;

Para que un batch pueda ser secuenciado, debe ser parte de la colección de batches que se secuenciarán. El Secuenciador de Confianza llama al Contrato PolygonZkEVM.sol, que utiliza su mapeo sequenceBatches. Este mapeo acepta una matriz de batches que se secuenciarán como argumento.

La constante pública del contrato, MAX_TRANSACTIONS_BYTE_LENGTH, determina el número máximo de transacciones que pueden incluirse en un lote (300000).

Del mismo modo, el número de batches de una secuencia está limitado por la constante pública del contrato MAX_VERIFY_BATCHES (1000). La matriz de batches debe contener al menos un batch y no más que el valor de la constante MAX_VERIFY_BATCHES.

La función sequencedBatches itera sobre cada batch de la secuencia, comprobando su validez. Un batch válido debe cumplir los siguientes criterios:

• Debe incluir un valor globalExitRoot que esté presente en el GlobalExitRootMap del contrato L1 PolygonZkEVMGlobalExitRoot.sol del puente. Un batch sólo es válido si incluye un globalExitRoot válido.

• La longitud de la matriz de bytes de transacciones debe ser inferior al valor de la constante MAX_TRANSACTIONS_BYTE_LENGTH.

• La marca de tiempo del batch debe ser mayor o igual que la del último batch secuenciado, pero menor o igual que la marca de tiempo del bloque en el que se ejecuta la transacción L1 secuenciada. Todos los batch deben estar ordenados por hora.

Si un batch no es válido, la transacción revierte, descartando toda la secuencia. En caso contrario, si todos los batch a secuenciar son válidos, el proceso de secuenciación continuará.

Como contador de batch se utiliza una variable de almacenamiento denominada lastBatchSequenced, que se incrementa cada vez que se secuencia un batch. Da un número de índice específico a cada batch que se utilizará como valor de posición en la cadena de batches.

El mismo mecanismo hash utilizado en las cadenas de bloques para enlazar un bloque con el siguiente se utiliza en los batches para garantizar la integridad criptográfica de la cadena de batches. Es decir, se incluye el resumen del batch anterior entre los datos utilizados para calcular el resumen del batch siguiente.

Como resultado, el resumen de un batch determinado es un hash acumulado de todos los batches secuenciados previamente, de ahí el nombre de hash acumulado de un batch, denotado por oldAccInputHash para el antiguo y newAccInputHash para el nuevo.

Un hash acumulado de un batch específico tiene la siguiente estructura:

keccak256 ( 
    abi.encodePacked (
        bytes32 oldAccInputHash, 
        keccak256(bytes transactions), 
        bytes32 globalExitRoot ,
        uint64 timestamp ,
        address seqAddress
    )
)

• oldAccInputHashes el hash acumulado del batch secuenciado anterior.

• keccack256(transactions)es el resumen de Keccak de la matriz de bytes de transacciones.

• globalExitRootes la raíz del árbol Merkle de salida global del puente.

• timestampes la marca de tiempo del batch.

• seqAddresses la dirección del Secuenciador de batches.

Como se muestra en el diagrama anterior, cada hash de entrada acumulado garantiza la integridad de los datos del batch actual (i.e., transactions, timestamp, y globalExitRoot, así como el orden en que fueron secuenciados).

Es importante tener en cuenta que cualquier cambio en la cadena de batches hace que todos los hash de entrada acumulados futuros sean incorrectos, lo que demuestra una falta de integridad en el estado L2 resultante.

Dado que las operaciones de almacenamiento en L1 son muy caras en términos de consumo de gas, es fundamental usarlo lo menos posible. Para lograr esto, las ranuras de almacenamiento (o las entradas de mapeo) se usan únicamente para almacenar un compromiso de secuencia.

Cada entrada de mapeo comete dos índices de batch.

• Ultimo batch de la secuencia anterior como valor de SequencedBatchData estructurar.

• Último batch de la secuencia actual como clave de mapeo.

Junto con el hash acumulado del último batch en la secuencia actual y una marca de tiempo.

Es importante tener en cuenta que solo se guarda el hash acumulado del último batch en la secuencia; todos los demás se calculan sobre la marcha para obtener el último.

Como se indicó anteriormente, el resumen del hash será un compromiso de toda la cadena de batches. Los índices de batch también comprometen información útil como el número de batches en la secuencia y su posición en la cadena de batches. La marca de tiempo ancla la secuencia a un punto específico en el tiempo.

La disponibilidad de datos de las transacciones L2 está garantizada porque los datos de cada batch se pueden recuperar la calldata de la transacción de secuenciación, que no forma parte del almacenamiento del contrato pero es parte del Estado L1. Finalmente un SequenceBatches emitirá el evento.

event SequenceBatches (uint64 indexed numBatch)

Una vez que los batches se secuencian correctamente en L1, todos los nodos zkEVM pueden sincronizar su estado L2 local obteniendo los datos directamente de L1 PolygonZkEVM.sol contrato, sin tener que depender solo del Secuenciador de confianza. Así es como se alcanza el estado virtual L2.

Los Agregadores de Confianza eventualmente debería agregar las secuencias de batches previamente cometidos por los Secuenciadores de Confianza para lograr la etapa final del Estado L2, que es el Estado Consolidado.

Agregar una secuencia significa agregar con éxito la raíz de estado L2 resultante a batchNumToStateRoot mapeo en el contrato L1 PolygonZkEVM.sol. Esta es una estructura de almacenamiento que contiene todas las raíces consolidadas del Estado L2, que están codificadas por el último índice de batch de cada secuencia agregada de batches.

// BatchNum --> state root
mapping (uint64 => bytes32) public batchNumToStateRoot;

Además, la agregación implica la verificación exitosa de la zk Proof de la integridad computacional de la ejecución de batches de transacciones.

SNARK, es el esquema subyacente zk Proof de verificación. Una de sus características clave es la concisión y la velocidad de verificación de la prueba.

Como resultado, la integridad de un cálculo exhaustivo se puede verificar utilizando una fracción de los recursos computacionales requeridos por el cálculo original. Como resultado, al emplear un esquema SNARK, podemos proporcionar seguridad en la cadena a cálculos exhaustivos fuera de la cadena de una manera eficiente con el gas.

Como se muestra en el diagrama anterior, la ejecución fuera de cadena de los batch supondrá una transición de estado L2 y, en consecuencia, un cambio a una nueva raíz de estado L2.

La integridad del cálculo (CI) prueba de la ejecución es generada por el Agregador, y su verificación en cadena garantiza la validez de la raíz de estado L2 resultante.

Los Executor y Prover son servicios del nodo Aggregator que ejecutan batch y generan pruebas. Los trataremos aquí como unos intérpretes de EVM que pueden:

• Ejecutar una secuencia de batches de transacciones en el estado L2 actual.

• Calcular la raíz de estado L2 resultante.

• Generar una zk Proof de integridad computacional para la ejecución.

El sistema de verificación y la prueba están diseñados de tal manera que una verificación exitosa de la prueba demuestra criptográficamente que la ejecución de una secuencia dada de batches sobre un Estado L2 específico resulta en un Estado L2 representado por el argumento newStateRoot.

Resumiendo y repasando lo aprendido antes de comenzar las exploraciones, en Polygon zkEVM se divide el estado en tres etapas: Trusted State, Virtual State y Consolidated State. Cada una de estas etapas representa una forma diferente en que los nodos de capa 2 pueden actualizar su estado.

• 1ª Etapa: se basa en información del Secuenciador de confianza antes de que los datos estén disponibles en L1.

• 2ª Etapa: utiliza información de la red L1 después de que los batch hayan sido secuenciados y los datos estén disponibles en L1.

• 3ª Etapa: utiliza zk Proof para actualizar el estado L2.

En la tabla inferior se describen las diferencias observadas en los batches de transacciones desde el Estado de Confianza “Trusted State” al Estado Virtual “Virtual State”, donde el batch ya ha sido secuenciado y los datos están disponibles en L1, a falta de la última Validity Proof.

Escogimos aleatoriamente batches, pero profundizaremos más entre los batch 10.680 y 10.683. Si los analizamos, vemos que comparten el mismo exitGlobalRoot, lo que significa que hay varios batches dentro de un mismo batch. Concretamente, se trata de cuatro batches distintos, cada uno con sus propias transacciones. En lugar de agregar un único batch, el Secuenciador agregó los cuatro batches compartiendo la misma raíz.

En los ejemplos que tienen un timestamp de alrededor de 400-510 segundos, suele haber un solo batch agregado y el timestamp que se observa corresponde a este único batch.

Sin embargo, en el caso mencionado anteriormente, el timestamp se va registrando cada vez que se agrega un nuevo batch con la misma exitGlobalRoot, hasta llegar al cuarto batch en el ejemplo 10.683. En este caso, el timestamp total marcado por el exitGlobalRoot en L1 es de 12283 sg entre el principio y el final de la secuencia de batches.

En el siguiente ejemplo, analizaremos el explorador de Polygon zkEVM y exploraremos la relación entre los batches, las transacciones y los bloques. En términos generales, encontramos una relación 1:1, lo que indica que las transacciones en los batches se corresponden con las totales de los bloques como aprendimos en el documento. Si deseas examinar estos datos, te proporcionaremos guías orientativas a continuación junto con el enlace al zkEVM PolygonScan para poder analizar su explorador.

https://zkevm.polygonscan.com/

Una vez hayas seleccionado una transacción o un batch, se mostrarán una serie de parámetros relevantes para el análisis, los cuales ya hemos revisado en el documento.

En este caso, examinaremos un ejemplo aleatorio del batch "10.681", el cual puedes observar en la tabla adjunta.

1. Global Exit Root: es la raíz del árbol Merkle de salida global del puente, que se sincronizará en el estado L2 al inicio de la ejecución por batches.

2. Acc Input Hash: es la huella digital criptográfica única del último batch en la secuencia.

3. Sequence Tx Hash: es el Hash de la transacción del Secuenciador en la que contendrá los datos del batch secuenciado.

4. Verify Batch Tx Hash: es el Hash de la transacción del Agregador después de verificar con la zk Proof que los datos son los correctos y consolidarlos en L1.

5. State Root: es la raíz del árbol Merkle de estado en L2 después de que se hayan ejecutado las transacciones de un batch sobre el estado anterior de L2. Es decir, es el resultado final de la actualización del estado en L2 después de la ejecución de las transacciones de un batch. Esta información se utiliza para la validación y sincronización de la información en la red.

6. l2Coinbase: la dirección del Secuenciador que envía la recompensa bloqueada para incentivar al Agregador a procesar batches.

7. batches.timestamp: la marca de tiempo en segundos en el momento en que se procesó el batch.

Otros datos de la transacción:

• batches.transactions: una lista de transacciones codificadas en bytes que se procesaron en el batch.

• batches.globalExitRoot: la raíz de Merkle del estado global de la cadena de bloques en el momento en que se procesó el batch. Esto se utiliza para verificar que una salida se ha incluido en la cadena.

• batches.minForcedTimestamp: el tiempo mínimo en segundos para que se fuerce la inclusión del batch.

Si deseas obtener más información sobre el contrato principal del rollup PolygonZkEvm puede revisar: 0x5132...7aB2Implementation (Upgradable)Admin, podrás acceder a las reglas del sistema, incluyendo los parámetros básicos, los actores con permisos y los procedimientos de emergencia. Este contrato es responsable de recibir batches de transacciones, raíces de estado de L2 y pruebas zk, lo que permite revisar prácticamente todos los aspectos del sistema.

También sugerimos explorar nuestra Biblioteca Layer 2 en Español y consultar en L2Beat, donde encontrarás información adicional sobre el estado y los riesgos asociados a Polygon zkEVM.

Actualmente, el principal inconveniente se relaciona con la posible falla del Secuenciador y su incapacidad para enviar batches de transacciones. Si esta función no está disponible, los usuarios no podrán confiar en el mecanismo de forzar batches, como se indica en L2Beat, ya que actualmente está deshabilitado.

Recuerda que siempre es importante consultar fuentes actualizadas para obtener la información más precisa sobre el estado y las características del sistema.

🎉 ¡Gracias por leer hasta el final!🎉 Si está interesado en esta solución de escalabilidad, le recomendamos revisar la primera parte o escuchar el Space para L2 en Español con el equipo de Polygon

https://www.youtube.com/live/O4WiUD7L1KA?feature=share&cbrd=1

Si quieren seguir aprendiendo y colaborando con nosotros, le invitamos a unirse a nuestra vibrante comunidad de Telegram L2 en Español y a seguirnos en nuestro Twitter L2 en Español. Allí encontrará una gran cantidad de información sobre Layer 2 y el ecosistema de Blockchain en general. ¡Te Esperamos!

Series Polygon zkEVM 2/2

¡Hola comunidad! 👋

¡Bienvenidos a la segunda parte de la serie Polygon zkEVM! En la primera parte, hicimos una introducción general sobre la arquitectura y componentes de esta tecnología, así como su pensamiento en cuanto a la compatibilidad/equivalencia con ETH, junto con su ética y valores fundamentales (Ethos).

En este artículo, explicaremos cómo se llega a un consenso a través de un Smart Contract y cómo funciona este mecanismo de incentivación económica.

También exploraremos cómo funcionan los estados de las transacciones y cómo se simulan y controlan varios estados para garantizar la validez de las transacciones con la seguridad en la capa de ETH, así como una parte de exploración de transacciones para aprender a visualizar esta información.

En la Parte 1 introducimos PoD (Proof of Donation) como un mecanismo de consenso utilizado en la blockchain. A diferencia de resolver problemas matemáticos complejos para validar transacciones y crear nuevos bloques, PoD funciona como una subasta descentralizada.

El modelo de implementación del Contrato de Consenso PolygonZkEVM.sol, emplea una técnica más sencilla y eficiente que el PoD para resolver los desafíos del consenso. Múltiples coordinadores producen batch en L2 y estos batch se crean a partir de las transacciones enrolladas de L1, este nuevo modelo es conocido como PoE (Proof of Efficiency)

La implementación estratégica del consenso basado en contratos tiene como objetivo garantizar que la red:

• 🌐 - Alcance un nivel aceptable de descentralización.

• 🔐 - Mantenga su característica Permissionless para producir batches L2.

• ⚡️ - Sea altamente eficiente, lo que es fundamental para el rendimiento general de la red.

• 🛡️ - Esté protegida de ataques malintencionados, especialmente por parte de los validadores.

• ⚖️ - Mantenga un equilibrio justo entre el esfuerzo global de validación y el valor de la red.

El contrato de Consenso PolygonZkEVM.sol desplegado en L1, se utiliza para garantizar que las transiciones de estado en el protocolo zkEVM se realizan de manera correcta, siguiendo un conjunto de reglas predefinidas. Este protocolo emplea una prueba de validez para asegurar la corrección de las transiciones de estado.

Para verificar que cada transición se completa correctamente, se utiliza un contrato inteligente que emplea circuitos zk-SNARK. El proceso se realiza en dos pasos, transacciones por batches y validación de transacciones.

En zkEVM, se utilizan dos tipos de participantes, Secuenciadores y Agregadores, para llevar a cabo los procedimientos.

• Los Secuenciadores: proponen batch de transacciones enrolladas en el Contrato de Consenso.

• Los Agregadores: verifican la validez de los batch y proporcionan pruebas de validez.

El contrato inteligente realiza dos llamadas, una para recibir los batch de los Secuenciadores y otra para validarlos con los Agregadores. Cualquier Agregador sin permisos puede enviar la prueba para demostrar la exactitud del cálculo de transición de estado.

El contrato inteligente de Consenso PolygonZkEVM.sol, establece los siguientes requisitos para los Secuenciadores y Agregadores:

Secuenciadores: actualmente, solo existe una entidad controladora que actúa como Secuenciador, aunque en el futuro se espera descentralizar este mecanismo. Por el momento, el contrato garantiza que solo el poseedor de la clave privada puede enviar secuencias. Sin embargo, veremos como habilitado en cierto casos prácticos el mecanismo forcebatch se consigue evitar la censura.

Para obtener el derecho a crear y proponer batches, el Secuenciador debe pagar una tarifa en forma de token MATIC. Si el Secuenciador propone batches válidos (que consisten en transacciones válidas), será incentivado con la tarifa pagada por los solicitantes de transacciones o los usuarios de la red.

Agregadores: son los responsable de recopilar todos los datos necesarios para una transacción y enviarlos al probador. El probador realizará cálculos polinómicos complejos para proporcionar una prueba zk que el contrato inteligente verificará para validar la transacción.

El Agregador también recibe la salida del proveedor y envía la información completa al contrato inteligente para su validación final.

Para poder proporcionar pruebas de validez para transacciones de capa 2, los Agregadores deben tener hardware especializado y ejecutar el software zkNode de zkEVM. Además, deben competir para producir pruebas de validez lo antes posible y el primer Agregador en presentar una prueba de validez gana la tarifa MATIC que paga el Secuenciador para ese batch específico.

En resumen, la tarea principal de un Agregador es proporcionar pruebas de validez para las transacciones propuestas por los Secuenciadores y competir para producir la primera prueba de validez y así ganar la tarifa MATIC. En cuanto a las tarifas y los incentivos, se ha diseñado una estructura adecuada para ellos, que se describe a continuación más detallada.

Como ya hemos visto en la arquitectura de zkEVM, la red cuenta con dos tipos de participantes: Secuenciadores y Agregadores. Es importante destacar que se han diseñado estructuras de incentivos adecuadas para cada uno de ellos con el fin de mantener la red rápida y segura. A continuación, se presenta un resumen de la estructura de tarifas para ambos.

El Secuenciador se encarga de recoger transacciones y publicarlas en batches. A cambio, recibe comisiones de las transacciones publicadas.

• Recoge transacciones y publica batches: el Secuenciador es responsable de recoger transacciones y agruparlas en batches para su procesamiento en la red zkEVM.

• Recibe comisiones: el Secuenciador recibe una comisión por cada transacción publicada en su batch.

• Paga las tarifas de transacción: el Secuenciador debe pagar las tarifas de transacción de L1 y MATIC (dependiendo de los batches pendientes).

• MATIC va a los Agregadores: parte de las tarifas de transacción pagadas por el Secuenciador se destinan a los Agregadores como incentivo para su participación.

• Es rentable si: las comisiones de las transacciones en el batch son mayores que la llamada L1 más la tarifa MATIC.

Los Agregadores son responsables de procesar las transacciones publicadas por los Secuenciadores, construir la prueba zk Proof y recibir MATIC como incentivo.

• Procesa las transacciones: los Agregadores procesan las transacciones publicadas por los Secuenciadores.

• Construyen zk Proof: los Agregadores deben construir la prueba zk Proof que valida la integridad de los batches de transacciones procesadas.

• Reciben MATIC: los Agregadores reciben MATIC como incentivo por su participación en la red zkEVM.

• Costo estático: los Agregadores deben pagar el costo de la llamada L1 y el costo del servidor para construir la prueba zk Proof.

• Es rentable si: la tarifa MATIC recibida es mayor que la llamada L1 más el costo del servidor.

Con estas estructuras de incentivos, zkEVM se mantiene rápido y seguro para sus participantes.

Para garantizar la sostenibilidad del sistema, los actores deben ser compensados por desempeñar correctamente sus roles y dar la finalidad del protocolo.

A menos que se especifique lo contrario, las medidas y reglas presentadas aquí se aplican a los casos en que los roles de Secuenciador y Agregador están descentralizados (es decir, cuando no haya Secuenciador de Confianza ni Agregador de Confianza), aunque veremos como aún esto no es el del todo posible, dado a la Confianza del Secuenciador.

La moneda nativa utilizada en L2 es Bridged Ether, que se origina en L1. Esta es la moneda que se utiliza para pagar las tarifas de transacción L2. Se puede transferir a una relación de intercambio 1: 1 de L1 a L2 y viceversa.

El Secuenciador gana las tarifas de transacción pagadas por los usuarios de L2 por enviar transacciones y, por lo tanto, se paga directamente en Bridged Ether. El monto de las tarifas pagadas depende del precio del gas, que es establecido por los usuarios en función de cuánto están dispuestos a pagar por la ejecución de sus transacciones.

Para incentivar al Agregador para cada batch secuenciado, el Secuenciador debe bloquear una serie de tokens MATIC en el Contrato de L1 PolygonZkEVM.sol proporcional al número de batches en la secuencia. El número de tokens MATIC bloqueados por batch secuenciado se guarda en la variable batchFee.

Para maximizar sus ingresos, el Secuenciador prioriza las transacciones con precios más altos de gas. Además, hay un umbral por debajo del cual no es rentable para el Secuenciador ejecutar transacciones porque las tarifas ganadas por los usuarios de L2 son menores que las tarifas pagadas por las tarifas de secuenciación (más la transacción de secuenciación y fee en L1).

Los usuarios deben asegurarse de que sus tarifas de transacción sean mayores que esto umbral para que el Secuenciador sea incentivado a procesar sus transacciones.

El valor neto de Ether obtenido por el Secuenciador para secuenciar una secuencia de batch está representado por la siguiente expresión:

• totalL2TxGasFeeses: es la suma total de las tarifas recaudadas de todas las transacciones L2 incluidas en la secuencia de lotes.

• L1SeqTxGasFeees: es la tarifa de gas de transacción de secuenciación pagada en L1.

• batchFee: es la variable de almacenamiento en el SC PolygonZkEVM.sol

• nBatcheses: es el número de batch en la secuencia.

• MATIC/ETH: es el precio de la ficha MATIC expresada en ETH.

El Agregador también necesita una compensación por cumplir correctamente su función.

El número de tokens MATIC que gana el Agregador cada vez que agrega una secuencia, denominado como batchReward, está determinado por el balance total del contrato MATIC y el número de batches agregados.

El MATIC ganado por batch agregado se calcula por el contrato L1 PolygonZkEVM.sol antes de la agregación de la secuencia utilizando la siguiente expresión:

La siguiente expresión representa la cantidad total de valor ETH que el Agregador ganará por la agregación de una secuencia de batches:

• L1AggTxGasFee: es la tarifa de gas de transacción de agregación pagada en L1.

• batchReward: es la cantidad de MATIC ganado por lote agregado.

• nBatches: es el número de batches en la secuencia

• MATIC/ETH: es el precio del token MATIC expresado en ETH.

Ahora procedamos a analizar en el explorador filtrado por la dirección del proxy con el token MATIC, para observar las entradas y salidas. De esta manera, podremos entender cómo el Secuenciador brinda un incentivo para el Agregador y cómo se retira una vez que el verificador ha realizado la prueba y se ha consolidado el estado.

En este caso, es importante destacar que la suma de las entradas de MATIC de los Sequence Batches debe ser igual a la salida de MATIC por los Verify Batches Trusted Aggregator, la cual indicará el estado ya consolidado con la prueba en L1 en la que vemos también un intervalo de tiempo entre Sequence Batches de 10 min entre ellos. Si en alguna ocasión estas sumas no coinciden, se debe revisar las transacciones y verificar que todo sea correcto, ya que a veces la visualización en el explorador puede ser engañosa y coincidir con la anterior “IN” y luego procesar una salida anterior.

Además, como aprendimos estos batches deben tener al menos 1 batch. En la imagen superior se aprecia que hay hasta 5 batches. En el ejemplo que estamos analizando, las sumas de "IN" coinciden con las de "OUT" de 2.8 y 2.2 MATIC, respectivamente.

Ahora explicaremos cómo el Protocolo Polygon zkEVM gestiona los estados del Rollup L2 al tiempo que proporciona verificabilidad y seguridad de transición estatal.

El Secuenciador de Confianza genera batches, pero para lograr una finalidad rápida de las transacciones L2 y evitar la necesidad de esperar el próximo bloque L1, se comparten con los nodos de red L2 a través de un canal de transmisión. Cada nodo ejecutará los batches para calcular el estado L2 resultante localmente.

Una vez el Secuenciador ha comprometido las secuencias de batches obtenidos directamente de los nodos de red L1, L2 los ejecutarán nuevamente, y ya no tendrán que confiar en ellos.

La ejecución fuera de cadena de los batches eventualmente se verificará en cadena a través de una zk Proof, y se comprometerá la raíz resultante del Estado L2. A medida que avanza el protocolo zkEVM, las nuevas raíces de estado L2 se sincronizarán directamente desde los nodos de red L1 en L2.

Tanto la disponibilidad de los datos como la verificación de la ejecución de las transacciones dependen únicamente de los supuestos de seguridad de L1 y, en la fase final del protocolo, los nodos sólo dependerán de los datos presentes en L1 para mantenerse sincronizados con cada transición de estado de L2.

Los nodos L2 pueden recibir datos de batches de tres maneras diferentes:

• Directamente desde el Secuenciador antes de que los batches estén comprometidos con L1, o bien.

• Directamente desde L1 después de que los batches hayan sido secuenciados.

• O sólo después de que el Agregador haya probado la corrección de la ejecución y verificado por el contrato PolygonZkEVM.sol

Vale la pena señalar que los tres formatos de datos de batch son recibidos por los nodos L2 en orden cronológico enumerado anteriormente.

Hay tres etapas del estado L2, cada una correspondiente a las tres formas diferentes en que los nodos L2 pueden actualizar su estado. Los tres casos dependen del formato de los datos del batch utilizados para actualizar el estado L2.

En el primera instancia, la actualización se basa únicamente en la información (i.e., batches que consisten en transacciones ordenadas) que provienen directamente del Secuenciador de Confianza, antes de cualquier disponibilidad de datos en L1. El estado L2 resultante se llama Estado de Confianza “Trusted State”.

En el segundo caso, la actualización se basa en información recuperada de la red L1 por nodos L2. Es decir, después de que los batches hayan sido secuenciados y los datos se hayan puesto a disposición en L1. El estado L2 se conoce como el Estado virtual “Virtual State”.

La información utilizada para actualizar el estado L2 en el último caso incluye zk Proof verificadas de integridad computacional. Es decir, después de que la zk Proof se haya verificado con éxito en los nodos L1, L2 sincronizan su raíz local del estado “State root” L2 con el cometido en L1 por el Agregador de Confianza “Trusted Aggregator”. Como resultado, dicho Estado L2 se conoce como el Estado Consolidado “Consolidated State”.

La siguiente figura muestra la línea de tiempo de las etapas del estado L2 desde una perspectiva de un batch, así como las acciones que desencadenan la progresión de una etapa a la siguiente.

Las transacciones en la red Polygon zkEVM se crean en las billeteras de los usuarios y se firman con sus claves privadas.

Una vez generado y firmado, las transacciones se envían al nodo del Secuenciador de Confianza a través de su interfaz JSON-RPC. Las transacciones se almacenan en el grupo de transacciones pendientes, donde esperan la selección del Secuenciador para su ejecución o descarte.

Los usuarios y el zkEVM se comunican utilizando JSON-RPC, que es totalmente compatible con Ethereum RPC. Este enfoque permite que cualquier aplicación compatible con EVM, como el software de billetera, funcione y se sienta como usuarios reales de la red Ethereum.

En el diseño actual, una sola transacción es equivalente a un bloque.

Esta estrategia de diseño no solo mejora la comunicación RPC y P2P entre nodos, sino que también mejora la compatibilidad con las herramientas existentes y facilita la finalidad rápida en L2. También simplifica el proceso de localización de transacciones de usuarios.

El Secuenciador de Confianza ”Trusted Sequencer “, lee las transacciones del grupo y decide si descartar ellos u ordenar y ejecutar ellos. Las transacciones que se han ejecutado se agregan a un batch de transacciones, y se actualiza el estado local de L2 del Secuenciador.

Una vez que se agrega una transacción al estado L2, se transmite a todos los demás nodos zkEVM a través de un servicio de transmisión. Vale la pena señalar que confiando en el Secuenciador de Confianza, podemos lograr una finalidad de transacción rápida (más rápida que en L1). Sin embargo, el Estado L2 resultante estará en un estado confiable hasta que el batch se comprometa en el Contrato de Consenso.

Los usuarios suelen interactuar con el Estado L2 de Confianza. Sin embargo, debido a determinadas características del protocolo, el proceso de verificación de las transacciones L2 (en la capa 1 para permitir las retiradas) puede llevar mucho tiempo, normalmente unos 30 minutos, pero hasta 2 semanas en casos excepcionales. En consecuencia, los usuarios deben ser conscientes de los riesgos potenciales asociados a las transacciones de alto valor, en particular las que no pueden anularse, como las retiradas, las transacciones en ventanilla y los puentes alternativos.

El Secuenciador de Confianza debe procesar las transacciones por batches utilizando la siguiente estructura BatchData especificada en el contrato PolygonZkEVM.sol.

  struct BatchData {
     bytes transactions;
     bytes32 globalExitRoot;
     uint64 timestamp;
     uint64 minForcedTimestamp;
}

Son arrays de bytes (estructura de datos con elementos homogéneos, del mismo tipo, numérico o alfanumérico) que contienen las transacciones por batches concatenados.

Cada transacción se codifica según los formatos Ethereum pre-EIP-155 o EIP-155 utilizando el estándar RLP (prefijo de longitud recursiva), pero los valores de firma, v, r y s, se concatenan como se muestra a continuación;

1. EIP-155: RLP (nonce,gasprice,gasLimit,to,value,data,chainid,0,0,)#v#r#s

2. pre-EIP-155: RLP (nonce,gasprice,gasLimit,to,value,data)#v#r#s.

Es la raíz del árbol Merkle de salida global del puente, que se sincronizará en el estado L2 al inicio de la ejecución por batches.

El puente transporta activos entre L1 y L2, y una transacción de reclamación desbloquea el activo en la red de destino.

Al igual que los bloques de Ethereum tienen marcas de tiempo, cada batch tiene una marca de tiempo.

Hay dos restricciones que cada marca de tiempo debe satisfacer para asegurar que los batches están ordenados en el tiempo y sincronizados con los bloques L1:

1. La marca de tiempo de un batch determinado debe ser mayor o igual que la marca de tiempo del último batch secuenciado.

2. La marca de tiempo máxima que un Secuenciador de Confianza puede asignar a un batch es la marca de tiempo del bloque en el que se ejecuta la transacción L1 de secuenciación.

Si un batch es de los denominados forzados, este parámetro debe ser mayor que cero. La censura se contrarresta utilizando batches forzados.

Los batches deben secuenciarse y validarse antes de que puedan formar parte del Estado Virtual L2.

El Secuenciador de Confianza añade con éxito un lote a una secuencia de batches utilizando el mapeo sequencedBatches del contrato L1 PolygonZkEVM.sol, que es básicamente una estructura de almacenamiento que contiene la cola de secuencias que definen el Estado Virtual.

// SequenceBatchNum --> SequencedBatchData
mapping(uint64 => SequencedBatchData) public sequencedBatches;

Para que un batch pueda ser secuenciado, debe ser parte de la colección de batches que se secuenciarán. El Secuenciador de Confianza llama al Contrato PolygonZkEVM.sol, que utiliza su mapeo sequenceBatches. Este mapeo acepta una matriz de batches que se secuenciarán como argumento.

La constante pública del contrato, MAX_TRANSACTIONS_BYTE_LENGTH, determina el número máximo de transacciones que pueden incluirse en un lote (300000).

Del mismo modo, el número de batches de una secuencia está limitado por la constante pública del contrato MAX_VERIFY_BATCHES (1000). La matriz de batches debe contener al menos un batch y no más que el valor de la constante MAX_VERIFY_BATCHES.

La función sequencedBatches itera sobre cada batch de la secuencia, comprobando su validez. Un batch válido debe cumplir los siguientes criterios:

• Debe incluir un valor globalExitRoot que esté presente en el GlobalExitRootMap del contrato L1 PolygonZkEVMGlobalExitRoot.sol del puente. Un batch sólo es válido si incluye un globalExitRoot válido.

• La longitud de la matriz de bytes de transacciones debe ser inferior al valor de la constante MAX_TRANSACTIONS_BYTE_LENGTH.

• La marca de tiempo del batch debe ser mayor o igual que la del último batch secuenciado, pero menor o igual que la marca de tiempo del bloque en el que se ejecuta la transacción L1 secuenciada. Todos los batch deben estar ordenados por hora.

Si un batch no es válido, la transacción revierte, descartando toda la secuencia. En caso contrario, si todos los batch a secuenciar son válidos, el proceso de secuenciación continuará.

Como contador de batch se utiliza una variable de almacenamiento denominada lastBatchSequenced, que se incrementa cada vez que se secuencia un batch. Da un número de índice específico a cada batch que se utilizará como valor de posición en la cadena de batches.

El mismo mecanismo hash utilizado en las cadenas de bloques para enlazar un bloque con el siguiente se utiliza en los batches para garantizar la integridad criptográfica de la cadena de batches. Es decir, se incluye el resumen del batch anterior entre los datos utilizados para calcular el resumen del batch siguiente.

Como resultado, el resumen de un batch determinado es un hash acumulado de todos los batches secuenciados previamente, de ahí el nombre de hash acumulado de un batch, denotado por oldAccInputHash para el antiguo y newAccInputHash para el nuevo.

Un hash acumulado de un batch específico tiene la siguiente estructura:

keccak256 ( 
    abi.encodePacked (
        bytes32 oldAccInputHash, 
        keccak256(bytes transactions), 
        bytes32 globalExitRoot ,
        uint64 timestamp ,
        address seqAddress
    )
)

• oldAccInputHashes el hash acumulado del batch secuenciado anterior.

• keccack256(transactions)es el resumen de Keccak de la matriz de bytes de transacciones.

• globalExitRootes la raíz del árbol Merkle de salida global del puente.

• timestampes la marca de tiempo del batch.

• seqAddresses la dirección del Secuenciador de batches.

Como se muestra en el diagrama anterior, cada hash de entrada acumulado garantiza la integridad de los datos del batch actual (i.e., transactions, timestamp, y globalExitRoot, así como el orden en que fueron secuenciados).

Es importante tener en cuenta que cualquier cambio en la cadena de batches hace que todos los hash de entrada acumulados futuros sean incorrectos, lo que demuestra una falta de integridad en el estado L2 resultante.

Dado que las operaciones de almacenamiento en L1 son muy caras en términos de consumo de gas, es fundamental usarlo lo menos posible. Para lograr esto, las ranuras de almacenamiento (o las entradas de mapeo) se usan únicamente para almacenar un compromiso de secuencia.

Cada entrada de mapeo comete dos índices de batch.

• Ultimo batch de la secuencia anterior como valor de SequencedBatchData estructurar.

• Último batch de la secuencia actual como clave de mapeo.

Junto con el hash acumulado del último batch en la secuencia actual y una marca de tiempo.

Es importante tener en cuenta que solo se guarda el hash acumulado del último batch en la secuencia; todos los demás se calculan sobre la marcha para obtener el último.

Como se indicó anteriormente, el resumen del hash será un compromiso de toda la cadena de batches. Los índices de batch también comprometen información útil como el número de batches en la secuencia y su posición en la cadena de batches. La marca de tiempo ancla la secuencia a un punto específico en el tiempo.

La disponibilidad de datos de las transacciones L2 está garantizada porque los datos de cada batch se pueden recuperar la calldata de la transacción de secuenciación, que no forma parte del almacenamiento del contrato pero es parte del Estado L1. Finalmente un SequenceBatches emitirá el evento.

event SequenceBatches (uint64 indexed numBatch)

Una vez que los batches se secuencian correctamente en L1, todos los nodos zkEVM pueden sincronizar su estado L2 local obteniendo los datos directamente de L1 PolygonZkEVM.sol contrato, sin tener que depender solo del Secuenciador de confianza. Así es como se alcanza el estado virtual L2.

Los Agregadores de Confianza eventualmente debería agregar las secuencias de batches previamente cometidos por los Secuenciadores de Confianza para lograr la etapa final del Estado L2, que es el Estado Consolidado.

Agregar una secuencia significa agregar con éxito la raíz de estado L2 resultante a batchNumToStateRoot mapeo en el contrato L1 PolygonZkEVM.sol. Esta es una estructura de almacenamiento que contiene todas las raíces consolidadas del Estado L2, que están codificadas por el último índice de batch de cada secuencia agregada de batches.

// BatchNum --> state root
mapping (uint64 => bytes32) public batchNumToStateRoot;

Además, la agregación implica la verificación exitosa de la zk Proof de la integridad computacional de la ejecución de batches de transacciones.

SNARK, es el esquema subyacente zk Proof de verificación. Una de sus características clave es la concisión y la velocidad de verificación de la prueba.

Como resultado, la integridad de un cálculo exhaustivo se puede verificar utilizando una fracción de los recursos computacionales requeridos por el cálculo original. Como resultado, al emplear un esquema SNARK, podemos proporcionar seguridad en la cadena a cálculos exhaustivos fuera de la cadena de una manera eficiente con el gas.

Como se muestra en el diagrama anterior, la ejecución fuera de cadena de los batch supondrá una transición de estado L2 y, en consecuencia, un cambio a una nueva raíz de estado L2.

La integridad del cálculo (CI) prueba de la ejecución es generada por el Agregador, y su verificación en cadena garantiza la validez de la raíz de estado L2 resultante.

Los Executor y Prover son servicios del nodo Aggregator que ejecutan batch y generan pruebas. Los trataremos aquí como unos intérpretes de EVM que pueden:

• Ejecutar una secuencia de batches de transacciones en el estado L2 actual.

• Calcular la raíz de estado L2 resultante.

• Generar una zk Proof de integridad computacional para la ejecución.

El sistema de verificación y la prueba están diseñados de tal manera que una verificación exitosa de la prueba demuestra criptográficamente que la ejecución de una secuencia dada de batches sobre un Estado L2 específico resulta en un Estado L2 representado por el argumento newStateRoot.

Resumiendo y repasando lo aprendido antes de comenzar las exploraciones, en Polygon zkEVM se divide el estado en tres etapas: Trusted State, Virtual State y Consolidated State. Cada una de estas etapas representa una forma diferente en que los nodos de capa 2 pueden actualizar su estado.

• 1ª Etapa: se basa en información del Secuenciador de confianza antes de que los datos estén disponibles en L1.

• 2ª Etapa: utiliza información de la red L1 después de que los batch hayan sido secuenciados y los datos estén disponibles en L1.

• 3ª Etapa: utiliza zk Proof para actualizar el estado L2.

En la tabla inferior se describen las diferencias observadas en los batches de transacciones desde el Estado de Confianza “Trusted State” al Estado Virtual “Virtual State”, donde el batch ya ha sido secuenciado y los datos están disponibles en L1, a falta de la última Validity Proof.

Escogimos aleatoriamente batches, pero profundizaremos más entre los batch 10.680 y 10.683. Si los analizamos, vemos que comparten el mismo exitGlobalRoot, lo que significa que hay varios batches dentro de un mismo batch. Concretamente, se trata de cuatro batches distintos, cada uno con sus propias transacciones. En lugar de agregar un único batch, el Secuenciador agregó los cuatro batches compartiendo la misma raíz.

En los ejemplos que tienen un timestamp de alrededor de 400-510 segundos, suele haber un solo batch agregado y el timestamp que se observa corresponde a este único batch.

Sin embargo, en el caso mencionado anteriormente, el timestamp se va registrando cada vez que se agrega un nuevo batch con la misma exitGlobalRoot, hasta llegar al cuarto batch en el ejemplo 10.683. En este caso, el timestamp total marcado por el exitGlobalRoot en L1 es de 12283 sg entre el principio y el final de la secuencia de batches.

En el siguiente ejemplo, analizaremos el explorador de Polygon zkEVM y exploraremos la relación entre los batches, las transacciones y los bloques. En términos generales, encontramos una relación 1:1, lo que indica que las transacciones en los batches se corresponden con las totales de los bloques como aprendimos en el documento. Si deseas examinar estos datos, te proporcionaremos guías orientativas a continuación junto con el enlace al zkEVM PolygonScan para poder analizar su explorador.

https://zkevm.polygonscan.com/

Una vez hayas seleccionado una transacción o un batch, se mostrarán una serie de parámetros relevantes para el análisis, los cuales ya hemos revisado en el documento.

En este caso, examinaremos un ejemplo aleatorio del batch "10.681", el cual puedes observar en la tabla adjunta.

1. Global Exit Root: es la raíz del árbol Merkle de salida global del puente, que se sincronizará en el estado L2 al inicio de la ejecución por batches.

2. Acc Input Hash: es la huella digital criptográfica única del último batch en la secuencia.

3. Sequence Tx Hash: es el Hash de la transacción del Secuenciador en la que contendrá los datos del batch secuenciado.

4. Verify Batch Tx Hash: es el Hash de la transacción del Agregador después de verificar con la zk Proof que los datos son los correctos y consolidarlos en L1.

5. State Root: es la raíz del árbol Merkle de estado en L2 después de que se hayan ejecutado las transacciones de un batch sobre el estado anterior de L2. Es decir, es el resultado final de la actualización del estado en L2 después de la ejecución de las transacciones de un batch. Esta información se utiliza para la validación y sincronización de la información en la red.

6. l2Coinbase: la dirección del Secuenciador que envía la recompensa bloqueada para incentivar al Agregador a procesar batches.

7. batches.timestamp: la marca de tiempo en segundos en el momento en que se procesó el batch.

Otros datos de la transacción:

• batches.transactions: una lista de transacciones codificadas en bytes que se procesaron en el batch.

• batches.globalExitRoot: la raíz de Merkle del estado global de la cadena de bloques en el momento en que se procesó el batch. Esto se utiliza para verificar que una salida se ha incluido en la cadena.

• batches.minForcedTimestamp: el tiempo mínimo en segundos para que se fuerce la inclusión del batch.

Si deseas obtener más información sobre el contrato principal del rollup PolygonZkEvm puede revisar: 0x5132...7aB2Implementation (Upgradable)Admin, podrás acceder a las reglas del sistema, incluyendo los parámetros básicos, los actores con permisos y los procedimientos de emergencia. Este contrato es responsable de recibir batches de transacciones, raíces de estado de L2 y pruebas zk, lo que permite revisar prácticamente todos los aspectos del sistema.

También sugerimos explorar nuestra Biblioteca Layer 2 en Español y consultar en L2Beat, donde encontrarás información adicional sobre el estado y los riesgos asociados a Polygon zkEVM.

Actualmente, el principal inconveniente se relaciona con la posible falla del Secuenciador y su incapacidad para enviar batches de transacciones. Si esta función no está disponible, los usuarios no podrán confiar en el mecanismo de forzar batches, como se indica en L2Beat, ya que actualmente está deshabilitado.

Recuerda que siempre es importante consultar fuentes actualizadas para obtener la información más precisa sobre el estado y las características del sistema.

🎉 ¡Gracias por leer hasta el final!🎉 Si está interesado en esta solución de escalabilidad, le recomendamos revisar la primera parte o escuchar el Space para L2 en Español con el equipo de Polygon

https://www.youtube.com/live/O4WiUD7L1KA?feature=share&cbrd=1

Si quieren seguir aprendiendo y colaborando con nosotros, le invitamos a unirse a nuestra vibrante comunidad de Telegram L2 en Español y a seguirnos en nuestro Twitter L2 en Español. Allí encontrará una gran cantidad de información sobre Layer 2 y el ecosistema de Blockchain en general. ¡Te Esperamos!