Acumulación de valor para marcos Rollup y RaaS (¿van a CERO?)

Si el futuro consiste en una economía en cadena de miles de acumulaciones, definitivamente estamos en la línea de tiempo correcta en el presente. Desde la pila Optimism y el kit de desarrollo de la cadena Polygon hasta Caldera y Stackr, en los últimos meses se ha visto llegar al mercado una variedad de marcos Rollup y proveedores de Rollups-as-a-Service (RaaS). Estos marcos ofrecen bases de código modulares (a menudo de código abierto) para los diferentes componentes de un paquete acumulativo, lo que permite a los desarrolladores elegir entre una variedad de opciones personalizadas para cada capa de la pila.

Pero, ¿cómo acumulan valor estos proveedores? ¿O acumulan algún valor? como argumentó Neel Somani recientemente en su charla “Las soluciones RaaS van a cero” en Modular Summit.

En esta publicación de blog, analizamos algunos de sus argumentos y también exploramos la intrincada dinámica de acumulación de valor para los marcos acumulativos y los proveedores de RaaS. Desde las capas individuales hasta las supercadenas, desentrañamos los mecanismos ocultos detrás de la creación y captura de valor por parte de marcos acumulativos y proveedores de RaaS.

Rollups frente a Rollup Framework frente a RaaS

Los rollups son aplicaciones que realizan ejecución fuera de la cadena y publican los datos de ejecución en otra cadena de bloques (host). Al hacerlo, obtienen las propiedades de seguridad de la cadena de host. La aplicación acumulativa en sí podría ser solo una función de transición de estado única, o podría ser una cadena de bloques separada para la cual un grupo de nodos mantiene el estado canónico.

Un marco de resumen es una base de código prediseñada que implementa los componentes esenciales de un resumen. En lugar de crear un paquete acumulativo desde cero, los desarrolladores pueden utilizar estas bases de código existentes (a menudo empaquetadas como SDK) y personalizarlas según sus necesidades específicas. Ejemplos de marcos acumulativos de código abierto incluyen OP Stack y Arbitrum Orbit.

Los protocolos Rollups-as-a-Service, o RaaS, son contenedores sin código creados sobre marcos acumulativos existentes. Permiten a los desarrolladores implementar rápidamente un paquete acumulativo desde cero seleccionando funciones personalizadas en los menús desplegables. Las empresas de RaaS suelen encargarse de la secuenciación de los paquetes acumulativos implementados y ofrecen servicios de consultoría adicionales.

donde va el dinero

Para comprender cómo el valor entra y sale de toda la pila, es importante comprender primero la arquitectura de un paquete acumulativo y cómo interactúan las diferentes capas entre sí. En términos generales, hay tres capas que constituyen una pila acumulativa:

1.Ejecución: esta capa ejecuta las transacciones aplicando la función de transición de estado (STF) en el estado existente del resumen. Dependiendo de qué tan "centralizado" esté el paquete acumulativo, un nodo de ejecución podría tener una variedad de responsabilidades, desde ordenar transacciones y ejecutarlas hasta publicarlas en L1 y crear pruebas de fraude/validez.

La capa de ejecución es la capa "de cara al usuario", donde el dinero ingresa a la pila acumulada. A los usuarios se les cobra una tarifa de transacción (gas), que generalmente es un margen sobre los diversos costos que la capa de ejecución tiene que pagar (más sobre esto más adelante). Esta capa también puede extraer valor adicional de los usuarios ordenando transacciones de ciertas maneras (también conocido como MEV: Valor máximo extraíble).

Desglose de la capa de ejecución operada por un secuenciador rollup centralizado. Sus responsabilidades incluyen: ordenar transacciones, publicar datos de transacciones en la capa DA, crear pruebas, publicar pruebas y cambios de estado en la capa de liquidación.

Desglose de la capa de ejecución operada por un secuenciador rollup centralizado. Sus responsabilidades incluyen: ordenar transacciones, publicar datos de transacciones en la capa DA, crear pruebas, publicar pruebas y cambios de estado en la capa de liquidación.

Desglose de la capa de ejecución operada por un secuenciador rollup centralizado. Sus responsabilidades incluyen: ordenar transacciones, publicar datos de transacciones en la capa DA, crear pruebas, publicar pruebas y cambios de estado en la capa de liquidación.

2.Liquidación: esto incluye verificar la validez/pruebas de fraude y "definir" el estado canónico del paquete acumulativo (en el caso de paquetes acumulativos de contratos inteligentes). La liquidación suele ser gestionada por una capa unificada y de alta seguridad como Ethereum. Los marcos acumulativos también pueden construir su propia capa de liquidación.

La liquidación no es una capa de la pila de captura de valor muy alto, ya que los costos de verificación suelen ser escasos. Optimism solo paga ~$5 por día a Ethereum para su liquidación. Una capa de liquidación competitiva costaría incluso menos. (como también se destaca en Los paquetes acumulativos como servicio van a cero)

3. Disponibilidad de datos: DA incluye la transmisión de los datos de las transacciones solicitadas al resto de la red (a veces también denominada publicación de datos). Garantiza que cualquiera pueda reconstruir sin permiso el estado acumulativo simplemente aplicando los datos de la transacción transmitida a algún estado previamente finalizado.

Los costos de DA constituyen una parte importante de todos los costos acumulativos. Publicar datos en una capa altamente segura como Ethereum puede resultar bastante costoso. Protocolos como Celestia, Avail y EigenDA están desarrollando activamente alternativas DA más baratas y rápidas. Los marcos acumulativos también podrían considerar la construcción de su propia capa DA, pero un DA fragmentado tiene altos costos de arranque y hace que la interoperabilidad sea más compleja.

Flujo de valor de alto nivel

Podría ser útil pensar en la capa de Ejecución como un modelo B2C y las capas de Liquidación y DA como modelos B2B:

La capa de ejecución compra espacio en bloque de la capa DA y vende sus servicios de ejecución directamente al usuario final (cliente). También compra servicios de verificación y puentes de la capa de Liquidación.

La capa DA vende espacio en bloque a otra empresa: la capa de ejecución

La capa de liquidación proporciona servicios de liquidación a otra empresa: la capa de ejecución

En una configuración de este tipo en mercados competitivos, la mayor parte de la captura de valor ocurre directamente desde el usuario final en la capa de ejecución de la pila, por lo que tiene sentido desglosarlo más y analizar sus flujos de valor de forma independiente.

Capa de ejecución: un modelo económico B2C

La capa de ejecución genera ingresos cobrando a los usuarios por cada transacción y paga los costos operativos a las otras empresas (capas) en la pila.

Ingresos: El valor entrante se puede clasificar de la siguiente manera:

Costos de gas pagados por los usuarios finales por transacción

MEV intradominio

MEV entre dominios (si el marco proporciona secuenciación para múltiples acumulaciones en la misma capa DA). De lo contrario, podría ser difícil de extraer)

MEV depende del flujo de transacciones (el valor "extraíble" será diferente para cada conjunto de transacciones) y, a menudo, es difícil de predecir de antemano. Los costos del gas cobrados a los usuarios suelen ser un margen sobre los costos predecibles combinados.

Costos: Las salidas de valor de la capa de ejecución son las siguientes:

• Gastos generales operativos del nodo

• Costos de ejecución (cómputo)

• Costos de prueba (validez/pruebas de fraude)

• Costos de publicación de datos (variable según la congestión en la capa DA)

Fuente: Comprensión del valor acumulativo acumulado por Sanjay Shah | Capital Eléctrica

A menudo, todas las responsabilidades de la capa de ejecución recaen en un nodo secuenciador centralizado. Este nodo único acumula todos los ingresos de los usuarios y es responsable de pagar el DA y los costos de liquidación. En otras ocasiones, la configuración puede tener diferentes nodos para diferentes responsabilidades:

• Los secuenciadores ordenan transacciones y publican datos en la capa DA. Ellos "ganan" las tarifas de transacción pagadas por los usuarios y pagan los costos generales de secuenciación y publicación de datos. La secuenciación también se puede realizar mediante un conjunto preseleccionado de secuenciadores o secuenciadores descentralizados como Espresso. Los secuenciadores también son responsables de publicar cambios de estado en la capa de liquidación y pagar los costos de liquidación.
• Los nodos probadores son responsables de generar pruebas. Puede ser un probador central o un conjunto descentralizado de nodos de prueba. Sus costos comprenden los gastos generales de generación de pruebas. Dependiendo de la configuración, los probadores "venden" las pruebas al secuenciador o las publican directamente en la capa de liquidación.
• Los rollups también pueden tener otros nodos completos (o nodos ligeros de verificación completa) que ejecutan todos los lotes de transacciones y mantienen el estado canónico del rollup. Estos nodos completos no necesariamente acumulan ingresos directos, pero capturan valor indirectamente al mantener el token de gas nativo del paquete acumulativo.

Lo anterior es una amplia diferenciación de las responsabilidades de los diferentes nodos. Qué nodo asume qué tareas puede diferir según cómo el equipo de resumen arquitectura su configuración. En aras de la simplicidad en este blog, nos limitaremos a una configuración de secuenciador centralizado donde un nodo realiza todas las tareas de ejecución requeridas.

La pregunta entonces es: si la capa de ejecución genera el mayor valor, ¿qué participante de la pila está mejor posicionado para capturarlo?

¡Cualquiera que ejecute el nodo de secuenciación y realice las diversas actividades asociadas con él!

Este puede ser el propio equipo de resumen. O, como se mencionó al principio del artículo, los proveedores de RaaS a menudo manejan la secuenciación de los paquetes acumulativos implementados que los utilizan. De hecho, esta es la parte mayoritaria de los ingresos de los proveedores de RaaS.

(¿Cómo) RaaS genera dinero?

Hay tres áreas principales que un RaaS puede capturar valor:

Alojamiento del secuenciador: el proveedor de RaaS ejecuta el secuenciador y las actividades asociadas para el paquete acumulativo. Es una división del trabajo en la que el equipo de desarrollo aporta la innovación (la aplicación que están creando) y el proveedor de RaaS hace todo lo demás. El secuenciador ordena transacciones, publica datos en L1 y crea pruebas cuando sea necesario.

Infraestructura adicional: Exploradores de bloques, puentes, etc.

Soporte dedicado: consultoría y asociación en decisiones de infraestructura (cómo secuenciar, MEV, etc.) + otro soporte técnico

RaaS es similar a un negocio B2B SaaS tradicional en el que la empresa puede cobrar a sus clientes una tarifa fija o una tarifa híbrida escalonada en función de los servicios adquiridos y el uso (número de transacciones de usuario final para un resumen, por ejemplo).

RaaS también podría proporcionar una integración con un secuenciador compartido como Espresso. Sin embargo, en este caso, perderían los ingresos del secuenciador, que constituye una parte importante de las ganancias de RaaS. Por lo tanto, estas asociaciones requieren una participación contractual en los beneficios entre el secuenciador compartido y el proveedor de RaaS.

Pero si RaaS es un contenedor construido sobre un marco acumulativo existente, también debe compartir los ingresos con ellos, ¿verdad?

Bueno, no necesariamente.

La mayoría de los marcos acumulativos lanzados hasta ahora han sido de código abierto y no tienen permiso para desarrollarse. Los proveedores de RaaS pueden usar el marco sin permiso para crear un contenedor sin código encima y no están obligados a compartir ninguna ganancia con el marco subyacente.

¿Pueden tener un acuerdo contractual con el marco acumulativo para compartir ganancias?

Pueden, pero si lo hacen:

1. Pierden parte de sus propios beneficios.
2. Otro competidor, RaaS, podría optar por no compartir ganancias con el marco acumulativo y sería económicamente dominante a largo plazo.

Por lo tanto, en teoría, para que el proveedor de RaaS sobreviva, la decisión racional es NO compartir las ganancias con el marco subyacente.

Entonces, si los proveedores de RaaS no comparten las ganancias, ¿cómo acumula algún valor un marco acumulativo?

Si alguien puede crear un paquete acumulativo sin permiso utilizando el marco de código abierto, ¿es siquiera una decisión económicamente viable desarrollar un marco acumulativo de código abierto en primer lugar?

La respuesta no es tan sencilla. Para que un marco acumulativo sea "económicamente viable", debe generar valor sostenible a largo plazo. Idan Levin compartió un buen modelo mental para pensar cómo se puede hacer esto. Ampliemos ese modelo aquí. Hay tres formas principales en que los marcos acumulativos pueden acumular valor:

Acumulación de valor indirecto: si el marco es bueno, cada vez más equipos lo utilizarán. Esto atraerá la atención de los desarrolladores y una mayor participación en el ecosistema. Atraer la mentalidad compartida siempre es positivo, ya que ayudará al equipo marco a desarrollar aún más las herramientas. Cualquier mejora que realice cualquiera de los equipos se puede incorporar al marco de OG. Esto crea un bucle de refuerzo positivo para todo el sistema.

Acumulación de valor semidirecto: algunos rollups que se construyen sobre el marco podrían recibir incentivos para compartir ingresos con la red del marco. Por ejemplo, Base tiene actualmente un acuerdo con OP Stack en el que comparten parte de la tarifa de secuenciación con Optimism.

¿Por qué se les incentiva a hacerlo?

Porque Base no tiene el ecosistema de desarrolladores necesario para mantenerse al día con el crecimiento y desarrollo del marco OP. Imagínese si el marco OP cambia uno de los módulos por completo, podrían optar por no brindar soporte de desarrollador a Base para mantenerse al día con los cambios.

Además, ser parte de la 'Superchain' proporciona efectos de red como la componibilidad cruzada que cadenas como Base podrían encontrar útiles (y esto podría tener el requisito de compartir ingresos con Optimism).

Una advertencia importante aquí es que es posible que los incentivos de los rollups y los marcos rollup no siempre estén alineados. En cualquier momento, el paquete acumulativo podría optar por seguir su propio camino personalizando el marco y eliminando cualquier acuerdo de reparto de ingresos.

1. Acumulación de valor directo: a través del propio paquete acumulativo del marco (por ejemplo, Optimism mainnet) creado utilizando el mismo marco (por ejemplo, OP Stack). El gas podría estar en el token nativo (por ejemplo, OP) y todo el MEV de este resumen se acumularía para el equipo marco. Además, el equipo también podría 'extraer' algún valor directo complementario:
2. Construyendo su propio RaaS: el marco podría optar por competir en el espacio RaaS y proporcionar sus propios servicios de consultoría y alojamiento de Sequencer. Si muchos marcos comienzan a hacer esto, esto podría hacer que el modelo de negocio RaaS sea insostenible a largo plazo. Esto se debe a que el marco podría aprovechar su credibilidad y posición en el mercado para superar a cualquier proveedor externo de RaaS construido sobre él.
3. Componibilidad entre paquetes como apalancamiento: cualquiera puede crear un paquete acumulativo utilizando el marco tal como está o modificándolo. Sin embargo, para obtener efectos de red e interoperabilidad con otros paquetes acumulativos creados en el mismo marco, el marco puede requerir el cumplimiento de ciertos estándares definidos.

Esto es lo que hace OP Stack con la Ley de Cadenas. Para ser parte de Superchain, debes seguir ciertas reglas. Estas reglas están definidas por la gobernanza del OP. Por ejemplo, una de estas reglas podría ser que todos los acumuladores en Superchain tengan que usar OP como token de gas. Esto también podría evolucionar para incluir leyes de acciones de MEV, por ejemplo, el X% de los ingresos de MEV entre cadenas volvería a la tesorería de OP.

Los equipos del marco acumulativo pueden jugar con los 3 segmentos anteriores para adaptar su mecanismo de "captura de valor" a sus objetivos y ambiciones. Para que acumulen algún valor directo, algunas opciones (no exhaustivas) podrían ser:

• Implementación de su propio paquete acumulativo
• Implementación de RaaS propio
• Aprovechar la componibilidad para regir los estándares del marco

Conclusión

El rápido desarrollo de marcos acumulativos y proveedores de Rollups-as-a-Service (RaaS) en el espacio blockchain ha generado preguntas sobre su acumulación de valor. Si bien la capa de ejecución captura la mayor parte del valor, los marcos acumulativos pueden obtener valor indirecto mediante la adopción y las mejoras. Algunas acumulaciones pueden incluso compartir los ingresos, creando una acumulación de valor semidirecta. Además, al implementar sus propios paquetes acumulativos y aprovechar la componibilidad entre paquetes, los marcos pueden capturar valor directamente. A medida que el ecosistema evolucione, lograr el equilibrio adecuado entre competencia y colaboración será vital para el crecimiento sostenible de los marcos acumulativos y los proveedores de RaaS.

Descargo de responsabilidad:

1. Este artículo está reimpreso de [Stackr Labs]. Todos los derechos de autor pertenecen al autor original [Shivanshu Madan]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn 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 Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.