En este artículo, descubrimos cuál es el nodo de secuenciador, un componente esencial del ecosistema enrollable de Ethereum.
Esta entidad de infraestructura es responsable de una serie de procesos que llevan los datos de transacción realizados en el L2 al L1 principal, actuando como un punto de conexión.
La operación y el grado de descentralización del secuenciador afectan directamente la seguridad, la confiabilidad y la resistencia a la censura de estas soluciones.
Veamos todo en detalle a continuación.
¿Cuál es el secuenciador y cuál es su papel en el mundo EVM?
En el paisaje de las soluciones de escalabilidad para Ethereum, El secuenciador es una entidad que ordena, ejecuta y agrega transacciones fuera de la cadena antes de publicarlas en la cadena de bloques de la capa-1. Su papel principal es mejorar la escalabilidad y la eficiencia de las soluciones de la capa 2, como los rollups, reduciendo los costos de gas y la aceleración de la finalización de la transacción.
Técnicamente definido como un nodo, el secuenciador procesa las transacciones ejecutadas en los rollups y las encapsula en una comprimida “lote. ” Luego envía estos datos a Ethereum, donde se registran oficialmente y se agregan a la cadena principal responsable de la seguridad.
Dependiendo de la arquitectura de la capa 2, el secuenciador puede ser centralizado o descentralizado, y puede influir en aspectos críticos como el orden de las transacciones, la disponibilidad de datos y la resistencia a la censura.
En el caso de Prolongado optimistacomo el árbitro y el optimismo, el secuenciador ordena el TX y los publica en Ethereum suponiendo que todos son válidos a menos que se disputen. En zk-rollupsin embargo, como Starknet y Zksync, el secuenciador no solo procesa las transacciones sino que también genera pruebas criptográficas que luego se verifican en Ethereum. Finalmente, en los rollups del Validium Escriba como ZKFair y Rhino.fi, se produce un proceso híbrido ya que los datos se verifican parcialmente fuera de la cadena.
Es importante enfatizar que esta figura también es utilizada por otras blockchains y soluciones de escalabilidad, pero para evitar confusiones, en este artículo nos centraremos solo en el mundo EVM. Para el conocimiento, señalamos que Hay componentes análogos a los secuenciadores en ecosistemas como cosmos, subredes de avalancha y celestia.
El flujo de trabajo de los secuenciadores en los diversos rollups de Ethereum
Al sumergirse más en las diversas tareas realizadas por los secuenciadores, vemos cómo administran el ciclo de vida de una transacción ejecutada dentro de un encierro.
Podemos agrupar su flujo de trabajo en 3 pasos fundamentales: La recolección y clasificación de transacciones, ejecución y publicación sobre Ethereum.
1) Colección y clasificación de transacciones
Los usuarios envían transacciones al secuenciador en lugar de directamente al L1, lo que las ordena en un bloque específico de acuerdo con una estrategia de pedido. En general, en los rollups, encontramos un “Basado en la subastaEstrategia, donde tiene lugar una subasta para determinar la orden de ejecución (aquellos que pagan más tarifas tienen prioridad y se ordenan primero).
Otras estrategias pueden ser del “Primero venido por primera vez“Tipo, donde las transacciones se aceptan y procesan en el orden que llegan.
2) Ejecución y cálculo del estado
Después de decidir el orden de las transacciones, el secuenciador las ejecuta localmente, actualizando el estado de la cadena fuera de la cadena.
Esta ejecución es determinista y sigue las reglas definidas por el contrato inteligente del rollo en L1, asegurando así la integridad de las operaciones.
3) Producción y publicación por lotes en L1
En este punto, las transacciones se agrupan en lotes y se envían a L1 Ethereum.
El secuenciador publica solo los datos esenciales (CallData) para la disponibilidad de datos (DA), asegurando que Ethereum siempre pueda reconstruir el estado en la cadena. Este paso asegura que se emplee el esfuerzo de computación mínimo para mantener bajas las tarifas de la red L2
Según el tipo de acumulación, estos 3 pasos pueden variar más o menos significativamente, como se muestra en la siguiente tabla.
“` Html
“` “` Html
El problema de la centralización del secuenciador
“`
Por el momento, la mayoría de los secuenciadores en Ethereum están centralizadosya que casi todos los rollups tienen un solo nodo responsable de administrar la conexión entre L2 y L1. Esta configuración es esencial en el “Etapa 0“Fases de los rollups, donde es necesario un compromiso entre la descentralización y la escalabilidad para que toda la infraestructura sea funcional y eficiente en su fase de desarrollo inicial.
“` Html
Avanzando con el tiempo, los rollups tienen como objetivo descentralizar sus secuenciadores, introduciendo nuevas soluciones para el intercambio de nodos y la federación, moviéndose así “Etapa 1” y “Etapa 2. ” Mientras tanto, sin embargo, la centralización excesiva de los secuenciadores, incluso durante un período de tiempo limitado, podría crear serios problemas estructurales para la red de segundo nivel en cuestión.
“`
En primer lugar, confiar el control a un solo nodo presenta un “punto único de falla “: Si el secuenciador sufriera un ataque, una falla técnica o una manipulación, toda la infraestructura podría verse comprometida, lo que lleva a retrasos en la transacción o incluso interrupciones del servicio. Además, esta concentración de poder podría facilitar el riesgo de censura en transaccionesya que el operador único tendría la capacidad de excluir o reordenar las transacciones arbitrariamente, aplicando estrategias MEV.
Otro aspecto crítico se refiere a confianza: La falta de un mecanismo de validación distribuido dificulta que los usuarios verifiquen de forma independiente que las transacciones se hayan manejado correctamente. Todo esto socava el principio de descentralización que está en la base de la filosofía de Ethereum.
La centralización de los nodos representa una espada de doble filo: el ejemplo práctico de la linea de capa 2.
La centralización excesiva de los secuenciadores se configura como un espada de doble filo, capaz de ahorrar literalmente un ecosistema completo del colapso, pero al mismo tiempo capaz de conducir a una censura fuertemente arbitraria de la red.
Lo que sucedió con la Linea de la capa 2 en junio del año pasado, durante el truco y la exploit del protocolo Velocore, es un claro ejemplo de esto.
En esa ocasión, durante el ataque cibernético contra el Dex, el equipo de Consensys (que administra el rollup de Linea) decidió Detener la producción de bloque, “apagado“Su secuenciador. Al hacerlo, con la cadena prácticamente congelada, el equipo de Velocare logró contener el incidente, resolviendo la vulnerabilidad del código encontrada. Mientras tanto, Consensys censuró la dirección del atacante, haciendo que la comunicación con el secuenciador sea imposible (que, como recordamos, valida las transacciones y las envía a L1).
Si el secuenciador no hubiera cerrado, habría habido consecuencias económicas muy graves, con impactos no solo en Linea, sino también en Ethereum.
Los piratas informáticos podrían haber drenado más fondos de los contratos inteligentes vulnerables, lo que lleva al agotamiento del valor de los activos basados en Linea. Además, el atacante podría haber alterado el estado de la red, lo que hace que sea más difícil detectar y solucionar el problema.
Esto habría tenido repercusiones en otros protocolos Defi conectados a Linea, lo que hace que muchos usuarios sufran liquidaciones o pérdidas irreversibles.
El evento de Hack de Velocore llevó a la comunidad Ethereum a reflexionar sobre el Delicado equilibrio entre seguridad y descentralización. Por un lado, la intervención rápida de Consensy evitó un desastre financiero, protegiendo a los usuarios y protocolos de pérdidas significativas. Por otro lado, el cierre del secuenciador y la censura de la dirección del atacante expresaron preocupaciones sobre el poder centralizado excesivo que tiene los operadores de la capa 2.