Radix Engine: un mejor modelo para la “consagración”

En mi Artículo anterior , repasé cómo Radix Engine evitó algunas de las fallas en MoveVM de Sui. Para resumir:

• MoveVM de Sui es demasiado genérico y de bajo nivel, lo que lo convierte en un entorno de programación DeFi engorroso.
• Radix Engine es de alto nivel y está orientado a la lógica empresarial + activos, lo que permite a los desarrolladores centrarse en la lógica DeFi en lugar de en los detalles de bajo nivel.

MoveVM de Sui sigue el original Filosofía etérea de un protocolo “limpio, simple y hermoso”, que delega todo a la capa de aplicación. Esto permite a los desarrolladores la libertad de explorar cualquier dominio, incluidos los desconocidos en ese momento.

Sin embargo, un protocolo demasiado simple y desestructurado crea compromisos importantes. Por ejemplo, las características comunes del sistema, como la autorización, requerirían una implementación compleja en el espacio de la aplicación, las interfaces estándar pueden volverse más fragmentadas y la optimización del rendimiento se vuelve más difícil.

Radix Engine, por otro lado, está diseñado para ejecutar lógica no genérica en todo el sistema como objetivo técnico central, ya que nos permite hacer lo siguiente:

• Hacer cumplir los estándares/implementaciones en todo el sistema . Un estándar obstinado permite que el desarrollo/mantenibilidad/herramientas sean más fáciles en toda la pila, ya que las API no están fragmentadas (por ejemplo, ERC-20 frente a ERC-721 frente a ERC-404) y comprender el comportamiento no requiere interpretación de código de bytes (no más Tiradores de alfombras ERC-20). Esto brinda a los desarrolladores y usuarios finales una experiencia DeFi más segura y consistente.
• Ejecute la lógica más cerca del hardware . Como no es necesario que un intérprete ejecute la lógica del sistema para que sea correcta, la ejecución de esa lógica se puede ejecutar lo más cerca posible del hardware.
• Paralelizar la ejecución. Al tener conocimiento directo del comportamiento de ciertos objetos, es más fácil tomar decisiones de análisis estático antes de la ejecución, lo que permite la ejecución paralela.

Vitalik abordó recientemente esta idea con el término “ consagración ”, o la idea de romper selectivamente con la abstracción para obtener los beneficios de la lógica impuesta por protocolo. Al robar una de sus imágenes, plantea el problema como un equilibrio entre abstracción y consagración:

Este equilibrio entre apoyar la abstracción (es decir, las necesidades futuras/diversas de los usuarios) y al mismo tiempo mantener el rendimiento/seguridad/usabilidad (es decir, la consagración) es en realidad un problema informático muy antiguo. El diseño de sistemas operativos específicamente ha estado tratando de resolver un problema similar durante las últimas décadas: ¿Cómo soportamos una variedad de aplicaciones abstractas mientras mantenemos un sistema rápido, seguro y utilizable?

En este artículo, repasaré cómo Radix Engine utiliza el modelo de sistema operativo para crear un marco capaz de realizar todo tipo de "consagración" sin la carga de complejidad del protocolo o la pérdida de flexibilidad que teme Vitalik.

Comencemos mirando el estándar actual de la industria, la Máquina Virtual Ethereum (“EVM”).

EVM como máquina virtual

El EVM es lo suficientemente básico como para modelarlo como una máquina virtual (“VM”) con los siguientes códigos de operación:

• Conjunto de códigos de operación completos de Turing
• Códigos de operación para llamadas a otros contratos inteligentes
• Códigos de operación para lectura/escritura en almacenamiento persistente propiedad del contrato inteligente actual

Los contratos inteligentes compilados en código de bytes EVM se pueden ejecutar sobre dicha VM.

En este modelo, cualquier forma de “consagración” requiere cambios en el EVM o el hardware de la VM. Por ejemplo, consagrar el soporte de firma BLS requeriría agregar una nueva precompilación. Implementar EIP-2938 requeriría la adición de nuevos códigos de operación. Ampliar lo que está consagrado inevitablemente da como resultado una máquina virtual más grande y complicada y obliga al diseñador del protocolo a tomar una decisión u otra que describe Vitalik.

El problema general con este modelo es que la dicotomía Abstracción/Consagración está demasiado acoplada con la dicotomía Software/Hardware. Es decir, consagrar cualquier lógica en el protocolo obliga a integrarla en la máquina virtual. No hay forma de expresar “software consagrado” o software que forma parte del sistema.

Los sistemas operativos resolvieron esta dicotomía con la noción de "software del sistema". Miremos más de cerca.

El modelo de sistema operativo

Uno de los principales objetivos de un sistema operativo es gestionar la dicotomía software/hardware o, más específicamente, la dicotomía aplicación/hardware. La parte central de cualquier sistema operativo es el kernel, el software que gestiona las aplicaciones del espacio del usuario y su acceso al hardware. Los módulos y controladores del kernel son piezas adicionales de software del sistema que amplían el conjunto de hardware compatible o amplían la funcionalidad del kernel.

\Desde una perspectiva de “consagración”, el núcleo y sus módulos son partes consagradas del sistema pero tienen la flexibilidad del software. Los módulos del kernel, las máquinas virtuales (“VM”) y los procesos del sistema en el espacio del usuario son aún más “suaves” ya que se abstraen del propio kernel.

En este modelo, la capa de indirección entre aplicaciones y hardware permite que la dicotomía software/hardware se desacople de la dicotomía abstracción/consagración. El “software del sistema” permite la consagración sin sobrecargar el hardware.

Radix Engine como sistema operativo

Utilizando este modelo de sistema operativo como inspiración, Radix Engine incluye múltiples capas, cada una con una responsabilidad y abstracción específicas, lo que permite la modularidad y la capacidad de conexión del sistema.

Este diseño modular permite aplicar la lógica del sistema y al mismo tiempo permite lo siguiente:

• Hereda las propiedades de aislamiento de la capa en la que se encuentra . Por ejemplo, un paquete consagrado, aunque consagrado, no puede acceder a un estado arbitrario sino que debe seguir los límites de la capa de aplicación. Este es un tipo de seguridad similar al que se ve en los controladores del espacio de usuario o en el diseño de microkernel. Es decir, el riesgo se mitiga aislando cada parte del sistema para que cualquier actualización en el sistema (consagración) no exponga a todo el sistema a riesgos.
• Acceda a las funciones de la capa en la que se encuentra. Por ejemplo, un paquete consagrado puede heredar funciones de autenticación y/o capacidad de actualización proporcionadas por el sistema.
• Desacoplar la gobernanza. Este diseño modular permite que la innovación en cada uno de estos módulos se produzca en paralelo y a diferentes ritmos.

Repasemos ahora cada una de estas capas y veamos cuáles son sus responsabilidades.

Capa de aplicación

La capa de aplicación es responsable de definir la lógica de alto nivel. El código de bytes que describe esta lógica, junto con otra información estática, se incluye en un formato ejecutable llamado Paquete. Luego, los paquetes se almacenan en el libro mayor y están disponibles para su ejecución.

Las aplicaciones escritas en Scrypto, el lenguaje basado en Rust que hemos creado para el desarrollo de DeFi, se encuentran en esta capa. Los programas Scrypto se compilan en programas WASM con acceso a un conjunto de exportaciones de funciones que permiten al programa acceder a los servicios del sistema/kernel. Este API de llamada al sistema es similar al linux llamadas al sistema , que proporcionan acceso a E/S compartidas.

Capa de máquina virtual

Pasando a la siguiente capa, la capa VM es responsable de proporcionar el entorno informático para la capa de aplicación. Esto incluye una VM completa de Turing, así como la interfaz para acceder a la capa del sistema.

Radix Engine actualmente admite dos máquinas virtuales: una máquina virtual Scrypto WASM utilizada para ejecutar aplicaciones Scrypto y una máquina virtual nativa que ejecuta paquetes nativos que se compilan en el entorno del host.

Si echamos un vistazo específicamente a la VM Scrypto WASM, se ve así:

Puede parecer esencialmente igual que el modelo EVM, pero existen dos diferencias cruciales:

• Eliminación del acceso directo al almacenamiento. En lugar de que cada contrato inteligente pueda acceder solo al almacenamiento de su propiedad, cualquier lectura/escritura de estado se realiza a través de llamadas al sistema. Esta capa de indirección permite implementar muchas cosas interesantes en el sistema, como compartir el estado entre aplicaciones, virtualización de estado, etc. Esta capa de indirección es similar a la indirección proporcionada por memoria virtual o de linux descriptores de archivos .

  
  

• Adición de llamadas al sistema . Las llamadas al sistema son el mecanismo por el cual la capa de aplicación puede acceder a los servicios de la capa del Sistema, como realizar invocaciones a otras aplicaciones o escribir datos en un objeto. Estas llamadas al sistema son similares a las instrucciones de interrupción de software en CPU reales (p. ej., EN T instrucción en x86).

Capa del sistema

La capa del sistema es responsable de mantener un conjunto de módulos del sistema o software conectable que puede ampliar la funcionalidad del sistema. Estos son similares a los de Linux. módulos del núcleo .

En cada llamada al sistema, se llama a cada módulo del sistema antes de que la capa del sistema pase el control a la capa del núcleo. Cuando se llama, cada módulo del sistema puede actualizar algún estado particular (por ejemplo, tarifas de actualización gastadas) o entrar en pánico para finalizar la transacción (por ejemplo, si falla el verificador de tipo).

Este patrón permite que el sistema implemente funciones como autorización, regalías o verificación de tipos mientras está desacoplado de las capas de aplicación y kernel.

Capa de núcleo

La capa del kernel es responsable de las dos funcionalidades principales de Radix Engine: acceso al almacenamiento y comunicación entre aplicaciones. Esto es algo similar a la responsabilidad del sistema operativo tradicional por el acceso al disco y a la red.

Para Radix Engine, esto incluye la siguiente gestión de bajo nivel:

• Compruebe que la semántica de movimiento/préstamo se mantenga en cualquier invocación o escritura de datos. El núcleo aplica la regla de propietario único y las reglas de préstamo. Si falla alguna de estas reglas, la transacción entrará en pánico.
• Administre objetos transitorios versus persistentes. Un objeto puede estar en el espacio global en cualquier momento o puede ser propiedad de un marco de llamada. El kernel mantiene punteros correctos a estos objetos durante el tiempo de ejecución a medida que se pasan referencias a estos objetos.
• Gestionar actualizaciones del estado de las transacciones. El kernel realiza un seguimiento de las actualizaciones de estado que se produjeron durante una transacción y que posteriormente se enviarán a la base de datos al final de la transacción.

Software consagrado

¿Cómo se relacionan estas capas con la consagración en un protocolo DLT? De manera similar a la capa del núcleo en los sistemas operativos, estas capas intermedias de Radix Engine proporcionan la dirección indirecta necesaria para desacoplar la dicotomía abstracción/consagración de la dicotomía software/hardware y crear la noción de "software consagrado".

El software consagrado tiene las propiedades de flexibilidad y seguridad del software y, al mismo tiempo, mantiene la capacidad de aplicar la lógica en todo el sistema.

Repasemos algunos ejemplos de consagración que se ejecutan actualmente en la red Radix y veamos cómo se implementan.

Recursos consagrados

El principal diferenciador de la plataforma Radix DeFi/Web3 es la idea de que un recurso (es decir, un activo) es una primitiva fundamental que debe entenderse independientemente de la lógica empresarial. Consagrar este concepto permite que todas las dApps, billeteras y herramientas tengan una comprensión común de cómo se ve la interfaz y el comportamiento de un activo, lo que hace que la componibilidad sea mucho más fácil.

Aunque los recursos son una de las partes más arraigadas del sistema, implementar su consagración solo requiere dos piezas modulares de software:

• Un paquete nativo que maneja la lógica de objetos de recursos como Buckets, Vaults y Proofs.

• Un módulo del sistema que impone las invariantes de vida útil de estos objetos (como la movilidad y quemabilidad de los recursos)

  
  

El hecho de que Radix Engine pueda expresar el concepto profundo de un recurso móvil estandarizado mientras se abstrae del sistema/núcleo muestra el poder de un marco de software de sistema modular.

Autorización y Regalías Consagradas

Radix Engine estandariza la autorización y las regalías al desacoplar esta lógica de la lógica empresarial e implementarlas como características del sistema. Esto permite a los usuarios y desarrolladores tener una forma común integrada de comprender los requisitos para acceder a cualquier función del libro mayor.

La modularidad de desacoplar la lógica de negocios de la lógica del sistema también permite opciones convenientes de desarrollo/depuración, como la capacidad de obtener una vista previa de una transacción sin las verificaciones de autenticación normales (¿quiere simular el resultado de enviar 10 millones de USDC a algún lugar? Con la autorización deshabilitada, su transacción de vista previa puede hacer la acuñación!).

Para consagrar la autenticación y las regalías se requieren cuatro piezas de software modular:

• Paquetes nativos de autenticación y regalías que permiten a la capa de aplicación acceder a la autenticación/regalías de cualquier objeto (por ejemplo, para recuperar la regla de autenticación para acceder a un método o reclamar regalías).

• Los módulos del sistema Auth y Royalties se llaman antes de una llamada al método de objeto para verificar si la persona que llama tiene autorización suficiente para realizar la llamada y cobrar regalías.

  
  

  
  

Transacción consagrada

La interfaz correcta entre el usuario y el sistema es primordial para que cualquier sistema sea utilizable. Para ser utilizable, la interfaz debe encontrar el equilibrio adecuado entre facilidad de uso y potencia/flexibilidad.

En el mundo de los sistemas operativos, la interfaz más común es la terminal, un proceso de espacio de usuario que le brinda al usuario una herramienta de línea de comandos para llamar y componer varias llamadas al sistema.

En el mundo DLT, esta interfaz es la transacción. El estándar de la industria para una transacción es utilizar una única llamada de invocación genérica de bajo nivel. Desafortunadamente, esto es demasiado simple porque dificulta entender lo que uno hace realmente cuando interactúa con el sistema.

Radix Engine, por otro lado, utiliza el patrón de sistema operativo tradicional y consagra un lenguaje de aplicación (similar a un lenguaje de scripting de terminal como bash) para llamar y componer llamadas al sistema en una sola transacción.

Debido a que el punto de entrada de una transacción opera en la capa de aplicación, el intérprete de lenguaje se implementa agregando un paquete nativo del Procesador de transacciones.

BLS consagrado

Las firmas BLS son una primitiva criptográfica importante, ya que permiten la posibilidad de firmas de umbral. Desafortunadamente, ejecutar dicha lógica en WASM consume rápidamente la unidad de costo máxima. En la reciente actualización "Anemone", consagramos BLS ejecutándolo de forma nativa y encontramos una ganancia de rendimiento 500 veces mayor en comparación con WASM.

Debido a que la lógica BLS no tiene estado, se puede agregar fácilmente como una precompilación adicional a la VM Scrypto WASM.

Conclusión

Qué consagrar y qué no consagrar es importante para cualquier protocolo DLT. Desafortunadamente, el modelo VM existente en la industria hace que cada decisión de consagración sea una decisión de alto riesgo.

Con el modelo de sistema operativo como inspiración, Radix Engine resuelve este problema agregando una capa de direccionamiento indirecto entre "software" y "hardware". Esto permite a Radix Engine expresar la noción de "software consagrado" y facilita que el protocolo agregue, modifique y exprese nuevos sistemas consagrados sin tomar decisiones comprometedoras de alto riesgo.

Originalmente, el sistema operativo estaba destinado a ser una pequeña pieza de software diseñada para administrar recursos compartidos para múltiples aplicaciones. A medida que crecieron las demandas de los usuarios de una plataforma mejor, más rápida y más segura, ha asumido cada vez más responsabilidad con un conjunto de software cada vez mayor.

DeFi no será diferente. A medida que crezca la demanda de una plataforma DeFi más rápida, más segura y más utilizable, seguirá una mayor consagración. Radix Engine se diseñó con esto en mente y proporciona el marco escalable y seguro necesario para expandir la consagración en el futuro.