En los últimos años, el modelo de Rollup-as-a-Service (RaaS) ha ganado terreno como respuesta pragmática a un problema real del ecosistema blockchain: lanzar y operar una red propia es costoso, complejo y requiere un nivel de especialización que la mayoría de los equipos de producto no poseen. El RaaS surge, por lo tanto, como una abstracción conveniente. Promete reducir las barreras técnicas, acelerar el time-to-market y permitir que los equipos se enfoquen en el producto, no en la infraestructura.

Este modelo cumple bien su función inicial. Pero a medida que las aplicaciones dejan de ser experimentales y comienzan a sustentar flujos económicos reales, surgen límites estructurales que ya no pueden tratarse como detalles técnicos. Es en este punto cuando la discusión deja de ser "¿cuál pila es más fácil?" y pasa a centrarse en la soberanía, la previsibilidad y la conectividad a largo plazo.

Este artículo propone un análisis comparativo sobrio entre el RaaS tradicional y el enfoque de @Tanssi , con un enfoque específico en estos dos ejes. La intención no es declarar ganadores universales, sino entender por qué arquitecturas diferentes producen resultados diferentes cuando se confrontan con casos de uso reales.

Lo que el RaaS tradicional resuelve, y dónde comienzan las fricciones

RaaS, en su forma más común, ofrece un paquete gestionado para el despliegue de rollups. El equipo elige un stack conocido, define algunos parámetros y hereda una infraestructura lista: sequencer, RPC, explorer, bridge estándar, indexación y monitoreo. Para MVPs y aplicaciones en etapa inicial, esto funciona bien. El costo cognitivo es bajo y la previsibilidad operacional inicial es alta.

El problema surge cuando la aplicación crece y comienza a depender de garantías más fuertes. Tres fricciones aparecen con frecuencia.

El primero es la soberanía limitada. Aunque el discurso es de “red propia”, la realidad es que buena parte de las decisiones críticas permanece condicionada al stack subyacente y al ecosistema de liquidación. Cambios profundos en la lógica de ejecución, en el modelo económico o en el comportamiento de la red tienden a ser difíciles o inviables sin romper la compatibilidad.

El segundo roce es la secuenciación. Muchos modelos de RaaS dependen, al menos inicialmente, de un sequencer operado de forma centralizada para garantizar rendimiento. Esto resuelve la UX a corto plazo, pero crea dependencia operativa y un único punto de fallo que se vuelve sensible a medida que el volumen crece.

El tercero es la conectividad. En general, interoperabilidad y bridges son tratadas como integraciones externas. Funciona, pero añade capas de dependencia, superficies de riesgo y costos operativos que no desaparecen con el tiempo. Solo se acumulan.

Estos límites no hacen que el RaaS sea “malo”. Solo delimitan claramente el tipo de aplicación para la cual es adecuado.

Soberanía como variable económica, no como eslogan

Cuando hablamos de soberanía en el contexto de este artículo, no estamos hablando de independencia abstracta, sino de control efectivo sobre cuatro dimensiones concretas: ejecución, economía, previsibilidad y gobernanza.

El control de ejecución significa poder definir cómo funciona la lógica de la red, sin estar restringido a un conjunto cerrado de opciones. El control económico involucra política de tarifas, subsidios, incentivos y cómo se percibe el costo por el usuario final. La previsibilidad se refiere a throughput y latencia estables, independientemente del comportamiento de aplicaciones externas. La gobernanza trata de quién decide cambios estructurales y a qué ritmo.

El enfoque de Tanssi parte de la premisa de que, para muchos casos de uso maduros, estas cuatro dimensiones no pueden ser subcontratadas indefinidamente. Por ello, en lugar de ofrecer solo rollups configurables, Tanssi se enfoca en la viabilización de L1s soberanas, con runtimes modulares que permiten una personalización profunda de la lógica de la red sin exigir que cada equipo construya y opere toda la infraestructura desde cero.

En la práctica, esto desplaza la soberanía del nivel del “stack elegido” al nivel de la propia chain. El equipo controla la ejecución y la economía, mientras Tanssi actúa como capa de aprovisionamiento, coordinación y confiabilidad operacional.

Infraestructura gestionada sin dependencia excesiva

Un punto sensible en cualquier comparación es el trade-off entre descentralización y operatividad. La propuesta de Tanssi no es exigir que cada proyecto monte su propio conjunto de operadores, pero tampoco concentrar funciones críticas en un único agente.

Esto aparece, por ejemplo, en el modelo de secuenciación. En lugar de depender exclusivamente de un sequencer fijo, la arquitectura prevé conjuntos de secuenciadores asignados y rotados. El objetivo no es alcanzar un ideal teórico inmediato, sino reducir riesgos operativos reales sin sacrificar el rendimiento.

Además, la existencia de nodos dedicados a la preservación de datos y lectura histórica refuerza la idea de infraestructura persistente. Para aplicaciones que lidian con auditoría, histórico financiero o datos regulatorios, esto no es un detalle técnico, sino un requisito funcional.

Conectividad como parte de la arquitectura, no como accesorio

Otro punto de distinción importante está en la forma en que se trata la conectividad. En el modelo de Tanssi, la interoperabilidad no es solo un conjunto de integraciones opcionales, sino un componente estructural.

Dentro del ecosistema, la comunicación entre redes ocurre de forma nativa, permitiendo el intercambio de mensajes y activos sin depender de soluciones externas para cada caso. Para el acceso a la liquidez y activos de Ethereum, el puente está diseñado con un modelo de confianza minimizada, evitando dependencia de custodios o multisigs opacos.

Esta combinación reduce el costo cognitivo y operativo de mantener conectividad a lo largo del tiempo, algo que se vuelve especialmente relevante cuando la aplicación deja de ser experimental.

Gotas: cuando la escala de consumidor expone límites arquitectónicos

El caso de Gotas ayuda a ilustrar estas diferencias de forma concreta. La plataforma opera en el contexto brasileño, con fuerte enfoque en el compromiso de usuarios finales y marcas. Sus números son relevantes: cientos de miles de billeteras, millones de interacciones y campañas en tiempo real.

Este tipo de carga de trabajo hace inviable depender de blockspace compartido impredecible. Campañas promocionales, redenciones e interacciones necesitan funcionar independientemente de congestiones externas. Además, la lógica de recompensas exige ajustes frecuentes en la economía de la red, algo difícil de sostener en stacks rígidos.

La elección por una L1 soberana permitió a Gotas aislar su ambiente de ejecución, controlar costos y reducir la dependencia de un sequencer único, manteniendo al mismo tiempo conectividad con otros ecosistemas. Aquí, la soberanía no aparece como ideología, sino como consecuencia directa de exigencias operativas.

Rivool: previsibilidad como requisito, no como bono

Mientras Gotas expone desafíos de escala de consumidor, Rivool evidencia otro tipo de presión: previsibilidad en contextos financieros y productivos.

Rivool opera, en su caso de uso inicial, con crédito agrícola on-chain, conectando productores a instrumentos financieros digitales. En este escenario, variabilidad de tarifas, latencia impredecible o dependencia de decisiones externas a la red no son aceptables. La lógica de crédito, garantías y plazos exige un ambiente controlado, auditado y estable.

Una vez más, la elección por una arquitectura soberana no es estética. Responde directamente a la necesidad de alinear la infraestructura blockchain a responsabilidades del mundo real.

Conectando los dolores a los diseños arquitectónicos

Al observar estos casos, es más fácil entender dónde encaja cada modelo.

RaaS tradicional sigue siendo una solución eficiente para aplicaciones que priorizan velocidad de lanzamiento y aceptan limitaciones estructurales a cambio de simplicidad. Por otro lado, el enfoque de Tanssi tiene más sentido cuando la aplicación exige control profundo sobre la ejecución, economía y conectividad, sin renunciar a una capa de soporte operativo.

No se trata de una evolución lineal, sino de elecciones arquitectónicas diferentes para etapas y necesidades diferentes.

Consideraciones finales

El mercado de infraestructura blockchain está saturado de promesas genéricas. Comparaciones honestas exigen ir más allá de eslóganes y observar cómo los sistemas se comportan cuando son sometidos a carga real, usuarios reales y responsabilidades reales.

Al posicionar la Tanssi frente al RaaS tradicional, el punto central no es afirmar que un modelo sustituye al otro, sino mostrar que soberanía y conectividad dejan de ser “características avanzadas” cuando las aplicaciones maduran. Se convierten en condiciones básicas para que la blockchain deje de ser solo una capa experimental y pase a sostener una economía real.