Una transacción debe atravesar el proceso repetible de "envío → secuenciación → confirmación por consenso → visibilidad del estado" para ser reconocida como "confirmada" por otras cadenas, puentes o aplicaciones en un entorno multicadena. Espresso Network (ESP) funciona como una capa base compartida de confirmación y liquidación, recibiendo bloques de los secuenciadores de Rollup. La red de validadores utiliza HotShot para brindar respaldo BFT en cuestión de segundos, permitiendo que los bloques confirmados por Espresso sean accesibles para los sistemas descendentes.
Este mecanismo resuelve el reto de la secuenciación de confirmaciones: las aplicaciones ya no tienen que esperar la liquidación final de Ethereum L1 para obtener una secuencia y estado verificables; la liquidación L1 puede seguir según las reglas del puente. Saber cuándo se activa cada etapa y cómo se retransmiten las confirmaciones ayuda a definir los límites para lecturas de estado entre cadenas.
¿Qué requisitos previos necesita una transacción para ingresar a Espresso?
Antes de que una transacción siga el camino de confirmación de Espresso, el sistema debe estar listo para integrarse: el entorno objetivo debe estar conectado a Espresso; debe existir un secuenciador autorizado (o un constructor de bloques equivalente); y la transacción debe ser aceptada según las reglas de ejecución y secuenciación del entorno. Espresso no reemplaza la capa de ejecución de cada entorno, sino que ofrece confirmación descentralizada para la salida del secuenciador.
| Elemento de preparación |
Verificación principal |
Impacto si no está listo |
| Integración del entorno |
¿El Rollup/aplicación está integrado con Espresso? |
El bloque no puede ingresar a la capa de confirmación |
| Secuenciador autorizado |
¿Existe un secuenciador autorizado para enviar bloques a Espresso? |
No puede iniciarse el envío ni la cola |
| Aceptación de transacciones |
¿La transacción ha sido aceptada por las reglas de mempool/secueciación del entorno? |
No se puede enviar ningún bloque para confirmación |
| Consumidor descendente |
¿Puentes, aplicaciones o solucionadores están suscritos a la vista de confirmación? |
La confirmación se completa pero no es legible entre entornos |
La tabla muestra que la confirmación de segundo nivel requiere "integración + envío autorizado + lectura descendente". Los usuarios suelen notar solo que "la transacción se ha enviado a un Rollup", pero el sistema debe incluir esa transacción en un bloque destinado a Espresso.
Paso 1: ¿Cómo se envían y ponen en cola las transacciones?
El proceso comienza cuando un usuario o aplicación envía una transacción a un Rollup (u otro entorno de ejecución). La transacción entra en la lógica de recepción y cola del entorno. Un secuenciador autorizado ordena y agrupa las transacciones en bloques o lotes según las reglas locales, y los envía a Espresso. Espresso recibe el flujo de bloques del secuenciador, no las transacciones individuales de los usuarios.
Durante la etapa de envío y cola, la interfaz puede mostrar rápidamente "recibido" o "preconfirmado"; estos son mensajes del secuenciador del Rollup, no de la confirmación de Espresso. Internamente, el secuenciador fija el orden del lote, genera un bloque para envío y lo transmite mediante la interfaz de integración. Este proceso puede repetirse tantas veces como sea necesario: las nuevas transacciones se agrupan y envían conforme llegan.
Si el secuenciador se retrasa, censura o no envía como corresponde, la transacción permanece en la cola local y el flujo descendente no puede ver la Finalidad a nivel Espresso. Si la secuenciación es centralizada es un tema estructural abordado en la comparación de capas de secuenciación compartidas; aquí el enfoque está en "qué sucede después del envío y cómo se completa la confirmación".
Paso 2: ¿Cómo completa HotShot la secuenciación y confirmación?
Cuando un bloque ingresa a Espresso, la red de validadores ejecuta el consenso HotShot: bajo un framework de prueba de participación (PoS) y tolerancia a fallos bizantinos (BFT), se acuerda el orden de los bloques y la disponibilidad de datos (DA). HotShot está diseñado para confirmar lo más rápido posible cuando las condiciones de red lo permiten. Fuentes públicas indican que los tiempos de confirmación en la red principal suelen ser de varios segundos.
La confirmación se activa cuando los validadores con suficiente peso votan sobre el bloque propuesto. Una vez que se alcanza el umbral, el bloque se convierte en bloque confirmado por Espresso, con su secuencia y compromiso finalizados en la capa de consenso. La ejecución permanece en cada entorno Rollup o aplicación, que realiza la transición determinista del estado para la secuencia confirmada; Espresso no ejecuta lógica de negocio.
| Etapa del proceso |
Condición de activación |
Acción del sistema |
Cambio visible para usuario/aplicación |
| Envío |
El secuenciador agrupa y envía el bloque |
El bloque ingresa al camino de confirmación de Espresso |
Suele mostrar "procesando/preconfirmado" |
| Confirmación HotShot |
Los validadores alcanzan el umbral de votación BFT |
El bloque logra Finalidad en Espresso |
La vista de confirmación de Espresso es consultable |
| Lectura descendente |
Puente/aplicación se suscribe a resultados de confirmación |
La lógica entre entornos avanza por secuencia de confirmación |
Las acciones entre cadenas pueden activarse por el estado de confirmación |
| Liquidación L1 (posterior) |
On-chain según reglas de puente y contrato |
Lote correspondiente enviado a Ethereum L1, etc. |
Liquidación final L1 completada (mayor demora) |
Esta tabla diferencia la "confirmación de segundo nivel" (completada por el consenso HotShot en Espresso) de la "liquidación final L1". Esta última puede seguir como fue diseñada, pero el protocolo puede requerir que solo los bloques que coinciden con la confirmación de Espresso sean elegibles para liquidación en el L1 puente.
Figura 1. Camino principal de confirmación en Espresso: envío por usuario/aplicación → agrupación por secuenciador de Rollup → confirmación por validadores HotShot → consumo de Finalidad por Rollup/puente/aplicación.
La participación de los validadores en la confirmación depende del staking y los incentivos del protocolo; staking de ESP y comisiones del protocolo explican el rol de ESP en el staking de validadores y pagos de comisiones, fundamentales para la operación de la capa de confirmación y sin modificar la secuencia anterior.
Paso 3: ¿Cómo se retransmiten los resultados de confirmación a Rollup, puente o aplicación?
Después de la confirmación HotShot, los bloques confirmados por Espresso pueden consultarse en segundos. Los nodos de Rollup, remitentes de lotes, componentes de puente, protocolos de mensajería, solucionadores y otras aplicaciones on-chain pueden usar servicios de consulta o flujos de eventos para acceder a la secuencia confirmada y el compromiso de estado, actualizando su vista del "estado confirmado" para el entorno.
Retransmitir no significa que los resultados de ejecución se envíen a todas las cadenas, sino que se proporciona una fuente de verdad compartida y verificable: quien lea primero la confirmación puede avanzar la lógica entre entornos según sus propias reglas. Las restricciones del protocolo garantizan que solo los bloques que coinciden con la confirmación de Espresso sean aceptados durante la liquidación L1 puente, evitando que los secuenciadores reescriban la secuencia confirmada. Para los usuarios, esto implica que las operaciones entre cadenas se habilitan más rápido; para los sistemas, la capa de confirmación ofrece hechos intermedios componibles antes de la liquidación final L1.
¿En qué se diferencia esto de "esperar la liquidación final en Ethereum L1"?
Si solo se depende de la liquidación final en Ethereum L1, los lotes de Rollup deben esperar la finalidad L1 antes de que los puentes y aplicaciones entre cadenas consideren el estado seguro, normalmente un proceso que toma más de diez minutos. El camino Espresso logra confirmación BFT en segundos tras el envío del secuenciador, permitiendo al flujo descendente leer el estado de confirmación antes, con la liquidación L1 como ancla de seguridad posterior.
| Dimensión |
Camino de confirmación Espresso |
Solo esperar liquidación final en Ethereum L1 |
| Entidad de confirmación |
Red de validadores HotShot (BFT) |
Finalidad de consenso de Ethereum L1 |
| Demora típica |
Varios segundos |
Normalmente más de diez minutos |
| Cuándo puede leer el flujo descendente |
Inmediatamente tras confirmación en Espresso |
Normalmente solo después de la finalidad L1 |
| Relación con secuenciador |
Cada entorno puede conservar su secuenciador, con respaldo por capa de confirmación descentralizada |
Los lotes van directamente al L1, ritmo L1 |
| Restricciones de ambigüedad |
Puede requerir que lotes de liquidación coincidan con confirmación Espresso |
Depende de contratos L1 y ventanas de prueba |
Esta tabla destaca la diferencia en "quién proporciona primero un compromiso de secuencia confiable" y "cuándo los puentes y aplicaciones inician acciones entre entornos". Espresso no elimina la liquidación L1, sino que inserta una capa de confirmación rápida y repetible entre medias.
Figura 2. Camino Espresso vs. solo liquidación L1: la izquierda muestra puentes/aplicaciones leyendo tras la confirmación HotShot de segundo nivel; la derecha muestra acciones tomadas tras la finalidad L1.
¿Cuáles son los riesgos y puntos de fallo en este proceso?
Hay puntos de fallo en el envío, consenso y consumo descendente. Si el secuenciador censura, falla o retrasa el envío, las transacciones no pueden ingresar a HotShot; si la red de validadores no alcanza el umbral de votación, la confirmación se retrasa o se estanca; si el flujo descendente no se suscribe a la vista de Espresso, la lógica entre cadenas puede seguir el cronograma anterior aunque el usuario vea éxito.
Los riesgos estructurales incluyen: la seguridad de la capa de confirmación depende de la distribución de staking y supuestos BFT; la Finalidad Espresso y la liquidación final L1 son límites de seguridad distintos—si las aplicaciones tratan la confirmación de segundo nivel como equivalente a la finalidad L1, pueden calibrar mal parámetros de puente y liquidación; los defectos de integración o consulta pueden generar estados "confirmados pero no legibles". Estos riesgos son propios del mecanismo y no constituyen asesoría de inversión.
Resumen
La confirmación de segundo nivel en Espresso Network es un proceso repetible: las transacciones son aceptadas por el entorno Rollup, agrupadas y enviadas por un secuenciador autorizado; los validadores HotShot completan la confirmación BFT en segundos; los bloques confirmados por Espresso están disponibles inmediatamente para lectura por Rollup, puente y aplicación; la liquidación final L1 puede seguir según reglas de coincidencia. Analizar los activadores y puntos de fallo de envío, confirmación y retransmisión aclara que la "Finalidad de segundo nivel" es un diseño de secuencia de confirmación, no un evento aislado.
Preguntas frecuentes
¿Qué es Espresso Network?
Espresso Network sirve como una capa base compartida de confirmación y liquidación para entornos multicadena y de aplicaciones. Cada entorno mantiene sus propias reglas de ejecución y secuenciación; tras enviar bloques a Espresso, los validadores ofrecen Finalidad rápida mediante HotShot, que puede ser leída por otras cadenas y puentes.
¿Cómo logra Espresso la Finalidad de segundo nivel?
Después de que los secuenciadores autorizados envían bloques a Espresso, los validadores ejecutan el consenso HotShot, confirmando el orden de los bloques y la disponibilidad de datos una vez que se alcanza el umbral de votación BFT. Fuentes públicas indican tiempos de confirmación de varios segundos, permitiendo al flujo descendente leer vistas de confirmación sin esperar la liquidación final en Ethereum L1.
¿Qué es el consenso HotShot?
HotShot es el protocolo de consenso tolerante a fallos bizantinos utilizado por Espresso Network para lograr rápidamente acuerdo entre validadores sobre el orden y disponibilidad de bloques. Está diseñado para confirmar rápido cuando las condiciones de red lo permiten, brindando Finalidad de segundo nivel para Rollups y aplicaciones, pero no ejecuta transacciones.
¿Cómo mejora Espresso la velocidad de confirmación entre cadenas?
Los puentes entre cadenas, protocolos de mensajería y solucionadores pueden leer directamente los bloques confirmados por Espresso para obtener vistas de estado confirmado de las cadenas integradas, sin esperar siempre que se cierre la ventana de finalidad L1. Con la secuenciación de confirmación adelantada, las acciones entre entornos pueden comenzar antes, mientras que las restricciones del protocolo aseguran que los lotes de liquidación on-chain coincidan con la confirmación Espresso.
¿Cuáles son los riesgos de usar Espresso?
Los riesgos principales incluyen fallos o censura en el envío por el secuenciador, consenso de validadores que no alcanza el umbral a tiempo, errores en componentes de consulta e integración, y confundir la Finalidad Espresso con la liquidación final L1, lo que puede llevar a errores en los límites de seguridad. La capa de confirmación depende de supuestos de staking y BFT; la interrupción en cualquier etapa puede impedir que se complete el camino de "confirmación de segundo nivel".
