La máquina virtual de Solana (SVM) es el entorno de ejecución que procesa los programas de Solana y aplica sus cambios de estado en toda la red. Los programas se compilan en el formato de bytecode de Solana, o sBPF, y se ejecutan dentro de un runtime aislado (sandbox). Las transacciones identifican los programas que invocan y las cuentas que cada instrucción puede leer o escribir, lo que proporciona al runtime la información necesaria para cargar el estado y programar el trabajo compatible.

La SVM separa el código ejecutable del programa de los datos de cuenta mutables y utiliza unidades de cómputo para medir el consumo de recursos. Este modelo respalda el runtime paralelo Sealevel de Solana, ya que las transacciones que no solicitan cuentas de escritura en conflicto pueden procesarse de forma concurrente. La SVM es una capa de ejecución, no el mecanismo de consenso de Solana, ni el cliente validador, ni el reloj de Proof of History.

¿Qué es la máquina virtual de Solana?

La máquina virtual de Solana (SVM) es el entorno de ejecución que ejecuta programas de contratos inteligentes y procesa las instrucciones de las transacciones en Solana. A diferencia de los sistemas en los que un contrato inteligente almacena su propio estado, Solana separa el código del programa de las cuentas de datos. Las transacciones especifican qué programas y cuentas van a utilizar, lo que permite a la red procesar transacciones independientes en paralelo.

El término SVM también puede referirse a entornos de ejecución compatibles con Solana utilizados por otras redes de cadena de bloques. Estas redes pueden admitir programas y herramientas de desarrollo similares, aunque utilizan sistemas distintos de consenso, secuenciación, disponibilidad de datos o liquidación. Por lo tanto, la compatibilidad con la SVM describe el entorno de ejecución, no el modelo de seguridad de la red subyacente.

¿Cómo funciona la máquina virtual de Solana?

La máquina virtual de Solana procesa cada transacción utilizando los programas y las cuentas indicados en esa transacción.

1. Cargar las cuentas necesarias: la SVM identifica al pagador de la comisión, los firmantes, las cuentas de escritura y los programas que necesita la transacción.

2. Ejecutar las instrucciones: las instrucciones se ejecutan en orden a través de los programas de Solana correspondientes, que también pueden invocar otros programas cuando es necesario.

3. Aplicar permisos y límites: el runtime verifica la propiedad de las cuentas, los permisos de los firmantes, el acceso de escritura y los límites de unidades de cómputo durante la ejecución.

4. Verificar el resultado: tras la ejecución, la SVM confirma que los saldos y los datos de las cuentas cumplen las reglas del protocolo de Solana.

5. Confirmar la transacción: si todas las instrucciones se completan correctamente, los cambios de estado se registran en conjunto. Si una falla, la transacción no actualiza parcialmente el estado de la aplicación.

Dado que las transacciones declaran a qué cuentas acceden, Solana puede ejecutar en paralelo transacciones que utilizan cuentas distintas, lo que ayuda a la red a soportar un mayor rendimiento.

¿Cuáles son los principales beneficios y casos de uso de la SVM?

La SVM está diseñada para aplicaciones que necesitan una ejecución predecible de los programas y que pueden beneficiarse del acceso explícito a las cuentas. Su rendimiento depende tanto del diseño del runtime como de si las transacciones compiten por el mismo estado de escritura.

1. El acceso declarado a las cuentas permite la programación paralela. Las transacciones enumeran las cuentas que necesitan antes de la ejecución, lo que permite al planificador ejecutar transacciones sin conflictos en distintos núcleos del procesador y, al mismo tiempo, proteger el estado de escritura compartido.

2. Los programas y el estado permanecen separados. Un programa sin estado puede operar sobre muchas cuentas de datos, lo que favorece la reutilización de la lógica de la aplicación y permite a los desarrolladores organizar el estado para la concurrencia en lugar de duplicar el código.

3. Las transacciones atómicas pueden componer varias instrucciones. Una transacción puede invocar varios programas en secuencia y confirmar juntos todos los cambios de estado exitosos, o rechazar la transacción completa cuando falla una instrucción.

4. Las unidades de cómputo hacen explícito el uso de recursos. El runtime mide el trabajo del programa y permite a las transacciones solicitar un presupuesto adecuado, lo que ayuda a los validadores a acotar la ejecución mientras los usuarios expresan prioridad mediante los mecanismos de comisiones de la red.

¿Cuáles son ejemplos de programas y redes con SVM?

La tecnología SVM aparece en aplicaciones de Solana y en redes que reutilizan la ejecución compatible con Solana. Los ejemplos difieren en liquidación e infraestructura, por lo que el hecho de admitir SVM no los convierte en la misma red.

• Programas nativos de Solana. El System Program crea cuentas, mientras que los programas de voto, staking, presupuesto de cómputo y tablas de búsqueda de direcciones ofrecen funciones básicas directamente compatibles con el runtime de Solana.

• Programas de aplicación de Solana. Los DEX, los mercados de préstamos, las plataformas de NFT y los juegos despliegan programas sBPF que operan sobre cuentas de usuario, mercado, bóveda, mint y posición suministradas con cada instrucción.

• Ejecución de Eclipse. Eclipse utiliza un entorno de ejecución basado en SVM mientras liquida a través de infraestructura relacionada con Ethereum, lo que ilustra cómo el runtime puede situarse dentro de una pila de blockchain modular diferente.

• Herramientas locales de prueba de SVM. Herramientas como LiteSVM reproducen el comportamiento relevante del runtime para el desarrollo y las pruebas sin requerir que cada caso de prueba envíe transacciones a un clúster de validadores en vivo.

¿Cuáles son las limitaciones y los riesgos de la SVM?

El modelo de rendimiento de la SVM genera restricciones de diseño específicas. Los desarrolladores deben declarar las cuentas con precisión, reducir la contención innecesaria y mantenerse dentro de los límites del runtime, mientras que los usuarios siguen enfrentándose a los riesgos habituales de los contratos inteligentes y las transacciones.

1. Las cuentas de escritura compartidas pueden limitar el paralelismo. Las transacciones que requieren la misma cuenta de escritura no pueden ejecutarse juntas de forma segura, por lo que una cuenta de estado global popular puede convertirse en un cuello de botella para la aplicación a pesar de un runtime paralelo.

2. Los programas requieren conocimientos de desarrollo específicos de Solana. Los desarrolladores deben comprender la compilación de sBPF, la propiedad de las cuentas, las direcciones derivadas de programas, las invocaciones entre programas, los presupuestos de cómputo y los requisitos de cuentas relacionados con el alquiler (rent).

3. Los límites de cómputo y de cuentas pueden rechazar llamadas complejas. Una transacción puede fallar cuando supera su presupuesto de cómputo, hace referencia a demasiados recursos, aumenta indebidamente los datos de una cuenta o alcanza las restricciones de profundidad de llamadas y del runtime.

4. La compatibilidad con la SVM no equivale a la seguridad de Solana. Una cadena SVM independiente puede utilizar validadores, puentes, secuenciadores, disponibilidad de datos o controles de actualización distintos, lo que crea supuestos de confianza ajenos al bytecode de ejecución.

¿En qué se diferencia la SVM de la EVM?

La SVM se diferencia de la EVM principalmente por su modelo de cuentas, su bytecode y su enfoque de la concurrencia. Las transacciones de Solana declaran el acceso a las cuentas antes de la ejecución, y los programas operan sobre cuentas de estado separadas, lo que permite a Sealevel programar en paralelo el trabajo sin conflictos. Los contratos de Ethereum suelen mantener el código y el almacenamiento en la misma dirección, y la ejecución tradicional de la EVM sigue la secuencia ordenada de transacciones. Ambos entornos requieren resultados deterministas en todos los nodos validadores, pero sus herramientas de desarrollo, su medición de comisiones, sus diseños de estado y sus estándares de compatibilidad son diferentes.

Conceptos relacionados

1. ¿Qué es un contrato inteligente?

2. ¿Qué es el gas?

3. ¿Qué es un validador?

4. ¿Qué es la blockchain?

Lecturas adicionales

1. ¿Cuáles son los principales proyectos de la máquina virtual de Solana (SVM) de 2025?

2. ¿Qué es Eclipse (ES), la primera capa 2 impulsada por SVM en Ethereum?

3. ¿Qué es Solscan y cómo usar el explorador de la blockchain de Solana?

4. Solana frente a Ethereum: un análisis comparativo