¿Por qué los rollups basados son el único futuro de Ethereum? 6 años después de que Ethereum diera a conocer su hoja de ruta centrada en el rollup, la visión está funcionando en gran medida: las tarifas de transacción han bajado, el rendimiento es mayor y el modelo de seguridad central se ha mantenido firme. 1. Sin embargo, la interoperabilidad sigue siendo un desafío sin resolver. A medida que se lanzan más rollups, más usuarios, aplicaciones y liquidez se dividen en entornos aislados. En lugar de una gran red Ethereum, tenemos docenas de pequeñas islas. Los puentes los conectan, pero agregan latencia, riesgo y fricción. Esta fragmentación se ve agravada por el hecho de que cada rollup hoy en día ejecuta su propio secuenciador centralizado, el sistema que decide el orden de las transacciones en un bloque, quién entra primero y también quién captura las ganancias de MEV. Debido a que cada secuenciador funciona de forma independiente, los rollups se ejecutan en diferentes líneas de tiempo. Las apps en rollups separados no pueden interactuar atómicamente, en el mismo bloque al mismo tiempo, lo que fractura la liquidez y debilita la componibilidad. 2. Los secuenciadores centralizados tenían sentido desde el principio. Permitieron que los equipos se lanzaran rápidamente al poner en marcha un servidor, redujeron la ejecución frontal a través del flujo de pedidos privados, proporcionaron confirmaciones previas casi instantáneas para una experiencia de usuario fluida y ofrecieron flexibilidad operativa. Pero estos beneficios vinieron con compensaciones. • El tiempo de inactividad del secuenciador ha dejado fuera de línea a rollups enteros durante horas. • Un secuenciador comprometido podría reordenar las transacciones y drenar millones. • No pueden escalar de forma neutra y descentralizada y provocan un problema de fragmentación. Cuando lo sumas todo, los secuenciadores centralizados fueron un punto de partida útil, pero no pueden llevar los rollups a donde necesitan ir. 3. El siguiente paso son los rollups basados. En lugar de operar su propio secuenciador, un rollup basado utiliza validadores de capa 1 (Ethereum, Celestia) para secuenciar (ordenar transacciones). Por eso se llama "basado": su secuenciación está ligada directamente a la capa base. Este cambio restaura la neutralidad. Ningún equipo de rollup individual controla el flujo de transacciones. Todos los rollups que están "basados" comparten la misma capa de secuenciación en todo Ethereum, lo que significa que pueden interactuar en el mismo bloque al mismo tiempo. El resultado es una red unificada: • La liquidez se mantiene concentrada en lugar de dividirse en silos. • La componibilidad es sincrónica, por lo que las apps en diferentes rollups pueden interactuar atómicamente. • El control es neutral, asegurado por los validadores de Ethereum en lugar de un servidor centralizado. 4. ¿Qué otros problemas resuelven los rollups basados en rollups? • DeFi: La liquidez se mantiene unificada bajo la capa de secuenciación de Ethereum. Las operaciones, los préstamos y las liquidaciones se realizan en L2, pero comparten el mismo orden base, lo que mantiene los mercados profundos y concentrados en lugar de dividirse o perderse ante Solana. • Usuarios: los límites del rollup se desvanecen. Con los contratos de depósito compartidos y las transferencias nativas de L2 a L2, los activos se mueven sin problemas a través de los rollups, sin necesidad de volver a través de L1 o preocuparse por "en qué cadena" se encuentra. • Desarrolladores: Vuelve la componibilidad. Las aplicaciones en diferentes acumulaciones pueden interactuar atómicamente en el mismo bloque, lo que permite préstamos entre acumulaciones, comercio y estrategias complejas que los secuenciadores centralizados no pueden admitir. 5. ¿No están haciendo lo mismo los secuenciadores compartidos? Esos 2 enfoques resuelven la fragmentación a escalas muy diferentes. Las pilas de rollup como Arbitrum Orbiy, Optimism Superchain y zkSync Elastic Chain están experimentando con secuenciadores compartidos que actúan como mini-hubs. Por lo tanto, la liquidez y los usuarios permanecen atrapados dentro de ese clúster de ecosistemas, en lugar de compartirse en Ethereum en su conjunto. Los rollups basados van más allá. En lugar de centros a nivel de ecosistema, utilizan el propio Ethereum como secuenciador universal. Eso significa que los pools de liquidez se fusionan en todos los rollups. Los secuenciadores compartidos reducen la fragmentación localmente, mientras que los rollups basados la resuelven globalmente en toda la red Ethereum. 6. Ethereum básicamente se convirtió en un secuenciador, pero ¿cómo? Durante la mayor parte de su historia, Ethereum solo pudo secuenciar sus propias transacciones. Los validadores recopilaron transacciones del mempool, las ordenaron y construyeron bloques. Si cada rollup hubiera volcado sus transacciones directamente en ese proceso, el resultado habría sido un caos: conflictos, espacio de bloque desperdiciado y transacciones fallidas. El gran avance llegó con la separación Proposer-Builder (PBS). Antes de PBS: Los validadores tenían que hacer todo, recopilar transacciones, ordenarlas y construir el bloque. Agregar tráfico acumulativo habría sido abrumador. Con PBS: El trabajo está dividido. • Los validadores (proponentes) simplemente firman los bloques, mientras que los constructores especializados hacen el trabajo pesado. • Los constructores recopilan transacciones (de Ethereum y rollups basados en Ethereum), las ordenan y producen bloques completos. • Los validadores solo firman el encabezado del bloque más valioso, sin necesidad de ver su contenido. Desde la perspectiva del validador, nada cambió, pero en la práctica, Ethereum se convirtió en el secuenciador neutral para cada rollup basado. 7. Pero, ¿quién captura MEV en el "mundo basado"? MEV, la ganancia de ordenar transacciones, que una vez fluyó a un secuenciador centralizado ahora va a la tubería PBS de Ethereum. Los constructores ensamblan bloques rentables, los validadores los firman y el MEV es capturado allí, no por el equipo de rollup. Sin embargo, MEV no siempre se queda con validadores y constructores. Otras partes de la pila pueden capturarlo directamente: • Los DEX con reconocimiento de MEV como CoWSwap o Uniswap v4 subastan oportunidades de arbitraje y devuelven ganancias a los proveedores de liquidez. • Herramientas como MetaMask Protect o Rabby enrutan las transacciones de forma privada a los constructores, protegiendo a los usuarios de la ejecución frontal y, a veces, redistribuyendo parte del MEV. Estos mecanismos reducen el arbitraje dañino, pero MEV no desaparece, simplemente cambia de manos y forma. 8. Con un nuevo tipo de rollup, viene un nuevo tipo de economía. Este cambio replantea la economía de los rollups. Muchos dudan en ir "basados" hoy porque capturan los ingresos de MEV a través de sus secuenciadores centralizados, intercambios de ejecución anticipada o arbitrar precios entre lugares. Pero a largo plazo, el flujo de ingresos más duradero son las tarifas de ejecución, el peaje que pagan los usuarios para ejecutar transacciones en la máquina virtual del rollup. Mostremos un ejemplo hipotético: Rollup con su propio secuenciador (hoy): • Tarifas de ejecución = $ 2 millones / mes • MEV = $ 1 millón / mes • Total = $ 3 millones / mes Mismo rollup que un rollup basado (futuro): • Validadores MEV → Ethereum = $0 • Tarifas de ejecución (de efectos de red unificados) = $ 10 millones / mes • Total = 10 millones de dólares al mes Ese es el Gambito MEV: sacrificar el peón (secuenciador MEV) para ganar el premio mayor (ingresos de ejecución mucho más altos). Los rollups basados evitan pelear por MEV y, en cambio, se enfocan en escalar su capa de ejecución. 9. ¿Puede Ethereum manejar esta capacidad? La pregunta obvia es: si cada rollup se conecta a Ethereum como su secuenciador, ¿puede Ethereum L1 realmente manejarlo? En este momento, Ethereum se ejecuta en ranuras de 12 segundos. El tiempo de franjas horarias es la verdadera limitación. Con ranuras de 12 segundos, la UX se siente lenta. La investigación muestra que Ethereum probablemente podría reducir esto a ~ 4 segundos sin sacrificar la descentralización, los validadores aún pueden ejecutarse en Internet doméstico o incluso en Raspberry Pis. Las preconfirmaciones sin confianza son clave para que Ethereum compita con los secuenciadores centralizados en velocidad. Este sistema utiliza proponentes que apuestan garantías y firman garantías para incluir transacciones, lo que puede resultar en confirmaciones de ~ 100 ms. Esto es significativamente más rápido que los tiempos de bloque actuales e incluso más rápido que algunas configuraciones de "supercadena", proporcionando velocidades similares a la latencia de Internet. 10. Sin embargo, esta gran carga de trabajo es demasiado para los validadores domésticos. APS (Attester Proposer Separation) divide el trabajo para resolver esto: los certificadores verifican y publican transacciones válidas, mientras que los proponentes/constructores construyen bloques y gestionan las confirmaciones previas. Inicialmente, esto se hace a través de puertas de enlace, pero eventualmente, APS y PBS consagrado permitirán a Ethereum proporcionar de forma nativa preconfirmaciones rápidas y sin confianza y secuenciación compartida. 11. Tela: Construyendo los estándares. Incluso con APS y PBS en su lugar, todavía existe la cuestión de la plomería. Hoy en día, todos los equipos de acumulación basados tienen que reinventar las API para las configuraciones previas, ajustar las canalizaciones de PBS, configurar registros y controlar el uso compartido de blobs. Si no se controla, esto corre el riesgo de fragmentarse en "mini estándares" incompatibles. @fabric_ethereum es el esfuerzo de coordinación para evitar eso. No lanza un rollup o token. En su lugar, ofrece componentes mínimos de código abierto, que incluyen: • API de compromisos para pre-confs • Contrato de Registro Universal para la responsabilidad del secuenciador • Blob compartido e infraestructura de puente Con el respaldo de equipos como @taikoxyz, @Scroll_ZKP, @Optimism, @arbitrum, @base, @Spire_Labs y más, Fabric está emergiendo como el punto de partida para la infraestructura de acumulación basada, alineando a los equipos en estándares compartidos para que el ecosistema se amplíe en conjunto, no en separado.