Rollups de aplicación específica.

Tesis de Cartesi: Cómo los entornos de ejecución modular para aplicaciones específicas pueden resolver el problema de programabilidad, incrementar el poder de cómputo e impulsar la innovación.

Published in

Cartesi en Español

11 min readDec 1, 2022

Escrito por: Felipe Argento, Erick de Moura y Augusto Teixeira (artículo originalmente publicado en Cartesi y traducido al Español con Inteligencia Artificial).

TL;DR

La tecnología Blockchain está al borde de una revolución. Cada vez son más los proyectos que comprenden la necesidad de modularidad y especialización. Las L1 más populares están dirigiendo su enfoque hacia la disponibilidad de datos, con el objetivo de soportar más datos de lo que antes era posible en órdenes de magnitud.

Mientras tanto, los entornos de ejecución y las capas de cálculo que planean escalar la potencia de cálculo a través de rollups (ya sean optimistas, ZK o soberanos) tienen la responsabilidad de adecuarse al aumento de las capacidades de datos y ofrecer una infraestructura lo suficientemente robusta para que se desarrollen aplicaciones reales.

La configuración capaz de proporcionar la escalabilidad computacional más significativa es: optimistic rollups de aplicación específica con resoluciones de disputas interactivas. Al mismo tiempo, las ganancias en escalabilidad computacional hacen posible aumentar la programabilidad y mejorar las herramientas de manera significativa.

Cartesi ha optado por este mismo camino, ofreciendo a los desarrolladores cálculos mucho más baratos y la posibilidad de construir contratos inteligentes robustos utilizando bibliotecas y componentes de código abierto existentes dentro de los runtimes de los sistemas operativos del mundo real.

El estado de los sistemas rollup

Las múltiples dificultades tecnológicas a las que se enfrentan las DApps destacan cuando analizamos su código base desde el punto de vista de la ingeniería de software. Proyectos como Uniswap están hábilmente elaborados para equilibrar varios objetivos que compiten entre sí: valor monetario para sus usuarios, minimización extrema del consumo de gas y seguridad. Las aplicaciones que no cumplen estos criterios comprometen su adopción, ponen en riesgo a sus usuarios o pierden en la feroz guerra de la oferta por espacio de bloque. Este es un escenario inhóspito para las aplicaciones y dificulta la innovación.

Además, en comparación con los servicios back-end tradicionales de la Web 2.0, la experiencia de codificación de los contratos inteligentes es abrumadoramente limitada. Decir que hay una diferencia considerable entre la capacidad de los servidores web convencionales y los contratos inteligentes de la blockchain es decir poco.

Ethereum y los rollups EVM son ordenadores descentralizados que te obligan a lidiar con los aspectos anteriores. Se trata de ordenadores excesivamente lentos y “peculiares” que requieren que los desarrolladores codifiquen en lenguajes de programación de nicho.

En esta extraña configuración, los desarrolladores dedican gran parte de sus esfuerzos en superar estas limitaciones en lugar de optimizar el núcleo de sus soluciones. El resultado suele ser un código no esencial y excesivamente complicado en torno a funciones simples y limitadas.

El problema de la escalabilidad: en defensa de los rollups de aplicación específica

Una red en la que todo el mundo verifica todo, no es sostenible para la adopción masiva. Con el modelo de consenso global, el aumento de la demanda conduce inevitablemente a luchas canibalistas entre las aplicaciones por el espacio de bloque. Este escenario degenera en tarifas elevadas, lo que supone una barrera de entrada cada vez mayor tanto para los proyectos como para los usuarios. Para hacer frente a esta lucha, Ethereum ha dado un giro, proponiendo una hoja de ruta centrada en rollups.

El nuevo plan reconoce que el problema de la escalabilidad comprende dos aspectos principales: la escalabilidad de datos y la escalabilidad de cálculo. La distinción entre estos dos aspectos suele pasarse por alto, ya que en la actualidad están enredados en la misma noción de costes de gas. Sin embargo, fue al distinguirlos que Ethereum previó su hoja de ruta actual.

Tras the merge, y con los desarrollos incluidos en la EIP-4844 y sharding Ethereum se reducirá el coste de añadir datos a su blockchain en varios órdenes de magnitud. Mientras tanto, el escalado computacional se ha delegado a los proyectos de rollups (de ahí el nombre de rollup-centric).

La relación entre el protocolo de Ethereum y las soluciones de rollups esconde un problema que no recibe la atención que merece. Pues los rollups compatibles con la EVM no son el mejor diseño para lograr la escalabilidad de cálculo necesaria para ajustarse a las grandes ganancias en disponibilidad de datos que Ethereum logrará.

Podemos pensar en los rollups basados en EVM como shards computacionales. Los defectos del diseño aparecen a medida que se van desplegando más y más aplicaciones que comparten la misma VM. La lucha Zero-Sum por un trozo de la capacidad de la CPU de la máquina virtual conduce a la gentrificación. Solo una pequeña fracción de aplicaciones es viable en cada shard; las demás son expulsadas. Así que es solo cuestión de tiempo para que estas redes se congestionen y se vuelvan caras.

Afortunadamente, es posible entender y utilizar los rollups de forma diferente. Ya que dejar de lado las VMs compartidas, permite a las aplicaciones tener su propia CPU y con ello un altísimo rendimiento computacional. La liquidación de activos, la composibilidad entre aplicaciones y la resolución de conflictos pueden delegarse a una capa base de uso general. Este diseño se denomina application-specific rollups.

El consenso dedicado de los rollups de aplicación específica está vinculado a la capa base, lo que permite que sus nodos validadores (públicos o privados) conserven las garantías de seguridad de dicha capa. En otras palabras, tener una capa base hace posible un modelo de seguridad 1-de-N, donde cualquier validador honesto puede, con la ayuda de la capa base, hacer cumplir un resultado correcto independientemente de la cooperación. Al mismo tiempo, el consenso dentro del modelo de aplicación específica hace posible que las aplicaciones disfruten de toda la potencia (no compartida) del hardware. Esto no solo evita el problema de la gentrificación de la red, sino que también proporciona una ganancia significativa en la escalabilidad computacional.

El cambio de un consenso compartido a uno para aplicaciones específicas no viene sin consecuencias. Aunque esta elección de diseño implica una mayor fricción para la composibilidad entre aplicaciones, argumentamos que esta es una preocupación menos relevante para la mayoría de ellas. Tener que esperar a que se verifique la comunicación entre aplicaciones o depender de una técnica de finalización blanda (es decir, proveedores de liquidez) no representa un gran compromiso a cambio de las enormes mejoras en la potencia de cálculo y la previsibilidad que ofrecen las cadenas de aplicaciones específicas.

En particular, la opción de los optimistic rollups con prueba de fraude interactiva ofrece a las aplicaciones descentralizadas recursos computacionales comparables a los mainstream (por ejemplo, miles de millones de instrucciones y grandes espacios de memoria) sin necesidad de hardware especial para alcanzar el consenso. Esto solo es posible porque las pruebas de fraude interactivas permiten a los árbitros con recursos computacionales limitados arbitrar disputas entre comprobadores computacionalmente ilimitados. En concreto, nuestro árbitro es una capa base con recursos limitados, y nuestros comprobadores son validadores rollup con recursos computacionales comparativamente ilimitados. Para entender mejor cómo es posible, consulta la sección 5.2 del documento técnico de Cartesi Core.

En su búsqueda por la máxima escalabilidad y personalización, los desarrolladores de aplicaciones y protocolos están dirigiendo su atención a diferentes formas de cadenas para aplicaciones específicas. Algunos ejemplos son: La cadena lateral Ronin de Axie Infinity, la cadena soberana de dYdX, el diseño de escalado fractal de Starkware, las capas de ejecución modulares de Celestia.

Las cadenas rollup de aplicación específica pueden satisfacer esta demanda, con la ventaja de no incurrir en la peligrosa fragmentación de la validación de las cadenas soberanas (capa uno) de aplicación específica. En cambio, las cadenas rollup heredan las sólidas garantías de seguridad de las capas base subyacentes sin depender de los puentes entre cadenas, que han demostrado ser peligrosos.

La ventaja tecnológica de las cadenas rollup deriva del hecho de que son seguras, con 1 de N partes honestas en lugar de la necesidad de una mayoría honesta. En resumen, los rollups específicos para una aplicación son tan buenos como las cadenas laterales específicas para una aplicación, sin los grandes compromisos de seguridad.

Los efectos del escalado concomitante de la capacidad de cálculo y de la disponibilidad de datos pueden visualizarse mejor con la ayuda de la figura anterior.

La figura está dividida en las principales áreas que representan las soluciones de escalado que se combinan y su rendimiento en términos de capacidad computacional y de datos. La capacidad computacional mejora a medida que pasamos de la capa uno de Ethereum a los rollups de EVM y finalmente a las appchains dedicadas, mientras que los datos mejoran con la adición de EIP-4844 y sharding. El cono azul muestra qué aplicaciones son progresivamente posibles con los escalados en ambas dimensiones. Llamamos a la zona azul el cono de innovación web3.

Las zonas grises fuera del cono son aquellas en las que las ganancias en la disponibilidad de datos no pueden disfrutarse plenamente porque las soluciones carecen de capacidad computacional y viceversa. Los pequeños cuadrados blancos son ejemplos de aplicaciones que empiezan a ser posibles cuando se alcanzan esos hitos; los no marcados nos recuerdan que no tenemos ni idea de qué nuevas y geniales aplicaciones surgirán una vez que el entorno sea más robusto.

El cono de innovación no pretende ser preciso. Su dirección y ángulo de apertura no deben tomarse literalmente. Además, las aplicaciones que se hacen posibles en cada región son propensas a caer en zonas diferentes. La figura pretende simplemente ofrecer una perspectiva intuitiva sobre el creciente horizonte de innovación de las aplicaciones descentralizadas.

El problema de la programabilidad: en defensa de mejores abstracciones

Además de las limitaciones computacionales descritas anteriormente, los desarrolladores de DApps se enfrentan a otra enorme carga: la falta de un entorno maduro, en forma de herramientas y bibliotecas software insuficientes.

Para ilustrar mejor este problema, mencionemos uno de los juegos descentralizados más impresionantes que hemos conocido en los últimos días, Topology. Este ambicioso proyecto mezcla la construcción de infraestructuras estratégicas con la dinámica planetaria. Una locura. Sin embargo, solo con mirar su código fuente, podemos ver las bestias que tuvieron que vencer. Por poner un solo ejemplo, tuvieron que desarrollar un algoritmo clásico para simular la dinámica planetaria desde cero. Detrás del impresionante talento que ha desplegado el equipo de Topology, hay una inquietud preocupante: sólo unos desarrolladores excepcionales pueden hacer realidad sus ideas en un entorno tan inmaduro.

El ejemplo anterior está lejos de ser único. Muchas bibliotecas (ej.: 1, 2, 3, 4, 5, 6) están siendo escritas en Solidity para ayudar al desarrollo de contratos inteligentes y DApps. Pero el estado actual del lenguaje es todavía muy inmaduro, con algunas tareas básicas que todavía requieren que la gente recurra a los foros, en busca de ayuda.

Esta no es la realidad en la industria del software tradicional. El juego Angry birds, por ejemplo, necesitaba las mismas librerías que Topology (al fin y al cabo, los planetas y los pájaros voladores siguen las mismas leyes de la física). Sin embargo, los desarrolladores de Angry Birds no se vieron obligados a escribir cada línea de código que necesitaban desde cero. Existen librerías para esto en prácticamente todos los lenguajes imaginables.

Lo que hace posible que los desarrolladores tradicionales tengan acceso a todas estas bibliotecas es el estándar de oro para resolver el problema de la programabilidad: un sistema operativo completo. Los desarrolladores que trabajan en todos los campos, desde la Web2 hasta los videojuegos tradicionales, pasando por el lanzamiento de satélites, cuentan con un sistema operativo que les da el soporte que necesitan. Los lenguajes y las bibliotecas que necesitan para materializar sus ideas es lo que les permite centrar sus esfuerzos en lo que realmente quieren construir, más que en la infraestructura subyacente que lo hace posible.

Por eso hemos elegido la arquitectura RISC-V para construir nuestra solución de rollups. Permite portar Linux u otros sistemas operativos a los rollups. De este modo, los desarrolladores pueden dar vida a sus ideas en sus lenguajes y bibliotecas favoritas, sin renunciar a las sólidas garantías de seguridad de la cadena de bloques, como se ha detallado en artículos anteriores (1, 2, 3).

Hasta este punto, Linux ha sido el centro de atención, pero es posible ejecutar cualquier sistema operativo que pueda ser compilado a RISC-V, como algunos microkernels muy seguros existentes.

Cartesi Rollups

En primer lugar, discutimos la importancia de una capa de ejecución modular que realmente escale el poder de cómputo y evite que las DApps se enfrenten entre sí en un juego Zero-Sum por los recursos computacionales. A continuación, explicamos la importancia de que los desarrolladores cuenten con la capacidad de abstracción de un sistema operativo, como hacen los desarrolladores convencionales.

Fue con estas dos necesidades en mente que hemos diseñado y construido Cartesi Rollups como una capa de ejecución modular que proporciona los siguientes beneficios de escalado para las DApps:

Cada DApp cuenta con su propia app-chain de alto rendimiento con una CPU dedicada;
No hay canibalización de recursos entre DApps en el ecosistema de Cartesi;
Aumento significativo de la escalabilidad computacional fuera de un entorno Zero-Sum;
Preservar las sólidas garantías de seguridad de la cadena de bloques subyacente;
Un sistema operativo completo que ofrece herramientas de calidad industrial para los desarrolladores.

Las aplicaciones Cartesi Rollups pueden utilizarse como capa 2 (es decir, encima de Ethereum), como capa 3 (es decir, encima de las cadenas Arbitrum o ZK-EVM) o como rollups soberanos (es decir, encima de Celestia). Además, los desarrolladores pueden trasladar sus aplicaciones de una plataforma a otra con mínimos cambios de código.

Palabras finales

Cartesi permite a los desarrolladores centrarse en sus creaciones en lugar de en dónde lo están haciendo o en las incómodas limitaciones con las que tendrán que lidiar.

De este modo, podemos impulsar la innovación sin que las aplicaciones más populares canibalicen a las menos posicionadas. Las aplicaciones descentralizadas pueden disponer de toda la potencia de cálculo que necesiten manteniendo la previsibilidad de los costes. Los desarrolladores pueden aprovechar las bibliotecas de programación ya probadas en batalla y crear MMORPG descentralizados que sean realmente divertidos y en los que matar a un goblin no cueste a los jugadores 3 dólares.

Desde el punto de vista de la personalización, las cadenas de aplicaciones de Cartesi Rollups dan a las DApps la posibilidad de cobrar diferentes precios por diferentes acciones. Podrían, por ejemplo, renunciar a las tasas de gas para los market makers en sus intercambios descentralizados o aumentar el coste de la pesca depredadora en su DApp simulador de océanos.

Cartesi tiene una visión muy clara de la revolución que está a punto de producirse en las tecnologías descentralizadas. Cartesi Rollups se está desarrollando como una respuesta enfocada a las necesidades de este nuevo entorno.

Acerca de Cartesi

The Blockchain OS, está construyendo Cartesi Rollups, una capa de ejecución modular que eleva los contratos inteligentes simples a tiempos de ejecución Linux descentralizado. Permite a los desarrolladores lanzar cadenas de rollups altamente escalables, y codificar su lógica descentralizada con sus lenguajes y componentes de software favoritos.

Cada DApp tiene su propia cadena de rollups de alto rendimiento;
No hay canibalización de recursos de otras DApps en el ecosistema de Cartesi;
No hay gentrificación de la red;
Permite una clase completamente nueva de DApps que actualmente no son posibles en cadenas EVM;
Preserva las fuertes garantías de seguridad de la cadena de bloques subyacente.

Bienvenid@ a The Blockchain OS, el hogar de lo que viene.

Sigue a Cartesi en sus canales oficiales (Inglés):

Únete a la conversación en Español:

Telegram | Twitter