ZKsync Era: Cómo funciona el rollup zkEVM y cómo construir sobre él

Qué es ZKsync Era y qué cubre esta guía

ZKsync Era es un rollup de Capa 2 sobre Ethereum construido alrededor de una EVM de conocimiento cero (zkEVM). Las transacciones son ejecutadas por un secuenciador fuera de la cadena, agrupadas en lotes y comprometidas en Ethereum junto con pruebas de validez. Debido a que la corrección se garantiza criptográficamente mediante la prueba en lugar de un período de desafío, los retiros y las transiciones de estado no dependen de que un vigilante honesto permanezca en línea durante una ventana de disputa.

El nombre se usa de dos maneras superpuestas. Se refiere a la cadena principal Era con la que los desarrolladores interactúan hoy, y también se refiere al código abierto matter-labs/zksync-era, que desde entonces se ha generalizado en el marco ZK Stack para lanzar cadenas personalizadas. Cuando leas documentación, verifica si una página describe específicamente la cadena Era o el stack más amplio.

Este artículo cubre la cadena Era como objetivo de integración: el modelo de ejecución, la superficie JSON-RPC, un procedimiento de lectura y escritura ejecutable, cómo verificar resultados y dónde están los modos de falla comunes. No cubre tokenomics ni precio, y no recomienda una URL de endpoint público específica; la selección de endpoint es una decisión separada cubierta por el Asistente RPC.

• Ejecución: el bytecode compatible con EVM se ejecuta en un secuenciador fuera de la cadena.
• Seguridad: pruebas de validez publicadas en Ethereum, no pruebas de fraude.
• Datos: los datos de transacción y los diffs de estado se comprimen y se publican en Ethereum.
• Herramientas: JSON-RPC estándar de Ethereum más un pequeño conjunto de métodos específicos de Era.

Requisitos previos y suposiciones

Los procedimientos a continuación asumen que tienes Node.js 18 o superior, curl y una cuenta con fondos en ZKsync Era si pretendes enviar una transacción. Necesitas un endpoint RPC que sirva la cadena Era; mantenlo en una variable de entorno llamada RPC_URL para que los mismos scripts funcionen con cualquier proveedor. Para operaciones de escritura, mantén la clave en PRIVATE_KEY y nunca la confirmes en el repositorio.

Ya deberías estar cómodo con los conceptos de Ethereum: cuentas, nonces, gas y la diferencia entre un hash de transacción y un recibo. Si eres nuevo en los patrones de acceso a nodos, la guía sobre alojamiento de nodos blockchain explica qué te ofrece un nodo dedicado que un endpoint compartido no.

Todos los resultados numéricos en este artículo son marcadores de posición. El estado de la cadena cambia constantemente, por lo que cualquier valor que veas es una instantánea de tu propia llamada, no un punto de referencia.

El modelo mental: ejecución, agrupamiento y pruebas

Piensa en ZKsync Era como tres capas de actividad. Primero, el secuenciador ordena y ejecuta transacciones, produciendo un nuevo estado. Segundo, un probador genera una prueba de conocimiento cero de que la transición de estado siguió las reglas. Tercero, una transacción de compromiso en Ethereum publica los datos comprimidos y la prueba para que cualquiera pueda verificar la transición sin volver a ejecutarla.

Esto difiere de los rollups optimistas de una manera que importa operativamente. En un rollup optimista, una transacción se acepta de forma optimista y puede ser desafiada durante una ventana; en Era, el argumento de seguridad se basa en la prueba. En la práctica, ambos se sienten similares para un desarrollador de aplicaciones, pero el momento en que una raíz de estado se considera final en Ethereum difiere, y no debes tratar una transacción incluida por el secuenciador como final en Ethereum.

Era también comprime los datos de llamada antes de publicarlos. Es por eso que las tarifas en Era suelen ser mucho más bajas que en L1, y por eso la estimación de gas puede parecer poco familiar: el costo de publicar datos es un componente importante, y se cotiza de una manera que refleja la compresión a nivel de byte en lugar de la longitud bruta de los datos de llamada.

En qué se diferencia ZKsync Era de una cadena EVM simple

La mayoría de los contratos se despliegan y ejecutan sin cambios, pero un puñado de comportamientos son específicos de Era y vale la pena conocerlos antes de depurar. El gas se divide en componentes de cómputo y pubdata, y el campo gasPerPubdataByte aparece en los tipos de transacción. Algunas precompilaciones y opcodes se comportan de manera diferente o no están disponibles, y la abstracción de cuentas es nativa en lugar de estar añadida, por lo que las cuentas pueden pagar tarifas en tokens ERC-20 y pueden llevar lógica de validación personalizada.

Para el trabajo de integración, la consecuencia más importante es que no debes asumir que un estimador de gas de la red principal de Ethereum producirá un límite correcto. Usa la estimación propia del nodo y añade un margen. De manera similar, no asumas que eth_getTransactionReceipt devolver un recibo significa que el lote está probado en Ethereum; significa que el secuenciador ha incluido la transacción.

• Abstracción de cuentas nativa: las cuentas inteligentes y los pagadores son de primera clase.
• Gas en dos partes: cómputo más pubdata, expuesto a través de campos específicos de Era.
• Finalidad basada en pruebas: la inclusión, el compromiso del lote y la verificación de la prueba son etapas distintas.
• Los métodos RPC específicos de Era complementan el conjunto estándar de Ethereum.

Lectura del estado de la cadena a través de JSON-RPC

Comienza con llamadas de solo lectura para confirmar que tu endpoint está sirviendo la cadena Era y que los métodos estándar se comportan como se espera. El siguiente script usa curl e imprime el ID de cadena, el número de bloque más reciente y el saldo de una dirección que proporciones. Reemplaza RPC_URL y ADDRESS antes de ejecutarlo.

Una ejecución correcta devuelve un ID de cadena que coincide con la red Era que pretendías, un número de bloque que aumenta monotónicamente y un saldo en wei como una cadena hexadecimal. Si el ID de cadena no coincide, estás apuntando a la red incorrecta y cada resultado posterior es sospechoso.

export RPC_URL="https://your-era-endpoint.example"
export ADDRESS="0xYourAddress"

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"eth_blockNumber","params":[]}'

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d "{\"jsonrpc\":\"2.0\",\"id\":3,\"method\":\"eth_getBalance\",\"params\":[\"$ADDRESS\",\"latest\"]}"

Envío de una transacción y seguimiento de sus etapas

El siguiente ejemplo de JavaScript usa ethers para enviar una transferencia pequeña y luego sondear el recibo. Lee el endpoint y la clave de las variables de entorno, estima el gas con el nodo y aplica un margen. También imprime el número de bloque en el que aparece el recibo para que puedas correlacionarlo con la actividad del lote más adelante.

Ejecútalo primero contra una cuenta de prueba. El resultado de verificación esperado es un recibo con status igual a 1 y un blockNumber mayor que el número de bloque que registraste antes de enviar. Si el recibo nunca aparece, la transacción puede seguir pendiente en el mempool del secuenciador; verifica el hash con eth_getTransactionByHash antes de reenviar.

import { JsonRpcProvider, Wallet, parseEther } from "ethers";

const provider = new JsonRpcProvider(process.env.RPC_URL);
const wallet = new Wallet(process.env.PRIVATE_KEY, provider);

const before = await provider.getBlockNumber();
const fee = await provider.getFeeData();
const gas = await provider.estimateGas({
  from: wallet.address,
  to: process.env.ADDRESS,
  value: parseEther("0.0001"),
});

const tx = await wallet.sendTransaction({
  to: process.env.ADDRESS,
  value: parseEther("0.0001"),
  gasLimit: (gas * 120n) / 100n,
  maxFeePerGas: fee.maxFeePerGas,
  maxPriorityFeePerGas: fee.maxPriorityFeePerGas,
});

console.log("sent", tx.hash, "from block", before);
const receipt = await tx.wait();
console.log("status", receipt.status, "in block", receipt.blockNumber);

Un procedimiento de medición reproducible

Si necesitas comparar endpoints o confirmar la latencia para tu propia aplicación, ejecuta un procedimiento controlado en lugar de confiar en una sola llamada. El método a continuación está diseñado para que otro ingeniero pueda repetirlo y obtener una estructura comparable, incluso si los números absolutos difieren.

Registra la siguiente tabla para cada endpoint que pruebes, usando al menos 100 iteraciones de cada llamada y reportando la mediana y el percentil 95. No completes números de este artículo; la tabla es una plantilla para tu propia ejecución.

• Calienta con 10 llamadas y descártalas.
• Mide eth_blockNumber y eth_getBalance por separado.
• Ejecuta desde la misma máquina y ruta de red para cada endpoint.
• Registra los fallos y tiempos de espera como su propia categoría, no como éxitos lentos.
• Repite a una hora diferente del día para exponer la varianza dependiente de la carga.

Verificación de resultados y comprensión de la finalidad

La verificación tiene dos niveles. El primero es la inclusión: el secuenciador ha ejecutado tu transacción y existe un recibo. El segundo es la liquidación a nivel de Ethereum: el lote que contiene tu transacción ha sido comprometido y su prueba verificada en Ethereum. Un recibo por sí solo no prueba lo segundo.

Para verificar la liquidación, busca el lote que incluye tu transacción usando métodos específicos de Era como zks_getTransactionDetails, que devuelve números de lote y metadatos relacionados, luego consulta el lote con zks_getL1BatchDetails. Compara los hashes de transacción de compromiso y ejecución del lote con Ethereum. Si esos hashes están ausentes, el lote aún no está liquidado.

Para la mayoría de la lógica de aplicación, la inclusión es suficiente y debes diseñar en torno a ella. Para puentes, custodia y cualquier cosa que deba sobrevivir a una falla del secuenciador, espera a que la prueba se verifique en Ethereum. La contrapartida es la latencia: la liquidación tarda más que la inclusión, y la brecha depende del rendimiento del probador y del tiempo de bloque de Ethereum.

• Inclusión: el recibo existe, el estado es 1.
• Compromiso: los datos del lote se publican en Ethereum.
• Ejecución: la prueba de validez se verifica en Ethereum.
• Regla de aplicación: elige la etapa que coincida con tu tolerancia al riesgo.

Solución de problemas comunes de integración

La mayoría de las fallas se agrupan en unos pocos casos. Un ID de cadena incorrecto significa que el endpoint está sirviendo una red diferente. Una reversión en la estimación de gas generalmente significa que la transacción fallaría en la ejecución, no que el endpoint esté roto; simula con eth_call primero. Un recibo ausente después de una larga espera a menudo significa que la transacción fue descartada o que el nonce está desactualizado.

Si ves tiempos de espera repetidos bajo carga, el problema pueden ser los límites de velocidad de tu endpoint en lugar de la cadena. Compara con un segundo endpoint usando el procedimiento de medición anterior. Para necesidades de rendimiento persistentes, un nodo dedicado elimina los límites de velocidad compartidos, y la página de precios de RPC explica cómo los planes se asignan al volumen de solicitudes.

Si un contrato se comporta de manera diferente que en la red principal de Ethereum, verifica el soporte de opcodes y precompilaciones específicos de Era antes de asumir un error del nodo. Reproduce la llamada con eth_call contra un bloque conocido como bueno para aislar si el problema depende del estado.

• Discrepancia de ID de cadena: confirma la red del endpoint antes de depurar más.
• Reversión en la estimación: simula con eth_call e inspecciona el motivo de la reversión.
• Nonce desactualizado: consulta el nonce pendiente y reemplaza la transacción.
• Límite de velocidad: compara endpoints y revisa los encabezados de respuesta.

Limitaciones y compensaciones

ZKsync Era no es un reemplazo directo de Ethereum en todos los aspectos. La abstracción de cuentas cambia cómo se pueden pagar las tarifas y cómo funciona la validación, lo que afecta la integración de billeteras y pagadores. El precio de pubdata significa que los costos de gas son sensibles al tamaño de los datos de llamada de maneras que difieren de L1. Y debido a que la liquidación depende de la generación de pruebas, el tiempo hasta la finalidad en Ethereum no es fijo.

También hay una compensación operativa en cómo accedes a la cadena. Los endpoints públicos compartidos son convenientes pero están sujetos a límites de velocidad y latencia variable; la infraestructura dedicada cuesta más pero ofrece un rendimiento predecible. Ninguna de las dos opciones cambia el protocolo, pero ambas cambian la experiencia que tienen tus usuarios.

Finalmente, el ecosistema es más amplio que la cadena Era por sí sola. ZK Stack permite a los equipos lanzar cadenas personalizadas que interoperan con Era, por lo que la documentación que leas puede describir un comportamiento que se aplica al stack en lugar de específicamente a Era. Siempre confirma a qué objetivo se dirige una página.

Próximos pasos para construir sobre ZKsync Era

Con las lecturas, escrituras y verificación funcionando, el siguiente paso es reforzar tu integración. Agrega reintentos con retroceso alrededor de las llamadas RPC, almacena en caché datos inmutables como el ID de cadena y registra el número de lote junto a cada transacción para que las verificaciones de liquidación sean fáciles más adelante. Si estás desplegando contratos, prueba contra un nodo local o una testnet antes de la red principal.

Para la selección de endpoint, usa el Asistente RPC en lugar de codificar una URL de un tutorial. Puede indicarte un endpoint Era adecuado y explicar las compensaciones. Para ver qué redes son compatibles, explora el directorio de redes, y para opciones de acceso gestionado revisa el servicio API. Si aún estás decidiendo entre acceso compartido y dedicado, la guía de endpoints RPC multicadena cubre la decisión con más profundidad.

• Agrega lógica de reintento y retroceso alrededor de cada llamada RPC.
• Registra los números de lote para las transacciones que requieren verificaciones de liquidación.
• Prueba los despliegues de contratos en una testnet antes de la red principal.
• Vuelve a ejecutar el procedimiento de medición después de cualquier cambio de infraestructura.