La tecnología Blockchain está a punto de revolucionar las aplicaciones. Cada vez más proyectos están familiarizados con la necesidad de modularidad y especialización. Varios tipos de capas que emergen en un flujo sin fin están cambiando su enfoque hacia la disponibilidad de datos, con el propósito de admitir datos de mayor orden de magnitud.
Al mismo tiempo, el entorno de ejecución y la capa de cómputo que planean expandir el poder de cómputo a través de Rollups (Optimistic, ZK o Sovereign) tienen la responsabilidad de igualar la mayor capacidad de datos y proporcionar una infraestructura suficientemente poderosa para desarrollar aplicaciones prácticas.
Optimistic Rollups puede brindar la configuración que brinda la mayor cantidad de ganancias en términos de escalabilidad computacional para una clase específica de aplicaciones con resolución de disputas interactiva. Al mismo tiempo, la escalabilidad computacional puede aumentar considerablemente la programabilidad y la posibilidad de mejorar las herramientas.
Cartesi ha elegido este camino para proporcionar a los desarrolladores una forma más conveniente de desarrollar y potencialmente construir poderosos contratos inteligentes utilizando sistemas operativos del mundo real que ejecutan bibliotecas y componentes de código abierto existentes.
Estado del sistema de Rollups
Los múltiples desafíos técnicos que enfrentan las DApps de blockchain salen a la luz cuando analizamos sus bases de código desde una perspectiva de ingeniería de software. Algunos proyectos bien diseñados, como Uniswap, equilibran varios objetivos competitivos: valor monetario para los usuarios, consumo mínimo de gas y seguridad. Las aplicaciones que no cumplen con estos criterios limitan su base de uso, ponen a los usuarios en riesgo o pierden en la feroz competencia por la interacción de la cadena de bloques. Esta situación no es adecuada para las aplicaciones y dificulta la innovación.
Además, la experiencia del usuario de codificar contratos inteligentes es significativamente limitada en comparación con los servicios de back-end Web 2.0 tradicionales. Es cierto que existe una brecha generacional considerable entre la funcionalidad de los servidores web tradicionales y los contratos inteligentes de blockchain.
Ethereum y EVM Rollups son computadoras descentralizadas que lo obligan a lidiar con los aspectos anteriores. Son "computadoras especializadas" extremadamente lentas que requieren que los desarrolladores codifiquen en lenguajes de programación específicos.
En esta extraña configuración, los desarrolladores se enfocan en superar estas limitaciones en lugar de optimizar sus soluciones principales. El resultado suele ser un código innecesario y muy complejo en torno a una funcionalidad simple y limitada.
Inquietudes de escalabilidad: protección de acumulaciones de aplicaciones específicas
Todo el mundo necesita validar todas las redes, lo que no es sostenible para la adopción masiva. En el consenso mundial, el aumento de la demanda conduce inevitablemente a un aumento del espacio de bloques, lo que a su vez conduce a una competencia feroz entre varias aplicaciones. En cambio, esta situación generará altos costos, que constituyen cada vez más costos de entrada para las partes del proyecto y los usuarios. Para solucionar este problema, Ethereum se ha transformado y ha propuesto una hoja de ruta centrada en los Rollups.
Los problemas de escalabilidad mencionados en el nuevo plan incluyen dos aspectos principales: escalabilidad de datos y escalabilidad informática. La diferencia entre los dos a menudo se pasa por alto porque actualmente tienen el mismo costo de gasolina. Sin embargo, es diferenciándolos que Ethereum tiene su hoja de ruta actual.
Después de la fusión, con el desarrollo de EIP-4844 y Ethereum fragmentado, el costo de agregar datos a su cadena de bloques será mucho más bajo. Mientras tanto, el escalado informático se ha confiado al proyecto Rollups (denominado rollup-centric).
La relación entre el protocolo Ethereum y la solución Rollups esconde un problema poco apreciado. Los paquetes acumulativos compatibles con EVM no son el mejor diseño para mejorar la escalabilidad computacional para que coincida con la implementación de disponibilidad de datos de Ethereum.
Los paquetes acumulativos basados en EVM pueden describirse como fragmentos informáticos. A medida que más y más aplicaciones se implementen gradualmente y compartan la misma máquina virtual, aparecerá esta falla de diseño. Un juego de suma cero de competir por la capacidad de la CPU de la máquina virtual conduce a problemas de alto nivel. Solo una pequeña fracción de aplicaciones está disponible en cada fragmento y otros usuarios se eliminan gradualmente. Estas redes pueden volverse extremadamente congestionadas y costosas.
Afortunadamente, los Rollups ahora se pueden entender y usar de manera diferente. Puede renunciar a las máquinas virtuales compartidas y dejar que las aplicaciones tengan sus propias CPU y computación de ultra alto rendimiento disponible. La liquidación de activos, la compatibilidad entre aplicaciones y la resolución de disputas se pueden delegar a una capa base común. Este diseño se llama Rollups específicos de la aplicación.
El consenso privado de los Rollups específicos de la aplicación se conecta a la capa base, lo que permite que sus nodos de validación (permitidos o no) conserven las garantías de seguridad de su capa de liquidación. En otras palabras, tener una capa base permite un modelo de seguridad 1 de N donde cualquier verificador honesto puede, con la ayuda de la capa base, ejecutar el resultado correcto independientemente de la cooperación. Al mismo tiempo, el consenso específico de la aplicación permite que las aplicaciones disfruten de todas las capacidades del hardware (no compartido). No solo evita el problema de la gentrificación de la red, sino que también brinda ganancias significativas en la escalabilidad computacional.
El paso del consenso compartido al consenso específico de la aplicación no está exento de inconvenientes. Si bien este diseño implica mayores enredos en la composición entre aplicaciones, creemos que este es un problema menos relevante para la mayoría de las aplicaciones. Tener que esperar a que se verifiquen sus comunicaciones o depender de técnicas de finalización suave (es decir, proveedores de liquidez) no es un gran compromiso a cambio de las grandes mejoras en el poder de cómputo y la previsibilidad que brindan las cadenas específicas de la aplicación.
En particular, Optimistic Rollups con Interactive Fraud Prevention proporciona aplicaciones descentralizadas con recursos informáticos comparables a los convencionales (por ejemplo, que implican miles de millones de pasos de instrucciones y grandes espacios de direcciones de memoria) sin necesidad de hardware especial para lograr el consenso. Esto solo es posible porque las pruebas de fraude interactivas permiten que los árbitros con recursos computacionales limitados resuelvan disputas entre probadores con recursos computacionales infinitos. En particular, nuestro árbitro es una capa de liquidación con recursos limitados, y nuestro probador es un validador de acumulaciones con recursos informáticos relativamente ilimitados. Para una mejor comprensión de cómo se logra esto, consulte la Sección 5.2 del documento técnico de Cartesi Core.
En la búsqueda de la máxima escalabilidad y personalización, los desarrolladores de aplicaciones y protocolos están dirigiendo su atención a diferentes formas de cadenas específicas de aplicaciones. Algunos ejemplos son: la cadena lateral Ronin de Axie Infinity, la cadena soberana de dYdX, el diseño de escalamiento fractal de Starkware, la capa de ejecución modular de Celestia.
Las cadenas de resumen de aplicaciones específicas pueden satisfacer esta necesidad, con la ventaja de no causar una fragmentación peligrosa de la verificación de cadenas específicas de aplicaciones soberanas (capa 1). En cambio, las cadenas de paquetes acumulativos específicos de la aplicación heredan las sólidas propiedades de seguridad de la capa base subyacente sin depender de puentes entre cadenas que han demostrado ser peligrosos.
La ventaja técnica de las cadenas de acumulación de aplicaciones se deriva del hecho de que son seguras para 1 de cada N partes honestas, no de la necesidad de una mayoría honesta. En general, los paquetes acumulativos específicos de la aplicación son tan buenos como las cadenas laterales específicas de la aplicación sin comprometer seriamente la seguridad.
Con la ayuda de la figura anterior, puede demostrar mejor el efecto de expandir visualmente los datos y la capacidad de disponibilidad de datos.
El gráfico se divide en varias áreas principales que representan las soluciones de escalamiento que se combinan y cómo se comportan en términos de capacidad de cómputo y datos. A medida que pasamos de Ethereum Layer 1 a EVM Rollups y, finalmente, a cadenas de aplicaciones privadas, la potencia informática aumentó, mientras que los datos también aumentaron con la adición de EIP-4844 y la fragmentación. Los conos azules muestran qué aplicaciones se vuelven progresivamente posibles a medida que se escalan las dos dimensiones. Nos referimos al área azul como el cono de innovación para web3.
El área gris fuera del cono es donde no se pueden disfrutar todos los beneficios de la disponibilidad de datos porque la solución carece de poder de cómputo. Lo opuesto también es cierto. Los pequeños cuadrados blancos son ejemplos de aplicaciones que comienzan a ser posibles a medida que alcanzamos estos hitos, y los que no están marcados nos recuerdan que no sabemos qué nuevas aplicaciones interesantes surgirán una vez que el entorno se vuelva más sólido.
Los conos de innovación no representan completamente datos precisos. Las direcciones y ángulos dibujados no deben tomarse literalmente. Además, cada región tiene posibles aplicaciones fácilmente en diferentes campos. El gráfico solo proporciona una perspectiva visual del creciente horizonte de innovación en aplicaciones descentralizadas.
El problema de la programabilidad: en defensa de mejores abstracciones
Además de las restricciones computacionales antes mencionadas, los desarrolladores de DApps enfrentan otra gran carga: la falta de un entorno maduro, que se manifiesta en la insuficiencia de herramientas y bibliotecas de software.
Para ilustrar mejor el punto, mencionemos Topology, el juego descentralizado más impresionante que hemos encontrado en los últimos días. ¡Este ambicioso proyecto combina la construcción de infraestructura estratégica y la dinámica planetaria! cosa loca. Sin embargo, con solo mirar su código fuente, vemos a la bestia que tienen que matar. Como ejemplo, tuvieron que desarrollar un algoritmo clásico para simular la dinámica planetaria desde cero. Detrás del impresionante talento mostrado por el equipo de topología, hay una preocupación: solo los buenos desarrolladores pueden hacer realidad sus ideas en un entorno tan inmaduro.
El ejemplo anterior no es el único. Muchas bibliotecas (por ejemplo: 1, 2, 3, 4, 5, 6, 7) están escritas en Solidity para ayudar en el desarrollo de contratos inteligentes y DApps. Pero el estado actual del idioma aún es muy inmaduro, y algunas tareas básicas aún requieren que las personas recurran al foro en busca de ayuda.
Esta no es la realidad de la industria del software tradicional. Por ejemplo, el juego Angry Birds requiere la misma biblioteca que Topology (después de todo, los planetas y las aves obedecen las mismas leyes físicas). Sin embargo, los desarrolladores detrás de Angry Birds no se vieron obligados a escribir cada línea de código que necesitaban desde cero. Hay bibliotecas maduras para básicamente todos los idiomas imaginables.
Para que los desarrolladores tradicionales tengan acceso a todas estas bibliotecas, que también es el estándar de oro para resolver problemas de programabilidad, se requiere un sistema operativo maduro. Los desarrolladores en todo, desde Web2 hasta juegos tradicionales y lanzamientos de satélites, confían en los sistemas operativos para brindarles el soporte que necesitan. Los lenguajes y bibliotecas que necesitan para implementar sus ideas les permiten concentrarse en lo que realmente quieren construir, en lugar de la infraestructura subyacente que lo hace posible.
Es por eso que elegimos la arquitectura RISC-V para construir la solución de Rollups. Puede portar Linux u otros sistemas operativos a Rollups. De esta forma, los desarrolladores pueden utilizar el lenguaje y la biblioteca con los que están más familiarizados y dar vida a sus ideas sin renunciar a las sólidas garantías de seguridad de blockchain, como se describe en artículos anteriores (1, 2, 3).
Linux ha sido el enfoque hasta ahora, y es un sistema operativo que puede ejecutar cualquier cosa que pueda compilarse en RISC-V, como algunos microkernels muy seguros.
Resumen cartesiano
Primero discutimos la importancia de una capa de ejecución de resumen modular que realmente escala el cómputo y evita que las DApps se comprometan entre sí en un juego de recursos informáticos de suma cero. Luego explicamos la importancia de que los desarrolladores confíen en las capacidades de abstracción del sistema operativo como lo hacen los desarrolladores principales.
Con estos dos requisitos en mente, diseñamos y construimos Cartesi Rollups como una capa de ejecución modular, proporcionando las siguientes ventajas de escalado para DApps:
- Cada DApp tiene su propia cadena de aplicaciones agregadas de alto rendimiento y CPU dedicada;
- No se invadirán los recursos de otras DApps en el ecosistema de Cartesi;
- Escalabilidad computacional significativamente mayor fuera de los entornos de juego de suma cero;
- Preservar las sólidas garantías de seguridad de la cadena de bloques subyacente;
- Un sistema operativo maduro que proporciona a los desarrolladores herramientas de grado industrial.
La aplicación Cartesi Rollups se puede utilizar como segunda capa (es decir, encima de Ethereum), tercera capa (es decir, encima de las cadenas Arbitrum o ZK-EVM) o como Sovereign Rollups (es decir, encima de Celestia). Los desarrolladores pueden portar sus aplicaciones de una plataforma a otra con cambios mínimos de código.
ultimas palabras
Cartesi permite que los desarrolladores se concentren en lo que están construyendo sin ponerlos en restricciones inconvenientes durante la construcción o cuando necesitan lidiar con problemas.
De esta manera, la innovación puede impulsar la innovación sin que las aplicaciones populares canibalicen a las menos establecidas. Las aplicaciones descentralizadas pueden tener todo el poder de cómputo que necesitan mientras mantienen los costos predecibles. Los desarrolladores pueden aprovechar las bibliotecas de programación probadas en batalla y crear MMORPG descentralizados que son realmente divertidos.
Desde el punto de vista de la personalización, la cadena de aplicaciones Cartesi Rollups brinda a DApp la posibilidad de cobrar diferentes precios para diferentes operaciones. Por ejemplo, podrían renunciar a las tarifas de gas para los creadores de mercado en un intercambio descentralizado, o aumentar el costo de la pesca depredadora en un DApp de simulador oceánico.
Cartesi tiene una visión muy clara de la próxima revolución en tecnología descentralizada. Cartesi Rollups se está desarrollando como una solución enfocada a las necesidades de este nuevo entorno.
Acerca de Cartesi
Blockchain OS está construyendo Cartesi Rollups, una capa de ejecución modular que levanta contratos inteligentes simples para ejecutarlos en un sistema operativo Linux descentralizado. Permite a los desarrolladores lanzar cadenas de resúmenes altamente escalables y escribir lógica descentralizada utilizando sus lenguajes y componentes de software favoritos.
- Cada DApp tiene su propia cadena de Rollups de alto rendimiento;
- No se invadirán los recursos de otras DApps en el ecosistema de Cartesi;
- No elevó el umbral de la red;
- Puede habilitar una categoría completamente nueva de DApps que actualmente no pueden ejecutarse en la cadena EVM;
- Preservar las sólidas garantías de seguridad de la cadena de bloques subyacente
Bienvenido al sistema operativo blockchain, puede obtener información sobre el siguiente paso.
