coescrito con arixon. inspirado en justin. bifurcado de charlie y dan. Gracias a Barnabe, Mike y Justin por leer los borradores de esto.

En Ethereum L1, todas las aplicaciones se ejecutan de forma atómica en una máquina de estado compartida. La hoja de ruta centrada en el rollup sacrifica esta propiedad central para escalar Ethereum.

El enfoque de resumen actual funciona bien mientras las aplicaciones permanecen locales en el resumen. Sin embargo, existe un límite en la cantidad de aplicaciones que cada uno de estos paquetes acumulativos puede admitir (debido a cuellos de botella secuenciales inherentes) y no están diseñados para comunicarse entre sí.

Hoy en día, la presión regulatoria y la falta de interoperabilidad nativa están impulsando los rollups hacia blockchains de middleware (o marcos rollup en el espíritu de las supercadenas/hipercadenas) que permiten la secuenciación compartida (y, por lo tanto, cierto grado de reparto de liquidez y componibilidad atómica entre ellas).

Un posible estado final aquí es un mundo en el que cada nueva L2 necesite middleware de terceros (un servicio de secuenciador compartido) para comunicarse eficientemente con los demás.

Una compensación importante (y subestimada) de este enfoque es que los rollups ya no heredan las garantías de vida subyacentes de la L1 (una gran parte de lo que hace especial a Ethereum) ni toda la fuerza de su neutralidad creíble (ya que los rollups dependerían de un consenso alternativo). mecanismo fuera de Ethereum).

Los rollups basados ofrecen una visión diferente para un futuro resistente a la censura: uno construido alrededor de la neutralidad y la vivacidad de la capa base como primer principio. Esta visión es inclusiva, no competitiva, respecto de los paquetes acumulativos existentes. Optimismo y otras plataformas podrán consolidarse sin perjudicar su modelo de negocio.

¿Qué es un resumen basado?

En resumen, los resúmenes basados (o secuenciados en L1) son un subconjunto especial de resúmenes. La secuenciación de dichos paquetes acumulativos es sumamente simple y hereda la vitalidad y la descentralización de L1. Además, los rollups de base están alineados de forma especialmente económica con su base L1.

Se dice que un resumen está basado, o secuenciado en L1, cuando su secuenciación es impulsada por la base L1. Más concretamente, un resumen basado es aquel en el que el siguiente proponente de L1 puede, en colaboración con los buscadores y constructores de L1, incluir sin permiso el siguiente bloque de resumen como parte del siguiente bloque de L1.

Los rollups basados son únicos porque heredan las propiedades de vida de la capa base y pueden lograr interoperabilidad sin depender de una cadena de bloques de middleware (lo que les permite aumentar significativamente su neutralidad creíble sin reducir su eficacia). Estas características se explican mejor en comparación con otras arquitecturas acumulativas.

Arquitecturas acumulativas

La mayoría de los paquetes acumulativos actuales utilizan un secuenciador centralizado. El secuenciador recopila transacciones del mempool, las agrupa y las publica en L1. La principal ventaja de este enfoque es que el secuenciador proporciona a los usuarios confirmaciones previas rápidas. También ayuda a mitigar los riesgos de acumulaciones en etapas iniciales sin pruebas de fraude/validez, y a mitigar el riesgo de errores en el sistema de pruebas para quienes las tienen. Si el secuenciador es operado por una entidad confiable (por ejemplo, Optimism Foundation), la probabilidad de que ocurra una transición de estado no válida se reduce significativamente.

El principal problema con los secuenciadores centralizados (aparte del potencial de abuso de MEV) es que presentan un único punto de falla desde una perspectiva de vivacidad y resistencia a la censura. Si bien los paquetes acumulativos actuales brindan trampillas de salida e inclusión forzada para proteger contra el tiempo de inactividad del secuenciador y la censura, de manera realista, esto no beneficiará a un porcentaje significativo de usuarios de L2, de quienes no se puede esperar que gasten una cantidad sustancial en transacciones de L1. Otro problema potencial es que si los usuarios se ven obligados a utilizar trampillas de salida, los efectos de red de ese resumen se restablecerán. También es relativamente fácil para un gobierno o regulador poderoso imponer requisitos de KYC o sanciones en la cadena a través del secuenciador.

Los secuenciadores compartidos tienen como objetivo abordar muchos de los problemas asociados con los secuenciadores centralizados, como permitir la interoperabilidad entre ecosistemas acumulativos y mejorar la descentralización: Espresso Systems y Astria son equipos que trabajan en este enfoque. Un buen aspecto del diseño del secuenciador compartido es que casi todos los paquetes acumulativos actuales pueden implementar esta arquitectura, sin importar si es optimista o zk. El argumento es que los paquetes acumulativos que adopten este diseño tendrán la capacidad de componerse atómicamente entre sí mientras mantienen un mayor nivel de descentralización en comparación con un paquete acumulativo secuenciado centralmente.

Una desventaja del modelo de secuenciador compartido externo es que los paquetes acumulativos no heredan las propiedades de vitalidad de la capa base (un factor subestimado de resistencia a la censura). Otra desventaja es que probablemente necesitará su propio token en algún momento (o necesitará participar en una forma obstinada de extracción de mev para ser rentable), lo que significa que los rollups que dependen de él, con toda probabilidad, serán menos . económicamente alineado con la capa base.

Un paquete acumulativo basado aprovecha directamente los proponentes L1 como secuenciadores compartidos sin depender del consenso externo de un sistema de secuenciador compartido como HotShot for Espresso (y el token intermediario y/o la política mev que lo acompaña). Como tal, hereda más neutralidad de la capa base.

Interoperabilidad

Al aprovechar los creadores y proponentes de la capa base, los paquetes acumulativos basados pueden preservar la interoperabilidad entre paquetes acumulativos, cuyos lotes se envían en el mismo bloque, sin necesidad de ningún middleware adicional.

Las confirmaciones previas rápidas (del orden de 100 ms) son triviales con la secuenciación centralizada y se pueden lograr con un consenso PoS externo. Se pueden lograr confirmaciones previas rápidas con secuenciación L1 aprovechando EigenLayer, listas de inclusión, SSLE y mev-boost.

Sencillez

La secuenciación basada es sumamente simple; significativamente más simple que incluso la secuenciación centralizada (aunque las confirmaciones previas basadas introducen cierta complejidad). La secuenciación basada no requiere verificación de la firma del secuenciador, ni trampilla de escape ni consenso externo de PoS.

La secuenciación basada (sin configuraciones previas) está funcionando en las redes de prueba hoy. El primer paquete acumulativo basado en Taiko se está preparando para la red principal y se espera que esté disponible en el primer trimestre de 2024.

El discurso resumen basado

Uno de los superpoderes de Ethereum, y un diferenciador clave en comparación con las cadenas Solana o Cosmos BFT, es su capacidad de autocurarse después de un estancamiento (una consecuencia directa de sus garantías de vida). Este énfasis en la disponibilidad dinámica permite que la capa base sea extremadamente resistente y prospere incluso en un entorno altamente adverso; la resistencia a la Tercera Guerra Mundial es, de hecho, un objetivo de diseño explícito.

Si bien la sabiduría predominante es que los diseños de inclusión de fuerza permiten que los rollups aprovechen la vida del L1, la realidad es que los rollups no basados sufren una vida degradada (incluso con trampillas de escape).

En comparación con los rollups basados, los rollups no basados tienen garantías de liquidación más débiles (las transacciones tienen que esperar un período de tiempo de espera antes de la liquidación garantizada), están sujetos a MEV tóxico (debido a la censura del secuenciador a corto plazo durante el período de tiempo de espera) y, a menudo, requieren que los usuarios incurran en una penalización de tiempo y gas para salir (debido a una compresión subóptima de datos de transacciones no por lotes).

Como consecuencia, corren el riesgo de que los efectos de su red se restablezcan en respuesta a una salida masiva provocada por una falla en la vida del secuenciador (por ejemplo, un ataque del 51% a un mecanismo de secuenciación PoS descentralizado).

La idea principal detrás de los paquetes acumulativos basados es utilizar la separación entre el creador y el proponente L1 para incluir blobs L2 (incluida cualquier compresión) de forma nativa en lugar de usar un secuenciador. Desde esta perspectiva, heredan todo lo que la L1 tiene para ofrecer.

La implementación inicial de Arbitrum fue un resumen basado. El secuenciador se introdujo más tarde debido a la demanda de los usuarios de transacciones más rápidas. Las confirmaciones previas basadas resuelven esta tensión. Una vez que EigenLayer, las listas de inclusión y SSLE entren en funcionamiento (esperas más largas del proponente), los rollups basados podrán heredar las propiedades de vivacidad y resistencia a la censura de L1 sin comprometer la experiencia del usuario.

Esta visión es inclusiva y no competitiva con respecto a los paquetes acumulativos existentes y sus modelos de ingresos. En particular, los rollups basados conservan la opción de obtener ingresos de las tarifas de congestión L2 (por ejemplo, Tarifas base L2 al estilo de EIP-1559) a pesar de sacrificar potencialmente algunos ingresos de MEV.

Los rollups basados también conservan la opción de soberanía a pesar de delegar la secuenciación a la L1. Un rollup basado puede tener un token de gobernanza, puede cobrar tarifas base y puede utilizar los ingresos de dichas tarifas base como mejor le parezca (por ejemplo, para financiar bienes públicos con un espíritu de optimismo).

Ventajas de los paquetes acumulativos basados

1. Costos más bajos: la secuenciación basada no tiene gastos generales de gas. Ni siquiera es necesario verificar las firmas de secuenciadores centralizados o descentralizados. La simplicidad de la secuenciación basada reduce los costos de desarrollo, reduce el tiempo de comercialización y colapsa el área de superficie para la secuenciación y los errores de eclosión.
2. Alineación económica: No es necesario utilizar una solución middleware con token propio. Además, el MEV que se origina a partir de acumulaciones basadas fluye naturalmente hacia la base L1. Estos flujos fortalecen la seguridad económica de L1 y, en el caso de la quema de MEV, mejoran la escasez económica del token nativo L1. Esta estrecha alineación económica con la L1 puede ayudar a que las acumulaciones basadas en activos generen legitimidad.
3. Mejor neutralidad y vivacidad: la secuenciación basada hereda la descentralización de la L1 y naturalmente reutiliza la infraestructura del buscador-constructor-proponente de la L1 (lo que la hace más creíblemente neutral). La secuenciación basada disfruta de las mismas garantías de vida que la L1 (en contraste con los rollups no basados que sufren una vida degradada).
4. Simplicidad: la secuenciación basada es sumamente simple; significativamente más simple que incluso la secuenciación centralizada. La secuenciación basada no requiere verificación de la firma del secuenciador, ni trampilla de escape, ni token ni consenso externo de PoS.

Desventajas de los paquetes acumulativos basados

1. Pérdida de ingresos de MEV: los rollups basados renuncian a MEV a la L1, lo que limita sus ingresos a las tarifas base.
   • Contraargumento 1: MEV es una pequeña fracción de los ingresos acumulados hoy en día en comparación con las tarifas de congestión. Es razonable imaginar que esto seguirá siendo cierto en el futuro (a medida que las aplicaciones se vuelvan más conscientes de los mev y las técnicas de mitigación como el cifrado de umbral se generalicen). Por las mismas razones, también es posible que los ingresos de los MEV disminuyan en el futuro.
   • Contraargumento 2: En general, convertirse en una empresa basada puede, de hecho, aumentar los ingresos generales de los rollups. El panorama de los rollups es plausiblemente en el que el ganador se lleva la mayor parte (debido a los fuertes efectos de red de la componibilidad sincrónica) y el rollup ganador puede aprovechar la seguridad mejorada, la descentralización, la simplicidad y la alineación de los rollups basados para lograr dominio y, en última instancia, maximizar los ingresos.
2. Es más difícil compartir costos entre paquetes acumulativos: la secuenciación compartida externa le brinda “gratis” la capacidad de compartir los costos de la publicación de datos , por ejemplo, comprar un solo blob para albergar los datos de dos paquetes acumulativos, lo que reduce los costos en comparación con la compra de dos blobs separados.
   • Contraargumento: es posible que el proponente L1 pueda compartir los costos entre todos los paquetes acumulativos basados para los que secuencia. Llevando esto un paso más allá, también es posible que el proponente L1 comparta los costos con otros servicios, incluidos los secuenciadores compartidos.
3. El rendimiento aún está limitado por el L1: todos los paquetes acumulativos comparten un Ethereum L1 único y de rendimiento limitado. No todos pueden lograr sus tps al mismo tiempo, ya que los datos están en cadena.
   • Contraargumento 1: Esto es cierto para todos los resúmenes. Si los rollups basados ganan una tracción significativa, entonces el L1, hasta cierto punto, evolucionará para cumplir con los requisitos de los rollups basados.
   • Contraargumento 2: 4844 (previsto para el primer trimestre de 2024) desacoplará los precios de DA de la competencia de la capa de ejecución. Ethereum con Danksharding puede escalar su rendimiento de DA tan alto como lo permita el ancho de banda de Internet.
4. La máquina de estado compartida es aún mejor para la atomicidad: todavía no obtienes las mismas garantías de atomicidad que al realizar transacciones en una máquina de estado compartida (por ejemplo, completamente en Ethereum L1), ya que el proponente no es quien ejecuta las transacciones.
   • Contraargumento 1: la componibilidad asíncrona atómica está sobrevalorada.
   • Contraargumento 2: si la atomicidad resulta deseable en un contexto asíncrono, entonces <a href="https://hackmd.io/@EspressoSystems/SharedSequencing#Cryptographically-guaranteed-cross-rollup-atomic-bundles">paquetes atómicos + <a href="https://hackmd.io/ @EspressoSystems/SharedSequencing#Cryptoeconomically-assured-cross-rollup-atomicity">las garantías criptoeconómicas probablemente sean lo suficientemente buenas para la mayoría de los casos de uso.
5. Las preconferencias basadas conllevan suposiciones de confianza adicionales: dado que las transacciones no preconferenciadas (dentro del paquete acumulativo) se ponen en cola hasta que se confirma el siguiente espacio preconferenciado, a menos que el 100 % de los validadores también participen como confirmadores previos, las garantías de vida de un paquete acumulado con preconferencias basadas son estrictamente peor que el de un paquete acumulativo basado que no usa configuraciones previas (y por lo tanto estrictamente peor que la capa base).
   • Contraargumento 1: En la práctica, la diferencia debería ser insignificante. Las preconferencias basadas solo comienzan a funcionar si tiene entre el 20% y el 30% del conjunto de validadores comprometidos como preconfirmadores, ya que deben ser preconferidos suficientes validadores L1 para tener al menos una preconferencia en la anticipación con alta probabilidad. Hoy en día, la cadena de balizas tiene al menos 32 proponentes en la mira hacia el futuro. Esto significa que si el 20% de los validadores son preconferidos, habrá una preconferencia con una probabilidad de al menos 1 - (1 - 20%)^32 ≈ 99,92%. Si el 30% de los validadores son preconferidos, esto aumenta a 1 - (1 - 30%)^32 ≈ 99,999%. Si le preocupa que las reorganizaciones o las preconferencias se desconecten aleatoriamente, puede hacer los cálculos para saber si hay al menos 2 o 3 (o n) preconferencias en la anticipación para cualquier porcentaje determinado de validadores que participen como preconferencias. Hay un porcentaje mucho menor que 100, para el cual la diferencia en las garantías de vida es insignificante (aunque ese número preciso puede variar dependiendo de con quién hables). Este es un mundo aparte de depender de un consenso externo para la vida.
   • Contraargumento 2: SSLE (Elecciones de Líder Secreto Único) permitirá aumentar drásticamente la anticipación (por ejemplo, a 1024 puestos), lo que elimina efectivamente esta preocupación. Tenga en cuenta que, según SSLE, los preconferidores pueden anunciar (fuera y dentro de la cadena) pruebas de conocimiento cero de los que son preconferidores en sus respectivos espacios sin revelar más información sobre su clave pública de validación.
   • Contraargumento 3: Si bien SSLE soluciona este problema, ni siquiera necesitamos esperar a SSLE, ya que en realidad podemos aumentar las anticipaciones de los proponentes de forma independiente. Y es mucho más fácil hacerlo.

En resumen

El diseño del protocolo acumulativo es confuso. No existe un nivel "correcto" de descentralización o seguridad. Cualidades como la resistencia a la censura no pueden definirse exhaustivamente.

Hoy en día, los paquetes acumulativos se ven impulsados a adoptar middleware blockchain con consenso externo para descentralizar su secuenciación y mejorar la interoperabilidad entre dominios. Los rollups basados ofrecen una alternativa más simple, más neutral y más alineada económicamente.

Los rollups basados en confirmaciones previas rápidas prueban la hipótesis de que los desarrolladores de aplicaciones (y sus usuarios) se preocupan por aprovechar al máximo la vitalidad de Ethereum y los superpoderes de neutralidad creíble si pueden hacerlo de una manera que no les obligue a sacrificar la eficacia (en este caso , la velocidad de confirmación). .

Con preconfs basadas, las compensaciones entre la experiencia del usuario y la experiencia del usuario se disuelven.

Descargo de responsabilidad:

1. Este artículo está reimpreso de [ <a href="https://hackmd.io/@sacha/based-rollup-thesis"> hackmd]. Todos los derechos de autor pertenecen al autor original [sacha ]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Sanv Nurlae y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Sanv Nurlae. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.