Sobre Linux y la Cadena de Bloques
El nucleo Cartesi como un cambio de paradigma en el desarrollo de DApps
Introducción
Tomemos un momento para contemplar la complejidad de la infraestructura software que permea cada vez más aspectos de nuestras vidas. Esta infraestructura involucra sistemas operativos, bibliotecas de código, herramientas, protocolos, lenguajes de programación, compiladores y otras tecnologías. Este entorno es el resultado de un esfuerzo global continuo, llevado a cabo durante los últimos 50 años y ha consumido miles de millones de horas de trabajo.
Es esta red de componentes interdependientes la que permitió al software ser omnipresente en nuestras vidas. Sin él, ninguno de los servicios y aplicaciones en los que hemos llegado a confiar hubiera sido posible, ni siquiera concebible.
Las cadenas de bloques son un avance relativamente reciente. La innovación clave de Bitcoin fue un mecanismo a través del cual una red de agentes puede mantener consenso sobre el estado de una red compartida, de forma descentralizada. En este contexto, la descentralización significa que el Estado es mantenido por los propios participantes de tal forma que no requiere confianza mutua. Este “estado” contiene, entre otros datos, un sistema de pago.
La participación que cada integrante mantiene dentro de esta economía resultante, funciona como su incentivo para hacer que dicho estado se encuentre ampliamente disponible y para rechazar cambios inválidos al mismo. Este sistema de pagos se construye sobre el consenso descentralizado, que funciona gracias a los incentivos creados por el propio sistema de pagos. Este círculo virtuoso hace que el sistema sea autosostenible.
Ethereum amplió significativamente esta idea al permitir que las transacciones se expresen como programas arbitrarios o Contratos Inteligentes. Pronto se hizo evidente que las transacciones programables en un estado descentralizado podrían usarse para mucho más que simplemente mantener un sistema de pago. Las cadenas de bloques se convirtieron esencialmente en “computadoras globales” equitativas y descentralizadas que no pueden apagarse y no pueden ser controladas por individuos o instituciones. Y así surgió un nuevo tipo de aplicación descentralizada, llamada DApp (Decentralized Application), que habrían de ejecutarse sobre estas computadoras globales.
En comparación con los programas informáticos tradicionales, las DApps se enfrentan a dos limitaciones principales. El primero es la escalabilidad. Debido a que los contratos inteligentes deben ser ejecutados por todos los participantes en una cadena de bloques, las DApps están paralizadas por estrictos límites de cómputo, lentas tasas de transacción, reducido espacio de almacenamiento y precios altos. Este problema ha sido ampliamente reconocido como una de las limitantes clave en la adopción de la tecnología blockchain y como resultado, varios proyectos en la actualidad se enfocan en desarrollar soluciones de escalabilidad como Plasma, Sharding, Cadenas laterales, Canales estatales, etc.
La segunda limitación ha recibido mucha menos atención y es la primitiva infraestructura software. Particularmente, la falta de un Sistema Operativo.
Los sistemas operativos han sido la base sobre la que se han construido los últimos 50 años de desarrollo software. Separados de todo este legado, los desarrolladores de DApps luchan realizando tareas que son triviales en el mundo software tradicional, como transferir archivos, comprimir datos, encontrar el color de un píxel en una imagen o consultar una base de datos para obtener un registro. Incluso falta el concepto de archivo en sí.
Existe un abismo entre el inmaduro software blockchain actual y la vasta infraestructura de software que está disponible y se ejecuta en nuestras computadoras portátiles y teléfonos inteligentes.
Las DApps deben lograr una capacidad de cálculo como el de las aplicaciones “centralizadas”. Los desarrolladores de DApps debe tener acceso a los lenguajes, bibliotecas y herramientas que son estándar en los sistemas operativos modernos como Linux. Yendo aún más lejos, deberíamos esforzarnos por lograr una infraestructura de primer nivel que sea genérica y escalable mientras abstraemos los aspectos particulares de las diferentes cadenas de bloques y sus capas de consenso.
Los desarrolladores deberían poder centrarse en la lógica de sus DApps en lugar de lidiar con las complejidades de los canales estatales, las cadenas laterales y la cadena de bloques en sí. Y sobre todo, las DApps deberían ser fácilmente portables a través de diferentes cadenas de bloques.
Este tipo de infraestructura desdibujaría las líneas entre las habilidades necesarias para desarrollar aplicaciones centralizadas y descentralizadas. Allanaría el camino hacia una nueva generación de DApps que son tan inconcebibles hoy como lo era la Internet moderna hace 50 años. En Cartesi hemos perseguido ese futuro, y con ese fin, creamos una infraestructura Linux descentralizada para aplicaciones blockchain escalables.
Pero antes de adentrarnos en los detalles de nuestro proyecto, demos un vistazo a los conceptos básicos de los sistemas de capa 2, los cuales se basan en los mismos conceptos fundamentales.
Soluciones de capa 2
Las cadenas de bloques logran el consenso mediante la redundancia, replicando los procesos de cómputo y los datos en toda la red. Por esto, las DApps no pueden llevar a cabo transacciones de alta frecuencia, procesamientos complejos o almacenar grandes cantidades de datos.
El consenso global en la red es un recurso costoso, y la mayoría de los datos y el procesamiento asociados con la ejecución de una DApp (aparte de los aspectos financieros) no son de interés para toda la red y solo le competen a las pocas partes involucradas en esa DApp específica. Por ello, casi siempre es suficiente con que las partes involucradas mantengan un consenso local, mientras que las sólidas garantías que ofrece el consenso global pueden utilizarse de forma moderada para resolver disputas eventuales.
La idea general es la siguiente. Todas las partes involucradas en una DApp determinada están unidas por contratos inteligentes con incentivos Criptoeconómicos bien definidos que recompensan el comportamiento honesto y castigan la deshonestidad.
Un diseño común dicta que los contratos inteligentes requieran a todas las partes involucradas colocar un depósito como garantía antes de comprometerse con la DApp. Cuando todos los participantes están de acuerdo con un cambio en el estado local de la DApp, comunican su acuerdo y el conjunto de cambios a la cadena de bloques. Luego, la cadena de bloques reacciona modificando su estado global. Cuando alguna de las partes involucradas tiene pruebas de mala conducta, esta puede apelar a la cadena de bloques antes de que los cambios sean permanentes. Así, la blockchain se convierte en un árbitro que arbitra a favor de la parte honesta, recompensándolo con las garantías incautadas al mal actor.
Esta idea simple, pero poderosa es un mecanismo de arbitraje inspirado en interacciones ancestrales entre humanos. No involucramos a la corte suprema antes de cada interacción humana. La gran mayoría de transacciones, incluso las que involucran dinero, se liquidan localmente. No llamamos a un abogado antes de salir a comprar frutas al mercado. En cambio, tenemos un sistema que se usa solo cuando es necesario: el sistema judicial solo está involucrado en caso de disputas legales. Aplicar esta metáfora a sistemas blockchain que involucren incentivos económicos criptográficos es la clave para lograr DApps eficientes y escalables.
Cartesi: Linux en la cadena de bloques
Acabamos de ver cómo un sistema de capa 2 puede desacoplar las interacciones locales fuera de la cadena principal al tiempo que conserva sus garantías de seguridad. Ahora aprovechemos este desacoplamiento para aumentar la expresividad y el poder de la infraestructura. Se trata de un cambio de paradigma en el desarrollo de DApps al transformar la plataforma de lo que se siente como una hoja de cálculo de juguete en algo que se comporta como una computadora real ejecutando Linux.
El Nucleo Cartesi es un conjunto de tecnologías básicas que constituyen el primer paso hacia la visión que venimos discutiendo. Incluye componentes que se ubican dentro y fuera de la cadena. El componente Off-Chain es lo que llamamos Nodo Cartesi. En pocas palabras, cada participante que quiera interactuar con una DApp Cartesi lo hace a través de un Nodo Cartesi. Los usuarios pueden ejecutar su propio nodo o contratar a un tercero que represente sus intereses.
El módulo esencial dentro del nodo Cartesi es la Máquina Cartesi, una máquina virtual personalizada que emula un microprocesador RISC-V y ejecuta una distribución de Linux incorporada. Al desarrollar una DApp con Cartesi, la mayor parte de la lógica descentralizada se codificará para ejecutarse en Linux fuera de la cadena, en lugar de codificarse como contratos inteligentes ejecutables On-chain.
Máquinas Cartesi
Las máquinas Cartesi son especiales en muchos sentidos. Primero, son completamente autónomos. Esto significa que no existen fuentes externas de entropía que puedan alterar el estado de la máquina de una manera no determinista (como un teclado, un mouse o un reloj de pared).
En segundo lugar, son reproducibles. Esto significa que cuando dos máquinas Cartesi parten del mismo estado inicial y se ejecutan durante el mismo número de ciclos de procesador, alcanzan exactamente el mismo estado final. Esto es cierto independientemente de la arquitectura y el sistema operativo que aloje el nodo Cartesi.
Finalmente, las máquinas Cartesi ofrecen transparencia total. El estado se especifica y expone de tal manera que cualquier observador externo con acceso a todo el estado en un ciclo de procesador dado puede predecir el estado completo en el siguiente ciclo de procesador.
Estas propiedades de autocontención y reproducibilidad aseguran que dos participantes con acceso al estado inicial de una Máquina Cartesi obtengan los mismos resultados cuando ejecuten la máquina en sus respectivos Nodos. Naturalmente, esto es vital para el consenso. La máquina Cartesi fue diseñada específicamente para satisfacer estos requisitos, ya que desafortunadamente, esta no es una garantía en el entorno de arquitecturas hardware y máquinas virtuales tradicionales.
La propiedad de transparencia significa que podemos crear una estructura Merkle para todo el estado de una máquina Cartesi. Entre otras cosas, esto permite a la cadena de bloques representar una máquina a través de un solo hash, permitiendo a su vez, que la cadena de bloques resuelva eficientemente cualquier disputa sobre los resultados propuestos por las máquinas Cartesi.
Representacion de la Maquina Cartesi
En la figura 2, izquierda, vemos representada la máquina Cartesi fuera de la cadena. Sus componentes principales son su memoria y una variedad de unidades.
En una configuración típica, el kernel de Linux se carga en la memoria y la unidad 1 contiene un sistema de archivos con una distribución Linux incorporada. La distribución se puede configurar para arrancar y ejecutar cualquier programa en este sistema de archivos. Un programa hipotético podría procesar el input encontrado en la unidad 2 y escribir los resultados en la unidad 3. Desde el exterior, las unidades son simplemente archivos que residen en el nodo Cartesi. La máquina Cartesi los expone al kernel de Linux como dispositivos. Desde el punto de vista de los programas que se ejecutan en Linux, se pueden montar como sistemas de archivos normales y pueden contener varios directorios y archivos. La ejecución de la máquina Cartesi producirá un archivo de salida en el nodo Cartersi que contiene otro sistema de archivos, y dentro de este sistema de archivos se encuentran los resultados del cálculo deseados.
En la figura 2, derecha, vemos a la máquina Cartesi On-Chain representada por el hash de la raíz del árbol Merkle de todo su estado.
Este estado incluye la memoria y las unidades, pero también todo lo necesario para el funcionamiento de la máquina(como los valores de todos los registros y dispositivos). Los hashes de la raíz del árbol de Merkle son especiales porque permiten dos operaciones importantes.
Primero, es posible verificar o rechazar cualquier reclamo sobre el valor de cualquier parte del estado. En segundo lugar, es posible obtener el nuevo hash de la raíz del árbol Merkle correspondiente a cualquier modificación del estado. Estas operaciones se pueden realizar de manera muy eficiente dentro de la cadena de bloques. Los contratos inteligentes pueden, por ejemplo, reemplazar una unidad completa en una máquina Cartesi y obtener el nuevo hash raíz correspondiente. En sentido contrario, una vez obtenido el hash raíz final para una máquina Cartesi y el hash de una unidad de salida, los contratos inteligentes pueden verificar que la unidad realmente pertenezca a esa máquina.
Solucion de disputas
Consideremos a dos actores, Alice y Bob, ambos involucrados en una transacción controlada por un contrato inteligente. Supongamos que la transacción implica algún cálculo complejo que no es práctico de ejecutar en cadena. Ahora suponga además que el contrato inteligente conoce el hash raíz inicial para una máquina Cartesi que, cuando se inicia, ejecuta un programa alojado en la unidad 1 y que realiza dicho cálculo utilizando la entrada de la unidad 2 y escribe la salida en la unidad 3. Usando operaciones hash eficientes, el contrato inteligente puede reemplazar la unidad 2 con la entrada deseada. A continuación, puede solicitar a Bob el hash raíz que resulta de ejecutar la máquina Cartesi correspondiente fuera de la cadena.
Ahora tenemos dos posibilidades. Si Alice está de acuerdo con Bob, el contrato inteligente, satisfecho de que tanto Alice como Bob estarán de acuerdo con los resultados, puede continuar solicitando a Bob detalles sobre la unidad 3. Si Alice no está de acuerdo, se inicia una disputa depositando una garantía. Si Bob quiere defenderse de la disputa, responde depositando la misma garantía. (De lo contrario, después de un tiempo de espera, se considera que ha perdido el derecho). Lo que sigue es un protocolo interactivo, que involucra a Alice y Bob y mediado por la cadena de bloques, que garantiza que quienquiera que sea honesto ganará la disputa.
El juego de verificación [Feige y Kilian 1997] es un algoritmo que permite a un árbitro con recursos computacionales limitados mediar en un juego entre dos jugadores computacionalmente ilimitados. En nuestro caso, el mediador limitado es un conjunto de contratos inteligentes que se ejecutan en la cadena de bloques. Los reproductores ilimitados son las máquinas Cartesi que se ejecutan en los nodos Cartesi de Alice y Bob. TrueBit también utiliza este procedimiento, y se puede encontrar una explicación detallada en este gran artículo de Sina Habibian.
En pocas palabras, utilizando una búsqueda n-ary, un contrato inteligente identifica el último ciclo del procesador en el que Alice y Bob acuerdan sobre el hash raíz de todo el estado de la máquina Cartesi. Luego, la cadena de bloques ejecuta una sola instrucción RISC-V para obtener el hash raíz para el siguiente estado. Se sabe que Alice y Bob no están de acuerdo con este hash. Al identificar quién publicó los resultados correctos, el contrato inteligente puede arbitrar a favor de la parte honesta y recompensarla con ambas garantías.
Ejecutar una sola instrucción RISC-V es sencillo y rentable para la cadena de bloques. La ubicación de la instrucción solo requiere tiempo y espacio logarítmicos. Además, este proceso solo se inicia en caso de haber una disputa, las cuales son extremadamente raras, porque las trampas siempre serán descubiertas y conllevan una penalización.
Juegos por turnos: un ejemplo completo
Como ejemplo concreto, mostraremos cómo Cartesi puede simplificar enormemente el trabajo de un desarrollador de DApps implementando un juego por turnos, como Go o Chess.
Alice y Bob jugarán por dinero, el ganador se lo lleva todo. Los jugadores están representados en el juego por los componentes DApp que se ejecutan dentro de sus nodos Cartesi. Empiezan un nuevo juego depositando el valor de sus apuestas en un contrato inteligente. Después de esto, el juego continúa casi completamente fuera de la cadena.
Alice y Bob mantienen la secuencia completa de movimientos “Merkelizados” fuera de cadena. Llamemos al hash raíz de este árbol el hash de secuencia. Cuando le toca a Alice hacer un movimiento, lo agrega a la secuencia, obtiene un nuevo hash de secuencia y lo firma. Luego envía el movimiento, el hash de secuencia y la firma a Bob utilizando un canal de estado. Bob valida el movimiento de Alice, lo agrega a su copia de la secuencia de movimientos, calcula el hash de la secuencia, confirma que coincide con el de Alice y luego verifica su firma. Si todo va bien, ahora es su turno. El juego procede de esta manera hasta que suceda una de dos cosas: dejan de jugar correctamente de forma prematura o uno de ellos finalmente gana el juego.
Supongamos que Bob quiere reclamar la victoria. Publica el hash de secuencia de Alice, su firma y su movimiento ganador en la cadena de bloques. Un contrato inteligente primero verifica la firma de Alice en el hash de la secuencia. Luego delega la decisión del ganador de “finalizar el juego” a una Máquina Cartesi (que se ejecuta inicialmente en el propio nodo de Bob, como mostraremos en breve). Esta es una máquina que, dada una secuencia de movimientos en el drive 2 y un movimiento final en el drive 3, se detiene con un código de salida de éxito si el movimiento gana el juego, o con falla, si no lo hace.
El software que se ejecuta dentro de esta máquina Cartesi fue escrito por el desarrollador en el lenguaje de programación de su elección. Es libre de aprovechar toda la infraestructura moderna y el software de código abierto disponibles dentro de un sistema operativo Linux que se ejecuta sin limitaciones de recursos artificiales en una máquina RISC-V autónoma.
Para definir el estado inicial de la máquina que finaliza el juego, el contrato inteligente utiliza operaciones hash para reemplazar la unidad 2 con la secuencia de movimientos proporcionada por Alice y para reemplazar la unidad 3 con el movimiento final de Bob. El contrato exige a Bob ejecutar la máquina correspondiente fuera de la cadena y finalmente publicar en la cadena de bloques el hash secuencia de su estado final. Si Bob dice la verdad, podrá defenderse de cualquier desafío potencial de Alice con respecto al valor de este hash. Bob también podrá demostrarle a la cadena de bloques que la máquina finalizadora se detuvo a su favor al mostrar que la palabra designada como código de salida en su memoria tiene el valor apropiado. Sin embargo, si Bob está mintiendo, Alice disputará su hash final y ganará el juego de verificación subsiguiente.
Un problema interesante ocurre cuando los jugadores dejan de colaborar entre sí de forma prematura. Quizás sea el turno de Bob y, al darse cuenta de que su posición es desesperada, se niega a enviar su movimiento a Alice. Por sí sola, la cadena de bloques no tiene forma de saber si esto realmente está sucediendo, o si Alice es la que ignora los intentos de Bob de contactar a través del canal de estado. Afortunadamente, existen formas de resolver este problema de disponibilidad de datos. Una solución simple es la siguiente. Frustrada con el comportamiento de Bob, Alice informa a la cadena de bloques. Enviando el último hash de secuencia de Bob y su firma. La cadena de bloques le ofrece a Bob la oportunidad de enviar un hash de secuencia aún más reciente firmado por Alice. Ahora ambos jugadores deberán enviar sus siguientes movimientos a través de la cadena de bloques.
A partir de ahora, todo lo que la cadena de bloques tiene que hacer es controlar los turnos, aceptar un nuevo movimiento del jugador correcto y usar operaciones hash para mantener actualizado el hash de la secuencia. Si uno de los jugadores deja de publicar movimientos, el otro puede reclamar un tiempo muerto y ganar la apuesta. Si uno de los jugadores reclama la victoria, la cadena de bloques tiene toda la información necesaria para reconstruir la máquina “finalizadora” como se hizo antes: problema resuelto.
Ventajas de este diseño
Las ventajas de este diseño son que toda la complejidad, el procesamiento y el almacenamiento de datos asociados con el juego ocurren fuera de la cadena de bloques. Una parte de este proceso se ejecuta en el nodo Cartesi y otra parte en la máquina Cartesi. Ambos sistemas ejecutan Linux, donde los desarrolladores son más productivos. En el escenario típico en el que los jugadores cooperan, la cadena de bloques simplemente acepta las apuestas cuando comienza un juego y las transfiere al ganador cuando termina. Cuando los jugadores dejan de cooperar, la cadena de bloques todavía tiene muy poco trabajo por hacer, pues solo debe mantener actualizado el hash secuencia. Nunca almacena la secuencia de movimientos, no necesita acceder al estado del juego, ni siquiera se preocupa por sus reglas. Incluso cuando surge una disputa, el Nucleo Cartesi la resuelve automáticamente.
Solo podemos empezar a imaginar el incremento en productividad que un diseño como este aporta al desarrollo de blockchain y la variedad de aplicaciones que esta escalabilidad permite.
El futuro
No hace falta decir que estas DApps implicarán cálculos verificables sobre grandes cantidades de datos, y aprovecharán la vasta infraestructura de software disponible para los desarrolladores en Linux. La misión de Cartesi es cerrar la brecha entre las aplicaciones centralizadas y descentralizadas, tanto en términos de posibilidad como de conveniencia y el Nucleo Cartesi es solo el primer paso.
Continuaremos trabajando para eliminar todas las limitaciones de las DApps impulsadas por Cartesi. Ofreceremos canales de estado inadvertibles y un protocolo de intercambio de datos verificable Off-chain. Crearemos un nuevo entorno de programación que integre el desarrollo de todos los componentes de una DApp Cartesi. En última instancia, haremos que las DApps sean fácilmente portables a través de diferentes cadenas de bloques.
Esperamos que, al empoderar a los desarrolladores de DApps, les ayudemos a crear productos que sean cada vez más atractivos para los usuarios y nos acerquemos a un futuro en el que la descentralización se vuelva menos onerosa.
Si quieres conocer los detalles sobre cómo abordamos los problemas de escalabilidad que enfrentan las cadenas de bloques. Te invitamos a leer el siguiente artículo:
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):
Telegram Announcements | Telegram | Discord (Development Community) | Reddit | Twitter | Github | StackOverflow | LinkedIn | Facebook | Instagram | Youtube | Cartesi Improvement Proposal (CIP) | Website
Únete a la conversación en Español:
Esta es una traducción y adaptación para la comunidad hispana de Cartesi.
Artículo originalmente publicado en el blog oficial de Cartesi: https://medium.com/cartesi/on-linux-and-blockchains-a955a49a84e1
La información presentada aquí no constituye un consejo de inversión ni una oferta para invertir. Las declaraciones, puntos de vista y opiniones expresadas en este artículo son únicamente las del autor.
