La Solana Virtual Machine, explicada para quienes solo conocen Bitcoin
Una guía sobre la Solana Virtual Machine para lectores familiarizados con Bitcoin: modelo de cuentas, ejecución paralela, herramientas de desarrollo y límites de la compatibilidad declarada por Bitcoin Hyper.
Finalidad educativa. Los contenidos de este artículo tienen una finalidad exclusivamente informativa y explicativa. No constituyen asesoramiento financiero. Declaración completa.
Del escritorio de Bitcoin a la cocina de Solana
Bitcoin dispone de un lenguaje de scripting —denominado Script— deliberadamente limitado. No es Turing completo, no admite bucles y solo permite operaciones elementales: verificar firmas, comprobar timelocks o configurar esquemas multisig. Esa simplicidad contribuye a que su comportamiento sea predecible y a reducir la superficie de ejecución, aunque la seguridad de Bitcoin depende de numerosos elementos del protocolo.
Ethereum siguió un camino distinto: introdujo la EVM (Ethereum Virtual Machine), un entorno Turing completo en el que pueden ejecutarse smart contracts. A nivel del protocolo, las transiciones de estado se procesan con un modelo secuencial, aunque las implementaciones pueden paralelizar determinadas tareas internas.
Solana respondió al desafío de la escalabilidad con una arquitectura radicalmente distinta: la SVM (Solana Virtual Machine) y el runtime Sealevel.
El modelo de cuentas de Solana (y de la SVM)
En Ethereum, un smart contract «posee» su estado: los datos residen dentro del propio contrato. En la SVM el diseño está desacoplado:
- - El código reside en una cuenta de programa; su posibilidad de actualización depende del mecanismo de despliegue y de la autoridad configurada
- - Los datos (el estado) residen en cuentas separadas, controladas por el programa
Esto permite que Sealevel analice las transacciones de antemano: si la transacción A afecta a las cuentas {X, Y} y la transacción B afecta a {Z, W}, ambas pueden ejecutarse en paralelo sin conflicto.
Este modelo permite ejecutar en paralelo transacciones que no compiten por las mismas cuentas. Puede aumentar la capacidad de procesamiento, pero no permite deducir por sí solo una ventaja cuantitativa frente a la EVM con hardware equivalente. No se han publicado pruebas específicas de rendimiento de Bitcoin Hyper.
Qué implica esto para los desarrolladores
Los programas para la SVM se escriben en Rust (o en C/C++) y se compilan a bytecode eBPF. Un framework ampliamente utilizado es Anchor, que añade macros y convenciones para agilizar el desarrollo.
La documentación de Bitcoin Hyper presenta como objetivo una compatibilidad inmediata o «drop-in compatibility» con el ecosistema Solana. Según el proyecto, un programa existente podría ejecutarse con adaptaciones limitadas, como el cambio del endpoint RPC y de determinados parámetros de red. La documentación también prevé compatibilidad con herramientas como la CLI de Solana, Anchor y los plugins de los IDE. El grado efectivo de compatibilidad continúa pendiente de verificación independiente.
Si este nivel de compatibilidad llegara a alcanzarse, podría reducir la barrera de entrada para desarrolladores familiarizados con Solana. Sin embargo, compartir un entorno basado en la SVM no garantiza por sí solo la compatibilidad de programas, APIs, programas de sistema, herramientas o comportamientos del runtime. Continúa siendo un objetivo de diseño y no un resultado verificado de forma independiente.
Qué no está aún claro
Dicho esto, conviene señalar con honestidad algunos puntos:
- La compatibilidad completa no se ha verificado de forma independiente: la devnet es selectiva y las pruebas públicas son limitadas
- Diferencias en el modelo de comisiones: según la documentación del proyecto, Bitcoin Hyper utiliza $HYPER para las comisiones en lugar de SOL, por lo que algunas abstracciones difieren
- Dependencias de los programas de sistema de Solana: algunas aplicaciones de Solana se apoyan en programas de sistema (como el Token Program oficial) que podrían no estar disponibles en una forma idéntica
La afirmación de ser «drop-in compatible» continúa pendiente de verificación. Su evaluación requiere documentación técnica pública, acceso suficiente a la devnet y pruebas reproducibles sobre programas, herramientas y dependencias del sistema.
La analogía de la franquicia
Puede imaginarse la SVM como la cocina de un restaurante en franquicia. La receta representa el código y el local representa la red en la que se ejecuta. Bitcoin Hyper pretende ofrecer un equipamiento compatible con el de Solana, pero todavía no se ha demostrado que todos los componentes sean idénticos ni que el resultado sea el mismo en todos los casos.
La diferencia está en el ingrediente principal: en lugar de SOL como «combustible» de la cocina, aquí se emplearía $HYPER.