El tiempo vuela. Según Gate, ha pasado más de un año, y según Arbitrum, casi medio año ha pasado; emitir monedas fue solo el primer paso en su largo viaje. Durante este período, Gate actualizó Bedrock y lanzó el stack L2 modular universal OP Stack, que dio origen a Rollups estrella como Base; Arbitrum se compromete a explorar la aplicación de L3 para promover Arbitrum Orbit.
Bajo el liderazgo de los dos gigantes, el TVL de Rollup Track superó una vez los 10 mil millones de dólares estadounidenses y actualmente se mantiene estable en alrededor de 10 mil millones de dólares estadounidenses. Detrás de que los Rollups sean disfrutados como la solución de escalado “firma” de Ethereum, todavía tienen atributos centralizados y no resistentes a la censura. Las cadenas de Rollup principales generalmente utilizan secuenciadores centralizados oficiales. Aunque proyectos de Rollup como Arbitrum, Optimism y StarkNet incluyen la descentralización de los secuenciadores en la hoja de ruta, no se han implementado a corto o medio plazo de planificación. Como la pieza de rompecabezas más importante de la descentralización de Rollup, el secuenciador descentralizado tiene una posición estratégica muy importante para Rollup en sí mismo, y también es la aspiración de la gente.
Según los datos de L2Beat, el TVL de la pista L2 a partir del 1 de octubre de 2023
Antes de entender qué es un secuenciador, hablemos de los componentes de las tarifas de transacción de Rollup. La tarifa de transacción de Rollup es la tarifa de gas que los usuarios incurren en transacciones de L2 como Arbitrum.
Principalmente consta de 2 partes:
1) Costos de ejecución L2
2) Tarifa de datos L1
Tarifa de ejecución L2: el costo de la ejecución de la transacción en L2 (cada transacción iniciada en la cadena L2 está sujeta a una tarifa de ejecución)
Precio del gas de transacción = tarifa base L2 + tarifa de prioridad L2
Tarifa de ejecución L2 = precio del gas de la transacción * uso de gas L2
Tarifa de datos L1: El costo de publicar transacciones L2 en L1. Generalmente, los datos de L1 cuestan más que los costos de ejecución de L2.
Tarifa de transacción L2 = tarifa de ejecución L2 + tarifa de datos L1
Ingresos netos del secuenciador = ingresos por tarifas de transacción L2 - costos operativos del secuenciador - tarifa de datos L1
El secuenciador centralizado operado por la parte del proyecto tiene cierto poder de fijación de precios (por ejemplo, las tarifas de ejecución de L2 son un poco más altas, las tarifas de datos de L1 son un poco más altas), por eso varios proyectos conocidos de Rollup están ganando mucho dinero.
Un secuenciador, como su nombre lo indica, es un rol responsable de clasificar transacciones. En la red de Bitcoin, los mineros son responsables de clasificar transacciones; Ethereum es responsable de una colección de nodos, ninguno de los cuales juega un rol fijo, sino más bien un mecanismo de consenso para determinar quién está autorizado para participar en la ejecución secuencial.
Actualmente, los Rollups principales ejecutan todos un secuenciador centralizado único. Las transacciones L2 del usuario ingresan al grupo de memoria (en este punto, las transacciones en el grupo de memoria están en un estado desordenado), y el secuenciador ordena y comprime las transacciones en un conjunto ordenado de lotes, y luego las envía a la capa DA de Ethereum.
Proceso de operación del secuenciador
La respuesta es no. Las transacciones en Rollup pueden omitir completamente el secuenciador y enviarse a la capa base L1. L1 es responsable de la clasificación y liquidación, pero también se enfrentará a un mayor consumo de gas y a tiempos de confirmación de transacciones más largos.
El secuenciador Rollup es similar a usar una “vía rápida”, comprimiendo cientos o miles de transacciones L2 en una sola transacción L1, lo que reduce enormemente los costos de gas. Por esto, los Rollups principales de hoy en día ejecutan secuenciadores centralizados, que ofrecen a los usuarios un menor costo de gas y una confirmación de transacción más rápida, mejorando así la experiencia del usuario en las transacciones.
Las ventajas de la centralización son muy evidentes. Puedes clasificar las transacciones como desees; no es necesario cambiar la clasificación, y no es necesario ponerse de acuerdo sobre los resultados de la clasificación. Esto significa que tiene una velocidad de confirmación de transacciones muy rápida y la experiencia del usuario es mejor;
Sin embargo, la centralización también otorga al secuenciador una gran autonomía para clasificar transacciones. Puede clasificar arbitrariamente transacciones para maximizar sus propias oportunidades de arbitraje, aprovechar el valor de MEV, retrasar transacciones de usuarios e incluso censurar por completo a los usuarios.
El secuenciador puede obtener valor de MEV al cambiar el orden de las transacciones dentro de un solo bloque; lo más perjudicial es que, dado que el secuenciador controla la secuenciación de múltiples bloques seguidos, es fácil ejecutar MEV entre bloques, causando ataques a gran escala.
Todas las situaciones anteriores son una mala conducta activa por parte del secuenciador. Algunos errores no son intencionados por el secuenciador, pero aún así dañan la experiencia y los derechos del usuario. Por ejemplo, el secuenciador vuelve a incluir accidentalmente una transacción de token que ya se ha gastado en una promesa suave y, a continuación, se ha enviado a L1 para su verificación. También puede haber casos en los que la transacción no pueda ser confirmada; También es como un solo secuenciador que se desconecta, lo que hace que la segunda capa no pueda generar bloques correctamente y la red esté inactiva durante mucho tiempo.
El pez y el oso son imposibles, pero optimizar el rendimiento de Rollup no debe ser a expensas de la descentralización y la resistencia a la censura.
Si la centralización es 1, entonces la descentralización es mucho. Hay diferencias en los caminos de implementación de diferentes soluciones de secuenciadores descentralizados, pero su concepto central es el mismo, que es la descentralización.
El secuenciador ya no tiene derecho a clasificar centralmente las transacciones. El rol responsable de la clasificación se selecciona de un conjunto de conjuntos de secuenciadores basados en un mecanismo de elección específico y rota durante un ciclo fijo.
La descentralización evita que los secuenciadores se apoderen continuamente de MEV, y también impide que un solo secuenciador revise las transacciones de los usuarios. Junto con el mecanismo correspondiente de castigo criminal, también puede regular eficazmente el comportamiento del secuenciador.
Después de tanto rodeo, finalmente nos pusimos manos a la obra. Secuenciadores descentralizados. Uno está hecho por el propio proyecto Rollup, y el otro es implementado por un tercero. Utilizar a un tercero para implementar un secuenciador descentralizado también puede ser llamado secuenciación como servicio, y la secuenciación es un servicio.
Proyectos como Espresso, Astria, SUAVE y Radius se centran en soluciones de secuenciador descentralizado, y sus caminos de implementación varían.
Espresso Systems fue inicialmente un proveedor de servicios centrado en soluciones de privacidad. En marzo de 2022, se anunció que había recibido casi 30 millones de dólares en financiación de la Serie A con Electric Capital, Sequoia y Blockchain Capital. Espresso Systems ahora se ha transformado básicamente en Espresso Sequencer, que se especializa en proporcionar servicios de secuenciador descentralizado para Rollup.
Financiación de Espresso
Según el mecanismo de clasificación del secuenciador de Espresso, las transacciones L2 generalmente experimentan el siguiente ciclo de vida:
1) Las transacciones realizadas por los usuarios en la segunda capa se envían al servidor Rollup (API);
2) Las transacciones entran en la mempool, y el secuenciador (seleccionado por el consenso HotShot) ordena e incluye las transacciones en un bloque;
3) El secuenciador difunde la transacción. Después de alcanzar un consenso HotShot a través de otros nodos, se emite el bloque y se ejecuta la transacción; la soft promise proporciona una rápida confirmación de la transacción
4) El secuenciador envía y almacena un certificado de consenso (QC: Certificado de Quorum) con la promesa de bloque que contiene la transacción en el contrato del secuenciador L1 (demostrando que el bloque ha alcanzado la finalidad suave a través del consenso);
5) El nodo Rollup que ha ejecutado el bloque envía el nuevo estado de Rollup a L1 (en este punto, zKrU requiere una prueba de validez, y ORU abre el período de desafío)
6) El contrato L1 Rollup verifica la validez de las actualizaciones de estado verificando el QC enviado por el contrato secuenciador.
El ciclo de vida de una transacción L2 bajo el mecanismo de clasificación Espresso
Este proceso parece oscuro y difícil de entender; la forma simple de entenderlo es:
El consenso HotShot selecciona uno de un conjunto de secuenciadores. Es responsable de ordenar transacciones de Rollup e incluir transacciones en un bloque; este bloque debe ser firmado y acordado por otros nodos de Rollup (2/3 o más nodos HotShot están de acuerdo) para ser “final”, y luego las promesas de bloque relevantes y la nueva raíz de estado de Rollup se envían a la capa base L1 para su verificación.
El "Finality" anterior está entre comillas; esta "finalidad entre comillas" y la finalidad sin comillas no es un concepto. La "finalidad" entre comillas permite confirmar las transacciones de Rollup más rápidamente, con menos demora y una mejor experiencia de usuario; sin embargo, las transacciones de Rollup requieren en última instancia que la capa base L1 verifique (zKru necesita verificar la prueba de validez, ORU tiene que esperar al final del período de desafío). Si no hay problema en verificar que la transacción enviada por Rollup está bien, entonces la transacción de Rollup es verdaderamente final.
Esto significa: si la capa base L1 verifica que la transacción es inválida, el bloque L2 correspondiente que ya ha sido liberado enfrentará un retroceso. Por lo tanto, la "finalidad" es que las transacciones se confirmen rápidamente, y la finalidad es heredar la seguridad de Ethereum.
Arquitectura de secuenciación de transacciones sin espresso
Integrar la arquitectura de secuenciación de transacciones de Espresso
Espresso resolvió el problema de rotación del secuenciador y la determinación de la "finalidad" de la transacción basada en el consenso HotShot, y resolvió el problema de admisión del secuenciador al introducir EigenLayer.
El mecanismo de re-apuesta de EigenLayer hace posible que los apostadores de Ethereum se conviertan simultáneamente en secuenciadores de Espresso, brindando seguridad para el consenso HotShot. En pocas palabras, los apostadores de nodos de Ethereum pueden convertirse en Secuenciadores de Espresso (ESQ) a través del mecanismo de re-apuesta de EigenLayer. Mientras reciben beneficios de los nodos de PoS, los apostadores de Ethereum también capturan el valor de MEV de segundo nivel.
Beneficios potenciales para los titulares de ETH = recompensas nativas de nodos de red + L2 EVM + recompensas de nodos de otras cadenas PoS (utilizando el mecanismo de reestaca EigenLayer). El triple refuerzo potencia enormemente a ETH.
Solución de secuenciador descentralizado de EigenLayer
Espresso es una solución de secuenciador descentralizado de propósito general. Además de EigenLayer, los proyectos de cooperación ecológica incluyen proyectos modulares populares como Arbitrum, OP Stack, Caldera, AltLayer, etc.
Espresso Proyecto de Cooperación Ecológica Diseño
Astria se posiciona como un secuenciador descentralizado genérico y sin permisos, proporcionando un servicio de secuenciador compartido listo para usar para diferentes Rollups. En cuanto a la financiación, Astria anunció la finalización de una ronda inicial de $5.5 millones liderada por Maven 11 en abril de 2023. Entre los coinversores se encuentran 1k (x), Delphi Digital, Lemniscap, Robot Ventures, etc. Aunque la escala de financiación es pequeña, la alineación institucional es magnífica.
Situación de financiación de Astria
El mecanismo de operación del secuenciador descentralizado Astria es similar al Secuenciador Espresso. El propósito es debilitar los privilegios de los secuenciadores mediante la delegación de los derechos de secuenciación de transacciones. Veámoslo más de cerca:
Para la rotación del secuenciador, Astria propuso dos mecanismos de rotación: rotación simple del líder (rotación del líder) y algoritmo de consenso de tolerancia a fallos bizantinos (BFT).
1) Rotación de líder
Un conjunto se forma a través de un secuenciador elegido y el conjunto de secuenciadores se turna para ordenar las transacciones consolidadas. Este método evita que un solo secuenciador continúe monopolizando los derechos de clasificación de las transacciones durante un largo período de tiempo, y resuelve el problema de la revisión continua de los usuarios hasta cierto punto.
El mecanismo de rotación de liderazgo de Astria
2) algoritmo de consenso BFT
Similar to the leader rotation mechanism, the sequencer who takes the turn is responsible for ranking transactions, but 2/3 or more members in the sequencer set must agree on this ranking.
Cada uno de los dos métodos tiene ventajas y desventajas: el primero permite una confirmación de transacción más rápida, una generación de bloques rápida y está cerca de la de un secuenciador centralizado. Sin embargo, el punto de equilibrio es que todavía es difícil contener a los secuenciadores a su vez para que no cometan maldades; usar el consenso BFT es aún menos probable, y 2/3 de los secuenciadores en el conjunto deben votar para alcanzar un consenso antes de que salga el bloque. Sin embargo, llevó cierta cantidad de tiempo llevar a cabo una votación de consenso, lo que causó retrasos en la red.
Algoritmo de consenso BFT de Astria
SUAVE es una solución secuenciadora compartida descentralizada y plug-and-play construida por Flashbots. Como solución general, SUAVE puede proporcionar grupos de memoria y construcción de bloques descentralizados para cualquier L1/L2. La diferencia entre SUAVE y el diseño de secuenciador compartido descrito anteriormente es que la propia cadena SUAVE es una cadena compatible con EVM, y las transacciones se ordenan a través de "subasta" de bloques.
La arquitectura de SUAVE consta de 3 componentes principales: un entorno de preferencias comunes, un mercado de ejecución óptimo y una construcción de bloques descentralizada.
1) Entorno preferido
Las preferencias van desde transacciones simples hasta eventos complejos. Las preferencias del usuario se reflejan en mempools en forma de transacciones, y el entorno de preferencias es un mempool público que reúne las preferencias. El entorno general de preferencias proporcionado por SUAVE hace que las preferencias de usuario multi-cadena sean abiertas y transparentes, elimina la información deficiente y resuelve en cierta medida el problema del MEV entre cadenas.
2) Ejecutar el mercado
El mercado de ejecución es una red donde los ejecutores son responsables de monitorear el memepool SUAVE y competir entre sí, y la competencia los impulsa a proporcionar la mejor ejecución para las preferencias del usuario. Se puede entender que todos los ejecutores logran las preferencias del usuario a través de "ofertas" y devuelven la mayor cantidad posible de MEV generada por las transacciones del usuario al usuario.
3) Construcción descentralizada de bloques
Finalmente, basado en las preferencias recopiladas y en la mejor ruta de ejecución, la red de construcción de bloques descentralizada los incluye en el bloque. En este punto, se ha logrado todo el proceso de descubrimiento de transacciones, secuenciación de transacciones y generación de bloques.
Los componentes principales de SUAVE
El enfoque de segmentación de Radius es una capa de ordenación compartida que no requiere confianza. A diferencia de los mecanismos de implementación descritos anteriormente, Radius garantiza que las transacciones de Rollup se clasifiquen sin confianza al habilitar mempools encriptados, eliminando así la MEV efectiva y la censura de transacciones de usuarios.
En términos de financiamiento, Radius anunció la finalización de la ronda de pre-semilla de $1.7 millones liderada por Hashed en junio de 2023, con coinversionistas que incluyen Superscrypt, LambdaClass y Crypto.com.
Información de financiamiento de Radius
Secuenciadores descentralizados basados en mecanismos de consenso como Espresso y Astria reducen MEV y revisan riesgos hasta cierto punto, pero a costa de la escalabilidad de la red y la eficiencia temporal, causan ciertos retrasos en la confirmación de transacciones (requiriendo consenso en la clasificación de transacciones). Además, aunque la clasificación de transacciones es en un entorno descentralizado, dado que las transacciones relacionadas con el mempool son transparentes, todavía hay margen para el mal uso para apoderarse de MEV. Radius encripta los mempools, y la información relevante de transacciones no es visible para el secuenciador. El objetivo es detener al secuenciador de extraer maliciosamente MEV y revisar transacciones en la fuente.
La arquitectura de tecnología de Radius se puede dividir en las siguientes cuatro capas funcionales: Radius (Radius), Capa de Ejecución (Rollup), Capa de Liquidación y Capa de Disponibilidad de Datos.
1) Capa de ordenación
2) Capa de ejecución
3) Capa de asentamiento
4) Capa de disponibilidad de datos
La capa de disponibilidad de datos almacena datos y garantiza que estén disponibles.
La arquitectura jerárquica funcional principal de Radius
Radius utiliza “Practical Verifiable Delayed Encryption” (PVDE), un esquema de cifrado basado en prueba de conocimiento cero, para crear un mempool encriptado.
El proceso específico es el siguiente:
Cuando un usuario envía una transacción al secuenciador:
1. El usuario genera un rompecabezas con bloqueo temporal y una clave simétrica;
2. El usuario utiliza una clave simétrica para cifrar la transacción, y la transacción cifrada entra en el mempool;
3. El secuenciador ordena las transacciones cifradas. El secuenciador necesita desbloquear el rompecabezas de bloqueo de tiempo para obtener la clave de descifrado;
4. El secuenciador calcula la promesa del pedido antes de desbloquear el rompecabezas de bloqueo de tiempo, y la capa de liquidación para la presentación de la promesa (utilizada para verificar que el secuenciador envíe transacciones a Rollup en orden).
Proceso de cifrado/descifrado de transacciones de radio
Los mempools encriptados aseguran que el secuenciador no sea de confianza, pero el riesgo de un único punto de fallo aún existe. Si ejecutas un único secuenciador + mempool encriptado, una falla del secuenciador hará que la red se caiga. Para resolver este problema, Radius propuso varias soluciones de implementación descentralizadas de secuenciadores, incluidos mecanismos de elección de líder secreto, mecanismos de segmentación de grupos de secuenciadores, etc.
Por supuesto, Radius también puede optar por hacer referencia al mecanismo de rotación del secuenciador de Espresso y Astria, al tiempo que hace que la secuenciación de transacciones sea descentralizada y sin confianza.
A través de la optimización del espacio de bloque, Radius tiene como objetivo lograr el objetivo de proteger a los usuarios mientras maximiza los beneficios de Rollup. Rollup utiliza un mecanismo de clasificación de servicio de primero en llegar, primero en ser servido (FCFS). La ventaja es que puede prevenir eficazmente MEV, y la desventaja es que se debe sacrificar el beneficio potencial de las subastas de espacio de bloque.
Para resolver el dilema de clasificación de transacciones descrito anteriormente, Radius divide el espacio de bloque en 2 partes: espacio de bloque superior y espacio de bloque inferior:
Entre ellos, el espacio de bloque superior está dedicado a las transacciones de usuario, cifrando las transacciones de usuario para eliminar la manipulación del ranking de transacciones, protegiendo así a los usuarios de los perjudiciales riesgos de MEV y censura; el bloque inferior introduce un mercado de transacciones basado en subastas donde los árbitros pueden enviar transacciones agrupadas y sus ofertas al secuenciador, y el secuenciador seleccionará la transacción agrupada con la oferta más alta para ser incluida en el bloque. Este método puede maximizar los beneficios de Rollup.
Lo anterior es la solución secuenciadora descentralizada general actualmente predominante. En el caso de Rollup, ¿te estás enfrentando a ejecutar un secuenciador centralizado o descentralizado? ¿Integrar una solución secuenciadora de propósito general de un tercero o descentralizarla tú mismo? ¿Qué tipo de tecnología se utiliza para implementar soluciones para descentralizar la secuenciación de transacciones? Evaluar los pros y los contras desde múltiples dimensiones, etc.
Varios Rollups principales, como Optimism, Arbitrum, zkSync y Base, ganan mucho dinero ejecutando secuenciadores centralizados. La descentralización implicará inevitablemente compartir beneficios. Sin considerar el paisaje cada vez más competitivo del circuito de Rollup, nadie quiere compartir este dulce regalo. Pero digamos que Rollup toma la delantera en el lanzamiento de un secuenciador descentralizado. Esto probablemente sea un gran punto de entrada de tráfico, formando un efecto demostrativo en el circuito de segmentación de Rollup, obligando así a otros proyectos de Rollup a descentralizar sus secuenciadores.
En términos generales, hay 2 formas para que los secuenciadores logren la descentralización: una es usar lo que otros han hecho; la otra es hacerlo tú mismo. Dado que terceros como Espresso y Astria pueden proporcionar a Rollup servicios de secuenciador descentralizado listos para usar, el propio Rollup puede seguir centrándose en la diferenciación del producto y en la optimización del rendimiento para mejorar su competitividad principal; además, las soluciones integradas de secuenciadores descentralizados de propósito general también son más propicias para lograr la interoperabilidad, lo que brinda más posibilidades, incluido el arbitraje cross-Rollup. La desventaja de esta solución puede ser que el propio token nativo de Rollup no se puede potenciar de manera efectiva.
Si Rollup utiliza una solución dedicada interna para implementar un secuenciador descentralizado, esta es la solución más lenta y costosa, pero de hecho es la forma más efectiva de habilitar el token nativo de Rollup. Por ejemplo, el proyecto StarkNet puede requerir al usuario que apueste el token nativo del acuerdo como secuenciador para participar en la clasificación de transacciones de Rollup y cobrar una cierta tarifa de servicio para lograr acumulación de valor.
Como se mencionó anteriormente, hay muchas soluciones de implementación técnica para lograr la clasificación descentralizada de transacciones, incluidas, entre otras, soluciones basadas en diferentes mecanismos de consenso, FCFS, subasta de bloques y mempools encriptados. Cada solución de implementación tecnológica tiene ventajas y desventajas: basado en mecanismos de consenso, la eficiencia temporal estará limitada, los mempools encriptados no pueden maximizar las ganancias de Rollup, etc. Por supuesto, también se puede hacer referencia a la integración de 2 implementaciones tecnológicas diferentes de Astria. El compromiso entre las diversas implementaciones técnicas es un problema que todos los proyectos de Rollup requieren una consideración cuidadosa.
Aunque Optimism y Arbitrum, los líderes del circuito Rollup, ahora han emitido monedas, esto probablemente es solo el punto de partida; la competencia en el verdadero sentido de la palabra puede haber comenzado apenas. Al menos, juzgando por las tendencias actuales, los secuenciadores descentralizados deben ser un campo de batalla para el ejército.
Los proyectos de ZK Rollup también están creciendo en silencio. En un entorno cada vez más competitivo, dar un paso en falso puede causar pérdidas irreparables. Sin embargo, ante las innovaciones que afectan la vida y la muerte del proyecto, Rollups no tuvieron más remedio que adaptarse a la tendencia general.
El tiempo vuela. Según Gate, ha pasado más de un año, y según Arbitrum, casi medio año ha pasado; emitir monedas fue solo el primer paso en su largo viaje. Durante este período, Gate actualizó Bedrock y lanzó el stack L2 modular universal OP Stack, que dio origen a Rollups estrella como Base; Arbitrum se compromete a explorar la aplicación de L3 para promover Arbitrum Orbit.
Bajo el liderazgo de los dos gigantes, el TVL de Rollup Track superó una vez los 10 mil millones de dólares estadounidenses y actualmente se mantiene estable en alrededor de 10 mil millones de dólares estadounidenses. Detrás de que los Rollups sean disfrutados como la solución de escalado “firma” de Ethereum, todavía tienen atributos centralizados y no resistentes a la censura. Las cadenas de Rollup principales generalmente utilizan secuenciadores centralizados oficiales. Aunque proyectos de Rollup como Arbitrum, Optimism y StarkNet incluyen la descentralización de los secuenciadores en la hoja de ruta, no se han implementado a corto o medio plazo de planificación. Como la pieza de rompecabezas más importante de la descentralización de Rollup, el secuenciador descentralizado tiene una posición estratégica muy importante para Rollup en sí mismo, y también es la aspiración de la gente.
Según los datos de L2Beat, el TVL de la pista L2 a partir del 1 de octubre de 2023
Antes de entender qué es un secuenciador, hablemos de los componentes de las tarifas de transacción de Rollup. La tarifa de transacción de Rollup es la tarifa de gas que los usuarios incurren en transacciones de L2 como Arbitrum.
Principalmente consta de 2 partes:
1) Costos de ejecución L2
2) Tarifa de datos L1
Tarifa de ejecución L2: el costo de la ejecución de la transacción en L2 (cada transacción iniciada en la cadena L2 está sujeta a una tarifa de ejecución)
Precio del gas de transacción = tarifa base L2 + tarifa de prioridad L2
Tarifa de ejecución L2 = precio del gas de la transacción * uso de gas L2
Tarifa de datos L1: El costo de publicar transacciones L2 en L1. Generalmente, los datos de L1 cuestan más que los costos de ejecución de L2.
Tarifa de transacción L2 = tarifa de ejecución L2 + tarifa de datos L1
Ingresos netos del secuenciador = ingresos por tarifas de transacción L2 - costos operativos del secuenciador - tarifa de datos L1
El secuenciador centralizado operado por la parte del proyecto tiene cierto poder de fijación de precios (por ejemplo, las tarifas de ejecución de L2 son un poco más altas, las tarifas de datos de L1 son un poco más altas), por eso varios proyectos conocidos de Rollup están ganando mucho dinero.
Un secuenciador, como su nombre lo indica, es un rol responsable de clasificar transacciones. En la red de Bitcoin, los mineros son responsables de clasificar transacciones; Ethereum es responsable de una colección de nodos, ninguno de los cuales juega un rol fijo, sino más bien un mecanismo de consenso para determinar quién está autorizado para participar en la ejecución secuencial.
Actualmente, los Rollups principales ejecutan todos un secuenciador centralizado único. Las transacciones L2 del usuario ingresan al grupo de memoria (en este punto, las transacciones en el grupo de memoria están en un estado desordenado), y el secuenciador ordena y comprime las transacciones en un conjunto ordenado de lotes, y luego las envía a la capa DA de Ethereum.
Proceso de operación del secuenciador
La respuesta es no. Las transacciones en Rollup pueden omitir completamente el secuenciador y enviarse a la capa base L1. L1 es responsable de la clasificación y liquidación, pero también se enfrentará a un mayor consumo de gas y a tiempos de confirmación de transacciones más largos.
El secuenciador Rollup es similar a usar una “vía rápida”, comprimiendo cientos o miles de transacciones L2 en una sola transacción L1, lo que reduce enormemente los costos de gas. Por esto, los Rollups principales de hoy en día ejecutan secuenciadores centralizados, que ofrecen a los usuarios un menor costo de gas y una confirmación de transacción más rápida, mejorando así la experiencia del usuario en las transacciones.
Las ventajas de la centralización son muy evidentes. Puedes clasificar las transacciones como desees; no es necesario cambiar la clasificación, y no es necesario ponerse de acuerdo sobre los resultados de la clasificación. Esto significa que tiene una velocidad de confirmación de transacciones muy rápida y la experiencia del usuario es mejor;
Sin embargo, la centralización también otorga al secuenciador una gran autonomía para clasificar transacciones. Puede clasificar arbitrariamente transacciones para maximizar sus propias oportunidades de arbitraje, aprovechar el valor de MEV, retrasar transacciones de usuarios e incluso censurar por completo a los usuarios.
El secuenciador puede obtener valor de MEV al cambiar el orden de las transacciones dentro de un solo bloque; lo más perjudicial es que, dado que el secuenciador controla la secuenciación de múltiples bloques seguidos, es fácil ejecutar MEV entre bloques, causando ataques a gran escala.
Todas las situaciones anteriores son una mala conducta activa por parte del secuenciador. Algunos errores no son intencionados por el secuenciador, pero aún así dañan la experiencia y los derechos del usuario. Por ejemplo, el secuenciador vuelve a incluir accidentalmente una transacción de token que ya se ha gastado en una promesa suave y, a continuación, se ha enviado a L1 para su verificación. También puede haber casos en los que la transacción no pueda ser confirmada; También es como un solo secuenciador que se desconecta, lo que hace que la segunda capa no pueda generar bloques correctamente y la red esté inactiva durante mucho tiempo.
El pez y el oso son imposibles, pero optimizar el rendimiento de Rollup no debe ser a expensas de la descentralización y la resistencia a la censura.
Si la centralización es 1, entonces la descentralización es mucho. Hay diferencias en los caminos de implementación de diferentes soluciones de secuenciadores descentralizados, pero su concepto central es el mismo, que es la descentralización.
El secuenciador ya no tiene derecho a clasificar centralmente las transacciones. El rol responsable de la clasificación se selecciona de un conjunto de conjuntos de secuenciadores basados en un mecanismo de elección específico y rota durante un ciclo fijo.
La descentralización evita que los secuenciadores se apoderen continuamente de MEV, y también impide que un solo secuenciador revise las transacciones de los usuarios. Junto con el mecanismo correspondiente de castigo criminal, también puede regular eficazmente el comportamiento del secuenciador.
Después de tanto rodeo, finalmente nos pusimos manos a la obra. Secuenciadores descentralizados. Uno está hecho por el propio proyecto Rollup, y el otro es implementado por un tercero. Utilizar a un tercero para implementar un secuenciador descentralizado también puede ser llamado secuenciación como servicio, y la secuenciación es un servicio.
Proyectos como Espresso, Astria, SUAVE y Radius se centran en soluciones de secuenciador descentralizado, y sus caminos de implementación varían.
Espresso Systems fue inicialmente un proveedor de servicios centrado en soluciones de privacidad. En marzo de 2022, se anunció que había recibido casi 30 millones de dólares en financiación de la Serie A con Electric Capital, Sequoia y Blockchain Capital. Espresso Systems ahora se ha transformado básicamente en Espresso Sequencer, que se especializa en proporcionar servicios de secuenciador descentralizado para Rollup.
Financiación de Espresso
Según el mecanismo de clasificación del secuenciador de Espresso, las transacciones L2 generalmente experimentan el siguiente ciclo de vida:
1) Las transacciones realizadas por los usuarios en la segunda capa se envían al servidor Rollup (API);
2) Las transacciones entran en la mempool, y el secuenciador (seleccionado por el consenso HotShot) ordena e incluye las transacciones en un bloque;
3) El secuenciador difunde la transacción. Después de alcanzar un consenso HotShot a través de otros nodos, se emite el bloque y se ejecuta la transacción; la soft promise proporciona una rápida confirmación de la transacción
4) El secuenciador envía y almacena un certificado de consenso (QC: Certificado de Quorum) con la promesa de bloque que contiene la transacción en el contrato del secuenciador L1 (demostrando que el bloque ha alcanzado la finalidad suave a través del consenso);
5) El nodo Rollup que ha ejecutado el bloque envía el nuevo estado de Rollup a L1 (en este punto, zKrU requiere una prueba de validez, y ORU abre el período de desafío)
6) El contrato L1 Rollup verifica la validez de las actualizaciones de estado verificando el QC enviado por el contrato secuenciador.
El ciclo de vida de una transacción L2 bajo el mecanismo de clasificación Espresso
Este proceso parece oscuro y difícil de entender; la forma simple de entenderlo es:
El consenso HotShot selecciona uno de un conjunto de secuenciadores. Es responsable de ordenar transacciones de Rollup e incluir transacciones en un bloque; este bloque debe ser firmado y acordado por otros nodos de Rollup (2/3 o más nodos HotShot están de acuerdo) para ser “final”, y luego las promesas de bloque relevantes y la nueva raíz de estado de Rollup se envían a la capa base L1 para su verificación.
El "Finality" anterior está entre comillas; esta "finalidad entre comillas" y la finalidad sin comillas no es un concepto. La "finalidad" entre comillas permite confirmar las transacciones de Rollup más rápidamente, con menos demora y una mejor experiencia de usuario; sin embargo, las transacciones de Rollup requieren en última instancia que la capa base L1 verifique (zKru necesita verificar la prueba de validez, ORU tiene que esperar al final del período de desafío). Si no hay problema en verificar que la transacción enviada por Rollup está bien, entonces la transacción de Rollup es verdaderamente final.
Esto significa: si la capa base L1 verifica que la transacción es inválida, el bloque L2 correspondiente que ya ha sido liberado enfrentará un retroceso. Por lo tanto, la "finalidad" es que las transacciones se confirmen rápidamente, y la finalidad es heredar la seguridad de Ethereum.
Arquitectura de secuenciación de transacciones sin espresso
Integrar la arquitectura de secuenciación de transacciones de Espresso
Espresso resolvió el problema de rotación del secuenciador y la determinación de la "finalidad" de la transacción basada en el consenso HotShot, y resolvió el problema de admisión del secuenciador al introducir EigenLayer.
El mecanismo de re-apuesta de EigenLayer hace posible que los apostadores de Ethereum se conviertan simultáneamente en secuenciadores de Espresso, brindando seguridad para el consenso HotShot. En pocas palabras, los apostadores de nodos de Ethereum pueden convertirse en Secuenciadores de Espresso (ESQ) a través del mecanismo de re-apuesta de EigenLayer. Mientras reciben beneficios de los nodos de PoS, los apostadores de Ethereum también capturan el valor de MEV de segundo nivel.
Beneficios potenciales para los titulares de ETH = recompensas nativas de nodos de red + L2 EVM + recompensas de nodos de otras cadenas PoS (utilizando el mecanismo de reestaca EigenLayer). El triple refuerzo potencia enormemente a ETH.
Solución de secuenciador descentralizado de EigenLayer
Espresso es una solución de secuenciador descentralizado de propósito general. Además de EigenLayer, los proyectos de cooperación ecológica incluyen proyectos modulares populares como Arbitrum, OP Stack, Caldera, AltLayer, etc.
Espresso Proyecto de Cooperación Ecológica Diseño
Astria se posiciona como un secuenciador descentralizado genérico y sin permisos, proporcionando un servicio de secuenciador compartido listo para usar para diferentes Rollups. En cuanto a la financiación, Astria anunció la finalización de una ronda inicial de $5.5 millones liderada por Maven 11 en abril de 2023. Entre los coinversores se encuentran 1k (x), Delphi Digital, Lemniscap, Robot Ventures, etc. Aunque la escala de financiación es pequeña, la alineación institucional es magnífica.
Situación de financiación de Astria
El mecanismo de operación del secuenciador descentralizado Astria es similar al Secuenciador Espresso. El propósito es debilitar los privilegios de los secuenciadores mediante la delegación de los derechos de secuenciación de transacciones. Veámoslo más de cerca:
Para la rotación del secuenciador, Astria propuso dos mecanismos de rotación: rotación simple del líder (rotación del líder) y algoritmo de consenso de tolerancia a fallos bizantinos (BFT).
1) Rotación de líder
Un conjunto se forma a través de un secuenciador elegido y el conjunto de secuenciadores se turna para ordenar las transacciones consolidadas. Este método evita que un solo secuenciador continúe monopolizando los derechos de clasificación de las transacciones durante un largo período de tiempo, y resuelve el problema de la revisión continua de los usuarios hasta cierto punto.
El mecanismo de rotación de liderazgo de Astria
2) algoritmo de consenso BFT
Similar to the leader rotation mechanism, the sequencer who takes the turn is responsible for ranking transactions, but 2/3 or more members in the sequencer set must agree on this ranking.
Cada uno de los dos métodos tiene ventajas y desventajas: el primero permite una confirmación de transacción más rápida, una generación de bloques rápida y está cerca de la de un secuenciador centralizado. Sin embargo, el punto de equilibrio es que todavía es difícil contener a los secuenciadores a su vez para que no cometan maldades; usar el consenso BFT es aún menos probable, y 2/3 de los secuenciadores en el conjunto deben votar para alcanzar un consenso antes de que salga el bloque. Sin embargo, llevó cierta cantidad de tiempo llevar a cabo una votación de consenso, lo que causó retrasos en la red.
Algoritmo de consenso BFT de Astria
SUAVE es una solución secuenciadora compartida descentralizada y plug-and-play construida por Flashbots. Como solución general, SUAVE puede proporcionar grupos de memoria y construcción de bloques descentralizados para cualquier L1/L2. La diferencia entre SUAVE y el diseño de secuenciador compartido descrito anteriormente es que la propia cadena SUAVE es una cadena compatible con EVM, y las transacciones se ordenan a través de "subasta" de bloques.
La arquitectura de SUAVE consta de 3 componentes principales: un entorno de preferencias comunes, un mercado de ejecución óptimo y una construcción de bloques descentralizada.
1) Entorno preferido
Las preferencias van desde transacciones simples hasta eventos complejos. Las preferencias del usuario se reflejan en mempools en forma de transacciones, y el entorno de preferencias es un mempool público que reúne las preferencias. El entorno general de preferencias proporcionado por SUAVE hace que las preferencias de usuario multi-cadena sean abiertas y transparentes, elimina la información deficiente y resuelve en cierta medida el problema del MEV entre cadenas.
2) Ejecutar el mercado
El mercado de ejecución es una red donde los ejecutores son responsables de monitorear el memepool SUAVE y competir entre sí, y la competencia los impulsa a proporcionar la mejor ejecución para las preferencias del usuario. Se puede entender que todos los ejecutores logran las preferencias del usuario a través de "ofertas" y devuelven la mayor cantidad posible de MEV generada por las transacciones del usuario al usuario.
3) Construcción descentralizada de bloques
Finalmente, basado en las preferencias recopiladas y en la mejor ruta de ejecución, la red de construcción de bloques descentralizada los incluye en el bloque. En este punto, se ha logrado todo el proceso de descubrimiento de transacciones, secuenciación de transacciones y generación de bloques.
Los componentes principales de SUAVE
El enfoque de segmentación de Radius es una capa de ordenación compartida que no requiere confianza. A diferencia de los mecanismos de implementación descritos anteriormente, Radius garantiza que las transacciones de Rollup se clasifiquen sin confianza al habilitar mempools encriptados, eliminando así la MEV efectiva y la censura de transacciones de usuarios.
En términos de financiamiento, Radius anunció la finalización de la ronda de pre-semilla de $1.7 millones liderada por Hashed en junio de 2023, con coinversionistas que incluyen Superscrypt, LambdaClass y Crypto.com.
Información de financiamiento de Radius
Secuenciadores descentralizados basados en mecanismos de consenso como Espresso y Astria reducen MEV y revisan riesgos hasta cierto punto, pero a costa de la escalabilidad de la red y la eficiencia temporal, causan ciertos retrasos en la confirmación de transacciones (requiriendo consenso en la clasificación de transacciones). Además, aunque la clasificación de transacciones es en un entorno descentralizado, dado que las transacciones relacionadas con el mempool son transparentes, todavía hay margen para el mal uso para apoderarse de MEV. Radius encripta los mempools, y la información relevante de transacciones no es visible para el secuenciador. El objetivo es detener al secuenciador de extraer maliciosamente MEV y revisar transacciones en la fuente.
La arquitectura de tecnología de Radius se puede dividir en las siguientes cuatro capas funcionales: Radius (Radius), Capa de Ejecución (Rollup), Capa de Liquidación y Capa de Disponibilidad de Datos.
1) Capa de ordenación
2) Capa de ejecución
3) Capa de asentamiento
4) Capa de disponibilidad de datos
La capa de disponibilidad de datos almacena datos y garantiza que estén disponibles.
La arquitectura jerárquica funcional principal de Radius
Radius utiliza “Practical Verifiable Delayed Encryption” (PVDE), un esquema de cifrado basado en prueba de conocimiento cero, para crear un mempool encriptado.
El proceso específico es el siguiente:
Cuando un usuario envía una transacción al secuenciador:
1. El usuario genera un rompecabezas con bloqueo temporal y una clave simétrica;
2. El usuario utiliza una clave simétrica para cifrar la transacción, y la transacción cifrada entra en el mempool;
3. El secuenciador ordena las transacciones cifradas. El secuenciador necesita desbloquear el rompecabezas de bloqueo de tiempo para obtener la clave de descifrado;
4. El secuenciador calcula la promesa del pedido antes de desbloquear el rompecabezas de bloqueo de tiempo, y la capa de liquidación para la presentación de la promesa (utilizada para verificar que el secuenciador envíe transacciones a Rollup en orden).
Proceso de cifrado/descifrado de transacciones de radio
Los mempools encriptados aseguran que el secuenciador no sea de confianza, pero el riesgo de un único punto de fallo aún existe. Si ejecutas un único secuenciador + mempool encriptado, una falla del secuenciador hará que la red se caiga. Para resolver este problema, Radius propuso varias soluciones de implementación descentralizadas de secuenciadores, incluidos mecanismos de elección de líder secreto, mecanismos de segmentación de grupos de secuenciadores, etc.
Por supuesto, Radius también puede optar por hacer referencia al mecanismo de rotación del secuenciador de Espresso y Astria, al tiempo que hace que la secuenciación de transacciones sea descentralizada y sin confianza.
A través de la optimización del espacio de bloque, Radius tiene como objetivo lograr el objetivo de proteger a los usuarios mientras maximiza los beneficios de Rollup. Rollup utiliza un mecanismo de clasificación de servicio de primero en llegar, primero en ser servido (FCFS). La ventaja es que puede prevenir eficazmente MEV, y la desventaja es que se debe sacrificar el beneficio potencial de las subastas de espacio de bloque.
Para resolver el dilema de clasificación de transacciones descrito anteriormente, Radius divide el espacio de bloque en 2 partes: espacio de bloque superior y espacio de bloque inferior:
Entre ellos, el espacio de bloque superior está dedicado a las transacciones de usuario, cifrando las transacciones de usuario para eliminar la manipulación del ranking de transacciones, protegiendo así a los usuarios de los perjudiciales riesgos de MEV y censura; el bloque inferior introduce un mercado de transacciones basado en subastas donde los árbitros pueden enviar transacciones agrupadas y sus ofertas al secuenciador, y el secuenciador seleccionará la transacción agrupada con la oferta más alta para ser incluida en el bloque. Este método puede maximizar los beneficios de Rollup.
Lo anterior es la solución secuenciadora descentralizada general actualmente predominante. En el caso de Rollup, ¿te estás enfrentando a ejecutar un secuenciador centralizado o descentralizado? ¿Integrar una solución secuenciadora de propósito general de un tercero o descentralizarla tú mismo? ¿Qué tipo de tecnología se utiliza para implementar soluciones para descentralizar la secuenciación de transacciones? Evaluar los pros y los contras desde múltiples dimensiones, etc.
Varios Rollups principales, como Optimism, Arbitrum, zkSync y Base, ganan mucho dinero ejecutando secuenciadores centralizados. La descentralización implicará inevitablemente compartir beneficios. Sin considerar el paisaje cada vez más competitivo del circuito de Rollup, nadie quiere compartir este dulce regalo. Pero digamos que Rollup toma la delantera en el lanzamiento de un secuenciador descentralizado. Esto probablemente sea un gran punto de entrada de tráfico, formando un efecto demostrativo en el circuito de segmentación de Rollup, obligando así a otros proyectos de Rollup a descentralizar sus secuenciadores.
En términos generales, hay 2 formas para que los secuenciadores logren la descentralización: una es usar lo que otros han hecho; la otra es hacerlo tú mismo. Dado que terceros como Espresso y Astria pueden proporcionar a Rollup servicios de secuenciador descentralizado listos para usar, el propio Rollup puede seguir centrándose en la diferenciación del producto y en la optimización del rendimiento para mejorar su competitividad principal; además, las soluciones integradas de secuenciadores descentralizados de propósito general también son más propicias para lograr la interoperabilidad, lo que brinda más posibilidades, incluido el arbitraje cross-Rollup. La desventaja de esta solución puede ser que el propio token nativo de Rollup no se puede potenciar de manera efectiva.
Si Rollup utiliza una solución dedicada interna para implementar un secuenciador descentralizado, esta es la solución más lenta y costosa, pero de hecho es la forma más efectiva de habilitar el token nativo de Rollup. Por ejemplo, el proyecto StarkNet puede requerir al usuario que apueste el token nativo del acuerdo como secuenciador para participar en la clasificación de transacciones de Rollup y cobrar una cierta tarifa de servicio para lograr acumulación de valor.
Como se mencionó anteriormente, hay muchas soluciones de implementación técnica para lograr la clasificación descentralizada de transacciones, incluidas, entre otras, soluciones basadas en diferentes mecanismos de consenso, FCFS, subasta de bloques y mempools encriptados. Cada solución de implementación tecnológica tiene ventajas y desventajas: basado en mecanismos de consenso, la eficiencia temporal estará limitada, los mempools encriptados no pueden maximizar las ganancias de Rollup, etc. Por supuesto, también se puede hacer referencia a la integración de 2 implementaciones tecnológicas diferentes de Astria. El compromiso entre las diversas implementaciones técnicas es un problema que todos los proyectos de Rollup requieren una consideración cuidadosa.
Aunque Optimism y Arbitrum, los líderes del circuito Rollup, ahora han emitido monedas, esto probablemente es solo el punto de partida; la competencia en el verdadero sentido de la palabra puede haber comenzado apenas. Al menos, juzgando por las tendencias actuales, los secuenciadores descentralizados deben ser un campo de batalla para el ejército.
Los proyectos de ZK Rollup también están creciendo en silencio. En un entorno cada vez más competitivo, dar un paso en falso puede causar pérdidas irreparables. Sin embargo, ante las innovaciones que afectan la vida y la muerte del proyecto, Rollups no tuvieron más remedio que adaptarse a la tendencia general.