Las DApps de Cartesi están aquí. 5 pasos para desarrollar aplicaciones en… de la Fundación Cartesi Cartesi Dic, 2021

5 pasos para desarrollar aplicaciones en el sistema operativo blockchain

Enfrentémoslo: el desarrollo de blockchain todavía es difícil y limitado en su etapa actual. Y si bien es cierto que la comunidad blockchain ha comprometido enormes cantidades de energía y esfuerzo para abordar algunos de estos problemas, algunos de ellos han permanecido prácticamente sin abordar hasta ahora.

Para empezar, dadas las restricciones inherentes de las tecnologías blockchain actuales, las aplicaciones descentralizadas del mundo real o DApps todavía son bastante limitadas en términos de complejidad. No poder recorrer una matriz muchas veces, realizar operaciones con cadenas o simplemente usar una base de datos, son limitaciones que intimidan a cualquier desarrollador que se atreva a aventurarse en el mundo de las cadenas de bloques. Además, en comparación con lo que disfruta la industria del software convencional, la tecnología y las herramientas disponibles para crear DApps son todas relativamente nuevas e inmaduras, incluso para el ecosistema Ethereum.

En términos prácticos, todo esto significa que existe una enorme barrera de entrada para la gran mayoría de los desarrolladores, lo que dificulta gravemente el crecimiento y la adopción de la tecnología blockchain en general. En Cartesi, creemos que la creación de aplicaciones descentralizadas no debería ser muy diferente de la creación de aplicaciones de escritorio, web o móviles. En este artículo, mostramos cómo Cartesi Rollups puede cumplir con esta visión, brindando a los desarrolladores acceso a un sistema operativo completo en la cadena de bloques por primera vez, junto con la flexibilidad de usar las pilas de software y las herramientas de su elección.

Como se describió originalmente en el artículo de Erick de Moura "Cartesi Rollups: contratos inteligentes escalables construidos con pilas de software convencionales", Cartesi Rollups es un marco de capa 2 en el que la lógica de la aplicación se puede desarrollar sobre un sistema operativo real como Linux, pero aún así integrado con una cadena de bloques Layer-1 subyacente y asegurado por ella.

Durante el año pasado, en Cartesi hemos trabajado duro para implementar este marco. Hemos publicado varios artículos que describen sus partes, explican las razones de las decisiones de diseño que tomamos y muestran cómo funciona todo en conjunto. Puede consultarlos para comprender en detalle cómo se implementaron nuestros contratos inteligentes en cadena, así como cómo funcionan los nodos de capa 2 fuera de cadena, que aprovechan nuestra máquina RISC-V Cartesi para permitir que se ejecute una computación verificable sobre Linux.

Ahora, nos complace anunciar que se está lanzando al público una versión alfa de la solución completa y que hemos llegado al punto en el que nuestro sueño se ha hecho realidad: permitir que cualquiera pueda desarrollar aplicaciones descentralizadas de complejidad arbitraria, utilizando herramientas de desarrollo convencionales y pilas de software y hacer que todo se asiente sobre redes de cadenas de bloques establecidas como Ethereum, Polygon, Avalanche o Binance Smart Chain.

En términos generales, desde el punto de vista de un desarrollador, una DApp Cartesi se compone de dos partes principales: una Interfaz y un back-end.

Tomando prestado de la terminología dominante familiar, el Interfaz corresponde a la interfaz de usuario, que a menudo proporcionará una GUI (por ejemplo, una aplicación web) pero también puede ser solo una interfaz de línea de comandos (por ejemplo, una tarea de Hardhat usando ethers.js, o una herramienta de línea de comandos escrita en Pitón).

Por otro lado, el back-end de una DApp Cartesi contiene la lógica empresarial de la aplicación, similar a lo que los sistemas tradicionales se ejecutarían dentro de un servidor. La diferencia aquí, y la razón para usar la tecnología blockchain en general, es que para las aplicaciones descentralizadas existe la necesidad de que esta lógica de back-end sea verifiable y por lo tanto sin esperanzas. Como tal, se ejecuta dentro de Cartesi Rollups, que almacena y actualiza el estado de la aplicación a medida que se recibe la entrada del usuario, produciendo las salidas correspondientes. Estos resultados pueden venir en forma de vales (transacciones que se pueden realizar en la Capa-1, como una transferencia de activos) y avisos (declaraciones informativas, como la puntuación resultante de un juego). En términos prácticos, un back-end de Cartesi DApp puede verse como un contrato inteligente, pero con esteroides.

Además de estos dos componentes principales, el front-end de DApp también puede, por supuesto, hacer uso de recursos externos como servicios de terceros. De hecho, para DApps más complejas, se espera que haya otros back-end además del que se ejecuta dentro de Cartesi Rollups. Estos se usarían siempre que la aplicación no necesite realmente un servicio para ser descentralizada y verificable, como proporcionar cachés de datos rápidos y accesibles, ayudar a los usuarios a comunicarse entre sí o interactuar con otros servicios que no son de blockchain.

En comparación con el desarrollo de software tradicional, la principal diferencia de una DApp Cartesi es que el back-end se implementa en una red descentralizada de nodos de capa 2, que verifican continuamente la exactitud de todos los resultados del procesamiento. Como consecuencia, el front-end y el back-end no se comunican directamente entre sí. Más bien, el front-end envía entradas al marco Cartesi Rollups, que a su vez las pone a disposición de las instancias de back-end que se ejecutan dentro de cada nodo. Una vez que las entradas son procesadas por la lógica de back-end, las salidas correspondientes se informan al marco de Rollups, que hace cumplir su corrección antes de ponerlas a disposición del front-end y otras partes interesadas.

El siguiente diagrama ilustra cómo funciona todo esto desde el punto de vista del desarrollador:

Aquí, los cuadros verdes representan las partes que el desarrollador necesita implementar para construir una DApp, mientras que las partes en violeta corresponden al marco general de Rollups proporcionado por Cartesi. Este marco incluye tanto la cadena de bloques Layer-1 subyacente, con los contratos inteligentes de Cartesi Rollups implementados, como los nodos fuera de la cadena de Layer-2.

Como se ilustra en la figura de arquitectura anterior, en una DApp de Cartesi, las partes frontal y posterior de la aplicación se comunican entre sí a través del marco Cartesi Rollups.

Al diseñar la API para esta comunicación con el marco, queríamos asegurarnos de que los desarrolladores pudieran crear sus aplicaciones sin tener que preocuparse demasiado por las idiosincrasias de la tecnología blockchain o nuestra solución acumulada. En particular, queríamos permitir que el código de back-end se abstraiga si se ejecuta dentro de una máquina virtual específica o no.

Con esto en mente, decidimos ofrecer una API HTTP como una capa de conveniencia para esta comunicación, aprovechando un estándar bien conocido y ubicuo en lugar de hacer que las aplicaciones se ocupen de cualquier dispositivo de nivel de kernel o específico de VM, o tener que entender cómo funciona nuestro La solución de rollups codifica y decodifica datos.

Desde el punto de vista del componente de back-end, la API se puede dividir en dos partes, como se ilustra en la siguiente figura.

Primero, se espera que el back-end de DApp implemente un par de puntos finales para recibir solicitudes del marco de Rollups, como se muestra en la lista a continuación:

AdvanceState – Proporciona información al back-end, que se procesa de forma asincrónica para avanzar en el estado de la aplicación.Inspeccionar Estado – Envía una consulta sobre el estado actual de la aplicación, para ser respondida de forma sincrónica.

A medida que el back-end procesa las entradas recibidas a través del punto final AdvanceState, puede acceder a un segundo conjunto de puntos finales HTTP proporcionados por el propio marco de Rollups, para informarle de los resultados calculados y las consecuencias, como se muestra a continuación:

AddVoucher – Llamado para especificar un efecto colateral en forma de una transacción que se puede llevar a cabo en la capa 1 (por ejemplo, una transferencia de tokens ERC-20).AddNotice – Informa sobre un nuevo estado relevante de la aplicación (por ejemplo, clasificaciones de jugadores actualizadas).AddReport – Proporciona diagnósticos o registros asociados con una entrada recibida.Terminar – Comunica que se ha completado el procesamiento asincrónico de una solicitud AdvanceState.

Tenga en cuenta que puede encontrar la especificación completa de OpenAPI para estos extremos en el repositorio público de Github de Cartesi.

La parte de front-end de la DApp necesita acceder al marco de Cartesi Rollups para enviar las entradas del usuario y recuperar los comprobantes y avisos correspondientes producidos por el back-end. La siguiente figura y tabla detallan cómo se realiza esta comunicación:

AddInput – Envía datos de entrada a los contratos inteligentes acumulados en la capa 1 como una transacción regular de la cadena de bloques JSON-RPC. Cuando se extrae y ejecuta esa transacción, se emite un evento que contiene el identificador de la entrada enviada, que el front-end puede usar más tarde para consultar los resultados asociados. En el futuro, también habrá soporte para enviar entradas a través de un servicio de agregación.QueryOutputs – Envía una consulta a un nodo de capa 2 para recuperar comprobantes, avisos e informes, según lo especificado por el esquema Cartesi Rollups GraphQL.Inspeccionar Estado – Envía una consulta a un nodo de capa 2 para recuperar el estado arbitrario de la aplicación específica de DApp. Tenga en cuenta que este punto final aún no está disponible en el momento de escribir este artículo.EjecutarVoucher – Envía una transacción de cadena de bloques JSON-RPC para solicitar que un cupón determinado sea ejecutado por los contratos inteligentes acumulados en la capa 1. Así es como los resultados de una DApp, como una transferencia de activos, pueden tener efecto en la cadena de bloques subyacente. Cabe señalar que los contratos solo ejecutarán realmente el bono si se ha finalizado, lo que significa que su contenido ya no puede ser discutido. Los cupones finalizados se explican con más detalle en el artículo Rollups On-Chain.

Ahora que hemos visto cómo el front-end y el back-end se comunican con el marco Cartesi Rollups, retrocedamos un poco para analizar cómo se puede implementar una DApp en la práctica.

Como se mencionó anteriormente, en Cartesi queríamos brindar una experiencia de desarrollo que fuera lo más familiar posible para los desarrolladores convencionales. Con eso en mente, definimos una serie de etapas cubriendo todo el ciclo de vida del desarrollo de una DApp Cartesi. La intención aquí es permitir que los desarrolladores utilicen su entorno de desarrollo convencional habitual para la mayor parte de sus proyectos, y para hacerlo posible, Cartesi proporcionará las herramientas y la infraestructura necesarias.

Esto implicaría el diseño conceptual general de la aplicación, especificando el alcance principal de la lógica de front-end y back-end, así como los requisitos generales de tecnología (por ejemplo, si utilizará una base de datos SQL, ejecutará un modelo de IA entrenado, etc. .)

Etapa de punto de control para implementar una prueba de concepto que garantice la viabilidad de ejecutar la lógica de back-end y las pilas de tecnología previstas dentro de una máquina Cartesi. Esta etapa puede implicar la compilación cruzada de una biblioteca con el sistema operativo Linux RISC-V de Cartesi y verificar que el rendimiento de la ejecución del software previsto en la máquina Cartesi sea satisfactorio.

Esta es la etapa en la que se implementan realmente la lógica de front-end y back-end, lo que representa la mayor parte del trabajo en el ciclo de vida de desarrollo de la DApp.

En esta etapa, el desarrollador de DApp hará uso de un entorno de host Cartesi Rollups para implementar los módulos de front-end y back-end de DApp utilizando tecnologías y herramientas comunes. Este entorno proporciona la misma API HTTP que la normal, imitando el comportamiento de los componentes Layer-1 y Layer-2 reales. De esta manera, los módulos de front-end y back-end se pueden probar como cualquier aplicación normal, como tener un front-end de aplicación web en el navegador y un back-end nativo ejecutándose en localhost. Esto permite al desarrollador ejecutarlos y depurarlos utilizando herramientas familiares, como un IDE.

Esperamos que esta característica cambie las reglas del juego en términos de productividad de desarrollo de DApp. El entorno host de Cartesi Rollups se puede ejecutar simplemente ejecutando un archivo Docker Compose, y se pueden encontrar instrucciones detalladas sobre su uso en nuestro repositorio de Rollups Github.

En esta etapa, la parte de back-end se empaqueta para ejecutarse dentro de una máquina Cartesi, para ser ejecutada por un nodo Layer-2 real (es decir, no una versión de desarrollo en la que el back-end se ejecuta directamente en el host). La viabilidad de ejecutarlo dentro de una máquina Cartesi ya debería haberse accedido durante la Etapa 2, y ahora veremos si la implementación completa de DApp también se ejecuta satisfactoriamente.

Dado que el back-end seguirá usando la misma API HTTP que antes, permanece sin cambios. La única diferencia es que esta vez interactuará con un servicio que se ejecuta dentro de la propia Máquina Cartesi, en lugar de comunicarse directamente con la infraestructura del Host de Rollups como en la Etapa 3.

Con la aplicación completa funcionando bien dentro de una máquina Cartesi, el paso final es implementarla. Esto se puede probar en un entorno local en el que una instancia de Hardhat actúa como una cadena de bloques local, pero el objetivo final es, por supuesto, implementarlo en una red de cadena de bloques remota.

Esta etapa implica publicar el back-end de DApp para que los nodos Cartesi Layer-2 puedan ejecutar su lógica dentro de una máquina Cartesi. Con ese fin, el desarrollador de DApp utilizará un script de implementación que registrará la DApp en la cadena de bloques de destino y cargará la configuración de la máquina back-end para que pueda ser utilizada por los nodos de Cartesi de destino. Tenga en cuenta que este script de implementación aún no está disponible para su uso en el momento de redactar este documento.

Estamos muy emocionados de poner esta solución a disposición de todos. Por primera vez, los desarrolladores pueden usar sus herramientas principales favoritas para crear aplicaciones descentralizadas utilizando prácticamente cualquier componente de software, mientras aprovechan un sistema operativo del mundo real y mantienen las garantías de seguridad de una cadena de bloques de Capa 1 como Ethereum.

Ya es posible comenzar a desarrollar Cartesi DApps ahora. Una vez más, le recomendamos que consulte nuestro repositorio principal de Rollups Github y explore. Pronto publicaremos seguimientos con ejemplos de código detallados de Cartesi DApps, ¡así que estad atentos!

Aparte de eso, Cartesi se está asociando actualmente con varias compañías de software convencionales para desarrollar una serie de aplicaciones de exhibición, que abarcan áreas tan diversas como juegos, IoT, finanzas e inteligencia artificial. En los meses siguientes, recopilaremos continuamente comentarios de los socios y la comunidad para iterar sobre la solución, aumentando su madurez y conveniencia de uso, y acercándola progresivamente a la disponibilidad de Mainnet.

De esta manera, Cartesi espera reducir la barrera de entrada para el océano de desarrolladores convencionales ansiosos por ingresar al espacio blockchain. Creemos firmemente que la adopción generalizada de tecnologías blockchain puede, a su vez, conducir a una explosión sin precedentes de innovación y crecimiento en el ecosistema, ayudándolo así finalmente a realizar todo su potencial.