Máquina virtual personalizada (Custom VM)

¿Qué es una máquina virtual personalizada?

Una máquina virtual personalizada, o Custom VM, es un entorno de ejecución blockchain diseñado con sus propias reglas para procesar transacciones, ejecutar programas, gestionar el estado y medir los recursos computacionales.

En pocas palabras, una Custom VM es la parte de una blockchain que determina qué pueden hacer los programas y cómo modifica cada transacción válida el estado de la blockchain.

Un equipo puede crear una Custom VM en lugar de utilizar un entorno ya existente, como la Ethereum Virtual Machine, si necesita unas características diferentes de rendimiento, seguridad, programación, privacidad o aplicaciones.

La palabra «personalizada» significa que el entorno de ejecución se ha creado, modificado u optimizado para las necesidades de una blockchain, un rollup, una cadena de aplicaciones o un sistema de pruebas criptográficas concretos.

Una Custom VM puede introducir su propio conjunto de instrucciones, estructura de cuentas, reglas de almacenamiento, formato de transacciones, modelo de comisiones, funciones del sistema y lenguaje de contratos inteligentes.

También puede modificar una máquina virtual existente, en vez de diseñarse íntegramente desde cero.

Por ejemplo, la documentación oficial de Solana sobre la ejecución de programas describe sBPF como una variante personalizada del bytecode eBPF adaptada al entorno de ejecución de su blockchain.

Una Custom VM es importante porque los nodos de una blockchain deben ejecutar las transacciones exactamente de la misma manera para llegar a un acuerdo sobre los saldos, los contratos, la titularidad y el estado de las aplicaciones.

Si dos nodos honestos ejecutan la misma transacción y obtienen resultados diferentes, la red puede bifurcarse o rechazar el bloque.

Por este motivo, una VM de blockchain debe ser determinista, segura, tener límites de recursos y estar especificada con precisión.

¿Qué hace una máquina virtual blockchain?

Una máquina virtual blockchain actúa como un ordenador controlado cuya ejecución puede reproducir cada nodo validador.

Recibe transacciones o instrucciones de programas y las aplica al estado actual de la blockchain.

La VM comprueba si la transacción cumple las reglas del protocolo, si el remitente tiene la autorización necesaria y si hay recursos suficientes para ejecutarla.

A continuación, realiza las operaciones permitidas, como transferir tokens, modificar el almacenamiento de un contrato, acuñar un NFT, actualizar una posición de préstamo o emitir un voto de gobernanza.

Tras la ejecución, la VM genera un nuevo estado que los demás nodos pueden verificar de forma independiente.

La documentación de la Ethereum Virtual Machine describe la EVM como un entorno virtual descentralizado que ejecuta código de forma coherente en los nodos de Ethereum.

Una Custom VM cumple la misma función general, pero puede utilizar una arquitectura y unas reglas de ejecución diferentes.

Normalmente, la VM no se ocupa de todos los aspectos de la blockchain.

El consenso determina cómo acuerdan los nodos el orden y la aceptación de los bloques, mientras que la VM determina qué hacen las transacciones ordenadas.

La disponibilidad de los datos determina si se pueden recuperar los datos de las transacciones necesarios para la verificación.

La liquidación determina dónde reciben reconocimiento definitivo los resultados, las pruebas o las disputas en los sistemas modulares.

La Custom VM pertenece específicamente a la capa de ejecución, aunque su diseño puede afectar a todas estas otras capas.

Por qué las blockchains crean Custom VM

Las blockchains crean Custom VM cuando los entornos de ejecución de propósito general no ofrecen el rendimiento o las características que necesitan sus aplicaciones previstas.

Una blockchain diseñada para trading de alta frecuencia podría requerir ejecución paralela de transacciones, comisiones previsibles y acceso rápido al estado.

Un videojuego en blockchain podría necesitar activos digitales nativos, acciones de bajo coste, permisos de cuenta y almacenamiento eficiente de objetos del juego.

Una cadena centrada en la privacidad podría necesitar un estado confidencial, compatibilidad con pruebas de conocimiento cero y acceso restringido a los datos.

Un rollup podría requerir un entorno de ejecución fácil de probar mediante criptografía de conocimiento cero.

Una blockchain específica para aplicaciones podría necesitar únicamente un conjunto reducido de operaciones controladas, en lugar de una plataforma de contratos inteligentes de propósito general.

Una Custom VM permite a los desarrolladores optimizar la blockchain en función de estos objetivos.

La contrapartida es que el equipo debe crear y mantener más infraestructura por su cuenta.

Podría necesitar compiladores, carteras, depuradores, exploradores de bloques, herramientas de seguridad, kits de desarrollo de software y documentación para desarrolladores propios.

Una VM muy optimizada puede ofrecer un rendimiento excelente, pero quizá tenga dificultades para atraer desarrolladores si sus herramientas son difíciles de utilizar.

Custom VM frente a Ethereum Virtual Machine

La Ethereum Virtual Machine, o EVM, es el entorno de ejecución utilizado para los contratos inteligentes de Ethereum y se ha convertido en un objetivo de compatibilidad ampliamente adoptado en el sector cripto.

Los desarrolladores suelen escribir contratos EVM en Solidity o Vyper y compilarlos a bytecode EVM.

La EVM utiliza una arquitectura basada en pila y mide la ejecución mediante gas.

Su amplio ecosistema de desarrolladores incluye carteras, bibliotecas, marcos de pruebas, herramientas de seguridad y estándares de contratos consolidados.

Una Custom VM puede diferir de la EVM en casi todas las decisiones de diseño importantes.

Puede utilizar registros en lugar de una pila, admitir la ejecución paralela, emplear un modelo de cuentas diferente o cobrar los recursos mediante unidades de cómputo o ponderaciones en vez de gas de la EVM.

También puede admitir lenguajes de programación que normalmente no se utilizan para los contratos EVM.

La principal ventaja de utilizar la EVM es la compatibilidad.

La principal ventaja de una Custom VM es la libertad para optimizar el entorno de ejecución con un fin concreto.

Sin embargo, la compatibilidad con la EVM y la ejecución personalizada no siempre son opciones completamente opuestas.

Algunas redes utilizan una VM central personalizada y añaden un intérprete o una capa de compatibilidad para el bytecode EVM.

Por ejemplo, la documentación oficial de EraVM describe una arquitectura en la que una VM optimizada para pruebas ZK sigue siendo el entorno de ejecución central, mientras que un intérprete EVM admite bytecode al estilo de Ethereum.

Este enfoque puede ofrecer cierta compatibilidad con el ecosistema sin renunciar a todas las ventajas de la ejecución personalizada.

Custom VM frente a entorno de ejecución blockchain personalizado

En ocasiones, los términos Custom VM y entorno de ejecución blockchain personalizado se utilizan como si significaran exactamente lo mismo, pero la diferencia puede ser importante.

Una máquina virtual suele ejecutar bytecode de acuerdo con un conjunto de instrucciones definido.

Entorno de ejecución es un término más amplio que se refiere a la lógica que procesa las transacciones y define las transiciones de estado de una blockchain.

Algunas blockchains utilizan una VM tradicional en la que los desarrolladores implementan bytecode independiente de contratos inteligentes.

Otras compilan la mayor parte de la lógica de negocio de la cadena en un único entorno de ejecución, en lugar de ofrecer una VM de contratos inteligentes sin restricciones.

La documentación del nodo y del entorno de ejecución del SDK de Polkadot describe el entorno de ejecución como la lógica de transición de estado de la blockchain, compilada en WebAssembly para ejecutarse de forma independiente de la plataforma.

La documentación de arquitectura del SDK de Cosmos describe una aplicación blockchain como una máquina de estados ensamblada a partir de módulos que definen la lógica de negocio y procesan las transacciones.

Estos sistemas ofrecen ejecución personalizada, aunque los desarrolladores pueden referirse al resultado como un entorno de ejecución, una máquina de estados de aplicación o un entorno de ejecución, en lugar de una Custom VM.

Por tanto, en los debates sobre criptomonedas, el término Custom VM se utiliza a veces de forma imprecisa.

Los usuarios deberían examinar la arquitectura real en vez de confiar únicamente en la denominación.

Componentes principales de una Custom VM

Conjunto de instrucciones

El conjunto de instrucciones define las operaciones de bajo nivel que pueden ejecutar los programas.

Las instrucciones pueden realizar operaciones aritméticas, leer memoria, escribir en el almacenamiento, comparar valores, verificar firmas, llamar a otro contrato o devolver datos.

Un conjunto de instrucciones más reducido puede ser más fácil de analizar y demostrar, mientras que uno más amplio puede ofrecer más funciones directamente.

Los diseñadores de Custom VM deben garantizar que cada instrucción tenga un significado claro y determinista.

Modelo de estado

El modelo de estado define cómo representa la blockchain las cuentas, los saldos, los contratos, los tokens, los objetos y los datos almacenados.

Algunas VM utilizan un estado global basado en cuentas, similar al de Ethereum.

Otras utilizan salidas de transacciones no gastadas, objetos independientes, almacenes clave-valor o registros específicos de una aplicación.

El modelo de estado influye considerablemente en la ejecución paralela de transacciones, el diseño de las carteras, los permisos de los contratos y la experiencia de los desarrolladores.

Memoria y almacenamiento

Por lo general, la memoria se refiere a los datos temporales utilizados durante una ejecución, mientras que el almacenamiento hace referencia a los datos persistentes que permanecen una vez finalizada la transacción.

El almacenamiento persistente en blockchain es costoso porque los nodos validadores deben reproducir o verificar los cambios realizados.

Una Custom VM puede introducir estructuras de almacenamiento especializadas para reducir costes o mejorar la generación de pruebas.

Las reglas de almacenamiento deben impedir que un contrato modifique sin autorización los datos de otro contrato.

Medición de recursos

La medición de recursos limita la cantidad de cómputo, memoria, almacenamiento y ancho de banda que puede consumir una transacción.

Sin límites de recursos, un atacante podría enviar un programa que se ejecutara indefinidamente o consumiera tantos recursos que impidiera a los nodos procesar otras transacciones.

La EVM utiliza gas, mientras que otros entornos de ejecución pueden utilizar unidades de cómputo, ponderaciones, ciclos u otras categorías de recursos.

El esquema de recursos debe asignar un coste suficiente a las operaciones caras para evitar abusos, sin que las aplicaciones legítimas resulten inviables.

Funciones del host y llamadas al sistema

Las Custom VM suelen ofrecer funciones del host o llamadas al sistema que los programas pueden utilizar para acceder a características específicas de la blockchain.

Estas funciones pueden verificar firmas criptográficas, leer información de bloques, llamar a otro programa, crear un activo, emitir un evento o acceder a datos externos autorizados.

La referencia de llamadas al sistema de Solana documenta funciones del entorno de ejecución para criptografía, registro de eventos, operaciones de memoria, llamadas entre programas y otras acciones de blockchain.

Las llamadas al sistema pueden mejorar la eficiencia, pero cada una amplía la superficie que debe especificarse, probarse y protegerse.

Cómo se ejecutan las transacciones dentro de una Custom VM

Normalmente, una transacción llega a la blockchain a través de un nodo o un endpoint RPC.

La red comprueba propiedades básicas como el formato, las firmas, las comisiones y la protección contra la repetición de transacciones.

El consenso o el software de producción de bloques determina la posición de la transacción con respecto a las demás.

A continuación, la Custom VM carga la transacción, el estado correspondiente y el programa que debe ejecutarse.

Verifica los permisos e inicializa el contexto de ejecución.

La VM procesa las instrucciones y realiza un seguimiento del consumo de recursos.

Si la ejecución finaliza correctamente, se confirman los cambios resultantes en el estado.

Si la ejecución falla, la VM suele revertir algunos o todos los cambios de estado conforme a las reglas del protocolo.

Es posible que la transacción siga pagando una comisión, ya que los nodos han utilizado recursos computacionales para procesar el intento fallido.

Todos los nodos validadores deben producir el mismo resultado final a partir del mismo estado inicial y de la misma transacción ordenada.

Este requisito se conoce como ejecución determinista.

Determinismo en una Custom VM

El determinismo significa que unas entradas idénticas deben producir unos resultados idénticos en todos los nodos honestos.

Este requisito impide que los validadores discrepen sobre el estado correcto de la blockchain.

Las aplicaciones informáticas normales pueden utilizar relojes locales, datos aleatorios del sistema operativo, cálculos de coma flotante o solicitudes de Internet que pueden producir resultados diferentes en distintos equipos.

Una VM de blockchain debe restringir estas fuentes de incertidumbre o definirlas cuidadosamente.

Por lo general, la aleatoriedad requiere una fuente aprobada por el protocolo, en lugar de que un programa solicite simplemente un número aleatorio al ordenador.

Normalmente, la información externa se introduce mediante un oráculo o un mensaje verificado, no a través de una solicitud web sin restricciones.

El comportamiento aritmético debe especificarse con precisión, incluidos el desbordamiento, la división, el redondeo y los límites numéricos.

Una Custom VM que no mantenga el determinismo puede causar fallos de consenso, bifurcaciones de la cadena o pruebas incorrectas.

Aislamiento y sandboxing

Normalmente, una Custom VM ejecuta los programas dentro de un entorno aislado que limita su acceso al sistema operativo del nodo.

Un contrato inteligente no debería poder leer los archivos privados de un validador, abrir conexiones de red arbitrarias ni tomar el control del equipo anfitrión.

El entorno aislado define a qué regiones de memoria, áreas de almacenamiento y funciones del host puede acceder el programa.

También limita la profundidad de las llamadas, el tamaño de la pila, el crecimiento de la memoria y el tiempo de ejecución.

Un aislamiento sólido protege a los validadores frente a programas maliciosos cargados por los usuarios.

También protege los contratos frente al acceso no autorizado de otros contratos.

Una vulneración del entorno aislado puede convertirse en un grave problema de seguridad de la red, ya que los validadores pueden ejecutar código proporcionado por un atacante al procesar bloques.

Por tanto, las implementaciones de Custom VM requieren auditorías rigurosas, pruebas fuzz, revisiones de dependencias y un diseño seguro de los compiladores.

Custom VM basadas en pila y en registros

Una VM basada en pila realiza muchas operaciones apilando valores y retirándolos cuando las instrucciones necesitan utilizarlos.

La EVM es una máquina virtual conocida basada en pila.

Una VM basada en registros almacena los valores de trabajo en registros identificados por nombres o números.

Los diseños basados en registros pueden reducir el número de instrucciones necesarias para algunos cálculos y ofrecer un rendimiento más previsible.

La documentación oficial de la arquitectura FuelVM describe FuelVM como una máquina virtual basada en registros y diseñada para la ejecución en blockchain.

Ninguna de las dos arquitecturas es automáticamente mejor para todas las blockchains.

Los sistemas basados en pila pueden tener bytecode más sencillo y herramientas consolidadas.

Los sistemas basados en registros pueden ofrecer ventajas de ejecución o compilación para determinadas cargas de trabajo.

La elección más adecuada depende de los objetivos de rendimiento, los sistemas de pruebas, los lenguajes de los desarrolladores, los objetivos de seguridad y la complejidad de la implementación.

Custom VM y ejecución paralela

La ejecución paralela permite a una blockchain procesar simultáneamente varias transacciones que no entran en conflicto.

La ejecución secuencial tradicional procesa las transacciones una tras otra, incluso cuando afectan a cuentas distintas y no relacionadas.

Una Custom VM puede diseñarse para identificar qué elementos del estado lee o modifica cada transacción.

Así, las transacciones que no entran en conflicto pueden ejecutarse en varios núcleos del procesador.

Esto puede mejorar el rendimiento de las aplicaciones con muchos usuarios independientes.

La ejecución paralela resulta más difícil cuando los contratos pueden acceder a cualquier parte del estado global sin declarar sus dependencias.

Una Custom VM puede exigir que las transacciones identifiquen las cuentas u objetos pertinentes antes de la ejecución.

También puede utilizar una ejecución optimista y volver a intentar las transacciones cuando se detectan conflictos.

El paralelismo solo mejora el rendimiento si la planificación, la detección de conflictos y los compromisos de estado siguen siendo correctos.

Los desarrolladores deben entender el modelo de concurrencia, ya que dos transacciones que funcionan por separado pueden comportarse de forma diferente al competir por el mismo estado.

Custom VM y lenguajes de contratos inteligentes

Una Custom VM suele necesitar uno o más lenguajes de programación que compilen al formato de bytecode o ejecutable que admite.

Una VM puede admitir Rust, C, C++, Move, lenguajes compatibles con WebAssembly o un lenguaje de contratos inteligentes creado específicamente para ella.

El lenguaje influye en la seguridad, la productividad de los desarrolladores, el tamaño de los contratos y la complejidad del compilador.

Un lenguaje con reglas estrictas de tipos y propiedad puede evitar algunos tipos de errores antes del despliegue.

Un lenguaje conocido puede atraer a más desarrolladores, aunque también puede incluir funciones difíciles de admitir de forma determinista.

El compilador forma parte de la cadena de seguridad porque traduce el código legible por humanos a instrucciones que ejecuta la VM.

Un error del compilador puede hacer que el bytecode desplegado se comporte de forma distinta al código fuente del desarrollador.

Los ecosistemas sólidos necesitan compilaciones reproducibles, verificación del código fuente, seguimiento de las versiones del compilador y revisiones de seguridad independientes.

Custom VM y WebAssembly

WebAssembly, conocido habitualmente como Wasm, es un formato portátil de instrucciones binarias que puede servir de base para la ejecución en blockchain.

Una blockchain puede compilar su entorno de ejecución o sus contratos inteligentes a Wasm y ejecutarlos en un entorno controlado.

Wasm admite varios lenguajes fuente y ofrece un formato de ejecución independiente de la plataforma.

El SDK de Polkadot almacena la lógica del entorno de ejecución de la blockchain como un binario Wasm y permite actualizarlo mediante procedimientos de gobernanza on-chain.

La documentación oficial sobre actualizaciones del entorno de ejecución explica que este diseño puede añadir funciones o corregir problemas sin necesidad de una bifurcación dura tradicional que afecte a toda la red.

Una blockchain que utiliza Wasm sigue siendo personalizada si define funciones del host específicas de la blockchain, costes de recursos, reglas de estado y comportamiento de las transacciones.

Wasm proporciona una base de ejecución, pero las reglas del entorno de ejecución que la rodea determinan cómo funciona esa base en el ámbito cripto.

Custom VM y blockchains específicas para aplicaciones

Una blockchain específica para aplicaciones se diseña en torno a una aplicación, un mercado o una categoría de actividad.

En lugar de compartir una VM de propósito general con aplicaciones no relacionadas, la cadena puede crear reglas de ejecución específicamente para sus propios usuarios.

La descripción oficial del SDK de Cosmos explica que los desarrolladores pueden combinar módulos predefinidos y crear módulos personalizados adaptados a las necesidades de sus aplicaciones.

Una cadena centrada en el trading podría incluir cruce de órdenes nativo y controles de riesgo.

Una cadena para videojuegos podría incluir creación nativa de objetos, cuentas de jugador y acciones repetidas de bajo coste.

Una cadena de identidad podría limitar los cambios de estado a credenciales verificadas y emisores autorizados.

La ejecución específica para aplicaciones puede mejorar la eficiencia porque las operaciones habituales se convierten en funciones del protocolo, en lugar de contratos inteligentes complejos.

La desventaja es una flexibilidad menor si los futuros desarrolladores quieren crear aplicaciones que el entorno de ejecución original no había previsto.

Custom VM en rollups

Un rollup ejecuta transacciones fuera de una blockchain base y envía datos, compromisos o pruebas a una capa de liquidación.

Como el rollup controla su software de ejecución, puede utilizar una Custom VM en lugar de copiar exactamente la VM de la capa base.

Una Custom VM puede reducir los costes de las pruebas, admitir distintos modelos de cuentas u ofrecer funciones especializadas para aplicaciones.

Sin embargo, la ejecución personalizada puede dificultar la compatibilidad con las carteras, los contratos y las herramientas de desarrollo existentes.

Los desarrolladores pueden necesitar bridges o intérpretes para admitir activos y aplicaciones de otro ecosistema.

Un rollup también debe definir cómo verifica la capa de liquidación los resultados de su Custom VM.

Un rollup optimista puede utilizar pruebas de fraude o juegos de disputa.

Un rollup de conocimiento cero puede enviar pruebas de validez que demuestren que la Custom VM ha seguido sus reglas.

Un rollup soberano puede depender en mayor medida de sus propios nodos y del consenso social para garantizar la corrección de la ejecución.

Por tanto, la Custom VM forma parte del modelo de seguridad e interoperabilidad del rollup.

Custom VM y blockchains modulares

El diseño modular de las blockchains separa la ejecución, el consenso, la disponibilidad de los datos y la liquidación en componentes diferentes.

Esta separación ofrece a los equipos de rollups más libertad para elegir o crear una Custom VM.

La documentación sobre disponibilidad de datos de Celestia explica que varias capas de ejecución pueden utilizar una infraestructura compartida de disponibilidad de datos y liquidación.

Una capa de ejecución puede utilizar la EVM, mientras que otra puede emplear Wasm, una VM de conocimiento cero o una máquina de estados específica para aplicaciones.

Esta flexibilidad es una de las principales ventajas de la arquitectura modular.

Sin embargo, el equipo debe definir cómo obtiene datos la Custom VM, verifica mensajes, se comunica con los bridges y produce resultados en los que otros sistemas puedan confiar.

Una VM de alto rendimiento no hace que una cadena modular sea segura si sus datos no están disponibles o si su bridge puede verse comprometido.

Custom VM y pruebas de conocimiento cero

Una máquina virtual de conocimiento cero, o zkVM, ejecuta programas mientras genera una prueba criptográfica de que la ejecución ha sido correcta.

A menudo, la prueba puede verificarse con más eficiencia que repetir todo el cálculo.

La documentación de la zkVM RISC Zero describe un sistema que demuestra la ejecución correcta de código Rust arbitrario.

Su especificación técnica señala que la VM implementa un conjunto de instrucciones RISC-V de 32 bits.

Una zkVM es un tipo especializado de Custom VM cuando se ha diseñado o adaptado para realizar cálculos demostrables.

El diseño de una zkVM personalizada puede optimizar las instrucciones, el acceso a memoria, el hashing y la aritmética para generar pruebas de forma eficiente.

Esto puede ayudar a los rollups a verificar grandes volúmenes de ejecución con pruebas compactas.

Sin embargo, la generación de pruebas puede requerir importantes recursos informáticos, hardware especializado y criptografía sometida a auditorías rigurosas.

Los usuarios no deben confundir la validez de una prueba de conocimiento cero con la seguridad total de una aplicación.

Una prueba puede demostrar que la VM ha seguido sus reglas aunque las reglas de la aplicación incluyan un diseño económico perjudicial o un error de programación.

Custom VM y compatibilidad con la EVM

Una Custom VM puede ser compatible con la EVM sin ser idéntica a ella.

La compatibilidad con la EVM suele significar que los desarrolladores pueden implementar contratos Solidity o utilizar herramientas conocidas de Ethereum con cambios limitados.

La equivalencia con la EVM es una afirmación más exigente: significa que el comportamiento de ejecución se aproxima mucho al de la EVM de Ethereum.

Un compilador personalizado puede traducir Solidity a un conjunto de instrucciones diferente.

Un intérprete puede ejecutar bytecode EVM dentro de la Custom VM.

Una capa de compatibilidad puede reproducir las API de Ethereum mientras utiliza un estado interno o sistemas de pruebas diferentes.

Cada método ofrece ventajas e inconvenientes en cuanto al rendimiento, el comportamiento del gas, la depuración, las suposiciones de los contratos y la complejidad de las actualizaciones.

Los desarrolladores no deben asumir que una cadena compatible con la EVM se comporta exactamente igual que Ethereum en todos los casos límite.

Las diferencias en los opcodes, los contratos precompilados, la información de bloques, las comisiones, la finalidad y el orden de las transacciones pueden afectar a las aplicaciones.

Ventajas de una máquina virtual personalizada

La primera ventaja de una Custom VM es el rendimiento específico para cada aplicación.

La VM puede optimizar las operaciones habituales, en lugar de obligar a todas las aplicaciones a utilizar un modelo de ejecución general.

La segunda ventaja es la flexibilidad del modelo de estado.

Los desarrolladores pueden elegir cuentas, objetos, UTXO, módulos u otro modelo que se adapte al uso previsto.

La tercera ventaja es una mejor ejecución paralela.

La VM puede exponer las dependencias entre transacciones de forma que las operaciones que no entren en conflicto puedan ejecutarse simultáneamente.

La cuarta ventaja es una seguridad especializada.

Un conjunto reducido de instrucciones o un entorno de ejecución limitado para aplicaciones puede reducir el número de acciones que los atacantes pueden intentar.

La quinta ventaja es la eficiencia en las pruebas criptográficas.

Una Custom VM puede utilizar instrucciones y estructuras de memoria diseñadas para sistemas de pruebas de conocimiento cero.

La sexta ventaja es una mejor experiencia de usuario.

La VM puede incluir recuperación nativa de cuentas, transacciones patrocinadas, permisos de sesión o comisiones previsibles.

La séptima ventaja es la funcionalidad a nivel de protocolo.

Funciones como los activos nativos, los libros de órdenes, las reglas de privacidad o la gobernanza pueden integrarse directamente en el entorno de ejecución.

Riesgos y limitaciones de una Custom VM

El primer riesgo son los errores de implementación.

Una VM nueva tiene menos pruebas en condiciones reales que un entorno de ejecución consolidado y utilizado por muchas redes.

El segundo riesgo son las herramientas deficientes para los desarrolladores.

Es posible que los desarrolladores no dispongan de compiladores, depuradores, marcos de pruebas, analizadores de seguridad y bibliotecas de contratos fiables.

El tercer riesgo es la compatibilidad limitada con el ecosistema.

Los contratos, las carteras y la infraestructura existentes quizá no funcionen sin modificaciones.

El cuarto riesgo es la complejidad de la especificación.

Cada instrucción, coste de recursos, regla de estado y función del sistema debe documentarse con precisión.

El quinto riesgo es la centralización de las actualizaciones.

Si un único equipo puede cambiar la VM sin controles de gobernanza sólidos, los usuarios deben confiar en que no introducirá comportamientos perjudiciales.

El sexto riesgo es un ecosistema de seguridad poco maduro.

Los auditores quizá tengan menos experiencia con un formato de bytecode o un modelo de ejecución nuevo.

El séptimo riesgo es una valoración económica incorrecta de los recursos.

Unos costes de recursos mal calibrados pueden abaratar los ataques de denegación de servicio o encarecer demasiado las aplicaciones legítimas.

El octavo riesgo es la fragmentación.

Demasiadas Custom VM incompatibles pueden dividir a los desarrolladores, la liquidez, las herramientas y los usuarios entre ecosistemas aislados.

Requisitos de seguridad de una Custom VM

Una Custom VM segura debe ejecutar las transacciones de forma determinista en distintas implementaciones de nodos y entornos de hardware.

Debe aislar los programas no fiables del sistema operativo del validador.

Debe impedir el acceso no autorizado al almacenamiento de contratos, los saldos de los usuarios y los privilegios del sistema.

Debe medir todos los recursos que los atacantes podrían agotar.

Debe gestionar con seguridad los límites de los números enteros, los límites de memoria, la recursividad, las llamadas a contratos y las condiciones de error.

Debe definir cómo se revierten los cambios de estado cuando falla una ejecución.

Debe impedir la repetición de firmas entre transacciones, cadenas o dominios.

Debe proteger las funciones privilegiadas del host y los contratos del sistema frente a llamadas no autorizadas.

El compilador y el verificador de bytecode deben rechazar los programas malformados o inseguros.

El proceso de actualización debe incluir revisión, pruebas, planificación de emergencias y una gobernanza clara.

Las pruebas de seguridad deben incluir pruebas unitarias, pruebas de integración, pruebas diferenciales, fuzzing, pruebas de propiedades y simulaciones económicas adversariales.

Cuando sea posible, varias implementaciones independientes pueden ayudar a detectar errores en la especificación que una única base de código podría ocultar.

Actualizaciones de Custom VM

Una Custom VM puede necesitar actualizaciones para corregir errores de seguridad, añadir instrucciones, mejorar el rendimiento o admitir nueva criptografía.

Modificar las reglas de la VM es delicado porque todos los nodos deben empezar a aplicar las nuevas reglas en el momento correcto de la cadena.

Una actualización incorrecta puede dividir la red si algunos nodos aceptan transacciones que otros rechazan.

Algunas blockchains coordinan las actualizaciones de la VM mediante versiones de software programadas y bifurcaciones duras.

Otras almacenan en la blockchain un entorno de ejecución actualizable y autorizan los cambios mediante la gobernanza.

Los rollups pueden utilizar contratos de liquidación actualizables, consejos de seguridad, multisig o bloqueos temporales de gobernanza.

Los usuarios deben saber quién puede aprobar las actualizaciones de una Custom VM y si existe un plazo de espera antes de que los cambios entren en vigor.

Una VM inmutable reduce los riesgos de gobernanza, pero dificulta las correcciones urgentes.

Una VM fácil de actualizar puede responder con rapidez, pero aumenta la confianza que debe depositarse en la autoridad responsable de las actualizaciones.

Cómo evalúan los desarrolladores una Custom VM

En primer lugar, los desarrolladores deberían examinar los lenguajes de programación de la VM y la madurez de sus compiladores.

Deberían revisar la documentación del conjunto de instrucciones, el modelo de cuentas, el almacenamiento, las comisiones y el ciclo de vida de las transacciones.

Deberían comprobar si los contratos pueden verificarse a partir del código fuente publicado.

Deberían revisar las herramientas de depuración, pruebas locales, testnet, despliegue y supervisión.

Deberían entender cómo gestiona la VM la reentrada, las llamadas entre contratos, la concurrencia y las transacciones fallidas.

Deberían examinar las auditorías de seguridad tanto de la VM como de la cadena de herramientas del compilador.

Deberían comprobar si las carteras, las herramientas de custodia, los indexadores y la infraestructura existentes son compatibles con la red.

Deberían evaluar si el rendimiento anunciado se aplica a aplicaciones realistas y no solo a transacciones sencillas de referencia.

También deberían analizar quién tiene autoridad para actualizarla, ya que los cambios en el entorno de ejecución pueden afectar incluso a un programa seguro.

Cómo evalúan los usuarios cripto una cadena con Custom VM

Los usuarios corrientes no necesitan leer cada opcode de la VM, pero sí deberían entender las principales suposiciones de confianza.

Deberían comprobar si la Custom VM lleva un periodo significativo en producción.

Deberían comprobar si la cadena publica auditorías, especificaciones técnicas, informes de incidentes y avisos de actualización.

Deberían saber si su cartera muestra los detalles de las transacciones en un formato comprensible.

Deberían comprobar si los activos dependen de bridges para trasladarse entre la cadena de la Custom VM y otras redes.

Deberían entender las comisiones de transacción, las reglas de finalidad, el modelo de secuenciador y el proceso de retirada de la cadena.

No deberían asumir que un elevado rendimiento de las transacciones implica automáticamente una mayor descentralización o seguridad.

Deberían probar las redes y aplicaciones que no conozcan con pequeñas cantidades antes de transferir activos valiosos.

Una Custom VM puede ofrecer funciones útiles, pero los usuarios siguen expuestos a riesgos de contratos inteligentes, bridges, carteras, gobernanza y mercado.

Usos habituales de las Custom VM

Las Custom VM se utilizan en redes de contratos inteligentes de alto rendimiento que necesitan ejecución paralela.

Se utilizan en cadenas de aplicaciones que necesitan lógica de negocio nativa y tipos de transacciones controlados.

Se utilizan en videojuegos blockchain que requieren muchas actualizaciones de estado de bajo coste.

Se utilizan en sistemas de finanzas descentralizadas que necesitan procesamiento especializado de órdenes o cálculos de riesgo.

Se utilizan en sistemas de privacidad que ejecutan programas confidenciales o de conocimiento cero.

Se utilizan en rollups que necesitan pruebas de validez eficientes.

Se utilizan en redes empresariales o permisionadas con requisitos de identidad y control de acceso.

Se utilizan en capas de interoperabilidad que necesitan verificar con eficiencia mensajes entre cadenas.

También se utilizan en investigaciones experimentales sobre blockchain que abordan nuevos modelos de estado, lenguajes de programación y mecanismos de comisiones por transacción.

Malentendidos frecuentes sobre las Custom VM

Un malentendido es creer que todas las blockchains que no utilizan la EVM tienen una Custom VM tradicional.

Algunas cadenas utilizan en su lugar un entorno de ejecución compilado o una máquina de estados específica para aplicaciones, sin admitir bytecode de propósito general desplegado por los usuarios.

Otro malentendido es pensar que una Custom VM es automáticamente más rápida que la EVM.

El rendimiento depende del acceso al estado, el hardware de los nodos, la red, el consenso, la disponibilidad de los datos, las cargas de trabajo y la calidad de la implementación.

Un tercer malentendido es creer que la ejecución personalizada mejora automáticamente la seguridad.

Una VM especializada puede reducir algunos riesgos y, al mismo tiempo, introducir nuevos riesgos de implementación y de herramientas.

Un cuarto malentendido es pensar que la compatibilidad con la EVM implica un comportamiento idéntico al de Ethereum.

Los sistemas compatibles pueden presentar diferencias de ejecución, comisiones, contratos precompilados, finalidad e infraestructura.

Un quinto malentendido es creer que una zkVM garantiza que todas las aplicaciones sean seguras.

Una zkVM demuestra que se han seguido unas reglas de ejecución definidas, pero no demuestra que el diseño económico de la aplicación o la decisión del usuario hayan sido acertados.

Un sexto malentendido es pensar que a los usuarios nunca les importa qué VM utiliza una cadena.

La VM puede afectar a la compatibilidad de las carteras, las comisiones de transacción, la seguridad de los contratos, los estándares de activos, la actividad de los desarrolladores y los requisitos de los bridges.

El futuro de las máquinas virtuales personalizadas

Las Custom VM están adquiriendo importancia a medida que el sector cripto avanza hacia los rollups, las blockchains modulares, las cadenas específicas para aplicaciones y la ejecución de conocimiento cero.

Algunos sistemas futuros podrían admitir varios entornos de ejecución en una misma red.

Un entorno podría ejecutar contratos EVM, mientras que otro gestionaría programas nativos de Wasm, RISC-V o específicos para una aplicación.

Los intérpretes y las capas de compilación podrían facilitar el traslado de aplicaciones entre distintas VM.

Las mejoras en las pruebas de conocimiento cero podrían permitir verificar de forma eficiente programas más generales.

La investigación sobre ejecución paralela podría mejorar el rendimiento de las aplicaciones cuyo acceso al estado puede predecirse con seguridad.

Los sistemas personalizados de cuentas podrían admitir directamente en la capa de ejecución la recuperación, los límites de gasto, las claves de acceso, los permisos de sesión y las comisiones patrocinadas.

El reto a largo plazo será equilibrar la especialización con la interoperabilidad.

Una VM muy especializada puede realizar una tarea extraordinariamente bien, pero los usuarios cripto también necesitan carteras, activos, liquidez, estándares y herramientas de seguridad compartidos.

Es probable que los ecosistemas de Custom VM más sólidos combinen ventajas técnicas con herramientas maduras, especificaciones claras, auditorías rigurosas y bridges fiables.

Preguntas frecuentes

¿Qué es una máquina virtual personalizada en el sector cripto?

Una máquina virtual personalizada es un entorno de ejecución blockchain diseñado con sus propias reglas para ejecutar programas, procesar transacciones, gestionar el estado y cobrar por los recursos computacionales.

¿Qué significa Custom VM?

Custom VM significa una máquina virtual creada o modificada para las necesidades específicas de una blockchain, un rollup, una cadena de aplicaciones o un sistema de pruebas.

¿Una Custom VM es lo mismo que la EVM?

No. La EVM es un entorno de ejecución concreto, mientras que una Custom VM puede utilizar instrucciones, modelos de estado, lenguajes, comisiones y reglas de seguridad diferentes.

¿Por qué utilizaría una blockchain una Custom VM?

Una blockchain puede utilizar una Custom VM para mejorar el rendimiento, admitir la ejecución paralela, añadir funciones nativas para aplicaciones, reforzar la privacidad o reducir los costes de las pruebas de conocimiento cero.

¿Puede una Custom VM admitir Solidity?

Sí. Una Custom VM puede admitir Solidity mediante un compilador personalizado, un intérprete EVM o una capa de compatibilidad, aunque su comportamiento quizá no coincida perfectamente con el de Ethereum.

¿Un entorno de ejecución blockchain es lo mismo que una VM?

No siempre. Un entorno de ejecución define de forma general la lógica de transición de estado, mientras que una VM suele ejecutar bytecode conforme a un conjunto de instrucciones definido.

¿Qué es una zkVM?

Una zkVM es una máquina virtual que ejecuta programas y genera pruebas criptográficas de que la ejecución ha seguido las reglas definidas.

¿Las Custom VM son más rápidas que la EVM?

Algunas Custom VM pueden ser más rápidas para determinadas cargas de trabajo, pero el rendimiento real también depende del consenso, el almacenamiento, la red, el hardware y el diseño de la aplicación.

¿Son seguras las Custom VM?

Una Custom VM puede ser segura si es determinista, está aislada y auditada, mide correctamente los recursos y cuenta con una cadena de herramientas madura, aunque las VM más nuevas pueden tener menos pruebas en producción.

¿Qué lenguajes de programación pueden utilizar las Custom VM?

Las Custom VM pueden admitir Solidity, Rust, C, C++, Move, lenguajes compatibles con Wasm o lenguajes de contratos inteligentes creados específicamente para ellas.

¿Puede una Custom VM ejecutar transacciones en paralelo?

Sí. Una Custom VM puede admitir ejecución paralela si puede identificar las transacciones que acceden a cuentas, objetos o áreas de almacenamiento independientes.

¿Las Custom VM necesitan gas?

Necesitan algún tipo de control de recursos, pero pueden utilizar gas, unidades de cómputo, ponderaciones, ciclos u otro modelo de medición.

¿Se puede actualizar una Custom VM?

Sí. Muchas Custom VM pueden actualizarse mediante bifurcaciones duras, gobernanza, sustitución del entorno de ejecución o contratos actualizables de rollups.

¿Cuál es la principal desventaja de una Custom VM?

La principal desventaja es que los desarrolladores deben crear y proteger un nuevo ecosistema de ejecución con compiladores, carteras, herramientas, estándares y documentación propios.

¿Una Custom VM afecta a los usuarios cripto?

Sí. Puede afectar a las comisiones de transacción, la compatibilidad de las carteras, la finalidad, la seguridad de los contratos, la disponibilidad de las aplicaciones, los estándares de activos y los requisitos de los bridges.

Conclusión

Una máquina virtual personalizada es un entorno especializado de ejecución blockchain que define cómo se procesan las transacciones, los contratos y los cambios de estado.

Ofrece a los desarrolladores de blockchain más control sobre el rendimiento, los lenguajes de programación, los modelos de estado, los costes de recursos, la privacidad, la ejecución paralela y las pruebas criptográficas.

Las Custom VM son especialmente importantes para los rollups, las blockchains modulares, las cadenas específicas para aplicaciones, las redes de alto rendimiento y los sistemas de conocimiento cero.

Su flexibilidad puede admitir funciones difíciles o ineficientes de implementar en un entorno de propósito general.

Sin embargo, la ejecución personalizada también crea nuevas responsabilidades.

Los equipos deben crear compiladores seguros, reglas deterministas, mecanismos de medición de recursos y aislamiento, herramientas para desarrolladores, compatibilidad con carteras, procesos de auditoría y sistemas de actualización seguros.

Una Custom VM no debe evaluarse únicamente por la velocidad de transacción anunciada.

Los desarrolladores y los usuarios también deben evaluar su historial de seguridad, su modelo de estado, su compatibilidad, su descentralización, su gobernanza, su sistema de pruebas, la disponibilidad de los datos y la infraestructura que la respalda.

Las mejores Custom VM combinan mejoras técnicas significativas con documentación clara y prácticas de seguridad maduras.

A medida que la arquitectura cripto se vuelva más modular y específica para cada aplicación, las Custom VM seguirán siendo una parte importante de la forma en que las blockchains compiten, escalan y admiten nuevos tipos de aplicaciones descentralizadas.