SolanaVM Explicado: Máquina Virtual de Solana
SolanaVM is Solana's execution environment processing programs in parallel. Learn how it compares to EVM and powers DeFi applications.
Nota de precisión: El rendimiento de la red, el número de validadores, las comisiones, las características del protocolo, el soporte de billeteras y las integraciones de terceros cambian con el tiempo. Trate las cifras fechadas como instantáneas históricas y verifique la documentación actual de la fuente principal.
SolanaVM (también conocida como Máquina Virtual de Solana o SVM) es el entorno de ejecución de la blockchain de Solana: la capa de software que procesa y ejecuta programas on-chain. Gestiona la computación, aplica la lógica del programa y registra los resultados en la red. SolanaVM no es un producto o token separado; es el motor de ejecución principal integrado en el protocolo de Solana.
Nota de terminología: En contextos de blockchain, SVM significa Solana Virtual Machine (Máquina Virtual de Solana). SVM también es el acrónimo de Support Vector Machine, un algoritmo de aprendizaje automático sin relación con la blockchain. A lo largo de este artículo, SVM se refiere exclusivamente a la Máquina Virtual de Solana.
Contenidos: Cómo Funciona SolanaVM | SolanaVM vs. EVM | Construyendo sobre SolanaVM | Adopción Multi-Cadena | Cómo se está desarrollando la adopción de SolanaVM | Preguntas Frecuentes
Una blockchain es un ledger distribuido que registra transacciones en una red de ordenadores sin depender de una autoridad central. Las blockchains modernas hacen más que registrar transferencias de valor. Ejecutan programas: software que gestiona préstamos, trading, gobernanza y miles de otras funciones on-chain. Para ejecutar programas, una blockchain necesita un entorno de ejecución, una capa de software controlada que recibe instrucciones, las procesa según reglas definidas y registra los resultados on-chain. Cada blockchain de contratos inteligentes necesita un entorno de ejecución. En Solana, ese entorno es SolanaVM.
Solana es una blockchain de capa 1 (L1), una red de capa base con su propio mecanismo de consenso y token nativo llamado SOL. SolanaVM no es lo mismo que Solana. La relación es análoga a un motor de coche y el coche en sí: SolanaVM es el motor; Solana es el vehículo completo. SOL es el combustible que paga la ejecución. Estas son tres entidades distintas, y confundirlas crea una confusión genuina al evaluar la arquitectura de Solana.
SolanaVM se construyó en torno a una filosofía de diseño centrada en el rendimiento (throughput-first), rastreada directamente a Anatoly Yakovenko, cofundador de Solana y antiguo ingeniero de Qualcomm que identificó la sobrecarga de ordenación de transacciones como el principal cuello de botella en los diseños de blockchain existentes.
Cómo Funciona SolanaVM: Arquitectura y Modelo de Ejecución
SolanaVM ejecuta programas de Solana a través de un pipeline de cinco etapas que se ejecuta en la infraestructura de validadores distribuidos de la red, procesando transacciones no conflictivas en paralelo en lugar de en secuencia.
En SolanaVM, los contratos inteligentes se denominan programas de Solana (el término de SolanaVM para contratos inteligentes). Este es el término oficial de la Fundación Solana, no una variación estilística. La diferencia de nomenclatura refleja una distinción arquitectónica real. Los contratos inteligentes EVM almacenan tanto la lógica del programa como los datos de estado dentro del mismo objeto de contrato. Los programas de Solana son sin estado: el código del programa reside en una cuenta on-chain, y los datos con los que opera residen en cuentas de datos separadas. Esta separación es lo que hace que la ejecución en paralelo sea factible a escala.
El pipeline de ejecución de SolanaVM sigue cinco etapas:
- Un desarrollador escribe un programa de Solana en Rust
- El código Rust se compila a bytecode sBPF
- El bytecode compilado se implementa como una cuenta de programa on-chain
- Un usuario envía una transacción que invoca el programa con datos de instrucción
- Los validadores de Solana (los nodos de la red que ejecutan SolanaVM) ejecutan el bytecode sBPF, consumen unidades de cómputo y registran el resultado en el ledger
Los validadores de Solana ejecutan SolanaVM en hardware dedicado y alcanzan consenso a través de dos mecanismos separados: Proof of History (PoH) para la ordenación de transacciones, y Tower BFT, un mecanismo de consenso de Prueba de Participación (Proof of Stake), para validar resultados. La red de validadores de Solana está asegurada por Tower BFT. Mientras PoH ordena las transacciones, Tower BFT determina el consenso sobre su validez. Estos son roles distintos y no deben confundirse.
Proof of History (Prueba de Historia) es un mecanismo de ordenación criptográfica inventado por Anatoly Yakovenko, detallado en el whitepaper de Solana Proof of History.). PoH funciona como un reloj sincronizado que permite a todos los validadores acordar cuándo ocurrió cada transacción sin necesidad de preguntarse entre sí, eliminando un importante cuello de botella de coordinación. Al pre-ordenar las transacciones criptográficamente, PoH proporciona a SolanaVM la base temporal que necesita para procesar múltiples transacciones simultáneamente. PoH no es un mecanismo de consenso; es un protocolo de marca de tiempo y ordenación que alimenta el consenso Tower BFT.
¿Qué es sBPF? Formato de Bytecode de SolanaVM
sBPF (Solana Berkeley Packet Filter) es el formato de bytecode que ejecuta SolanaVM: la versión modificada de Solana del conjunto de instrucciones Berkeley Packet Filter, adaptada específicamente para la ejecución de programas de blockchain.
Cuando un desarrollador escribe un programa de Solana en Rust, ese código Rust no se ejecuta directamente on-chain. El compilador de Rust lo traduce a bytecode sBPF, un formato de instrucción compacto y de bajo nivel que el motor de ejecución de SolanaVM puede procesar de manera eficiente. Los validadores ejecutan bytecode sBPF directamente; aquí es donde la computación ocurre físicamente en la red.
sBPF es distinto del BPF (Berkeley Packet Filter) original, una tecnología de redes utilizada en kernels de sistemas operativos para filtrar paquetes. sBPF de Solana es una fork modificada adaptada a las restricciones de la ejecución de máquinas virtuales de blockchain. Utilice siempre "sBPF" en lugar de "BPF" solo cuando se refiera al formato de bytecode de Solana.
Para los desarrolladores que provienen del ecosistema EVM, sBPF ocupa el mismo rol funcional que los opcodes de EVM: es el conjunto de instrucciones de bajo nivel que la máquina virtual interpreta y ejecuta.
Ejecución en Paralelo: Cómo SolanaVM Procesa Múltiples Transacciones Simultáneamente
SolanaVM procesa transacciones no conflictivas simultáneamente en lugar de una a la vez, una diferencia fundamental con el modelo de ejecución secuencial de EVM.
Imagine un banco donde cada cajero atiende a un cliente diferente al mismo tiempo en lugar de una larga cola atendida por una sola ventanilla. La ejecución en paralelo de SolanaVM funciona de manera similar para transacciones que no acceden a las mismas cuentas.
El mecanismo es Sealevel, el motor de ejecución en paralelo de SolanaVM. Antes de ejecutar cualquier transacción, Sealevel analiza las dependencias de cuentas de cada transacción: ¿de qué cuentas lee esta transacción y a cuáles escribe? Si dos transacciones acceden a cuentas completamente diferentes, no tienen conflicto y pueden ejecutarse simultáneamente en múltiples núcleos de CPU. Las transacciones que comparten cuentas se ponen en cola secuencialmente para esas cuentas específicas, mientras que todas las transacciones no relacionadas continúan en paralelo.
El resultado es un techo de rendimiento que escala con el hardware del validador en lugar de un cuello de botella secuencial fijo. El rendimiento máximo teórico de Solana alcanza aproximadamente 65.000 transacciones por segundo en condiciones óptimas, en comparación con las aproximadamente 15 a 30 TPS de la Mainnet de Ethereum (Fuente: Solana Foundation, solana.com; ethereum.org, a fecha del primer trimestre de 2025). El rendimiento en el mundo real bajo carga es menor para ambas redes, y las cadenas de capa 2 (L2) compatibles con EVM construidas sobre Ethereum logran un rendimiento sustancialmente mayor que la propia Mainnet de Ethereum.
SolanaVM frente a EVM: comparación de los dos entornos de ejecución
SolanaVM y la Máquina Virtual Ethereum (EVM) representan dos enfoques arquitectónicos distintos para la ejecución de programas en la blockchain, cada uno con compensaciones medibles que favorecen diferentes casos de uso. Un tercer estándar de máquina virtual, WebAssembly (WASM), es utilizado por cadenas como NEAR Protocol y Polkadot, y representa una elección arquitectónica diferente tanto de la EVM como de SolanaVM.
La Máquina Virtual Ethereum (EVM): el estándar establecido
La Máquina Virtual Ethereum (EVM), diseñada originalmente por Vitalik Buterin y el equipo de Ethereum, es el entorno de ejecución compartido por Ethereum y todas las cadenas compatibles con EVM. La documentación completa de la Máquina Virtual Ethereum está disponible en ethereum.org.
La EVM procesa las transacciones de forma secuencial: una a una, en orden estricto. Cada transacción de un bloque se ejecuta después de que finalice la anterior. Los programas se escriben en Solidity o Vyper y se compilan en opcodes de la EVM. Este modelo secuencial crea un techo de rendimiento ligado al tiempo de bloque en lugar de a la capacidad del hardware, pero también simplifica el razonamiento del estado. En cualquier punto de la ejecución, el estado completo es determinista y totalmente coherente.
La ventaja competitiva más duradera de la EVM es su efecto de red. Más de 100 cadenas compatibles con EVM, incluidas Polygon, Arbitrum, Avalanche C-Chain y BNB Chain, comparten el mismo estándar de ejecución. Los desarrolladores que aprenden Solidity pueden desplegar en cualquier cadena compatible con EVM sin reescribir su código. Esta portabilidad se ha acumulado durante una década, creando un ecosistema de herramientas (Hardhat, Foundry, Remix, OpenZeppelin) y una comunidad de desarrolladores que SolanaVM aún no ha igualado en escala.
SolanaVM frente a EVM: comparación paralela
La diferencia fundamental entre SolanaVM y la EVM radica en cómo procesan las transacciones: SolanaVM ejecuta las transacciones que no entran en conflicto en paralelo, mientras que la EVM procesa las transacciones de forma secuencial. La siguiente tabla muestra estas diferencias arquitectónicas a través de seis dimensiones principales.
| Dimensión | SolanaVM | EVM (Máquina Virtual Ethereum) |
|---|---|---|
| Modelo de ejecución | Paralelo (motor Sealevel; transacciones concurrentes que no entran en conflicto) | Secuencial (una transacción a la vez; cola ordenada) |
| Formato de bytecode | sBPF (Solana Berkeley Packet Filter) | Opcodes de EVM (bytecode compilado de Solidity/Vyper) |
| Lenguaje de desarrollo principal | Rust (también admite C y C++) | Solidity (también admite Vyper) |
| Rendimiento de transacciones (TPS) | Hasta ~65.000 TPS de máximo teórico | ~15-30 TPS en la Mainnet de Ethereum |
| Medición de costes | Unidades de computación (CU): tarifa base fija + mercado de tarifas de prioridad | Gas: mercado de tarifas dinámico (tarifa base EIP-1559 + propina) |
| Adopción de la cadena | Mainnet de Solana + ecosistema creciente de L2 de SVM | Ethereum + más de 100 cadenas compatibles con EVM |
| Arquitecto fundador | Anatoly Yakovenko (cofundador de Solana) | Vitalik Buterin y el equipo de Ethereum |
Las cifras de TPS representan máximos teóricos en condiciones óptimas y varían significativamente bajo una carga de red real. Las cadenas L2 compatibles con EVM logran un rendimiento sustancialmente mayor que la Mainnet de Ethereum. Última actualización: primer trimestre de 2025. Fuentes: Solana Foundation (solana.com), ethereum.org.
El efecto de red de la EVM en más de 100 cadenas es su ventaja competitiva duradera. La arquitectura de ejecución paralela de SolanaVM ofrece ventajas de rendimiento medibles para casos de uso específicos de alta frecuencia, pero la velocidad bruta es solo una dimensión de una decisión de construcción o inversión.
Programas de Solana frente a contratos inteligentes de Ethereum: ¿cuál es la diferencia?
Los programas de Solana (el término oficial de la Solana Foundation para los contratos inteligentes en SolanaVM) se diferencian de los contratos inteligentes de la EVM no solo en el nombre, sino en su arquitectura estructural.
Los programas de Solana no tienen estado. La lógica del programa reside en una cuenta On-Chain; los datos sobre los que opera ese programa residen en cuentas de datos separadas que el programa lee y escribe. Un contrato inteligente de la EVM, por el contrario, agrupa tanto la lógica como el estado en un único objeto de contrato. El contrato posee su propio almacenamiento. Esta separación en el modelo de Solana es lo que permite a Sealevel determinar las dependencias de las cuentas antes de la ejecución: las cuentas involucradas en cualquier transacción se declaran explícitamente de antemano, lo que proporciona al motor de ejecución la información que necesita para programar la ejecución paralela de forma segura.
SolanaVM no es compatible con EVM. La fuente cita a Neon EVM como un entorno EVM de tercero independiente asociado con Solana. No hace que la propia SVM sea compatible, y su arquitectura actual, estado de despliegue, soporte de herramientas y limitaciones deben evaluarse de forma independiente.
Desarrollo en SolanaVM: lenguajes, herramientas y primeros pasos
Los programas de Solana se escriben principalmente en Rust, un lenguaje de programación de sistemas elegido por sus garantías de seguridad de memoria y sus características de rendimiento, y se compilan en bytecode sBPF antes de su despliegue en SolanaVM.
Rust impone la seguridad de la memoria en el momento de la compilación a través de un modelo de propiedad que elimina clases enteras de errores: desreferencias de punteros nulos, carreras de datos y desbordamientos de búfer, todo ello sin depender de un recolector de basura. Estas propiedades se alinean con los requisitos de seguridad y rendimiento de la ejecución On-Chain, donde los errores no se pueden parchear después del despliegue y los costes de ejecución importan a nivel de instrucción. C y C++ también son técnicamente compatibles con SolanaVM, pero Rust es el estándar de facto en todo el ecosistema de desarrolladores de Solana.
El Anchor Framework para el desarrollo de Solana abstrae gran parte de la complejidad de bajo nivel de Rust y sBPF, funcionando de forma análoga a Hardhat o Foundry en el ecosistema EVM. Anchor proporciona validación de cuentas estructurada, manejo de errores y definiciones de interfaz de programas, lo que reduce significativamente el código repetitivo necesario para escribir un programa de Solana correcto. Tenga en cuenta que el Anchor Framework para Solana no está relacionado con Anchor Protocol, el protocolo de préstamo de Terra/Luna DeFi que colapsó en 2022.
La arquitectura de ejecución paralela de SolanaVM la hace particularmente adecuada para aplicaciones DeFi que requieren un alto rendimiento: libros de órdenes On-Chain, motores de Liquidación y programas de optimización de rendimientos que exigen baja latencia y alta densidad de transacciones. Los principales protocolos nativos de SolanaVM en DeFi incluyen Raydium (Maker de mercado automatizado), Jupiter (agregador de DEX) y Kamino (optimización de rendimientos). El SOL se puede adquirir en los principales intercambios de Criptomoneda y se utiliza para pagar unidades de computación al interactuar con los programas de SolanaVM.
Para obtener una guía de inicio rápido completa para desarrolladores, visite la documentación oficial para desarrolladores de Solana.
Unidades de computación: cómo mide SolanaVM la ejecución de programas
Las unidades de computación (CU) son el equivalente en SolanaVM al gas de Ethereum: la unidad que mide los recursos computacionales consumidos por la ejecución de un programa de Solana.
Cada transacción de SolanaVM opera dentro de un presupuesto de unidades de computación. El máximo actual es de 1,4 millones de CU por transacción, según se especifica en la documentación de la Solana Foundation (Fuente: docs.solana.com, a fecha del primer trimestre de 2025). Un programa que exceda su presupuesto de CU a mitad de la ejecución se aborta y la transacción falla. Los desarrolladores solicitan un límite de CU específico para cada transacción; solicitar de más desperdicia un Ahorro potencial en las tarifas, mientras que solicitar de menos causa fallos evitables.
Las comisiones de transacción en Solana se pagan en SOL y están determinadas en parte por el consumo de CU (unidades de cómputo). Se aplica una Tarifa base a todas las transacciones; un mercado de comisiones de prioridad opcional permite a los usuarios pagar más para adelantarse en la programación de espacios durante periodos de alta demanda. Las unidades de cómputo funcionan de manera similar al gas de Ethereum en el sentido de que ambas miden el coste computacional, pero el sistema de CU de Solana utiliza una Tarifa base de precio fijo en lugar de una subasta totalmente dinámica, con comisiones de prioridad añadidas encima.
¿Se pueden portar los contratos EVM a SolanaVM?
La portabilidad directa de contratos de EVM a SolanaVM no es posible sin una reescritura. Los programas de Solana requieren Rust y código de bytes sBPF, no Solidity ni códigos de operación (opcodes) de EVM. Los modelos de ejecución son arquitectónicamente lo suficientemente diferentes como para que no exista una traducción línea por línea.
Los contratos de EVM y los programas de Solana utilizan modelos de estado y de cuenta diferentes, por lo que una migración nativa suele requerir cambios arquitectónicos. Un entorno EVM independiente puede preservar partes de un flujo de trabajo de Solidity, mientras que el desarrollo nativo de SVM utiliza cadenas de herramientas diferentes. Compare la compatibilidad, el rendimiento, las auditorías, las dependencias operativas y el soporte actual en lugar de tratar cualquiera de las dos vías como la opción por defecto.
SolanaVM más allá de Solana: adopción multicadena y el ecosistema SVM
SolanaVM opera más allá de la red principal de Solana, con proyectos de capa 2 que la implementan como un entorno de ejecución independiente en otras blockchains de capa base.
Aunque SolanaVM fue diseñada como un entorno de ejecución de capa 1, su adopción por parte de proyectos de capa 2 marca una evolución arquitectónica significativa. La tesis de la portabilidad, que sostiene que SolanaVM puede funcionar como un estándar de ejecución compartido a través de múltiples cadenas al igual que lo hace la EVM, está pasando de la teoría a la producción.
La siguiente tabla enumera las cadenas SVM actuales por tipo y estado:
| Nombre de la cadena | Tipo de cadena | Capa de Liquidación | Estado |
|---|---|---|---|
| Solana Mainnet | capa 1 | Nativa (Solana) | Activa |
| Eclipse | capa 2 | Ethereum | Activa (Mainnet) |
Última actualización: primer trimestre de 2025. Verifique el estado actual del proyecto antes de volver a publicar. Fuentes: eclipse.xyz, documentación de la Solana Foundation. Hay proyectos adicionales de rollups SVM en desarrollo; esta tabla requiere actualizaciones periódicas a medida que el ecosistema evoluciona.
En todas las cadenas SVM, las aplicaciones de DeFi, particularmente los DEX, los protocolos de préstamo y los programas de optimización de rendimientos, representan el principal caso de uso para las capacidades de ejecución paralela de SolanaVM. Neon EVM representa una dimensión diferente del crecimiento del ecosistema SVM, permitiendo que contratos compatibles con EVM se ejecuten en la SolanaVM de Solana y tendiendo un puente entre los dos ecosistemas de contratos inteligentes más grandes.
Eclipse: SolanaVM como una capa 2 de Ethereum
La fuente cita a Eclipse como un ejemplo de tecnología SVM utilizada fuera de Solana. Su arquitectura actual, modelo de Liquidación, disponibilidad de datos, supuestos de seguridad y rendimiento medido deben verificarse a partir de fuentes primarias actualizadas en lugar de resumirse como si heredaran una garantía de seguridad general.
La arquitectura separa dos funciones que la mayoría de las blockchains agrupan. SolanaVM se encarga de la ejecución: recibe transacciones, procesa programas de Solana en paralelo utilizando Sealevel y genera salidas de estado a alta velocidad. Ethereum se encarga de la Liquidación: Eclipse envía los datos de las transacciones de vuelta a Ethereum, heredando su modelo de seguridad y finalidad. Eclipse desacopla la velocidad de ejecución del modelo de seguridad de la cadena base, accediendo a ambos de forma independiente.
Esta arquitectura demuestra que SolanaVM puede funcionar como un estándar de ejecución portátil fuera de la propia red de Solana. Sigue la misma portabilidad arquitectónica que permitió que la EVM se extendiera por docenas de cadenas. El despliegue de Eclipse es la evidencia actual más clara de la tesis de portabilidad de SVM.
Para obtener todos los detalles arquitectónicos, visite la documentación oficial de Eclipse en eclipse.xyz.
SVM Rollups: La próxima frontera de la adopción de SolanaVM
Un rollup SVM (una solución de capa 2 impulsada por SolanaVM) es una Blockchain que utiliza SolanaVM como su entorno de ejecución mientras envía los datos de las transacciones a una cadena de capa base para su Liquidación y disponibilidad de datos.
La arquitectura de rollup desacopla la velocidad de ejecución de SolanaVM del modelo de seguridad de cualquier cadena individual. En lugar de requerir una nueva cadena independiente, un rollup SVM puede conectarse a una capa base existente (Ethereum, Celestia o la propia Solana) para la disponibilidad de datos y la finalidad. El rendimiento de ejecución paralela de SolanaVM se vuelve accesible en todo el ecosistema Blockchain más amplio en lugar de ser exclusivo de la propia red de Solana.
El despliegue en la red principal de Eclipse representa la arquitectura de rollup SVM más avanzada actualmente en producción. Hay proyectos adicionales de rollups SVM en desarrollo, aunque su estado cambia con frecuencia. Si la adopción de rollups SVM continúa su trayectoria actual, la presencia multicadena de SolanaVM podría acercarse a la amplitud de la adopción de la EVM, aunque el tamaño del ecosistema de desarrolladores sigue siendo la variable diferenciadora clave.
Esta sección cubre desarrollos del ecosistema con visión de futuro. El estado de los proyectos requiere una verificación periódica. Última actualización: primer trimestre de 2025.
Cómo se está desarrollando la adopción de SolanaVM más allá de Solana
SolanaVM está mostrando signos tempranos de adopción multicadena, con proyectos como Eclipse implementándola como una capa de ejecución fuera de la red de Solana. El hecho de que SolanaVM logre una estandarización multicadena similar a la de la EVM depende de las tasas de adopción de los desarrolladores, la madurez de las herramientas y el éxito de los proyectos de rollups SVM.
La evidencia del creciente alcance de SolanaVM es concreta. Eclipse opera una red principal en vivo utilizando SolanaVM como su entorno de ejecución en Ethereum. Los proyectos de rollups SVM están pasando de estar anunciados a estar activos. El Anchor Framework ha madurado hasta el punto en que el desarrollo en SolanaVM es sustancialmente más accesible de lo que era hace dos años. Los protocolos DeFi en Solana (Raydium, Jupiter, Kamino) demuestran que la arquitectura de ejecución paralela de SolanaVM genera actividad económica real, no solo números teóricos de capacidad de procesamiento.
Los obstáculos son igualmente concretos. La EVM tiene una ventaja de una década en adopción por parte de desarrolladores, madurez de herramientas y despliegue multicadena. Un desarrollador que conoce Solidity puede desplegar en más de 100 cadenas hoy en día; un desarrollador que conoce Rust y el Anchor Framework puede desplegar en la red principal de Solana y en Eclipse, con más cadenas SVM llegando gradualmente. El efecto de red de la EVM representa un foso competitivo genuino, no una carga del pasado que SolanaVM desplace automáticamente. La arquitectura de ejecución paralela de SolanaVM ofrece ventajas medibles para casos de uso de DeFi de alto rendimiento, pero la superioridad técnica en una dimensión no se traduce automáticamente en adopción por parte del ecosistema.
La creciente adopción de SolanaVM en la red nativa de Solana aumenta la demanda de SOL como el token de comisión para los pagos de unidades de cómputo. Las cadenas SVM que liquidan en otras redes (como Eclipse liquidando en Ethereum) pueden utilizar estructuras de comisiones diferentes; la relación de demanda de SOL varía según la arquitectura de la cadena.
Este contenido tiene fines informativos únicamente y no constituye asesoramiento financiero ni de inversión. SolanaVM y SOL (la Criptomoneda nativa de Solana) conllevan riesgos inherentes a la tecnología Blockchain y a los Recursos digitales. Los lectores deben realizar una investigación independiente antes de tomar cualquier decisión de inversión.
La trayectoria de la adopción de SolanaVM en la red principal de Solana, Eclipse y los rollups SVM emergentes vendrá determinada tanto por el crecimiento de la comunidad de desarrolladores como por el mérito arquitectónico. El argumento arquitectónico a favor de SolanaVM está bien establecido. El argumento del ecosistema aún se está construyendo.
Explorar SOL en Bybit
Los lectores pueden revisar la información actual del mercado de SOL) o el mercado Spot de SOL/USDT.). Estos enlaces proporcionan acceso al mercado y no prueban que Solana, un monedero o un protocolo de un Tercero sean adecuados para cada lector.
Preguntas frecuentes: explicación de SolanaVM
¿Qué es SolanaVM?
SolanaVM (también conocida como Máquina Virtual Solana o SVM) es el entorno de ejecución del blockchain Solana: la capa de software que procesa los programas de Solana y confirma sus resultados en la red. SolanaVM no es un token ni un producto independiente; es un componente arquitectónico central de Solana. En contextos de blockchain, SVM significa Máquina Virtual Solana, no Máquina de Vectores de Soporte.
¿En qué se diferencia SolanaVM de la EVM?
SolanaVM y la Máquina Virtual Ethereum (EVM) difieren en tres dimensiones arquitectónicas principales. Primero, SolanaVM procesa transacciones no conflictivas en paralelo utilizando el motor Sealevel; la EVM procesa las transacciones secuencialmente. Segundo, SolanaVM ejecuta bytecode sBPF compilado desde Rust; la EVM ejecuta opcodes compilados desde Solidity o Vyper. Tercero, SolanaVM mide el coste de ejecución en unidades de cómputo (CU); la EVM utiliza gas. La EVM tiene un ecosistema multichain sustancialmente mayor.
¿Qué lenguaje de programación se utiliza para SolanaVM?
Los programas de Solana se escriben principalmente en Rust, un lenguaje de programación de sistemas valorado por sus garantías de seguridad de memoria y su rendimiento. El código Rust se compila a bytecode sBPF antes de su despliegue on-chain. El Marco Anchor para Solana simplifica el desarrollo en Rust al gestionar la validación de cuentas y la estructura del programa de forma automática. Técnicamente, C y C++ también son compatibles, pero Rust es el estándar de facto.
¿Es SolanaVM más rápida que EVM?
El rendimiento máximo teórico de SolanaVM alcanza aproximadamente 65.000 TPS en condiciones óptimas; la mainnet de Ethereum procesa aproximadamente 15 a 30 TPS secuencialmente (Fuente: Solana Foundation, ethereum.org, a Q1 2025). La ejecución en paralelo de SolanaVM le otorga una ventaja de velocidad medible para cargas de trabajo de transacciones no conflictivas. Las cadenas de capa 2 compatibles con EVM, como Arbitrum y Optimism, logran cifras de rendimiento que reducen significativamente esta brecha en la práctica.
¿Qué es sBPF en Solana?
sBPF (Solana Berkeley Packet Filter) es el formato de bytecode que ejecuta SolanaVM: la versión modificada de Solana del conjunto de instrucciones Berkeley Packet Filter, adaptada para la ejecución de programas de blockchain. Cuando un desarrollador escribe un programa de Solana en Rust, el compilador de Rust lo traduce a bytecode sBPF antes de su despliegue. Los validadores ejecutan directamente ese bytecode sBPF. sBPF es distinto de la tecnología de red BPF original utilizada en los kernels de sistemas operativos.
¿Se pueden ejecutar contratos EVM en SolanaVM?
El bytecode EVM no se ejecuta de forma nativa en SolanaVM porque los modelos de ejecución y de cuentas difieren. Un entorno EVM de Tercero independiente puede admitir partes de un flujo de trabajo de Solidity, mientras que una implementación SVM nativa requiere un lenguaje y una arquitectura compatibles. Verifique la compatibilidad de herramientas actual y evalúe la carga de trabajo real antes de elegir un camino.
¿Qué es el blockchain Eclipse y cómo utiliza SolanaVM?
Eclipse es un blockchain de capa 2 de Ethereum que utiliza SolanaVM como su entorno de ejecución mientras realiza la Liquidación de transacciones en Ethereum. Eclipse procesa transacciones utilizando el motor de ejecución en paralelo Sealevel de SolanaVM, logrando un rendimiento a nivel de Solana. La Liquidación y la disponibilidad de datos son gestionadas por Ethereum, heredando su modelo de seguridad. Eclipse demuestra que SolanaVM puede funcionar como un estándar de ejecución portable más allá de la red Solana.
¿Qué son los programas de Solana?
Los programas de Solana son el término oficial de SolanaVM para contratos inteligentes: código on-chain autoejecutable que SolanaVM procesa cuando es invocado por una transacción. A diferencia de los contratos inteligentes de EVM, que almacenan tanto la lógica como el estado dentro del mismo objeto de contrato, los programas de Solana no tienen estado. La lógica del programa reside en una cuenta de programa; los datos sobre los que opera residen en cuentas de datos separadas. Este diseño sin estado permite que el motor de ejecución en paralelo de SolanaVM ejecute de forma segura múltiples programas simultáneamente.
¿Qué son las unidades de cómputo en Solana?
Las unidades de cómputo (CU) son el equivalente de SolanaVM al gas de Ethereum: la unidad que mide los recursos computacionales consumidos por la ejecución de un programa de Solana. Cada transacción de SolanaVM opera dentro de un presupuesto de CU limitado a 1,4 millones de CU por transacción (Fuente: documentación de Solana Foundation, docs.solana.com, a Q1 2025). Los programas que exceden su presupuesto de CU son abortados. Las comisiones de transacción en Solana se pagan en SOL, determinadas en parte por el consumo de CU, con un mercado de comisiones prioritarias para periodos de alta demanda.
¿Se está convirtiendo SolanaVM en un nuevo estándar de blockchain?
La fuente identifica una adopción temprana de SVM más allá de Solana, incluyendo Eclipse y otros proyectos anunciados. Los despliegues y la actividad actuales deben ser verificados. Si la tecnología SVM se estandarizará ampliamente sigue siendo incierto y no debe presentarse como una previsión.