L2 en EspañolIntroducción a la Data Availability
📌IntroducciónUno de los conceptos que más se repiten en la industria cripto es “trustless”, lo cual significa en esencia que no debes confiar en nadie sin validarlo primero. Es por esto que las blockchains poseen nodos completos, los cuales descargan y ejecutan la data que proporcionan los “bloques” (blocks en inglés) y se aseguran que los cálculos propuestos por el block producer coinciden precisamente con los cálculos hechos por el validador. De esta manera, los nodos verifican que esta nu...
L2 en EspañolIntroducción al Optimistic Rollup de Arbitrum
🔵IntroducciónEl Optimistic Rollup de Arbitrum es una solución de capa 2 diseñada para abordar los desafíos de escalabilidad de la red Ethereum. Arbitrum ofrece una forma más rápida y económica de realizar transacciones en Ethereum al aprovechar la técnica de los Optimistic Rollups. En este sistema, la mayoría de las operaciones se realizan fuera de la cadena principal (es decir fuera de mainnet ó off-chain), lo que permite aumentar la eficiencia y reducir los costos. En este artículo, explic...
L2 en EspañolArbitrum Nitro: Guía para correr un full node
IntroducciónLos Rollups, al igual que cualquier blockchain, operan en función de un nodo completo. En una blockchain de capa 1, el nodo completo representa la unidad fundamental que impulsa la seguridad y descentralización de la red. Para el usuario individual, proporciona accesibilidad, soberanía y privacidad al interactuar con la red. En un Optimistic Rollup completamente funcional, la noción de un "nodo completo" no ofrece el mismo nivel de beneficios desde la perspectiva de la red, debido...
Comunidad dedicada al estudio de soluciones de escalabilidad en Ethereum. Impulsado y administrado por DeFi para Principiantes y SEED Latam.
Subscribe to L2 en Español
Subscribe to L2 en Español
Comunidad dedicada al estudio de soluciones de escalabilidad en Ethereum. Impulsado y administrado por DeFi para Principiantes y SEED Latam.
L2 en EspañolIntroducción a la Data Availability
📌IntroducciónUno de los conceptos que más se repiten en la industria cripto es “trustless”, lo cual significa en esencia que no debes confiar en nadie sin validarlo primero. Es por esto que las blockchains poseen nodos completos, los cuales descargan y ejecutan la data que proporcionan los “bloques” (blocks en inglés) y se aseguran que los cálculos propuestos por el block producer coinciden precisamente con los cálculos hechos por el validador. De esta manera, los nodos verifican que esta nu...
L2 en EspañolIntroducción al Optimistic Rollup de Arbitrum
🔵IntroducciónEl Optimistic Rollup de Arbitrum es una solución de capa 2 diseñada para abordar los desafíos de escalabilidad de la red Ethereum. Arbitrum ofrece una forma más rápida y económica de realizar transacciones en Ethereum al aprovechar la técnica de los Optimistic Rollups. En este sistema, la mayoría de las operaciones se realizan fuera de la cadena principal (es decir fuera de mainnet ó off-chain), lo que permite aumentar la eficiencia y reducir los costos. En este artículo, explic...
L2 en EspañolArbitrum Nitro: Guía para correr un full node
IntroducciónLos Rollups, al igual que cualquier blockchain, operan en función de un nodo completo. En una blockchain de capa 1, el nodo completo representa la unidad fundamental que impulsa la seguridad y descentralización de la red. Para el usuario individual, proporciona accesibilidad, soberanía y privacidad al interactuar con la red. En un Optimistic Rollup completamente funcional, la noción de un "nodo completo" no ofrece el mismo nivel de beneficios desde la perspectiva de la red, debido...
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
Series Polygon zkEVM 1/2
¡Hola comunidad! 👋
Hoy les presentamos la primera parte de una serie de dos artículos en los que exploraremos todo lo que necesitan saber sobre Polygon zkEVM. Esta solución de escalabilidad descentralizada de Ethereum Layer 2 utiliza pruebas criptográficas de conocimiento cero (ZK Proof), para acelerar la validación y finalización de las transacciones fuera de la cadena, también conocido como ZK Rollup.
Si están interesados en conocer cómo funciona esta solución de escalabilidad descentralizada y cómo puede mejorar su experiencia en la red Ethereum, ¡no se pierdan esta ni la venidera segunda parte!
A diferencia de otras soluciones de escalabilidad, Polygon zkEVM no solo es compatible con EVM de Ethereum, sino que también mejora significativamente su equivalencia con la EVM a través de pequeños cambios.
En esta primera parte, abordaremos los componentes de esta nueva arquitectura, el ciclo de vida de las transacciones en Polygon zkEVM, el esquema del puente Polygon zkEVM y otros aspectos importantes, pero primero empecemos viendo como Polygon zkEVM propone mejorar ETH e incorpora tecnologías valiosas como pruebas de validez de conocimiento cero (ZK - Validity Proof).
Como hemos visto en varias ocasiones, la blockchain de Ethereum basada en la tecnología de libro mayor distribuido (DLT), se enfrenta a un desafío conocido como el trilemma de la escalabilidad, la descentralización y la seguridad, lo que significa que no puede escalar más allá de su umbral de transacción sin sacrificar uno o más de estos factores.
Para abordar este problema, Polygon ha desarrollado la zkEVM, una máquina virtual que emula la EVM (máquina virtual Ethereum) y soporta todos los códigos de operación existentes en Ethereum. Esto permite la implementación transparente de Smart Contracts de Ethereum en la capa 2 de la red, lo que aumenta significativamente la escalabilidad y la cantidad de transacciones por segundo (TPS), mientras mantiene la seguridad de la capa principal de Ethereum
La zkEVM es una máquina de estado que procesa las transacciones de capa 2 enviadas por los usuarios a la red, generando pruebas de validez o Validity Proofs. Estas pruebas son rápidas y sencillas de verificar, garantizando la integridad de los cambios de estado realizados.
La red zkEVM de Polygon apunta a ser una red descentralizada, sin permisos, altamente segura y eficiente, diseñada para proporcionar una solución que reduzca la fricción para los usuarios y desarrolladores. Los esfuerzos de desarrollo permiten que cualquier persona que tenga el software zkEVM participe en la red. Además, el algoritmo de consenso brinda a todos la oportunidad de desempeñar el papel de Secuenciador o Agregador (también conocido como provers).
Hemos visto la importancia de la DA en artículos anteriores desde L2 en Español, y como esta disponibilidad de datos es crucial para la descentralización, pero el equipo de zkEVM aún tiene que decidir la mejor configuración para garantizar que no haya censura y que ninguna de las partes pueda controlar la red, por lo que no se puede definir uno establecido.
La seguridad es una consideración clave en la arquitectura de zkEVM, y como solución L2, la mayor parte de la seguridad se hereda de Ethereum. Los contratos inteligentes asegurarán que todos los que ejecutan cambios de estado lo hagan de manera adecuada, creen una prueba que acredite la validez de un cambio de estado y pongan a disposición pruebas de validez en la cadena para su verificación.
La tecnología zkEVM de Polygon tiene como objetivo crear una máquina de estado genérica que funcione como un procesador, con registros y un reloj. Esta máquina recibe instrucciones en forma de programas escritos en ensamblador y realiza transiciones de estado en cada pulso del reloj según estas instrucciones.
Consulte la figura a continuación para ver un ejemplo de una máquina de estado con los registros A y B y un estado que cambia a otro estado en función de dos instrucciones.
Para implementar pruebas ZK en zkEVM de Polygon, se ha desarrollado una implementación especial de STARK llamada PIL-STARK. Esta implementación utiliza el lenguaje de dominio específico PIL (Polynomial Identities Language), para nombrar polinomios y describir las identidades que definen los cálculos realizados por la máquina de estado. Además, se basa en el protocolo FRI para su esquema de Compromiso polinómico.
Si desea obtener más información acerca de las matemáticas y el funcionamiento detrás del lenguaje Polynomial PIL, puede revisar el vídeo que hemos dejado a continuación para tener una mejor comprensión. A continuación, profundicemos en la arquitectura de zkEVM y sus componentes principales.
La arquitectura de Polygon zkEVM se enfoca en manejar las transiciones de estado, que resultan de las ejecuciones de transacciones de la capa 2 enviadas por los usuarios a la red.
Los componentes principales de Polygon zkEVM que permiten su funcionamiento eficiente y seguro son los siguientes:
Contrato de consenso: PolygonZkEVM.sol
zkNode
Sincronizador
Secuenciadores y Agregadores
RPC
zkProver
Puente zkEVM
Cada uno de estos componentes desempeña un papel importante en el funcionamiento de la máquina virtual zkEVM de Polygon, en la mejora de la escalabilidad y las transacciones por segundo de Ethereum.
Como dato curioso, el equipo tras Hermez siempre ha innovado en la descentralización de los rollups. De hecho, la versión anterior, Polygon Hermez 1.0, un ZK Rollup para pagos instantáneos, se basó en el mecanismo de consenso llamado Prueba de Donación (PoD). Esta fue básicamente una subasta descentralizada realizada automáticamente, en la que los participantes (coordinadores) ofrecían un cierto número de tokens para ser elegidos y crear el siguiente bloque.
En el antiguo mecanismo de PoD, se establecieron incentivos económicos para que los validadores fueran altamente eficientes y competitivos, ya que se basaba en un modelo de subasta descentralizado para obtener el derecho de producir bloques en un plazo específico.
El nuevo Contrato de Consenso, PolygonZkEVM.sol, aprovecha la experiencia del mecanismo de PoD de la versión 1.0, pero con la adición del soporte para múltiples coordinadores sin permiso para producir bloques en la capa 2.
Esta última versión del Contrato de Consenso zkEVM (desplegado en la capa 1) se modela después de la Prueba de Eficiencia (Proof of Efficiency). Aprovecha la experiencia del mecanismo PoD existente en la versión 1.0 y agrega soporte para múltiples coordinadores sin permiso para producir bloques en la capa 2.
En la parte dos de esta serie se tratarán otros temas, incluyendo su Modelo de Implementación, tokenomics y estructura de incentivación, si desea aprender más sobre ellos.
El zkNode es el software necesario para ejecutar cualquier nodo zkEVM en la red Polygon. Funciona como un cliente que ayuda a implementar la sincronización y a gobernar los roles de los participantes, ya sean Secuenciadores o Agregadores.
Los usuarios de Polygon zkEVM pueden elegir participar en la red como un simple nodo para conocer el estado de la red, o como participante en el proceso de producción por lotes en cualquiera de los dos roles mencionados anteriormente. La arquitectura del zkNode es modular para mayor flexibilidad y eficiencia.
El zkNode se puede utilizar en tres modos diferentes: Secuenciador, Agregador y RPC.
Modo Secuenciador: el nodo zkNode cuenta con una instancia de Estado L2, una API integrada para manejar las interacciones de los usuarios L2 (como solicitudes de transacción y consultas de Estado L2) y gestiona la transmisión por batch a otros nodos de la red L2. También cuentan con una base de datos para almacenar temporalmente las transacciones que aún no han sido ordenadas ni ejecutadas (pool de transacciones pendientes), así como todos los componentes necesarios para interactuar con L1 y mantener su Estado L2 local actualizado
Modo Agregador: el nodo zkNode cuenta con todos los componentes necesarios para ejecutar batch de transacciones, calcular el Estado L2 resultante y generar las pruebas de integridad computacional llamadas Validity Proof. Además, puede obtener batch de transacciones comprometidos en L1 por el Secuenciador de Confianza y verificar públicamente las transiciones de Estado L2 en L1 mediante la llamada a funciones específicas.
Modo RPC: el nodo zkNode tiene una funcionalidad limitada. Principalmente mantiene una instancia actualizada del Estado L2, utilizando los batch transmitidos por el Secuenciador de Confianza y las secuencias de batch obtenidos del Contrato de Consenso. Además, el nodo interactúa con L1 de manera continua para mantener el Estado L2 local actualizado y verificar la sincronización de las raíces de Estado L2. La tasa de sincronización predeterminada del sincronizador es de cada 2 segundos, aunque se puede modificar en la configuración.
Ahora nos centraremos en resumir la descripción general esquelética del zkEVM que emplea tecnología avanzada de ZK para crear Validity Proof. Utiliza un zkProver que se puede ejecutar en cualquier servidor y está diseñado para ser compatible con la mayoría del hardware de consumo. Cada Agregador utilizará este zkProver para validar batch y proporcionar Validity Proof.
El zkProver consta de un Ejecutor de Máquina de Estado Principal, una colección de Máquinas de Estado secundarias (cada una con su propio ejecutor), un generador de pruebas STARK y un generador de pruebas SNARK.
El zkEVM expresa los cambios de estado en forma polinómica. Como resultado, las restricciones que debe cumplir cada batch propuesto son restricciones polinómicas o identidades polinomiales. Para decirlo de otra manera, todos los batch válidos deben satisfacer restricciones polinómicas específicas, aunque veremos más sobre el proceso en la segunda* *parte del artículo.
Para realizar cualquier transacción en Polygon zkEVM, los usuarios necesitan disponer de fondos en esta capa. Esto se logra mediante la transferencia de una cantidad de éter desde L1 a L2 a través del puente zkEVM de Polygon.
El puente zkEVM de Polygon es un contrato inteligente que permite la transferencia segura de activos entre dos capas (L1 y L2). Este puente es descentralizado y consta de dos contratos inteligentes, uno en L1 y otro en L2. El contrato del puente L1 se encarga de administrar las transferencias de activos entre rollups, mientras que el contrato del puente L2 se responsabiliza de las transferencias de activos entre Mainnet y el Rollup.
El ciclo de vida de las transacciones en L2 comienza con la transferencia de ether desde L1 a L2 a través del puente zkEVM. La interoperabilidad de L2 permite migrar activos entre diferentes redes nativamente, y el puente zkEVM de Polygon se encarga de asegurar la comunicación y migración de activos entre la red Polygon zkEVM y otras redes. Los contratos inteligentes L1 en los rollups L2 garantizan la correcta gestión de las transiciones de estado L2 y la disponibilidad de datos. Ahora, veamos cómo es el esquema del puente.
El esquema del puente Polygon zkEVM implica dos redes (L1 y L2). Para mover un activo entre ambas redes, un usuario debe bloquear el activo en la red de origen (Capa 1). El contrato inteligente del puente crea un activo representativo de valor equivalente en la red de destino L2, que se conoce como Token envuelto.
Una vez acuñado el Token envuelto, el usuario o destinatario en la red de destino L2 puede reclamar el activo. También es posible realizar la operación opuesta; después de quemar el token envuelto, el Bridge SC desbloquea el activo original en la red de origen.
El Bridge SC también puede utilizarse para la mensajería entre cadenas, lo que permite enviar cargas de datos de una red a otra a través de las operaciones Puente y Reclamación.
El zkEVM Bridge SC se implementa utilizando el diseño del contrato de depósito de Ethereum PoS como base, pero con algunas modificaciones. Por ejemplo, en lugar de utilizar árboles Merkle convencionales, emplea árboles Merkle de agregación especialmente diseñados. A pesar de estas diferencias, la lógica subyacente del contrato zkEVM Bridge es la misma que la del Contrato de Depósito de Ethereum.
Además de las diferencias mencionadas en la implementación del contrato zkEVM Bridge en comparación con el Contrato de Depósito de Ethereum 2.0, hay otras relacionadas con el hash base y los nodos hoja:
El Contrato de Depósito utiliza la función hash SHA256, mientras que zkEVM utiliza la función hash Keccak. La razón detrás de esta elección es que, además de ser compatible con EVM, la función hash Keccak tiene un costo de gas más bajo en la red Ethereum.
El contrato Bridge genera tokens envueltos la primera vez que se agrega un nuevo token a la red zkEVM. Además, se agregan los metadatos del token ERC20, como el nombre, el número de decimales o el símbolo, a la información contenida en la hoja.
La característica principal del contrato inteligente Polygon zkEVM Bridge es el uso de Árboles de Salida (Exit Trees) y el Árbol de Salida Global (Global Exit Tree), con la raíz del árbol de salida global que sirve como la fuente principal de la verdad del estado.
El uso de dos distintos administradores de Raíz de Salida Global (Global Exit Root) para L1 y L2, así como lógica separada para el contrato Bridge SC y cada uno de estos administradores de raíz de salida global, permite una amplia interoperabilidad de red.
Cualquier nodo de L1 y L2 puede validar todas las transferencias de activos gracias a la DA. El zkEVM Bridge SC desplegado en L1 utiliza la función Claim para finalizar las transferencias y el Agregador recibe una compensación en tokens MATIC por su función. La cantidad de tokens ganados por cada secuencia agregada, llamada batchReward, se determina por el saldo total del contrato MATIC y el número de secuencias agregadas.
Si deseas aprender más sobre el árbol de estado utilizado en zkEVM y sus características, te recomendamos ver el siguiente vídeo
En el siguiente análisis evaluaremos las propuestas de zkEVM en cuanto a su compatibilidad o equivalencia con EVM. Para obtener más información, te invitamos a revisar nuestro artículo "Comparando las zkEVM en testnet", donde examinamos en detalle las diferentes implementaciones de zkEVM y comparamos su rendimiento y funcionalidad en su red de prueba.
https://mirror.xyz/layer2es.eth/YPGL8m1ve2aA_Ql6496f4yjuxkU1NIUSDM4EH6u10i0
En general, una solución compatible requeriría menos cambios en el código que una solución equivalente. Sin embargo, hay casos en los que incluso una solución compatible puede requerir cambios significativos en el código, especialmente si las dos soluciones son muy diferentes en su diseño o arquitectura.
El objetivo de lograr la equivalencia es tener una solución que sea lo más similar posible a la solución original, lo que minimiza los cambios necesarios en el código y reduce el riesgo de introducir nuevas vulnerabilidades de seguridad. Además, la equivalencia permite que las aplicaciones, herramientas e infraestructura creadas para la solución original sean compatibles de manera más efectiva con la nueva solución.
Los opcodes en zkEVM son las instrucciones básicas que permiten la ejecución de contratos inteligentes en la cadena de bloques. En comparación con EVM, zkEVM ha realizado algunos cambios en los opcodes para mejorar la seguridad y el rendimiento.
La siguiente sección detalla los cambios que se han realizado en los opcodes en zKEVM en comparación con EVM:
AUTODESTRUCT: Ha sido eliminado y reemplazado por ENVIAR.
EXTCODEHASH: Devuelve el hash del código de bytes del contrato del árbol de estado zkEVM sin verificar si la cuenta está vacía.
DIFFICULTY: Devuelve "0" en lugar de un número aleatorio como en el EVM.
BLOCKHASH: Devuelve todos los hash de bloque anteriores en lugar de solo los últimos 256 bloques. BLOCKHASH es la raíz del estado al final de una transacción procesable y se almacena en el contrato inteligente del sistema.
NUMBER: Devuelve el número de transacciones procesables.
Los contratos precompilados en zkEVM son programas que se ejecutan automáticamente en la cadena de bloques sin la necesidad de ser invocados directamente por un contrato inteligente. En zkEVM, algunos de los contratos precompilados son diferentes a los de EVM:
eRecover: Permite la recuperación de una clave pública a partir de una firma y un hash de mensaje.
identity: Proporciona una manera segura de verificar la identidad de un usuario en la cadena de bloques.
Los demás contratos precompilados no tienen efecto en el árbol de estado zkEVM y se tratan como un revert, devolviendo todo el gas al contexto anterior y estableciendo el success bandera a "0".
En la implementación de zkEVM, cuando se despliega un contrato en una dirección, el almacenamiento no se limpia (es decir, no se borra). Esto se debe a la manera en que está diseñado el árbol de estado de zkEVM, que no requiere borrar el almacenamiento cuando se despliega un contrato, otras diferencias son:
El opcode JUMPDEST está permitido en push bytes para evitar el análisis de bytecode en tiempo de ejecución.
La zkEVM implementa EIP-3541 de la Hardfork de Londres.
EIP-2718, que define el Typed Transaction Envelope, no es compatible.
EIP-2930, que define el tipo de transacción Optional Access Lists, no es compatible.
Como hemos podido comprobar la compatibilidad y la equivalencia son objetivos diferentes, y aunque ambas buscan facilitar la integración entre diferentes soluciones, la equivalencia tiene como objetivo lograr una integración más profunda y sin problemas que la compatibilidad. En el caso de Polygon zkEVM, el objetivo es lograr la equivalencia con el EVM de Ethereum, lo que permite una integración profunda y sin problemas entre ambas soluciones.
Para terminar esta primera parte de la serie repasemos como la eficiencia es clave para el rendimiento de la red. zkEVM aplica varias estrategias de implementación para garantizar la eficiencia. A continuación se enumeran algunas de ellas:
La primera estrategia: Desplegar un Contrato de Consenso, que incentiva a los Agregadores más eficientes a participar en el proceso de generación de pruebas.
La segunda estrategia: Llevar a cabo todos los cálculos fuera de la cadena mientras se mantienen solo los datos necesarios y las pruebas ZK en la cadena.
La tercera estrategia: Forma en que se implementa el contrato inteligente de puente, como la liquidación de cuentas de manera UTXO, utilizando solo las raíces del árbol de salida.
Estrategias combinadas: Utilización de primitivas criptográficas especializadas dentro del zkProver para acelerar los cálculos y minimizar el tamaño de las pruebas, como se ve en:
Ejecución de un lenguaje de ensamblaje ZK (zkASM) para la interpretación de códigos de bytes.
Uso de herramientas ZK como zk-STARKs para fines de demostración, estas pruebas son muy rápidas, aunque son más grandes en tamaño.
En lugar de publicar las pruebas zk-STARK de gran tamaño como pruebas de validez, se utiliza un zk-SNARK para atestar la corrección de las pruebas zk-STARK. Estos zk-SNARK se publican a su vez como pruebas de validez de los cambios de estado. Esto ayuda a reducir los costos de gas de 5 millones a 350K.
La red zkEVM de Polygon se ha propuesto ofrecer una solución eficiente y de baja fricción para los usuarios y desarrolladores de aplicaciones descentralizadas. Esto ha sido posible gracias a la implementación de estrategias de eficiencia, como las descritas anteriormente. Con esto hemos aprendido cómo Polygon está ofreciendo una solución de cadena de bloques eficiente y de baja fricción a través de su red zkEVM.
🎉 ¡Gracias por leer hasta el final! Si está interesado en seguir aprendiendo y colaborando con nosotros, le invitamos a revisar nuestra biblioteca sobre zkEVM Polygon para obtener más detalles y también nuestra Biblioteca de Layer 2 en Español para estar actualizado sobre diversas soluciones.
En la segunda parte, profundizaremos en el funcionamiento de Proof of Efficiency, la gestión de estados del Rollup L2 y proporcionaremos ejemplos visuales del explorador de bloques para una mejor comprensión.
Además, 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 1/2
¡Hola comunidad! 👋
Hoy les presentamos la primera parte de una serie de dos artículos en los que exploraremos todo lo que necesitan saber sobre Polygon zkEVM. Esta solución de escalabilidad descentralizada de Ethereum Layer 2 utiliza pruebas criptográficas de conocimiento cero (ZK Proof), para acelerar la validación y finalización de las transacciones fuera de la cadena, también conocido como ZK Rollup.
Si están interesados en conocer cómo funciona esta solución de escalabilidad descentralizada y cómo puede mejorar su experiencia en la red Ethereum, ¡no se pierdan esta ni la venidera segunda parte!
A diferencia de otras soluciones de escalabilidad, Polygon zkEVM no solo es compatible con EVM de Ethereum, sino que también mejora significativamente su equivalencia con la EVM a través de pequeños cambios.
En esta primera parte, abordaremos los componentes de esta nueva arquitectura, el ciclo de vida de las transacciones en Polygon zkEVM, el esquema del puente Polygon zkEVM y otros aspectos importantes, pero primero empecemos viendo como Polygon zkEVM propone mejorar ETH e incorpora tecnologías valiosas como pruebas de validez de conocimiento cero (ZK - Validity Proof).
Como hemos visto en varias ocasiones, la blockchain de Ethereum basada en la tecnología de libro mayor distribuido (DLT), se enfrenta a un desafío conocido como el trilemma de la escalabilidad, la descentralización y la seguridad, lo que significa que no puede escalar más allá de su umbral de transacción sin sacrificar uno o más de estos factores.
Para abordar este problema, Polygon ha desarrollado la zkEVM, una máquina virtual que emula la EVM (máquina virtual Ethereum) y soporta todos los códigos de operación existentes en Ethereum. Esto permite la implementación transparente de Smart Contracts de Ethereum en la capa 2 de la red, lo que aumenta significativamente la escalabilidad y la cantidad de transacciones por segundo (TPS), mientras mantiene la seguridad de la capa principal de Ethereum
La zkEVM es una máquina de estado que procesa las transacciones de capa 2 enviadas por los usuarios a la red, generando pruebas de validez o Validity Proofs. Estas pruebas son rápidas y sencillas de verificar, garantizando la integridad de los cambios de estado realizados.
La red zkEVM de Polygon apunta a ser una red descentralizada, sin permisos, altamente segura y eficiente, diseñada para proporcionar una solución que reduzca la fricción para los usuarios y desarrolladores. Los esfuerzos de desarrollo permiten que cualquier persona que tenga el software zkEVM participe en la red. Además, el algoritmo de consenso brinda a todos la oportunidad de desempeñar el papel de Secuenciador o Agregador (también conocido como provers).
Hemos visto la importancia de la DA en artículos anteriores desde L2 en Español, y como esta disponibilidad de datos es crucial para la descentralización, pero el equipo de zkEVM aún tiene que decidir la mejor configuración para garantizar que no haya censura y que ninguna de las partes pueda controlar la red, por lo que no se puede definir uno establecido.
La seguridad es una consideración clave en la arquitectura de zkEVM, y como solución L2, la mayor parte de la seguridad se hereda de Ethereum. Los contratos inteligentes asegurarán que todos los que ejecutan cambios de estado lo hagan de manera adecuada, creen una prueba que acredite la validez de un cambio de estado y pongan a disposición pruebas de validez en la cadena para su verificación.
La tecnología zkEVM de Polygon tiene como objetivo crear una máquina de estado genérica que funcione como un procesador, con registros y un reloj. Esta máquina recibe instrucciones en forma de programas escritos en ensamblador y realiza transiciones de estado en cada pulso del reloj según estas instrucciones.
Consulte la figura a continuación para ver un ejemplo de una máquina de estado con los registros A y B y un estado que cambia a otro estado en función de dos instrucciones.
Para implementar pruebas ZK en zkEVM de Polygon, se ha desarrollado una implementación especial de STARK llamada PIL-STARK. Esta implementación utiliza el lenguaje de dominio específico PIL (Polynomial Identities Language), para nombrar polinomios y describir las identidades que definen los cálculos realizados por la máquina de estado. Además, se basa en el protocolo FRI para su esquema de Compromiso polinómico.
Si desea obtener más información acerca de las matemáticas y el funcionamiento detrás del lenguaje Polynomial PIL, puede revisar el vídeo que hemos dejado a continuación para tener una mejor comprensión. A continuación, profundicemos en la arquitectura de zkEVM y sus componentes principales.
La arquitectura de Polygon zkEVM se enfoca en manejar las transiciones de estado, que resultan de las ejecuciones de transacciones de la capa 2 enviadas por los usuarios a la red.
Los componentes principales de Polygon zkEVM que permiten su funcionamiento eficiente y seguro son los siguientes:
Contrato de consenso: PolygonZkEVM.sol
zkNode
Sincronizador
Secuenciadores y Agregadores
RPC
zkProver
Puente zkEVM
Cada uno de estos componentes desempeña un papel importante en el funcionamiento de la máquina virtual zkEVM de Polygon, en la mejora de la escalabilidad y las transacciones por segundo de Ethereum.
Como dato curioso, el equipo tras Hermez siempre ha innovado en la descentralización de los rollups. De hecho, la versión anterior, Polygon Hermez 1.0, un ZK Rollup para pagos instantáneos, se basó en el mecanismo de consenso llamado Prueba de Donación (PoD). Esta fue básicamente una subasta descentralizada realizada automáticamente, en la que los participantes (coordinadores) ofrecían un cierto número de tokens para ser elegidos y crear el siguiente bloque.
En el antiguo mecanismo de PoD, se establecieron incentivos económicos para que los validadores fueran altamente eficientes y competitivos, ya que se basaba en un modelo de subasta descentralizado para obtener el derecho de producir bloques en un plazo específico.
El nuevo Contrato de Consenso, PolygonZkEVM.sol, aprovecha la experiencia del mecanismo de PoD de la versión 1.0, pero con la adición del soporte para múltiples coordinadores sin permiso para producir bloques en la capa 2.
Esta última versión del Contrato de Consenso zkEVM (desplegado en la capa 1) se modela después de la Prueba de Eficiencia (Proof of Efficiency). Aprovecha la experiencia del mecanismo PoD existente en la versión 1.0 y agrega soporte para múltiples coordinadores sin permiso para producir bloques en la capa 2.
En la parte dos de esta serie se tratarán otros temas, incluyendo su Modelo de Implementación, tokenomics y estructura de incentivación, si desea aprender más sobre ellos.
El zkNode es el software necesario para ejecutar cualquier nodo zkEVM en la red Polygon. Funciona como un cliente que ayuda a implementar la sincronización y a gobernar los roles de los participantes, ya sean Secuenciadores o Agregadores.
Los usuarios de Polygon zkEVM pueden elegir participar en la red como un simple nodo para conocer el estado de la red, o como participante en el proceso de producción por lotes en cualquiera de los dos roles mencionados anteriormente. La arquitectura del zkNode es modular para mayor flexibilidad y eficiencia.
El zkNode se puede utilizar en tres modos diferentes: Secuenciador, Agregador y RPC.
Modo Secuenciador: el nodo zkNode cuenta con una instancia de Estado L2, una API integrada para manejar las interacciones de los usuarios L2 (como solicitudes de transacción y consultas de Estado L2) y gestiona la transmisión por batch a otros nodos de la red L2. También cuentan con una base de datos para almacenar temporalmente las transacciones que aún no han sido ordenadas ni ejecutadas (pool de transacciones pendientes), así como todos los componentes necesarios para interactuar con L1 y mantener su Estado L2 local actualizado
Modo Agregador: el nodo zkNode cuenta con todos los componentes necesarios para ejecutar batch de transacciones, calcular el Estado L2 resultante y generar las pruebas de integridad computacional llamadas Validity Proof. Además, puede obtener batch de transacciones comprometidos en L1 por el Secuenciador de Confianza y verificar públicamente las transiciones de Estado L2 en L1 mediante la llamada a funciones específicas.
Modo RPC: el nodo zkNode tiene una funcionalidad limitada. Principalmente mantiene una instancia actualizada del Estado L2, utilizando los batch transmitidos por el Secuenciador de Confianza y las secuencias de batch obtenidos del Contrato de Consenso. Además, el nodo interactúa con L1 de manera continua para mantener el Estado L2 local actualizado y verificar la sincronización de las raíces de Estado L2. La tasa de sincronización predeterminada del sincronizador es de cada 2 segundos, aunque se puede modificar en la configuración.
Ahora nos centraremos en resumir la descripción general esquelética del zkEVM que emplea tecnología avanzada de ZK para crear Validity Proof. Utiliza un zkProver que se puede ejecutar en cualquier servidor y está diseñado para ser compatible con la mayoría del hardware de consumo. Cada Agregador utilizará este zkProver para validar batch y proporcionar Validity Proof.
El zkProver consta de un Ejecutor de Máquina de Estado Principal, una colección de Máquinas de Estado secundarias (cada una con su propio ejecutor), un generador de pruebas STARK y un generador de pruebas SNARK.
El zkEVM expresa los cambios de estado en forma polinómica. Como resultado, las restricciones que debe cumplir cada batch propuesto son restricciones polinómicas o identidades polinomiales. Para decirlo de otra manera, todos los batch válidos deben satisfacer restricciones polinómicas específicas, aunque veremos más sobre el proceso en la segunda* *parte del artículo.
Para realizar cualquier transacción en Polygon zkEVM, los usuarios necesitan disponer de fondos en esta capa. Esto se logra mediante la transferencia de una cantidad de éter desde L1 a L2 a través del puente zkEVM de Polygon.
El puente zkEVM de Polygon es un contrato inteligente que permite la transferencia segura de activos entre dos capas (L1 y L2). Este puente es descentralizado y consta de dos contratos inteligentes, uno en L1 y otro en L2. El contrato del puente L1 se encarga de administrar las transferencias de activos entre rollups, mientras que el contrato del puente L2 se responsabiliza de las transferencias de activos entre Mainnet y el Rollup.
El ciclo de vida de las transacciones en L2 comienza con la transferencia de ether desde L1 a L2 a través del puente zkEVM. La interoperabilidad de L2 permite migrar activos entre diferentes redes nativamente, y el puente zkEVM de Polygon se encarga de asegurar la comunicación y migración de activos entre la red Polygon zkEVM y otras redes. Los contratos inteligentes L1 en los rollups L2 garantizan la correcta gestión de las transiciones de estado L2 y la disponibilidad de datos. Ahora, veamos cómo es el esquema del puente.
El esquema del puente Polygon zkEVM implica dos redes (L1 y L2). Para mover un activo entre ambas redes, un usuario debe bloquear el activo en la red de origen (Capa 1). El contrato inteligente del puente crea un activo representativo de valor equivalente en la red de destino L2, que se conoce como Token envuelto.
Una vez acuñado el Token envuelto, el usuario o destinatario en la red de destino L2 puede reclamar el activo. También es posible realizar la operación opuesta; después de quemar el token envuelto, el Bridge SC desbloquea el activo original en la red de origen.
El Bridge SC también puede utilizarse para la mensajería entre cadenas, lo que permite enviar cargas de datos de una red a otra a través de las operaciones Puente y Reclamación.
El zkEVM Bridge SC se implementa utilizando el diseño del contrato de depósito de Ethereum PoS como base, pero con algunas modificaciones. Por ejemplo, en lugar de utilizar árboles Merkle convencionales, emplea árboles Merkle de agregación especialmente diseñados. A pesar de estas diferencias, la lógica subyacente del contrato zkEVM Bridge es la misma que la del Contrato de Depósito de Ethereum.
Además de las diferencias mencionadas en la implementación del contrato zkEVM Bridge en comparación con el Contrato de Depósito de Ethereum 2.0, hay otras relacionadas con el hash base y los nodos hoja:
El Contrato de Depósito utiliza la función hash SHA256, mientras que zkEVM utiliza la función hash Keccak. La razón detrás de esta elección es que, además de ser compatible con EVM, la función hash Keccak tiene un costo de gas más bajo en la red Ethereum.
El contrato Bridge genera tokens envueltos la primera vez que se agrega un nuevo token a la red zkEVM. Además, se agregan los metadatos del token ERC20, como el nombre, el número de decimales o el símbolo, a la información contenida en la hoja.
La característica principal del contrato inteligente Polygon zkEVM Bridge es el uso de Árboles de Salida (Exit Trees) y el Árbol de Salida Global (Global Exit Tree), con la raíz del árbol de salida global que sirve como la fuente principal de la verdad del estado.
El uso de dos distintos administradores de Raíz de Salida Global (Global Exit Root) para L1 y L2, así como lógica separada para el contrato Bridge SC y cada uno de estos administradores de raíz de salida global, permite una amplia interoperabilidad de red.
Cualquier nodo de L1 y L2 puede validar todas las transferencias de activos gracias a la DA. El zkEVM Bridge SC desplegado en L1 utiliza la función Claim para finalizar las transferencias y el Agregador recibe una compensación en tokens MATIC por su función. La cantidad de tokens ganados por cada secuencia agregada, llamada batchReward, se determina por el saldo total del contrato MATIC y el número de secuencias agregadas.
Si deseas aprender más sobre el árbol de estado utilizado en zkEVM y sus características, te recomendamos ver el siguiente vídeo
En el siguiente análisis evaluaremos las propuestas de zkEVM en cuanto a su compatibilidad o equivalencia con EVM. Para obtener más información, te invitamos a revisar nuestro artículo "Comparando las zkEVM en testnet", donde examinamos en detalle las diferentes implementaciones de zkEVM y comparamos su rendimiento y funcionalidad en su red de prueba.
https://mirror.xyz/layer2es.eth/YPGL8m1ve2aA_Ql6496f4yjuxkU1NIUSDM4EH6u10i0
En general, una solución compatible requeriría menos cambios en el código que una solución equivalente. Sin embargo, hay casos en los que incluso una solución compatible puede requerir cambios significativos en el código, especialmente si las dos soluciones son muy diferentes en su diseño o arquitectura.
El objetivo de lograr la equivalencia es tener una solución que sea lo más similar posible a la solución original, lo que minimiza los cambios necesarios en el código y reduce el riesgo de introducir nuevas vulnerabilidades de seguridad. Además, la equivalencia permite que las aplicaciones, herramientas e infraestructura creadas para la solución original sean compatibles de manera más efectiva con la nueva solución.
Los opcodes en zkEVM son las instrucciones básicas que permiten la ejecución de contratos inteligentes en la cadena de bloques. En comparación con EVM, zkEVM ha realizado algunos cambios en los opcodes para mejorar la seguridad y el rendimiento.
La siguiente sección detalla los cambios que se han realizado en los opcodes en zKEVM en comparación con EVM:
AUTODESTRUCT: Ha sido eliminado y reemplazado por ENVIAR.
EXTCODEHASH: Devuelve el hash del código de bytes del contrato del árbol de estado zkEVM sin verificar si la cuenta está vacía.
DIFFICULTY: Devuelve "0" en lugar de un número aleatorio como en el EVM.
BLOCKHASH: Devuelve todos los hash de bloque anteriores en lugar de solo los últimos 256 bloques. BLOCKHASH es la raíz del estado al final de una transacción procesable y se almacena en el contrato inteligente del sistema.
NUMBER: Devuelve el número de transacciones procesables.
Los contratos precompilados en zkEVM son programas que se ejecutan automáticamente en la cadena de bloques sin la necesidad de ser invocados directamente por un contrato inteligente. En zkEVM, algunos de los contratos precompilados son diferentes a los de EVM:
eRecover: Permite la recuperación de una clave pública a partir de una firma y un hash de mensaje.
identity: Proporciona una manera segura de verificar la identidad de un usuario en la cadena de bloques.
Los demás contratos precompilados no tienen efecto en el árbol de estado zkEVM y se tratan como un revert, devolviendo todo el gas al contexto anterior y estableciendo el success bandera a "0".
En la implementación de zkEVM, cuando se despliega un contrato en una dirección, el almacenamiento no se limpia (es decir, no se borra). Esto se debe a la manera en que está diseñado el árbol de estado de zkEVM, que no requiere borrar el almacenamiento cuando se despliega un contrato, otras diferencias son:
El opcode JUMPDEST está permitido en push bytes para evitar el análisis de bytecode en tiempo de ejecución.
La zkEVM implementa EIP-3541 de la Hardfork de Londres.
EIP-2718, que define el Typed Transaction Envelope, no es compatible.
EIP-2930, que define el tipo de transacción Optional Access Lists, no es compatible.
Como hemos podido comprobar la compatibilidad y la equivalencia son objetivos diferentes, y aunque ambas buscan facilitar la integración entre diferentes soluciones, la equivalencia tiene como objetivo lograr una integración más profunda y sin problemas que la compatibilidad. En el caso de Polygon zkEVM, el objetivo es lograr la equivalencia con el EVM de Ethereum, lo que permite una integración profunda y sin problemas entre ambas soluciones.
Para terminar esta primera parte de la serie repasemos como la eficiencia es clave para el rendimiento de la red. zkEVM aplica varias estrategias de implementación para garantizar la eficiencia. A continuación se enumeran algunas de ellas:
La primera estrategia: Desplegar un Contrato de Consenso, que incentiva a los Agregadores más eficientes a participar en el proceso de generación de pruebas.
La segunda estrategia: Llevar a cabo todos los cálculos fuera de la cadena mientras se mantienen solo los datos necesarios y las pruebas ZK en la cadena.
La tercera estrategia: Forma en que se implementa el contrato inteligente de puente, como la liquidación de cuentas de manera UTXO, utilizando solo las raíces del árbol de salida.
Estrategias combinadas: Utilización de primitivas criptográficas especializadas dentro del zkProver para acelerar los cálculos y minimizar el tamaño de las pruebas, como se ve en:
Ejecución de un lenguaje de ensamblaje ZK (zkASM) para la interpretación de códigos de bytes.
Uso de herramientas ZK como zk-STARKs para fines de demostración, estas pruebas son muy rápidas, aunque son más grandes en tamaño.
En lugar de publicar las pruebas zk-STARK de gran tamaño como pruebas de validez, se utiliza un zk-SNARK para atestar la corrección de las pruebas zk-STARK. Estos zk-SNARK se publican a su vez como pruebas de validez de los cambios de estado. Esto ayuda a reducir los costos de gas de 5 millones a 350K.
La red zkEVM de Polygon se ha propuesto ofrecer una solución eficiente y de baja fricción para los usuarios y desarrolladores de aplicaciones descentralizadas. Esto ha sido posible gracias a la implementación de estrategias de eficiencia, como las descritas anteriormente. Con esto hemos aprendido cómo Polygon está ofreciendo una solución de cadena de bloques eficiente y de baja fricción a través de su red zkEVM.
🎉 ¡Gracias por leer hasta el final! Si está interesado en seguir aprendiendo y colaborando con nosotros, le invitamos a revisar nuestra biblioteca sobre zkEVM Polygon para obtener más detalles y también nuestra Biblioteca de Layer 2 en Español para estar actualizado sobre diversas soluciones.
En la segunda parte, profundizaremos en el funcionamiento de Proof of Efficiency, la gestión de estados del Rollup L2 y proporcionaremos ejemplos visuales del explorador de bloques para una mejor comprensión.
Además, 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!
No activity yet