Solo con fines educativos; no constituye asesoramiento financiero, de inversión, de finalidad de transacciones ni de seguridad. El comportamiento del secuenciador, las vías alternativas y las garantías de liquidación varían según la red y pueden cambiar tras una actualización.
Respuesta directa
En muchos rollups, un secuenciador es el componente o participante que acepta transacciones, elige su orden y produce bloques o lotes. Puede dar al usuario una confirmación rápida antes de que los datos ordenados se publiquen en la capa base. La división exacta del trabajo varía: la construcción de bloques, la ejecución y la publicación de lotes pueden depender del mismo operador o de servicios separados.
Que una cartera muestre éxito no convierte al secuenciador en la fuente de liquidación final. La solidez de la confirmación depende de si el secuenciador solo anunció el bloque, si los datos del protocolo llegaron a L1 y si el bloque de L1 y la afirmación o prueba del rollup alcanzaron el estado de finalidad requerido.
Cómo funciona
- Recepción. Los usuarios o aplicaciones envían transacciones firmadas a un punto de acceso del secuenciador, aunque la red también puede definir una vía de envío por L1.
- Ordenación. El secuenciador selecciona transacciones y determina su orden sujeto a las reglas de validez del protocolo. La elección puede afectar a latencia, comisiones, censura y MEV.
- Construcción. Agrupa las transacciones ordenadas en bloques del rollup y puede ejecutarlas para calcular el estado resultante.
- Preconfirmación. El secuenciador distribuye rápidamente un bloque o recibo. Es una señal provisional de orden, no un resultado finalizado automáticamente en L1.
- Publicación. Un publicador de lotes o servicio equivalente envía los datos definidos por el protocolo a la capa de disponibilidad de datos, a menudo L1. Los nodos independientes usan esos datos y las reglas para derivar la cadena canónica del rollup.
- Liquidación. Los compromisos de estado, las pruebas de fallo o de validez conectan los resultados de ejecución con la liquidación. Verifican o establecen la corrección de las transiciones, pero no descentralizan por sí solos el orden.
Ejemplo
Una cartera primero muestra una transacción como confirmada por el secuenciador. En ese momento, el operador aún puede no publicar el lote correspondiente o sustituir un bloque no publicado según las reglas de la red. Cuando los datos del lote se incluyen en L1, los nodos independientes pueden derivar la posición de la transacción, aunque una reorganización de L1 todavía puede afectarla. La aplicación solo debería etiquetar el resultado como corresponda después de cumplirse las condiciones de finalidad de L1 y del rollup.
Esta secuencia es un modelo de estados, no una promesa temporal universal. Términos como pendiente, inseguro, seguro y finalizado dependen del protocolo, y un puente puede añadir una demora de prueba o impugnación antes de que un retiro sea ejecutable.
Riesgos
- Inactividad. Si se detiene el secuenciador activo, el envío directo y la producción rápida de bloques pueden pausarse aunque no se pierdan fondos.
- Censura. Un operador puede retrasar o rechazar transacciones concretas. Una vía de inclusión forzada o salida solo ayuda si está desplegada, no requiere permiso, es utilizable y dispone de los datos necesarios.
- Reordenación y MEV. Controlar el orden puede permitir front-running, back-running o trato preferente dentro de las restricciones del protocolo.
- Reversión del estado provisional. Una aplicación que trata el recibo del secuenciador como final puede actuar sobre un bloque sustituido después o nunca publicado.
- Fallo de publicación o de la capa base. La congestión, el fallo del publicador, la falta de datos o una reorganización de L1 pueden retrasar o cambiar la cadena derivada por los verificadores.
- Concentración operativa. Un solo operador, clave de firma, punto RPC o autoridad de actualización puede crear puntos comunes de fallo y control incluso si las pruebas verifican la ejecución.
Errores comunes
- El secuenciador decide la liquidación final. Esta sigue los contratos, las reglas de prueba o impugnación, la disponibilidad de datos y el consenso de la capa base.
- Un recibo rápido es irreversible. Una preconfirmación puede ser útil sin ofrecer la misma garantía que los datos publicados y finalizados.
- La inclusión forzada garantiza ejecución inmediata. La alternativa puede requerir una transacción en L1, un periodo de espera, calldata específica y una ruta contractual operativa.
- Las pruebas de validez eliminan el riesgo del secuenciador. Pueden demostrar ejecución correcta mientras el orden sigue centralizado, censurable o no disponible.
- La secuenciación descentralizada elimina toda confianza. Puede repartir el poder de ordenar, pero introduce supuestos propios de consenso, disponibilidad, gestión de claves e interoperabilidad.
Temas relacionados
Fuentes
- Escalado de Ethereum - Ethereum.org (consultado: 2026-08-21)
- Derivación - OP Stack Specification (consultado: 2026-08-21)
- Finalidad de las transacciones - Optimism Documentation (consultado: 2026-08-21)
- Arbitrum Nitro: un rollup optimista de segunda generación - Arbitrum Documentation (consultado: 2026-08-21)