Etherlink: Guía práctica para la capa 2 EVM en Tezos

Qué es Etherlink y qué cubre esta guía

Etherlink es una capa de ejecución de capa 2 para Tezos. Es no custodial y está impulsada por la tecnología Tezos Smart Rollup, y es compatible con EVM, por lo que se pueden usar herramientas familiares de Ethereum como MetaMask, Hardhat y Foundry. Se puede acceder a la misma blockchain a través de dos interfaces: la interfaz EVM y la interfaz Michelson.

Esta guía está dirigida a desarrolladores y operadores que necesitan conectarse a Etherlink, desplegar o llamar contratos, verificar resultados de transacciones y diagnosticar fallos. Se asume que tienes familiaridad básica con conceptos EVM como direcciones, gas y JSON-RPC, y que puedes ejecutar herramientas de línea de comandos. No se asume ningún proveedor específico; la selección de endpoint es una decisión separada que se cubre más adelante.

• Alcance: conexión, despliegue, verificación y solución de problemas en Etherlink.
• Fuera de alcance: análisis de precios de tokens, estrategias de rendimiento y mecánicas de votación de gobernanza.
• Suposición: tienes una billetera EVM y una cuenta con fondos en la red que elijas.

El modelo mental: una cadena, dos interfaces, liquidación en L1

Piensa en Etherlink como una blockchain con dos puertas de entrada. La puerta EVM acepta transacciones y llamadas JSON-RPC al estilo Ethereum. La puerta Michelson acepta interacciones al estilo Tezos. Ambas puertas conducen al mismo estado, por lo que los activos pueden moverse entre Etherlink y Tezos L1 Mainnet y las cadenas compatibles con EVM pueden interoperar.

La liquidación ocurre en Tezos Layer 1. Etherlink utiliza Smart Rollups, un mecanismo de rollup optimista consagrado implementado por Tezos. El secuenciador proporciona confirmaciones de baja latencia, mientras que la finalidad y la seguridad dependen en última instancia de Tezos L1. Esta separación importa operativamente: una transacción puede aparecer confirmada en la capa de ejecución antes de liquidarse en la capa de consenso.

La documentación describe tiempos de confirmación de alrededor de 500 ms en la capa de ejecución y liquidación de aproximadamente 6 segundos en L1, con una función experimental de confirmación instantánea que proporciona preconfirmaciones en unos 50 ms. Trata estas cifras como características documentadas, no como garantías para tu carga de trabajo específica. Mídelas en tu propia ruta.

• Capa de ejecución: donde se ordenan y ejecutan las transacciones EVM.
• Capa de consenso: Tezos L1, donde se anclan la liquidación y la seguridad.
• Secuenciador: proporciona confirmaciones rápidas; no es la fuente final de verdad.
• Gobernanza: integrada con la gobernanza on-chain de Tezos para cambios de protocolo.

Requisitos previos y supuestos del entorno

Antes de ejecutar los procedimientos a continuación, prepara un entorno de trabajo. Necesitas Node.js y npm para los ejemplos de JavaScript, curl para las comprobaciones RPC, y una billetera EVM o una clave privada para el despliegue. Mantén los secretos fuera del historial de shell y del control de versiones.

También necesitas un endpoint RPC para Etherlink. Los ejemplos usan el marcador de posición RPC_URL. No codifiques un endpoint público en producción; elige un proveedor según tus requisitos de latencia, límite de tasa y fiabilidad. Para una recomendación concreta de endpoint, usa el RPC Assistant en lugar de adivinar.

• Node.js 18 o posterior y npm.
• curl instalado.
• Una cuenta con fondos en Etherlink para pruebas de despliegue.
• Un RPC_URL que controles o en el que confíes, más una PRIVATE_KEY almacenada en una variable de entorno.

Conexión a Etherlink mediante JSON-RPC

La forma más rápida de confirmar la conectividad es una llamada JSON-RPC estándar. Etherlink es compatible con EVM, por lo que eth_chainId y eth_blockNumber se comportan como esperas. Ejecuta lo siguiente y registra el ID de cadena y el número de bloque. El ID de cadena es lo que configurarás en billeteras y scripts de despliegue.

Si la llamada falla, el problema suele ser el endpoint, la selección de red o un proxy delante de tu cliente. Prueba primero con curl y luego pasa a una biblioteca.

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":[]}'

Despliegue y llamada a un contrato con ethers

Un despliegue mínimo confirma que tu cadena de herramientas, cuenta y ruta RPC funcionan juntas. El siguiente script usa ethers para leer el ID de cadena, enviar una transacción y esperar un recibo. Reemplaza RPC_URL y PRIVATE_KEY con tus propios valores. El bytecode del contrato se omite intencionalmente; usa tu propio artefacto compilado.

El punto clave de verificación es el estado del recibo. Un estado de 1 significa que la transacción se ejecutó correctamente en la capa de ejecución. Por sí solo no prueba la liquidación en L1, que es una comprobación separada.

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

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

const chainId = (await provider.getNetwork()).chainId;
console.log("chainId", chainId.toString());

const factory = new ContractFactory(abi, bytecode, wallet);
const contract = await factory.deploy();
const deployTx = contract.deploymentTransaction();
console.log("deploy tx", deployTx.hash);

const receipt = await deployTx.wait();
console.log("status", receipt.status, "block", receipt.blockNumber);

Verificación del estado de la transacción y la liquidación

La verificación tiene dos capas. Primero, confirma el recibo de la capa de ejecución con eth_getTransactionReceipt. Segundo, confirma que la transacción se refleja en el estado de la cadena leyendo el contrato o saldo relevante después del bloque del recibo. Para operaciones sensibles a la liquidación, verifica también el lado L1 según las herramientas de Tezos y la documentación de Etherlink.

Usa el siguiente procedimiento y registra los resultados en una tabla. No rellenes números de memoria; ejecuta cada paso y pega la salida real. La tabla es una plantilla, no una afirmación sobre el rendimiento.

• Paso 1: llama a eth_getTransactionReceipt y registra status, blockNumber y gasUsed.
• Paso 2: lee el estado afectado en el bloque del recibo y registra el valor.
• Paso 3: repite la lectura tras un breve retraso y confirma la consistencia.
• Paso 4: para comprobaciones de liquidación, sigue la ruta de verificación documentada en Tezos L1.

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

Plantilla de tabla de resultados para tus propias mediciones

Usa esta tabla Markdown para registrar tus propias observaciones. Deja las celdas en blanco hasta que las hayas medido. Las columnas separan la confirmación de la capa de ejecución de la liquidación en L1 para que no confundas ambas.

Solución de fallos comunes en Etherlink

La mayoría de los fallos se agrupan en unas pocas categorías: red incorrecta, fondos insuficientes para gas, conflictos de nonce y problemas de endpoint. Dado que Etherlink es compatible con EVM, se aplica la depuración estándar de Ethereum, pero también debes tener en cuenta la capa de liquidación L1 cuando una transacción parece atascada.

Trabaja de fuera hacia dentro. Confirma que el endpoint responde, luego confirma la cuenta y el nonce, y después confirma el recibo de la transacción. Si la capa de ejecución muestra éxito pero tu aplicación no, verifica si estás leyendo el estado en el bloque correcto.

• Conexión rechazada o tiempo de espera agotado: verifica RPC_URL y cualquier proxy o firewall.
• Cadena incorrecta: confirma que eth_chainId coincide con la red que configuraste.
• Fondos insuficientes: comprueba el saldo nativo para gas antes de enviar.
• Nonce demasiado bajo o alto: inspecciona las transacciones pendientes y restablece el nonce.
• Recibo ausente: espera y vuelve a consultar; no asumas fallo por una sola consulta.
• Discrepancia de estado: fija las lecturas a un número de bloque específico.

Limitaciones, compensaciones y qué medir

Etherlink hereda las compensaciones de su diseño. Las confirmaciones rápidas de la capa de ejecución mejoran la experiencia del usuario, pero no son lo mismo que la finalidad de L1. Los diseños de rollup optimista implican períodos de desafío y pruebas de fraude, por lo que la semántica de liquidación difiere de una L1 monolítica. La gobernanza está integrada con Tezos, lo que proporciona actualizabilidad pero también significa que los cambios de protocolo siguen los procesos de gobernanza de Tezos.

Mide las cosas que afectan a tu aplicación: latencia de extremo a extremo desde tus usuarios hasta tu endpoint RPC, latencia de recibo, consistencia de lectura de estado y tasas de error bajo carga. No te bases en cifras publicadas para la planificación de capacidad. Si necesitas un rendimiento predecible, considera un nodo dedicado en lugar de un endpoint público compartido.

• La confirmación de ejecución no es la liquidación final.
• Los endpoints públicos pueden limitar la tasa; las cargas de trabajo de producción necesitan planificación de capacidad.
• Las operaciones entre interfaces requieren comprender tanto las herramientas EVM como las Michelson.
• Las actualizaciones siguen la gobernanza de Tezos y pueden cambiar el comportamiento del kernel.

Próximos pasos: herramientas, endpoints y operaciones

Con la conectividad y el despliegue verificados, pasa al endurecimiento operativo. Coloca tu configuración RPC en variables de entorno, añade reintentos con retroceso exponencial y monitorea la latencia de recibo y las tasas de error. Si estás eligiendo un endpoint, usa el RPC Assistant para una recomendación directa y revisa los detalles de la red antes de configurar billeteras.

Para equipos que ejecutan cargas de trabajo de producción, evalúa la infraestructura dedicada y los precios frente a tu rendimiento medido. Mantén un runbook para conflictos de nonce y comprobaciones de liquidación, y vuelve a ejecutar el procedimiento de verificación después de cualquier cambio de proveedor o red.

• Revisa las redes compatibles antes de configurar tu stack.
• Compara las opciones de servicio API para acceso gestionado.
• Evalúa las opciones de nodo dedicado para un rendimiento predecible.
• Consulta los precios para la planificación de capacidad RPC.
• Usa el RPC Assistant para obtener orientación sobre la selección de endpoints.