Las soluciones multicadena y de capa 2 siempre han enfrentado el dilema entre una “ordenación rápida con confirmación débil” y una “confirmación sólida con largas esperas”. Los secuenciadores centralizados ofrecen confirmaciones suaves en cuestión de segundos, pero dependen de la reputación del operador, mientras que la finalidad en L1 es más robusta, aunque suele requerir más tiempo de espera. HotShot traslada la responsabilidad de la confirmación a un conjunto descentralizado de validadores con staking, buscando una finalidad componible en segundos.
Para entender HotShot, debes tener claros tres principios básicos: el consenso solo regula el orden y la confirmación; la ejecución y la disponibilidad de datos (DA) están separadas; y la capacidad de respuesta optimista reduce la latencia. También es clave comprender el significado de la finalidad a nivel de segundos para los casos de uso cross-chain y financieros.
¿Qué es HotShot? ¿Cuál es su función en Espresso?
HotShot es el protocolo de consenso BFT de Espresso Network (ESP), basado en HotStuff y HotStuff-2. Los líderes proponen bloques, los validadores alcanzan certificados de quórum tras varias rondas de votación y, bajo la premisa de mayoría honesta, se logra el acuerdo final sobre el orden de los bloques.
En la arquitectura de Espresso, HotShot se encarga de la liquidación y la confirmación: genera un registro final, unificado y verificable de los resultados de las transacciones presentadas por los entornos integrados. Cada aplicación o cadena mantiene su propio entorno de ejecución, estrategia de orden y reglas de cumplimiento. Espresso no obliga a centralizar todo el estado en una máquina compartida; múltiples partes comparten una base común de finalidad.
| Componente de HotShot |
Función en Espresso |
| Núcleo de consenso BFT |
Proporciona la confirmación final descentralizada del orden de los bloques |
| Conjunto de validadores |
Hace staking de ESP, vota y produce bloques |
| Certificado de quórum |
Demuestra que una supermayoría de validadores con staking aprobó un bloque |
| Capa de ejecución (externa) |
Cada app/cadena gestiona sus propias transiciones de estado |
| Capa DA (separable) |
EspressoDA es predeterminada; otras soluciones son opcionales |
Esta tabla aclara el reparto de funciones entre HotShot y los módulos circundantes: el consenso prueba que “el orden está finalizado”, mientras que la ejecución y la disponibilidad de datos son modulares y componibles. La seguridad depende del peso del staking: para comprometer los resultados suele ser necesario controlar al menos dos tercios del ESP en staking. Staking de ESP y comisiones del protocolo explican cómo el staking de validadores, los umbrales y las penalizaciones sostienen este modelo.
¿Cómo funciona HotShot? ¿Por qué es importante la capacidad de respuesta optimista?
El proceso estándar de HotShot es: el módulo de ordenación envía bloques o flujos de transacciones → el líder los empaqueta y transmite → los validadores votan para formar certificados → al alcanzar el quórum, el bloque se finaliza. A diferencia de los protocolos con intervalos de bloque fijos, HotShot prioriza la capacidad de respuesta optimista: si la red funciona bien y los mensajes llegan rápido, el protocolo avanza a la velocidad real de propagación, sin recurrir a tiempos de espera conservadores para los peores casos.
La capacidad de respuesta optimista permite que, bajo buenas condiciones, la latencia se reduzca a unos pocos viajes de red, en vez de extenderse artificialmente al máximo posible. HotStuff-2 disminuye aún más las rondas necesarias para cambios de vista y rutas de certificados, haciendo posible la “finalidad en tres viajes de red” en la práctica. En situaciones adversas, el protocolo recurre a rutas con timeout para mantener la seguridad y la vivacidad.
| Atributo |
Capacidad de respuesta optimista (HotShot) |
Intervalo fijo no responsivo (Ejemplo) |
| Ritmo de avance |
Progresa a la velocidad de la red si las condiciones son buenas |
Tiempo fijo de slot/bloque |
| Latencia de red favorable |
Puede reducirse a segundos o menos |
Sigue limitada por intervalos fijos |
| Peor caso |
Depende de timeouts y cambios de vista |
Siempre opera con parámetros conservadores |
| Integración CDN |
Puede acelerar la distribución de certificados/datos |
Normalmente carece de esa integración |
Esta tabla compara ambos enfoques de ritmo. El protocolo de HotShot está diseñado para ser “rápido en promedio”, integrando aceleradores de red como CDN. La comparativa de capas de secuenciación compartida explica por qué la “confirmación rápida” debe involucrar un conjunto de validadores y no solo un secuenciador.
Figura 1. Ruta del consenso HotShot: propuesta de bloque → votación de validadores → certificado de quórum → finalidad en segundos. La capacidad de respuesta optimista permite avanzar a la velocidad de la red en condiciones favorables.
¿Por qué HotShot confirma sin ejecutar transacciones?
HotShot, de forma intencionada, no ejecuta transacciones: los validadores no reejecutan contratos inteligentes ni máquinas de estado de aplicaciones durante el consenso. Lo que se confirma es que “una secuencia fue aprobada por una supermayoría de validadores con staking”, no que “la raíz de estado se calcule en esta capa”. Una vez que los entornos de ejecución reciben la secuencia finalizada, derivan el estado según sus propias reglas. Las aplicaciones de privacidad pueden descifrar y ejecutar solo cuando las partes autorizadas dispongan de las claves.
Esta separación entre confirmación y ejecución tiene dos consecuencias principales. Primero, el rendimiento de Espresso ya no está limitado por un único ejecutor global: los entornos especializados pueden ejecutar en paralelo, mientras HotShot finaliza sus flujos de salida. Segundo, la colaboración entre entornos puede basarse en mensajes verificables (como pruebas de conocimiento cero), de modo que las cadenas destino puedan verificar la corrección del estado fuente sin duplicar toda la lógica de negocio en Espresso.
La disponibilidad de datos (DA) también está separada del consenso. Los integradores pueden usar EspressoDA (que incluye dispersión de información verificable, comités DA y aceleración por CDN) u otras soluciones DA. HotShot se centra en la ordenación y los certificados; la DA garantiza que los datos sean recuperables. El flujo de confirmación en segundos conecta propuestas, certificados y recuperación de datos en un proceso completo de confirmación.
Figura 2. Separación entre confirmación y ejecución: HotShot emite el orden y los certificados de quórum, EspressoDA (u otra DA) asegura la recuperabilidad de los datos y las aplicaciones derivan el estado de forma independiente.
¿Qué implica la finalidad en segundos para los casos cross-chain y financieros?
La finalidad en segundos significa que una secuencia de transacciones se confirma como irreversible en cuestión de segundos por un conjunto descentralizado de validadores. A diferencia de la “confirmación suave del secuenciador”, la finalidad de HotShot está respaldada por una supermayoría de validadores con staking. A diferencia de algunos L1 con finalidad lenta, los integradores no necesitan esperar una época completa para obtener una confirmación sólida. La documentación de la red principal indica confirmaciones normalmente en segundos (por ejemplo, Mainnet 1 suele señalar menos de tres segundos), pero los tiempos reales dependen de la carga de la red y la versión, así que consulta siempre el estado y los avisos públicos.
En escenarios cross-chain, la finalidad unificada reduce la ventana en la que “un lado considera finalizada una transacción mientras el otro aún puede reorganizar”, facilitando la supervisión de colateral, el paso de mensajes y el enrutamiento de liquidez. Para la emisión de stablecoins, redes de pago, activos tokenizados y gestión de margen, la confirmación en segundos acorta la exposición y los retrasos de conciliación, permitiendo gestión de riesgos en tiempo real y colateralización entre sistemas, siempre que la ejecución, el cumplimiento y la gestión de claves sigan bajo control de cada app.
¿Cuáles son las ventajas y limitaciones de HotShot?
Las principales ventajas de HotShot son: la finalidad descentralizada es más auditable que los modelos de secuenciador único; la capacidad de respuesta optimista reduce la latencia de confirmación en buenas condiciones de red; y la separación entre confirmación, ejecución y DA permite mayor rendimiento y personalización. Los integradores pueden mantener su propia VM, tarifas y reglas de cumplimiento, compartiendo la misma capa de liquidación.
Las limitaciones también son claras. HotShot no sustituye la corrección en la capa de aplicación: la lógica defectuosa, claves erróneas o entradas incorrectas de oráculos seguirán generando estados incorrectos. La vivacidad depende de la red y la participación de validadores; en condiciones extremas, el protocolo puede recurrir a rutas más lentas por timeout. La seguridad depende de la distribución del staking y los mecanismos de penalización; la concentración de validadores y la diversidad de clientes son factores a largo plazo. Una mala elección de DA o fallos en la recuperación de datos pueden afectar la ejecución posterior y la verificación cross-chain, aunque los certificados de consenso sigan siendo válidos.
En cuanto al riesgo, hay que distinguir entre: riesgos de protocolo (fallos en los supuestos de consenso, bugs de implementación), riesgos de integración (ordenación, puentes, sistemas de prueba) y riesgos operativos (claves, permisos, cumplimiento). Lo anterior solo describe las fortalezas y límites del mecanismo.
Resumen
Como protocolo de consenso BFT para Espresso Network, HotShot ofrece una ordenación final de transacciones verificable, asegurada por el staking de validadores, y logra finalidad en segundos gracias a su capacidad de respuesta optimista. El protocolo no ejecuta transacciones, la DA es modular y la ejecución permanece en el entorno de cada aplicación. Los escenarios cross-chain y financieros se benefician de ventanas de confirmación más cortas y consistentes, pero la corrección de la aplicación, la distribución del staking, las condiciones de red y la elección de DA siguen siendo límites críticos.
Preguntas frecuentes
¿Qué es el consenso HotShot?
HotShot es el protocolo de consenso tolerante a fallos bizantinos (BFT) utilizado por Espresso Network, basado en HotStuff y HotStuff-2. Los validadores votan el orden de los bloques y forman certificados de quórum, proporcionando confirmación final bajo la premisa de mayoría honesta. HotShot no ejecuta las transiciones de estado de las transacciones.
¿Cómo logra Espresso la finalidad en segundos?
Espresso aprovecha la capacidad de respuesta optimista y la votación en varias rondas de HotShot para avanzar el consenso a velocidad de red en buenas condiciones, por lo que las confirmaciones en la red principal suelen darse en pocos segundos. La finalidad está respaldada por un conjunto descentralizado de validadores con staking, no solo por la confirmación suave de un secuenciador.
¿Qué es Espresso Network?
Espresso Network es una infraestructura de liquidación y confirmación compartida por múltiples cadenas y aplicaciones. Cada entorno mantiene su propia ejecución y reglas, los resultados de las transacciones logran finalidad descentralizada mediante HotShot, y la disponibilidad de datos y mensajería cross-chain pueden integrarse para minimizar la dependencia de intermediarios de confianza.
¿Cuál es la utilidad del token ESP?
ESP es el token de utilidad nativo de Espresso Network, usado principalmente para el staking de validadores que asegura HotShot y para participar en los mecanismos de tarifas del protocolo. El peso del staking determina la influencia en la votación; para comprometer la confirmación suele requerirse el control de una parte significativa del ESP en staking.
¿Cuáles son los riesgos de usar Espresso?
Los principales riesgos incluyen: errores en la lógica de la aplicación o en las claves no se corrigen automáticamente por el consenso; un comportamiento extremo de la red o los validadores puede ralentizar la confirmación; la concentración de staking y las vulnerabilidades de los clientes afectan la seguridad; los fallos en DA y en los componentes de puente/prueba pueden afectar la disponibilidad posterior. La evaluación de riesgos debe distinguir entre riesgos de protocolo y de integración.
