TL;DR

La hoja de ruta centrada en Rollup provocó blockchains fragmentadas y separadas. Esta fragmentación causó falta de transferencia de valor entre rollups. Como solución a este problema, surgieron mecanismos de secuenciador compartido como Espresso, Astria y Radius. Pero esta solución inherentemente requiere nuevas suposiciones de confianza. Porque tal capa tiene que tener su propio conjunto de seguridad.

Si queremos construir una capa de secuenciación compartida para rollups, Ethereum es la capa neutral más creíble que podemos construir/usar como secuenciador compartido. La secuenciación basada (también conocida como rollups basados) tiene plena composibilidad con Ethereum por naturaleza, y otros rollups basados. Sin embargo, ser un rollup basado conlleva algunos desafíos. El más importante de estos desafíos es que el tiempo de bloque está limitado a 12 segundos, al igual que Ethereum. La solución es un mecanismo para dar a los usuarios una confirmación rápida, como secuenciadores centralizados, o para acelerar el tiempo de bloque de Ethereum. En la red de prueba, las preconfirmaciones basadas dan preconfirmaciones más rápidas que los secuenciadores centralizados hoy en día.

Encrucijada

Es bueno recordar la dirección elegida de Ethereum al principio del post. Ethereum ha abrazado la descentralización desde el primer día. Esta es la primera prioridad. Esta prioridad nos impone ciertas limitaciones en la experiencia del usuario. Estas limitaciones surgen de los desafíos de diseñar un sistema distribuido descentralizado (como lidiar con el estado global, la ejecución secuencial, y así sucesivamente). Esta es la diferencia exacta entre Ethereum y otros L1s. Ellos eligieron diferentes caminos. Otros L1s optaron por ser rápidos y baratos sacrificando algo de descentralización. Son rápidos y baratos porque tienen prueba de historia, tamaños de bloque más grandes, procesamiento paralelo. Estos conceptos permiten transacciones rápidas y baratas, pero también aumentan la carga en los validadores. Por eso, los requisitos de hardware de otros validadores L1 son más altos que los de Ethereum.

Hasta que Ethereum mismo se escale con actualizaciones como la expiración del historial, la falta de estado, el árbol Verkle, etc., le dimos la misión a los rollups.

Hace 4 años, Ethereum adoptó una hoja de ruta centrada en rollup para externalizar la ejecución y hacer que sea un lugar más amigable para el usuario hasta que lleguen las mejoras. Gracias a eso, hemos alcanzado un promedio diario de 250 TPS en todo Ethereum.

rollup.wtf

Como se mencionó anteriormente, han pasado 4 años desde que Ethereum decidió seguir una hoja de ruta centrada en rollups. Durante este tiempo, ha habido mucha experimentación en las capas 2 sobre "cómo debería ser Ethereum en sí mismo". AltVMs (Fuel, Fluent), zkVMs (Aztec, Starknet), zkEVMs (Scroll, Linea, zkSync), EVMs paralelos (MegaETH), y así sucesivamente. Todo esto da una idea del futuro de Ethereum en sí mismo. Pero también ha creado muchas blockchains separadas que ni siquiera tienen conexión entre ellas. Por eso llegaron las capas de secuenciación compartidas para resolver la fragmentación.

Capas de secuenciación compartida

Actualmente, los rollups tienen secuenciadores centralizados. Esto introduce enormes riesgos de censura, viabilidad y extracción de MEV. En cambio, los rollups podrían optar por secuenciadores compartidos si quieren ser descentralizados. Al utilizar secuenciadores compartidos, los rollups pueden aprovechar la finalidad, la descentralización, las transacciones rápidas y la atomicidad entre cadenas. Como dice Vitalik, "La descentralización de los rollups implica el 90% del esfuerzo de desarrollar un nuevo L1". Por lo tanto, el esfuerzo de ingeniería para la descentralización se puede evitar al optar por un secuenciador compartido.

La capa de secuenciación compartida es básicamente una capa que conecta los derechos de secuenciación de los rollups participantes en una sola red de secuenciadores. Esta capa ejecuta un protocolo de consenso, como BFT, en el que cualquiera puede participar (dentro de los límites del diseño del protocolo de consenso). Así, varios rollups tienen un mecanismo común para determinar el orden de las transacciones. Este mecanismo también proporciona una finalización rápida de L2 y la capacidad de componer entre todos los rollups participantes.

La capa de secuenciador compartido es un mercado de secuenciadores. En este mercado, los rollups pueden vender su espacio en bloque (y derechos de propuesta) a postores más altos ranura por ranura. Esto también crea una capa que redistribuye MEV entre todos los rollups participantes.

Preocupaciones

Las capas de secuenciación compartidas tienen un efecto de red que crea composabilidad atómica y MEV compartido entre todos los rollups participantes. Los rollups se unen a la red para aumentar el valor de sus bloques (y también descentralizar su secuenciador).

Sin embargo, según el diseño del sistema de secuenciadores compartidos, debería haber tantos rollups como sea posible. Si el rollup participante X abandona la cadena, esta distribución de MEV se ve interrumpida y afecta directamente el efecto de red. La secuenciación compartida es, por lo tanto, un juego interminable en el que los participantes deben permanecer en el juego en todo momento. Es un modelo b2b puro como Rushidicho.

Las capas de secuenciación compartidas ejecutan un protocolo como BFT para una rápida finalidad L2 junto al mercado de secuenciadores compartidos, y está introduciendo una suposición de honestidad. Se supone que la mitad de los validadores son honestos. Si por alguna razón la mitad de los validadores están desconectados o son deshonestos, la cadena puede perder la vivacidad (pueden utilizar el fallback basado). Si el protocolo BFT pierde la vivacidad, los rollups participantes no pueden aprovechar la finalidad rápida porque tienen que certificar la finalidad desde el protocolo BFT. Los retiros de la capa también se detendrán. Pero incluso si el protocolo BFT está roto, la redistribución de MEV seguirá ocurriendo, porque en Espresso, por ejemplo, la redistribución de MEV es independiente del protocolo BFT. Al comparar, Ethereum siempre será el protocolo BFT más sólido en términos de seguridad criptoeconómica y vivacidad.

Además, tienen riesgos de restaking si lo están utilizando. Si los requisitos de hardware para el validador son altos, esto conducirá a un monopolio. También puede haber un recorte masivo si hay un error en el servicio de restaking; ver Eigenlayer’s.Preguntas frecuentes sobre riesgospara más. Para enfoques de restaking en secuenciadores compartidos, consulte la investigación conjunta de Nethermind y Fourpillaraquí.

Es importante tener en cuenta que, dado el uso de la preconfirmación por parte de los secuenciadores compartidos, este proceso se puede completar en L1 (también conocido como preconfirmación basada), eliminando la necesidad de una nueva capa. También hay que tener en cuenta que el secuenciador compartido todavía tiene que pasar de todos modos por el canal de L1. Por lo tanto, la "finalización rápida" no tiene sentido aquí.

En resumen, creemos que las capas compartidas del secuenciador son un único punto de falla si no están descentralizadas y son sólidas. Se convertirán en el eslabón más débil para todos los rollups opt-in.

La composabilidad neutral ya no es un meme: sé basado.

Como dijimos, Ethereum es la capa neutral más creíble para construir algo. Los Rollups hacen esto enviando sus lotes/pruebas para usar Ethereum como la capa DA. Actualmente, la mayoría de los Rollups son ejecutados por secuenciadores centrales, y todas las transacciones son secuenciadas por los equipos de Rollup. Algunos equipos todavía están trabajando en algunos diseños para descentralizar su red, como Aztec’sFernet. También hay otra forma de descentralizar la red sin gastar toneladas de recursos de ingeniería: basado en la secuenciación.

Taiko es el primer rollup basado en Ethereum que utiliza Ethereum como capa de secuenciación. La construcción de bloques pertenece completamente a Ethereum. Cualquier persona puede proponer un bloque, es completamente sin permisos. Cada rollup puede lograr la composabilidad al estar basado. No agregando una nueva capa. Dado que Ethereum y los slots de rollup basados se mueven de manera sincronizada, son completamente compatibles entre sí. Esto significa que es posible tomar un préstamo flash en L1 y realizar alguna actividad en un rollup basado en el mismo slot (gracias a nuestro diseño BBR, leer más aquí). Pero estar basado tiene algunos costos.

fuente: L2Beat

Abordamos este tema en el "Consideraciones centradas en Rollup de Preconfirmaciones basadasPero vamos a resumir brevemente el artículo. Como dijimos, los rollups basados tienen el mismo tiempo de bloque de 12 segundos que Ethereum. Esto significa que los rollups basados necesitan enviar sus datos a L1 con blobs (o calldata) cada 12 segundos. Si no puede llenar el blob con suficientes transacciones L2 para cubrir la tarifa L1, perderá dinero. Para no trasladar esto a nuestros usuarios al principio, lo cubrimos nosotros mismos y gastamos mucho dinero. Hoy en día, el tiempo de bloque es mayor de 12 segundos (∼20s) para que el proponente sea rentable.

https://dune.com/taiko_xyz/taikobcr

Estos son ejemplos de las dificultades que puede experimentar un rollup basado a través del ejemplo de Taiko. En resumen, el problema principal es el tiempo de bloqueo y la restricción de los ingresos solo a las tarifas base, a diferencia del secuenciador central. Sacrificas ingresos porque la secuenciación es completamente sin permisos y tu MEV fluye completamente a Ethereum, no puedes capturar ningún valor de las transaccionesSpire Labs está desarrollando un marco basado para mejorar el modelo de ingresos basado en rollups).

Para resolver la experiencia del usuario, los tiempos de bloqueo, tenemos dos opciones:

1. Preconfirmaciones basadas
2. Bloques más rápidos en L1

Preconfirmaciones basadas

Las preconfirmaciones basadas simplemente utilizan algunos de los validadores L1 para dar preconfirmaciones a los usuarios L2. Las preconfirmaciones basadas actualmente están funcionando con éxito en la red de pruebas de Helder, y ahora es posible hacerlo súper rápido (20ms en la demostración de Gattaca,∼260msen transacciones de Arbitrum) en Taiko.

Demo de preconfirmación basado en Titan

En las preconfirmaciones basadas, no heredas toda la vitalidad y seguridad de Ethereum. Solo confías en un subconjunto del conjunto de validadores de Ethereum. Pero es bueno mencionar aquí que estamos obteniendo un compromiso creíble del actual proponente de Ethereum. Cualquiera puede ser un preconfer (proveedor de preconfirmación) apostando una cantidad exacta de ETH en el contrato del registro. Explicamos los detalles de las preconfirmaciones basadas en nuestra publicación de blog anterior, ver aquí.

El espacio de preconfirmación en el que se basa todavía se encuentra en sus primeras etapas de desarrollo. Tiene algunas amenazas, al igual que la centralización de la construcción de bloques de Ethereum, pero con nuevos enfoques e investigaciones, se diseñará una arquitectura mucho más razonable. Pronto compartiremos nuestro diseño de preconfirmación.

¿Bloques más rápidos?

Nadie se negaría a hacer que Ethereum sea más amigable para el usuario. Mayor finalidad, tiempos de bloque más rápidos y transacciones más rápidas. Este es el escenario más útil para un rollup basado porque, como dijimos, los tiempos de bloque de L1 son el único obstáculo para ser basado. Un bloque de L1 más rápido significa bloques de rollup basados más rápidos.

La idea principal para un L1 más rápido es un consenso que reduce nativamente el tiempo de ranura.Single Slot Finality(SSF) es un mecanismo de consenso(Orbit SSFen una forma más específica) siendo considerado, donde cada espacio puede ser finalizado en unos pocos segundos. En el protocolo Gasper actual, el tiempo de finalización es de 2 épocas, es decir, 13 minutos. Sin embargo, la desventaja de SSF es que es vulnerable a una fuga de inactividad del 33%.

La pregunta principal aquí es por qué, si un L1 más rápido es siempre una necesidad, el esfuerzo de ingeniería gastado en cuatro años de rollups no se utiliza para acelerar el L1 en sí. Hemos dedicado mucho esfuerzo de I+D a los rollups. Hemos hecho un gran trabajo y hemos logrado muchos enfoques diferentes. Incluso si los tiempos de bloque más cortos fueran acordados hoy, tomará 2-3 años como máximo para desarrollarlos.

Ethereum ha elegido un camino muy claro. Este camino significa no hacer concesiones en cuanto a la descentralización y no tocar a los 'solo home stakers'. Es obvio que bloques rápidos requieren un cambio en el consenso de Ethereum, y que este consenso cambiado llevará a una distribución de validadores mucho más baja que ahora. Esta es una decisión importante que la comunidad de Ethereum debe tomar.

Conclusión

A medida que los rollups se desarrollan y se vuelven más populares, la fragmentación y el aislamiento se convierten en problemas serios. Por lo tanto, ser un rollup basado y unirse a capas secuenciales compartidas es una distinción importante. Las capas secuenciales compartidas se pueden utilizar para una finalidad rápida y una composabilidad entre cadenas, pero requieren nuevas suposiciones de confianza y podrían fallar y perder el efecto de red. Los rollups basados utilizan la infraestructura existente de Ethereum para la construcción de bloques, pero enfrentan desafíos con los tiempos de bloque y los modelos de ingresos. Sin embargo, ofrecen una solución a la fragmentación de liquidez por naturaleza y una plena composabilidad con el L1.

El camino a seguir puede residir en nuevas soluciones como preconfirmaciones basadas y tiempos de bloque L1 más rápidos para superar las desventajas de los rollups basados. Estos tienen como objetivo mejorar la experiencia del usuario sin comprometer la alineación de Ethereum. El objetivo es crear un ecosistema escalable, descentralizado y fácil de usar que se mantenga fiel a la visión de Ethereum.

La elección de basarse o no es más que una decisión técnica. Se trata de la dirección del "marco" acumulativo descentralizado.

Únete a nosotros

Explora las posiciones abiertas en nuestro tablero de trabajo.

Síguenos

Obtén lo último de Taiko:

1. Sitio web: https://taiko.xyz.
2. Discord: https://discord.gg/taikoxyz.
3. GitHub: https://github.com/taikoxyz.
4. Twitter: https://twitter.com/taikoxyz.
5. Foro comunitario: https://community.taiko.xyz.
6. YouTube: @taikoxyz"">https://www.youtube.com/@taikoxyz.
7. Warpcast: https://warpcast.com/taikoxyz.

Contribuir

¡Contribuye a Taiko en GitHub y gana un GitPOAP! También aparecerá como colaborador en nuestro archivo README. Comience con el método contribuyendo manual.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [espejo], Todos los derechos de autor pertenecen al autor original [Taiko Labs&Jünger]. If there are objections to this reprint, please contact the Gate Learnequipo, y ellos lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.