Algunos amigos estaban discutiendo sobre Based Rollup, principalmente desde una perspectiva de seguridad. Aquí, compartiré mis puntos de vista sobre Based Booster Rollup desde la perspectiva de las relaciones L1 y L2 y la construcción de aplicaciones.
La idea detrás de Based Rollup es sencilla: los usuarios envían transacciones L2 directamente a L1, donde L1 se encarga de la clasificación y empaquetado. Sin embargo, L1 no verifica la validez de las transacciones, solo asegura el orden y la disponibilidad de las transacciones. L2 es una capa de ejecución puramente, procesando las transacciones L2 empaquetadas en L1. Si esta configuración te resulta familiar, es porque se asemeja al modelo de Inscripción. De hecho, puedes pensar en el Indexador de Inscripción como L2 en este contexto, un punto que discutí en mi artículo “¿Es Inscripción un Bug o una Característica?”
Booster Rollup adopta un enfoque diferente: ¿cómo puede L2 leer directamente el estado de L1 a través de contratos? Dado que Based Rollup ya está ejecutando transacciones L2 en L1, ¿por qué no hacer que también procese transacciones L1? De esta manera, los estados de L1 y L2 pueden existir dentro de un árbol de estado unificado, permitiendo que los contratos L2 accedan directamente al estado de L1.
Esto ha llevado a proyectos a fusionar Based Rollup y Booster Rollup, comúnmente referidos como Based Booster Rollup (BBR), como se ve en proyectos como #Taiko .
Antecedentes de BBR
El creciente interés en BBR se debe en gran medida a la fragmentación actual en las soluciones L2 principales de Ethereum. Esta fragmentación ocurre entre L1 y L2, y entre los propios L2. Las soluciones L2 actuales operan de manera similar a un Alt-L1, dependiendo de oráculos para acceder a los datos de L1, puentes de activos y requiriendo cambio de red en las billeteras. Además, el vínculo entre L1 y L2 no siempre es fuerte, y los L2 podrían implementar fácilmente sus propios mecanismos de consenso para convertirse en Alt-L1s, operando de manera independiente.
¿Reemplazar todas las soluciones L2 actuales con Based Rollup solucionaría esta fragmentación? #Optimism y #Arbitrum podrían argumentar que es factible ya que las principales soluciones L2 tienen mecanismos de Inclusión Forzada que eliminan al Sequencer, permitiendo a los usuarios enviar transacciones directamente a L1 y lograr Based Rollup.
Sin embargo, mientras Arb y Op envían transacciones a L1 en tiempo real para clasificación, siguen permaneciendo fragmentados, ya que solo reconocen sus propias transacciones. La clave para resolver esta fragmentación con Based Rollup radica en tener un protocolo que permita transacciones o datos compartidos entre L2s, con datos que:
1. Tiene un formato independiente de la plataforma o implementación, definido a nivel de L1, ya que diferentes L2s varían en cuentas y máquinas virtuales.
2. Es aceptado por múltiples L2s.
Por lo tanto, el diseño del protocolo debe venir primero, creando un formato de datos compartido en el que los L2s puedan estar de acuerdo, y dejando solo los datos esenciales del protocolo en la cadena, con la ejecución y verificación ocurriendo fuera de la cadena. Esta dirección ha demostrado ser desafiante ya que los desarrolladores de Ethereum generalmente diseñan protocolos utilizando contratos inteligentes en lugar de formatos de datos. El principal intento aquí fue Ethscriptions durante la anterior locura de Inscripción.
De BBR a BBSR: L2 Apilable
Una vez que se aborden los problemas de intercambio de datos, la experiencia del usuario se convierte en una preocupación. Enviar todas las transacciones a L1 se parecería a usar L1 en términos de tarifas de gas y tiempo de confirmación. Para mejorar esto, algunos han diseñado protocolos de pre-confirmación para Based Rollup, aunque implementar tales protocolos efectivamente reintroduce a los Sequencers, deshaciendo algunas de las simplificaciones.
Esta contradicción surge de la confusión de tres tipos de transacciones:
1. Transacciones L1 enviadas y ejecutadas directamente por L1.
2. Transacciones L1.5 enviadas a L1 pero no ejecutadas inmediatamente por L1, facilitando protocolos de intercambio de datos L2.
3. Transacciones específicas de L2 enviadas a Sequencers de L2 para pre-confirmación y ejecución.
Based Rollup solo es relevante para los dos primeros tipos, mientras que el tercero cae bajo el modelo actual de Sequencer Rollup. Estos pueden coexistir. Imagina un modelo Rollup donde:
1. El Sequencer sincroniza y ejecuta automáticamente todas las transacciones L1 (incluidas las L1.5) en el orden definido por L1.
2. El Sequencer recibe y mezcla transacciones L2 con transacciones L1 para clasificación y ejecución.
En esta configuración, 1 habilita las funcionalidades de Based y Booster, mientras que 2 logra una confirmación rápida de transacciones L2 sin sacrificar la experiencia del usuario. Llamaré a esto el modelo L2 Apilable, donde L2s se apilan sobre L1 e incorporan todas las transacciones y estados de L1. Este enfoque está siendo implementado por Rooch Network.
Asegurando la Disponibilidad de Datos (DA) para Transacciones L2: ¿Rollup o Rollout?
Con este modelo, se vuelve redundante para L2 empaquetar sus transacciones para enviarlas a L1, ya que ejecutarían repetidamente los mismos datos. Por lo tanto, la solución de Rooch utiliza Rollout en lugar de Rollup, conservando el valioso espacio de bloque de L1 al dejarlo para las transacciones L1 y L1.5, mientras las transacciones L2 se expanden en espacios de bloque alternativos, beneficiando a todo el ecosistema.
Práctica BBSR/L2 Apilable del Ecosistema Bitcoin
Esta descripción hasta ahora es desde el punto de vista de Ethereum. Sin embargo, como la primera práctica BBSR o L2 apilable en Bitcoin, Rooch aprovecha algunas ventajas únicas.
Bitcoin L2 carece de contratos inteligentes Turing-completos, lo que hace que el modelo Based Rollup sea ideal, ya que solo requiere DA sin permisos. Los proyectos de Bitcoin, como Colored Coins, RGB, Taproot Assets y Ordinals Inscription, han adoptado durante mucho tiempo protocolos basados en estructuras de datos, encajando bien dentro del amplio marco CSV (Validación del Lado del Cliente) y ejemplificando transacciones típicas L1.5. Si los proyectos de Ethereum adoptan Based L2, sus protocolos podrían parecer similares.
En el modelo BBSR basado en Bitcoin de Rooch:
1. Los usuarios envían tanto transacciones L1 como L1.5 a Bitcoin.
2. Rooch sincroniza todas las transacciones L1, procesa UTXOs, identifica transacciones con datos de protocolo y las ejecuta con módulos específicos (por ejemplo, módulo ord para transacciones de Inscripción).
3. Los usuarios envían transacciones L2 directamente al Sequencer de Rooch, con resultados combinados en un árbol de estado completo que los contratos de aplicación pueden utilizar plenamente.
Este modelo admite dos tipos de transacciones: transacciones de protocolo público (Based, en L1) y transacciones específicas de la aplicación (ordenadas por el Sequencer), combinando beneficios de Booster con protocolos sin permisos y mejoras en la experiencia del usuario.
El diseño del protocolo público, que requiere tiempo y práctica para validar y alcanzar consenso, tiene un entorno de prueba conveniente con Rooch, donde diseñar un protocolo de aplicación de Bitcoin es tan simple como definir el formato y desplegar el contrato Move correspondiente.
El Valor de L1 como un Bus de Datos Global
Desde DeFi Summer, la industria cripto ha buscado aplicaciones no DeFi. La reciente locura por la Inscripción y las discusiones sobre Based Rollup revelan un redescubrimiento del valor de L1 como un bus de datos. En sistemas descentralizados, los buses de datos permiten desacoplar sistemas, una condición clave para operaciones sin permisos. Las aplicaciones solo necesitan actualizar los protocolos de transacción a transacciones específicas de la aplicación para tener un impacto mínimo en los sistemas existentes.
Este artículo se ha centrado en BBR desde una perspectiva de ecosistema y aplicación. Más adelante, exploraremos la seguridad de BBR, la interoperabilidad L1-L1.5-L2 y temas relacionados con más detalle.