Analizando la arquitectura de zkSync Era

Series zkSync Parte 1/3

Hola comunidad 👋

Desde L2 Español, nos hemos propuesto analizar en profundidad la arquitectura de zkSync, así como explorar sus principios y su utilidad tanto para usuarios como para desarrolladores. En esta serie de tres partes, examinaremos distintos aspectos de esta tecnología, comenzando por la definición de zkSync y su funcionamiento en el sistema de transacciones.

En esta misma parte, también trataremos otros temas relevantes de zkSync que permitirán a los lectores tener una visión más completa de esta solución, sus características y beneficios en relación a la escalabilidad de blockchain. Esperamos que esta serie de artículos sea de gran ayuda para comprender mejor zkSync y cómo se puede utilizar para mejorar la experiencia de los usuarios y desarrolladores en la cadena de bloques.

Además, hemos creado una parte interactiva con un tutorial de “Crosschain Governance” para que todos puedan incrementar un contador desde L2, así los usuarios podrán tener una experiencia práctica y ver en acción cómo funciona zkSync.

Estamos emocionados de presentar esta serie y esperamos que sea de gran interés y utilidad para todos.

💻 Introducción a zkSync

zkSync es un protocolo de capa 2 de Ethereum, que fue lanzado en 2020 con el objetivo de proporcionar transacciones escalables y de bajo costo en la cadena de bloques de Ethereum. Fue desarrollado por Matter Labs, una empresa de investigación y desarrollo en tecnología blockchain, y se basa en la tecnología de "rollups" para lograr este objetivo.

En el caso de zkSync, los rollups se combinan con la tecnología de pruebas de conocimiento cero (ZK).

zkSync es operado centralmente por el equipo de Matter Labs, pero se espera que se traslade a un modelo descentralizado en el futuro cercano. Con su enfoque en la escalabilidad, la privacidad y la accesibilidad, zkSync es una tecnología emocionante que podría desempeñar un papel importante en el futuro de Ethereum y la tecnología blockchain en general. A continuación, presentamos los datos de la actividad que ha tenido zkSync en un período de aproximadamente 3 meses.

Actividad en zkSync en 3 meses
Actividad en zkSync en 3 meses

🚀 Fair Onboarding Alpha

Como ya adelantamos en nuestra Newsletter #3, Fair Onboarding Alpha marca un hito emocionante en la adopción de la criptografía para la soberanía personal. El primer zkEVM en Mainnet de Ethereum, finalmente abrió sus puertas para permitir que los proyectos registrados se implementen en la red principal. Este evento representa una gran oportunidad para miles de desarrolladores y millones de personas que quieren utilizar la criptografía para escalar Ethereum y preservar sus valiosas propiedades.

Fair Onboarding Alpha
Fair Onboarding Alpha

Para llegar a este punto, zkSync ha contado con el apoyo inquebrantable de su comunidad, la empresa se enorgullece de haber contado con su apoyo en cada paso del camino, como resultado, zkSync ha prometido ser completamente de código abierto, y ha cumplido su promesa al hacer que “zkSync 2.0 sea zkSync Era” y “zkSync 1.0 sea zkSync Lite”. La nueva marca, Era, representa una nueva fase en la adopción de la criptografía y habla de la visión de zkSync para una nueva era de Ethereum.

El nombre “ERA” ha sido elegido bajo el siguiente razonamiento:

  • Es simple y universalmente entendido

  • Tiene un amplio atractivo y amplia aplicabilidad

  • Habla de la visión de zkSync para una nueva era de Ethereum.

Como parte de este nuevo hito, zkSync también lanzó una distinción clara entre las dos versiones de su solución de escalabilidad de Ethereum. zkSync 1.0, ahora zkSync Lite, es una versión reducida del protocolo, que ha sido simplificada y optimizada para dApps más simples. zkSync Era, por otro lado, es una versión más completa que cuenta con un zkEVM completamente funcional y una amplia gama de herramientas y funcionalidades para los desarrolladores.

Durante el período de Fair Onboarding Alpha, zkSync permitirá que solo los proyectos registrados puedan implementar y probar sus dApps en la red principal de zkSync. Para ello, es necesario que los proyectos se registren aquí.

Es importante tener en cuenta que, durante Fair Onboarding Alpha, Mainnet permanecerá cerrado para los usuarios finales. Esto se debe a que los equipos pueden implementar y probar sus aplicaciones en un entorno cerrado antes de que el sistema se abra a usuarios externos. A pesar de que la seguridad sigue siendo una prioridad máxima para zkSync, no se recomienda bifurcar el código todavía hasta el Full Launch Alpha.

🌅 Nueva Era y su zkEVM

La zkEVM es una arquitectura que permite la generación de pruebas de conocimiento cero (ZKP), para la ejecución de contratos inteligentes escritos originalmente para EVM.

La arquitectura de zkSync Era y su zkEVM se basa en los siguientes componentes:

  • zkVM: una máquina virtual similar a RISC, completa en Turing y optimizada para pruebas en un circuito ZKP. Tiene varias implementaciones: Executor (ejecución nativa rápida en CPU), generador de testigo (executor nativo para generar un testigo ZKP), y probador (implementación real del circuito ZKP).

  • Copilador basado en LLVM con frontend de Solidity: (más precisamente, frontend de Yul) y Vyper, y backend zkVM.

  • Circuitos de propósito especial: (que dependen en gran medida de las compuertas y tablas de búsqueda personalizadas de PLONK) como "precompilaciones" para operaciones computacionalmente intensivas, como hashes no algebraicos (Keccak, SHA256, Blake2), acceso al almacenamiento (caminos de Merkle), emparejamiento de curvas elípticas y circuitos de agregación recursiva (combina las pruebas de las partes mencionadas anteriormente).

Podemos resumir la zkEVM como una arquitectura que permite generar pruebas de conocimiento cero para contratos inteligentes, con componentes clave como zkVM, un compilador basado en LLVM y circuitos de propósito especial. zkVM hereda estrictamente el modelo de programación EVM y sus invariantes, incluidas las convenciones de llamadas ABI, y admite reversiones y transacciones reversibles para garantizar la protección mutua.

Arquitectura de Copiladores de zkSync y zkEVM
Arquitectura de Copiladores de zkSync y zkEVM

Los desarrolladores pueden confiar en la resistencia a la censura proporcionada por L1 sin cambios relacionados con el mecanismo de escotilla de escape, lo que significa que los activos en una cuenta zkRollup en zkSync tienen las mismas garantías de seguridad que en L1.

🆕🆙 Mejoras en la EVM

La zkEVM mejora la adopción y beneficia los proyectos de ecosistema al mantener la máxima compatibilidad con el EVM y agregar mejoras significativas.

Una de ellas es el compilador basado en LLVM, este aumenta la eficiencia del código y permite integrar bases de código de otros lenguajes de programación. Además, el zkEVM incluye la abstracción de cuenta (AA), una función esperada por la comunidad de desarrolladores de Ethereum, que mejora la experiencia del usuario al ofrecer soporte nativo para billeteras de contratos inteligentes, mejor UX para multisigs (dirección que está asociada con más de una clave privada), la posibilidad de pagar tarifas de transacción en cualquier token y permitir que los protocolos puedan subsidiar el gas para los usuarios de sus contratos inteligentes.

También permite confirmar lotes de transacciones con un solo clic, lo que mejora la UX en Ethereum.

🌐 Transacciones

Las transacciones en Ethereum son instrucciones firmadas criptográficamente por una cuenta externa (una cuenta propiedad de un usuario y no de un código). Estas instrucciones se almacenan en la blockchain y se añaden a un bloque. El estado de la máquina virtual de Ethereum (EVM) cambia cuando se inicia una transacción. Una transacción puede ser cualquier cosa, desde enviar ether a otra cuenta hasta invocar las funciones de un contrato inteligente.

¿Cómo funcionan las transacciones?

Cuando un usuario inicia una transacción en Ethereum, se crean algunos datos específicos:

  • Receptor: el receptor es la dirección de la cuenta para recibir la transacción, este receptor puede ser una cuenta de contrato o una cuenta externa. Cada transacción va dirigida a un destinatario concreto.

  • Nonce: este campo muestra la transacción más reciente basada en el contador de la cuenta, que mantiene un registro de cuántas transacciones realiza. La red utiliza el nonce de la transacción para garantizar que las transacciones se completan en la secuencia correcta.

  • Precio del gas: la mayoría de las transacciones requieren el pago de una tasa al autor de la transacción, este coste se calcula por unidad de gas. La unidad es wei, una unidad de éter más pequeña.

  • Límite de gas: el autor de la transacción especifica el número de unidades de gas utilizadas para la transacción y es la cantidad total de gas que se puede consumir.

  • Valor: la cantidad de wei o Éter que la cuenta remitente desea transmitir al destinatario está representada por el valor.

  • Datos: si el receptor de la transacción es un contrato inteligente, los datos contienen información para que se ejecuten las funciones del contrato. Se compone de datos de longitud variable.

  • Firma: la firma indica quién ha enviado la comunicación, la firma se crea cuando una cuenta externa confirma y firma la transacción con su clave privada.

🔄 Tipos de transacciones

Las transferencias de activos tales como ETH, tokens o interacciones con contratos son funcionalidades básicas en Ethereum para entre cuentas. Este tipo de transferencias son comunes en las operaciones diarias de la red y son necesarias para llevar a cabo cualquier tipo de transacción en Ethereum. Por otro lado, las transacciones de despliegue de contratos son aquellas en las que se crea un nuevo contrato inteligente en la red de Ethereum.

El despliegue de contratos en zkSync es bastante diferente al de Ethereum:

  • Ethereum: el despliegue de contratos se produce cuando un usuario envía una transacción a la dirección cero (0x000...000) con el campo de datos de la transacción igual al bytecode del contrato concatenado con los parámetros del constructor.

  • zkSync: para desplegar un contrato en zkSync, un usuario llama a la función create del ContractDeployer y proporciona el hash del contrato a publicar, así como los argumentos del constructor. El propio bytecode del contrato se suministra en el campo factory_deps de las transacciones EIP-712. Si el contrato es una fábrica (es decir, puede desplegar otros contratos), los bytecodes de estos contratos deben incluirse también en factory_deps.

zkSync soporta los tipos de transacción "antiguos" (pre EIP-2718) de Ethereum, el tipo de transacción EIP-1559 y sus transacciones EIP-712. Las transacciones de este tipo se pueden utilizar para acceder a características específicas de zkSync como la abstracción de cuentas. Además, los contratos inteligentes sólo pueden desplegarse con este tipo de transacción.

¿Cuándo se considera que una transacción es final?

La finalidad de una transacción se refiere a la promesa de que las transacciones no pueden ser revertidas, alteradas o mutadas en el contexto de una red blockchain.

Bajo prueba de participación, las transacciones de Ethereum finalizan en 2,5 épocas (16 minutos) de media en condiciones normales: revertir esa transacción costaría 1/3 del suministro total de Ethereum.

Una vez que un bloque se ha llenado y sellado en ZK Rollups, su estado se registra en la cadena principal de Ethereum. A continuación, se inicia la etapa de comprobación y se construye una prueba de validez SNARK para cada transacción de bloque. Una vez completada, la SNARK se envía para su verificación en el contrato inteligente L1, y el estado de la transacción se convierte en definitivo tras la verificación.

Desde el punto de vista de zkSync, la finalidad se produce cuando la transacción (la verificación SNARK) es ejecutada por L1. En este punto, las garantías son las mismas que cualquier otra transacción L1 dentro del mismo bloque L1, cuantos más bloques L1 se emitan después de que se procese el bloque inicial, menos probable será que esta transacción se anule.

Cuando un usuario transmite una transacción, zkSync espera actualmente a que se llene todo el bloque, lo que significa que el tiempo de finalidad puede ser mayor dependiendo del volumen de transacciones enviadas a través de zkSync. El tiempo de finalización se reducirá a medida que aumente el rendimiento.

👩🏼‍💻 Los Operadores o Secuenciadores

Los operadores son los actores que llevan a cabo las funciones esenciales de zkRollup. Son responsables de producir bloques, empaquetar transacciones, realizar cálculos y enviar datos a la cadena principal de Ethereum para su verificación.

🟪 Bloques en la era zkSync

En zkSync existen dos nociones de bloques, los bloques a nivel de L2 y los bloques entendidos como lotes o “batches” para el rollup en L1.

  • Bloques en L2: son simplemente los bloques creados en L2, es decir, en la red zkSync y no se incluyen en la cadena Ethereum. Un bloque L1 rollup, que le dan el nombre de "lote", es un conjunto de bloques (L2) consecutivos, contiene todas las transacciones, y en el mismo orden, desde el primer bloque del lote hasta el último bloque del lote.

  • Lotes para L1: como su nombre indica se envían a Ethereum. La razón principal para tener estas nociones diferentes es que un bloque puede contener un número mínimo de transacciones, y así ser procesado rápidamente, mientras que en un lote pueden incluir muchas transacciones, para hacer que el coste de la interacción con L1 se reparta entre muchas transacciones.

⏳ Tiempo de procesamiento de los bloques

El operador procesa inmediatamente las transacciones y las añade a los bloques, que se generan inmediatamente. Una vez que zkSync esté totalmente descentralizado, el tiempo de bloque tardará un par de segundos, ya que las entidades implicadas necesitan alcanzar un consenso.

En general, un lote (rollup) se sellará cuando:

  • Se alcanza la "capacidad" del lote.

  • La capacidad incluye el gas L1 utilizado, el gas L2 consumido y otros parámetros.

  • Ha transcurrido el tiempo de espera del lote.

Cada lote L1 (que comprende varios bloques L2) se ejecuta en una única instancia de VM. La VM ejecuta las transacciones una a una y luego ejecuta algún código que no tiene nada que ver con la última transacción, sino con todo el lote. Actualmente, el ETH recaudado de las comisiones se transfiere desde la dirección formal del bootloader a la dirección del minero de bloques. La cuestión es que esta transferencia emite un evento (como cualquier otra transferencia), de ahí que hayan incluido este evento en un bloque L2 para que sea accesible vía API.

Es posible añadir eventos en el último bloque L2 del lote L1, pero debemos considerar ciertos escenarios. Por ejemplo, si un bloque L2 ya se ha cerrado, pero su lote L1 aún no, y no se han recibido nuevas transacciones en un tiempo, entonces el lote L1 debe cerrarse para evitar tiempos de espera. Si añadimos el evento al último bloque cerrado, se modificará el bloque y se generará una reorganización en la cadena de bloques.

Para evitar esta situación, se construye un bloque puramente ficticio que sólo contiene el evento. De esta manera, se evita modificar el último bloque cerrado y se mantiene la integridad de la cadena de bloques.

#️⃣ Hashes

Los hashes de bloque en zkSync son deterministas, la razón de tener un hash de bloque determinista es que estos hashes no son demostrables (recuerde que los bloques L2 no se envían a L1). Se recomienda a los proyectos que no utilicen el hash de bloque L2 como fuente de aleatoriedad.

📜 Propiedades de los Bloques en L2

En este texto se presentan las principales propiedades de los bloques en L2 de zkSync, además, se destaca que zkSync no tiene consenso de prueba de trabajo.

  • Marca de tiempo: la hora de creación del bloque actual en segundos que devuelve la marca de tiempo del lote L1.

  • Número de bloque: el número secuencial único de este bloque.

  • Límite de gas: el límite de gas del bloque actual, siempre devuelve 2^32-1.

  • Coinbase: la dirección del minero del bloque actual, devuelve la dirección del bootloader.

  • Dificultad: la dificultad del bloque actual, devuelve 2500000000000000 (zkSync no tiene consenso de prueba de trabajo).

🕵️‍♂️ La etapa de validación

Durante el paso de validación, la cuenta debe decidir si acepta la transacción y, en caso afirmativo, pagar las comisiones correspondientes. Si falla alguna parte de la validación, no se cobra comisión a la cuenta, y dicha transacción no puede incluirse en un bloque.

  • Paso 1. El sistema comprueba que el nonce de la transacción no se haya utilizado antes.

  • Paso 2. El sistema llama al método validateTransaction de la cuenta. Si no revierte, procede al siguiente paso.

  • Paso 3. El sistema comprueba que el nonce de la transacción se ha marcado como utilizado.

  • Paso 4 (sin pagador). El sistema llama al método payForTransaction de la cuenta. Si no revierte, pasa al siguiente paso.

  • Paso 4 (pagador). El sistema llama al método prePaymaster del remitente. Si esta llamada no revierte, se llama al método validateAndPayForPaymasterTransaction del pagador. Si tampoco revierte, se procede al siguiente paso.

  • Paso 5. El sistema verifica que el gestor de arranque ha recibido al menos tx.gasPrice * tx.gasLimit ETH al gestor de arranque. Si es así, la verificación se considera completa y podemos proceder al siguiente paso.

🔐 La etapa de ejecución

El paso de ejecución se considera responsable de la ejecución real de la transacción y del envío de los reembolsos de cualquier gas no utilizado al usuario. Si se produce alguna devolución en este paso, la transacción sigue considerándose válida y se incluirá en el bloque.

  • Paso 6. El sistema llama al método executeTransaction de la cuenta.

  • Paso 7. (sólo en caso de que la transacción tenga un pagador) Se llama al método postOp del pagador. Este paso debería utilizarse normalmente para reembolsar al remitente el gas no utilizado en caso de que el pagador se haya utilizado para facilitar el pago de comisiones en tokens ERC-20.

💸 Fees o Tasas de transacciones en zkSync

En zkSync, su objetivo es ser compatible con Ethereum, lo que significa que su objetivo es compartir similitudes y minimizar las grandes diferencias, una de esas similitudes es el modelo de tarifa de gas de zkSync.

La versión de zkSync de gas representa no solo los costos de los cálculos, sino también el costo de publicar datos en la cadena y afectar el almacenamiento.

Dado que los costos de publicar los datos de llamada en L1 son muy volátiles, la cantidad de gas necesaria para cambiar una ranura de almacenamiento no es constante. Para cada bloque, el operador define los siguientes parámetros dinámicos:

  • gas_price: la tabla para el precio base actual en cada ficha. El valor de este parámetro se usa para determinar los costos de ejecución de VM en cada token.

  • gas_per_pubdata: el precio gas por publicar un byte de datos en Ethereum.

Tenga en cuenta que los datos públicos se postean solo para diferencias de estado. Si la misma ranura de almacenamiento se actualiza 10 veces en el mismo bloque acumulativo, solo se publicará la actualización final en Ethereum, por lo que solo se cobrará una vez por los datos públicos.

📊 Comparación del modelo de tarifas entre zkSync y Ethereum

En zkSync, a diferencia de Ethereum, los códigos de operación tienen precios de gas similares debido a que el costo de los mismos es diferente. Por lo general, la propia ejecución de operaciones aritméticas es económica, aunque como en Ethereum, la mayor parte del costo se incurre en actualizaciones de almacenamiento.

A pesar de estas diferencias, el modelo de tarifas en zkSync es similar al de Ethereum, donde la operación más costosa sigue siendo el cambio de almacenamiento. Una ventaja de los ZR Rollup sobre los optimistic rollup, es que, en lugar de publicar todos los datos de transacciones, los ZR Rollup pueden publicar solo las diferencias de estado, lo que minimiza los cambios de almacenamiento.

🤖 Pruebas L2 Español

🗳️ Crosschain Governance

En este tutorial se mostrará cómo se puede utilizar la interoperabilidad entre L1 y L2 para crear un sistema de gobernanza controlado desde L1 y su wallet. Para lograr esto, se crearán dos contratos, uno en L1 y otro en L2.

El contrato en L2 será un simple contrato de "contador" que almacenará un número que puede ser incrementado llamando al método "increment". Este contrato será accesible para todos los usuarios de L2.

El contrato de gobernanza en L1 tendrá la función de incrementar el contador en L2 y será controlado únicamente por el administrador. Además, este contrato permitirá votar y ajustar otros contratos en L2.

El creador del contrato será establecido como el único gobernador y se incluirá una función que permitirá solicitar transacciones en L2 a través del contrato inteligente zkSync.

Para votar desde L2, los usuarios podrán llamar al método "increment" en el contrato de contador en L2, pero para realizar ajustes desde L1, el administrador tendrá que llamar al método correspondiente en el contrato de gobernanza en L1, que a su vez llamará al contrato correspondiente en L2.

En conclusión, la interoperabilidad entre L1 y L2 permite crear sistemas de gobernanza que pueden ser controlados desde L1, pero accesibles para todos los usuarios en L2. Esta funcionalidad puede ser utilizada para votar, realizar ajustes y controlar otros contratos en L2 desde L1, y todo ello de forma segura.

🧪 Añadir red Testnet zkSync ERA

Si desea interactuar con zkSync, puede agregar la red Testnet zkSync Era a su Metamask a través del enlace oficial proporcionado, o puede hacerlo directamente agregando una nueva red y utilizando la información de conexión específica de zkSync Era que se detalla a continuación.

Información de la red de la red de prueba

Para comenzar a utilizar zkSync, primero debe obtener faucet ETH en la red principal (L1) y transferirlos a la red zkSync Era a través del Portal Bridge. Puede obtener estos tokens ETH desde varios enlaces disponibles en la red L1, o utilizar el Portal Faucet zkSync Era para recibir una combinación de varios tokens ERC20 de forma gratuita.

Además, puede revisar la sección de zkEVM en nuestro artículo para obtener más información sobre el funcionamiento de zkSync en la red Ethereum.

Incrementar Counter

Primero, desplegamos el contrato de Governance en L1, como se mencionó anteriormente, para que sea responsable de controlar las configuraciones e incluso aumentar el contador desde L1.

Contrato Governance en L1 y su gobernador
Contrato Governance en L1 y su gobernador

Una vez que tenga ETH, puede acceder al contrato que hemos implementado y verificado para que el usuario pueda revisarlo y actuar sobre él. Como puede observar, ya se ha definido el contrato de gobernanza en L1 que hemos creado.

Counter en L2 zkSync con Smart de Governance
Counter en L2 zkSync con Smart de Governance

Interactuar con Counter

Si deseas interactuar con el contrato de gobernanza en zkSync, haz clic aquí y se mostrará una imagen con el contrato “Counter” de L2 y su explorador, donde deberá conectar su billetera, agregar la red de pruebas zkSync ERA y tener fondos en ella. Luego podrá hacer clic en "write" en “increment” y deberá pagar la tarifa correspondiente a la transacción.

Una vez haya pagado saldrá la transacción con su Hash
Una vez haya pagado saldrá la transacción con su Hash

Puede observar como hemos aumentado el contador a 1, siéntase libre de probar y aumentar el contador de L2 utilizando una wallet de Testnet en zkSync. Hemos configurado el contrato de gobernanza para que los ajustes del contador en L2 estén abiertos a todos los usuarios.

Sin embargo, es importante destacar que el control del contrato de gobernanza en L1 está limitado al propietario.

El contador ha incrementado
El contador ha incrementado

Así de fácil se realiza el voto en Cross Chain utilizando zkSync Era, con un desarrollo sencillo y seguro.

🫂 Agradecimientos

Terminamos la primera parte de la serie de zkSync, en esta parte analizamos la arquitectura de esta solución de escalabilidad blockchain. En la segunda edición, hablaremos sobre el futuro de la escalabilidad con zkSync Era y sus nuevas implementaciones, abordaremos temas muy importantes antes de llegar a la tercera parte, en la que estamos preparando una sección “Extra” interactiva, en la que esperamos que disfrutes participando en actividades relacionadas con zkSync y el ecosistema blockchain.

🎉 ¡Gracias por leer hasta el final! Si está interesado en continuar aprendiendo y colaborando con nosotros, le invitamos a unirse a la 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!

Subscribe to L2 en Español
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.