EVM vs SVM: una guía para desarrolladores

Publicado el 25 de septiembre de 202611 min de lectura

Toda blockchain funciona sobre una máquina virtual, el motor que ejecuta programas y aplica sus cambios de estado. El motor de Ethereum es la EVM (Ethereum Virtual Machine), que también impulsa la mayoría de sus Layer 2. El de Solana es la SVM (Solana Virtual Machine), construida para ejecutar transacciones en paralelo. La diferencia arquitectónica central es que la EVM almacena el código y el estado de un contrato juntos, mientras que la SVM los mantiene en cuentas separadas. Esa diferencia determina cómo los programas almacenan datos, cómo se ejecutan las transacciones y cómo responden las comisiones a la congestión.

Esta guía compara ambas en cuanto a modelos de cuentas, ejecución, comisiones, diseño de programas y herramientas, con ejemplos de código breves, y cierra con un marco para decidir dónde construir o portar. Si preferís video, nuestra guía de SVM vs EVM para builders cubre la misma comparación.

¿Qué son la EVM y la SVM?

La EVM es una máquina virtual basada en pila que procesa transacciones una a la vez, actualizando un único árbol de estado compartido. Su principal ventaja es la compatibilidad. El mismo contrato en Solidity se despliega sin cambios en Ethereum, en sus Layer 2 (Arbitrum, Base, Optimism, Unichain, World Chain, Ink) y en chains EVM independientes (BNB Chain, Avalanche, Polygon, Monad, Berachain), y las herramientas asociadas funcionan en todos lados donde funciona el bytecode. Si la EVM es nueva para vos, nuestra explicación de la Ethereum Virtual Machine cubre los fundamentos.

La SVM fue diseñada en torno a la ejecución paralela. Los programas se compilan a bytecode sBPF, un formato basado en registros derivado de eBPF (el mismo diseño de bytecode que usa el kernel de Linux), y cada transacción declara de antemano qué cuentas leerá y escribirá. Esta declaración permite que Sealevel, el runtime paralelo de Solana, ejecute simultáneamente transacciones que no entran en conflicto entre sí en distintos núcleos de CPU. Nuestra explicación de la Solana Virtual Machine cubre el pipeline de ejecución en profundidad.

La siguiente tabla resume las principales diferencias.

Dimension	EVM	SVM
Account model	Code and storage bundled in contract accounts	Everything is an account; programs are stateless
Execution	Sequential within a block	Parallel across non-conflicting transactions
Virtual machine	Stack-based, 256-bit words	Register-based, eBPF-derived
Fee market	One global base fee plus tips	Base fee per signature plus priority fees scoped to contested accounts
Primary language	Solidity	Rust with Anchor
Tokens	One contract per token	Shared Token Program, one mint account per token
Upgrades	Immutable by default, proxies to upgrade	Upgradeable by default, revoke authority to freeze

¿En qué se diferencian los modelos de cuentas?

Ethereum tiene dos tipos de cuentas: cuentas de propiedad externa, controladas por claves privadas, y cuentas de contrato, controladas por código. Una cuenta de contrato mantiene su propio storage, un almacén clave-valor de slots de 32 bytes, junto con su bytecode. Cuando llamás a balanceOf en un token ERC-20, el contrato lee tu balance de un mapping en su propio storage. El código y el estado comparten una dirección y no se pueden separar.

Solana usa un modelo de cuenta único para todo. Cada pieza de estado en Solana es una cuenta con la misma estructura: un balance en lamports (la unidad más pequeña de Solana, equivalente al wei), un campo de datos, un owner y un flag ejecutable. Un programa es una cuenta cuyo dato es bytecode sBPF y cuyo flag ejecutable está en true. El estado que gestiona un programa vive en cuentas de datos separadas. El runtime aplica la propiedad directamente, ya que solo el programa dueño de una cuenta puede modificar sus datos, lo que elimina gran parte de la lógica de control de acceso que un contrato en Solidity implementa por sí mismo. Nuestra guía de cuentas de datos vs. cuentas de programa en Solana cubre esta separación en detalle.

Las program derived addresses (PDAs) son, por lo general, el concepto menos familiar para los desarrolladores de EVM. Donde un contrato en Solidity almacena datos por usuario en un mapping, un programa de Solana deriva una dirección de cuenta dedicada para cada usuario a partir del ID del programa y un conjunto de seeds, típicamente la clave pública del usuario. La derivación es determinística y produce una dirección fuera de la curva Ed25519, por lo que no existe una clave privada para ella. Solo el programa puede firmar en su nombre. En la práctica, cada entrada de un mapping en Solidity se convierte en su propia cuenta en Solana.

Los dos modelos también fijan el precio del storage de forma distinta. En Ethereum, pagás por el storage una sola vez, en gas, cuando lo escribís. En Solana, cada cuenta debe mantener un depósito reembolsable proporcional a su tamaño, conocido como exención de rent. El depósito se devuelve cuando se cierra la cuenta, lo que le da a los desarrolladores un incentivo directo para eliminar el estado que ya no se usa.

¿Cómo funciona la ejecución paralela en la SVM?

La EVM ejecuta las transacciones de un bloque de forma secuencial. Una transacción puede leer o escribir cualquier slot de storage, y esos accesos no se conocen hasta que se ejecuta, por lo que la EVM no puede ejecutar dos transacciones al mismo tiempo con seguridad.

Solana elimina esa incertidumbre al exigir que cada transacción liste todas las cuentas que va a leer y escribir antes de la ejecución. El scheduler ejecuta en paralelo las transacciones que solo leen cuentas compartidas y serializa las transacciones que escriben en la misma cuenta. Un bloqueo de escritura permite un solo hilo a la vez. Las transacciones que necesitan el mismo bloqueo se encolan y se procesan en orden, y no fallan por el conflicto.

Este modelo afecta el diseño de los programas. El estado que muchos usuarios actualizan al mismo tiempo debería dividirse en varias cuentas, que es como están estructurados los tokens SPL (el estándar de tokens de Solana). Dos transferencias de USDC entre wallets no relacionadas escriben en cuatro cuentas de token distintas, por lo que pueden ejecutarse al mismo tiempo. En Ethereum, las mismas dos transferencias actualizan el storage de un único contrato ERC-20 y se ejecutan una después de la otra.

La ejecución paralela también está llegando al ecosistema EVM. Monad ejecuta una L1 EVM con ejecución paralela y compatibilidad total de bytecode, y MegaETH aplica técnicas similares como L2 de Ethereum. Estas chains detectan conflictos en tiempo de ejecución en lugar de exigir que las transacciones declaren sus cuentas, lo que preserva la compatibilidad con EVM a la vez que aumenta el throughput.

¿Cómo se comparan las comisiones?

Ethereum usa un único mercado de comisiones global. Cada transacción paga el mismo base fee, que el protocolo ajusta en cada bloque y quema, más una propina opcional al validador. Una transferencia estándar de ETH cuesta 21,000 de gas, y los bloques apuntan a 30 millones de gas con un límite de 60 millones de gas. Como el base fee aplica a toda la chain, la demanda de una aplicación afecta a todos. Un mint de NFT popular o un claim de airdrop eleva el base fee para todos los usuarios, incluidos los de aplicaciones no relacionadas.

Solana usa una estructura de comisiones distinta. Cada transacción paga un base fee de 5,000 lamports por firma, del cual la mitad se quema y la mitad se paga al validador. El cómputo se mide en compute units (CU), con un presupuesto por defecto de 200,000 CU por instrucción y un máximo de 1.4 millones de CU por transacción. Las transacciones también pueden incluir una comisión de priorización, con precio en micro-lamports por compute unit, para ser programadas antes que otras.

La diferencia clave es el alcance de la competencia por comisiones. Como cada transacción nombra las cuentas en las que escribe, la competencia por priority fee se concentra entre las transacciones que disputan las mismas cuentas. El ecosistema se refiere a este comportamiento como mercados de comisiones locales. El método RPC getRecentPrioritizationFees refleja este diseño al filtrar las muestras de comisiones según las cuentas escribibles que una transacción va a bloquear. Durante un mint popular, las comisiones suben para las transacciones que escriben en las cuentas del mint, mientras que las transacciones no relacionadas prácticamente no se ven afectadas.

Esto afecta la planificación de capacidad. En Ethereum, la actividad de aplicaciones no relacionadas puede elevar tus costos de transacción, y el diseño de la aplicación no puede evitarlo. En Solana, la presión de comisiones proviene principalmente de la contención sobre tus propias cuentas, por lo que distribuir el estado que se escribe con frecuencia entre más cuentas la reduce.

¿Qué cambia en el diseño de programas?

Un contrato en Solidity es una única unidad de código y storage, y es inmutable por diseño. Cambiar su lógica después del despliegue requiere un patrón de proxy construido sobre delegatecall, que enruta las llamadas a un contrato de implementación reemplazable. Un contador mínimo en Solidity se ve así:

solidityCopied
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
contract Counter {
  uint64 public count; // state lives inside the contract itself
  function increment() external {
      count += 1;
  }
}

El programa equivalente en Solana, escrito con Anchor (un framework de programas de Solana ampliamente usado), no almacena estado por sí mismo. El valor del contador vive en una cuenta separada que cada llamada pasa explícitamente:

rustCopied
use anchor_lang::prelude::*;
// Run anchor keys sync to set your program ID here and in Anchor.toml.
declare_id!("REPLACE_WITH_YOUR_PROGRAM_ID");
#[program]
mod counter {
  use super::*;
  pub fn increment(ctx: Context<Increment>) -> Result<()> {
      ctx.accounts.counter.count += 1;
      Ok(())
  }
}
#[derive(Accounts)]
pub struct Increment<'info> {
  #[account(mut)]
  pub counter: Account<'info, Counter>, // state account passed in explicitly
}
#[account]
pub struct Counter {
  pub count: u64,
}

Una versión completa también incluiría una instrucción de inicialización para crear y financiar la cuenta del contador. Antes de que se ejecute el handler, Anchor verifica cada cuenta contra el struct Increment, que confirma que la cuenta tiene el tipo y el owner esperados. Esa verificación no restringe quién puede llamar a la instrucción. Tal como está escrito, cualquiera puede llamar a increment, así que un programa real agregaría un requisito de firmante o una restricción de dirección derivada para controlar quién puede actualizar el contador.

El comportamiento de actualización por defecto está invertido. Los programas de Solana desplegados con una upgrade authority son actualizables de forma nativa, y revocar esa autoridad vuelve al programa inmutable. Por lo tanto, los programas de Solana no necesitan contratos proxy, lo que elimina una categoría de código en la que las auditorías de EVM suelen enfocarse.

Los tokens siguen el mismo patrón. Cada token ERC-20 es su propio contrato que implementa una interfaz estándar, por lo que una aplicación que soporta muchos tokens depende de muchas bases de código independientes. En Solana, los tokens se emiten a través de un Token Program compartido, y Token-2022 ofrece una versión extendida que soporta funciones opcionales como comisiones por transferencia. Cada token es una cuenta mint que registra el supply y los decimales, y el balance de cada holder se almacena en una cuenta de token. Una aplicación que integra estos programas puede soportar cualquier token SPL sin código específico por token.

El manejo de eventos es un área donde la EVM tiene una ventaja clara. Los contratos EVM emiten eventos indexados que eth_getLogs y los indexadores consumen de forma nativa. Solana no tiene un sistema de eventos nativo. Los programas escriben mensajes de log, y los macros de eventos de Anchor codifican datos estructurados en esos logs, que pueden truncarse. Como resultado, la indexación en producción en Solana suele depender de infraestructura de streaming como webhooks y Solana gRPC streaming.

¿Cómo es el stack de cliente?

La elección de VM también determina el lenguaje y las herramientas. El desarrollo en EVM usa Solidity y un toolchain maduro (Foundry, Hardhat) con amplio soporte para testing, fuzzing y despliegue. El desarrollo en Solana usa Rust y Anchor, que tiene una curva de aprendizaje más pronunciada y un grupo de auditores más pequeño, aunque en crecimiento. Nuestro panorama de lenguajes de programación web3 cubre las opciones de lenguaje con más detalle.

La diferencia en los modelos de datos también se ve en el código del cliente. En la EVM, leer estado significa llamar a una función del contrato, que devuelve datos de su propio storage. Este ejemplo usa viem:

typescriptCopied
import { createPublicClient, http, parseAbi, formatUnits } from "viem";
import { mainnet } from "viem/chains";
const client = createPublicClient({
chain: mainnet,
transport: http("https://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY"),
});
const balance = await client.readContract({
address: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", // USDC contract
abi: parseAbi(["function balanceOf(address) view returns (uint256)"]),
functionName: "balanceOf",
args: ["0x47ac0Fb4F2D84898e4D9E7b4DaB3C24507a6D503"],
});
console.log(formatUnits(balance, 6));

En Solana, leer estado significa obtener la cuenta que contiene los datos. El balance de un token se almacena en una cuenta de token en lugar del Token Program, así que el cliente lee esa cuenta directamente. Este ejemplo usa @solana/kit:

typescriptCopied
import { createSolanaRpc, address } from "@solana/kit";
const rpc = createSolanaRpc("https://solana-mainnet.g.alchemy.com/v2/YOUR_API_KEY");
// SOL balance: fetch the account's lamports by its address
const { value: lamports } = await rpc
.getBalance(address("83astBRguLMdt2h5U1Tpdq5tjFoJ6noeGwaY3mDLVcri"))
.send();
// SPL balance: read the token account directly
const { value: tokenBalance } = await rpc
.getTokenAccountBalance(address("2ocS3orPq3jyszjsJ4NozKWyhdotr3csDjAizmkj65aH"))
.send();
console.log(lamports, tokenBalance.uiAmountString);

Este patrón se aplica en toda la capa de cliente. Un cliente EVM consulta un contrato, mientras que un cliente de Solana necesita saber qué cuenta contiene cada dato, lo que hace del layout de cuentas parte del diseño de la aplicación.

¿Qué se rompe al portar una app de EVM a Solana?

Mover una aplicación de la EVM a Solana requiere reescribir el código onchain, porque los modelos de cuentas y de ejecución son distintos. Los principales cambios son:

msg.sender se convierte en cuentas firmantes. La autorización en Solana proviene de cuentas marcadas como firmantes en la transacción y verificadas por tu programa, más PDAs por las que el programa firma cuando el propio programa tiene la autoridad.
Los mappings se convierten en PDAs. Cada clave de un mapping en Solidity pasa a ser una cuenta derivada que debe crearse y financiarse con rent antes del primer uso. La lectura de los datos también cambia, ya que los clientes obtienen cuentas en lugar de consultar el storage del contrato.
El storage del contrato se convierte en cuentas dimensionadas y financiadas con rent. El estado debe asignarse por adelantado con un tamaño conocido, y el depósito se devuelve cuando se cierra la cuenta.
Los patrones de proxy para actualizaciones ya no son necesarios. La upgrade authority del programa reemplaza la configuración de proxy, y revocar esa autoridad vuelve al programa inmutable.
Los eventos se convierten en logs y streaming. Cualquier sistema que consumía eth_getLogs debe reconstruirse en torno al parseo de logs, webhooks o streams de gRPC.
El stack de cliente y de testing cambia. El código de cliente pasa de viem a @solana/kit, los tests pasan de Foundry al framework de testing de Anchor, y el CI necesita un validador local.

Los equipos que se mueven en la dirección opuesta, de la SVM a la EVM, suelen ganar profundidad de herramientas, indexación nativa de eventos y un mercado de auditores más grande, y ceden ejecución paralela, confirmación en menos de un segundo y aislamiento de comisiones por cuenta.

En ambas direcciones, la curva de aprendizaje del equipo suele ser el costo más grande. Para ingenieros de EVM que se mueven a Solana, nuestra hoja de ruta de desarrollo en Solana es un buen punto de partida.

¿Cómo elegís entre la EVM y la SVM?

You are building	Suggested starting point	Why
A high-throughput consumer app (payments, trading, mints)	SVM	Parallel execution and per-account fee isolation keep costs stable under your own load
A DeFi protocol that composes with existing liquidity	EVM	Established DeFi protocols, integrations, and auditors are concentrated in the EVM ecosystem
A team experienced in Solidity with latency-tolerant products	EVM, or a parallel EVM chain	Staying on the existing stack avoids a rewrite when the workload does not require SVM throughput

¿Cómo respalda Alchemy el desarrollo en EVM y SVM?

Respaldamos ambos ecosistemas desde una única plataforma. Nuestros endpoints RPC cubren Ethereum, las principales L2 y el resto del ecosistema EVM. Nuestra infraestructura de Solana entrega llamadas de archivo hasta 20 veces más rápido con 99.99% de uptime, y gRPC streaming provee los feeds de datos en tiempo real de los que depende la indexación en Solana. Si estás evaluando infraestructura de Solana, nuestra guía de RPC de Solana cubre qué buscar en un proveedor.

Una API key gratuita te da endpoints para chains EVM y Solana desde un solo dashboard, sin contrato ni compromiso mínimo, y sin necesidad de integrar un proveedor distinto para cada ecosistema.