---
title: "¿Qué es la Solana virtual machine (SVM) y cómo funciona?"
description: "Un análisis profundo de la arquitectura que impulsa a Solana y por qué importa para los devs."
---

# ¿Qué es la Solana virtual machine (SVM) y cómo funciona?

<ImageBlock
  src="https://media.alchemy.com/1766069216-blog-solana-virtual-machine-1.png"
  alt="Una visualización de la máquina virtual"
  width={1920}
  height={900}
  priority
/>

Solana se ha convertido en una de las blockchains más utilizadas en el ecosistema cripto, ubicándose constantemente entre las cinco primeras por direcciones activas diarias y volumen de transacciones. Solo en octubre de 2025, la red de Solana procesó aproximadamente [70 millones de transacciones diarias y facilitó $143 mil millones](https://liquidityfinder.com/news/solanas-transaction-volume-and-revenue-surpass-all-major-layer-1-blockchains-c3df7) en volumen de DEX, con un throughput en los momentos de mayor actividad que detendría a la mayoría de las demás chains.

Lo que hace esto posible no es solo un consenso rápido o requisitos de hardware robustos, sino que en el núcleo del desempeño de Solana hay un motor de ejecución fundamentalmente distinto: la Solana Virtual Machine \(SVM\).

La Solana Virtual Machine es un runtime basado en registros construido sobre bytecode eBPF que ejecuta transacciones en paralelo al requerir la declaración previa de todas las dependencias de estado. A diferencia del modelo de transacciones secuencial de la [Ethereum Virtual Machine](https://www.alchemy.com/overviews/what-is-the-ethereum-virtual-machine-evm), la SVM fue diseñada desde cero en torno a la ejecución paralela, procesando miles de transacciones de forma concurrente entre núcleos de CPU en lugar de una por una.

Esta decisión arquitectónica repercute en todo: cómo los programas almacenan el estado, cómo se construyen las transacciones, cómo se calculan las fees y cómo los desarrolladores piensan en la construcción de aplicaciones on-chain.

Esta guía desglosa la SVM desde sus fundamentos. Comenzaremos con los componentes centrales, explicaremos cómo funcionan individualmente y luego mostraremos cómo se combinan para permitir el desempeño de Solana. Al final, entenderás no solo _qué_ hace la SVM, sino _por qué_ está construida así.

## ¿Qué es una máquina virtual?

Antes de entrar en detalle en la SVM, establezcamos qué es realmente una máquina virtual y por qué las blockchains las necesitan.

Una máquina virtual \(VM\) es una computadora basada en software que se ejecuta dentro de otra computadora. Ofrece un entorno controlado donde el código puede ejecutarse sin acceder directamente a los recursos del sistema anfitrión. Las VMs están en todas partes: la Java Virtual Machine ejecuta bytecode de Java, tu navegador ejecuta JavaScript en una VM, y los servidores en la nube a menudo se ejecutan dentro de VMs.

Las blockchains necesitan VMs por una razón específica: la ejecución determinista de código no confiable. Cuando despliegas un smart contract, miles de validadores alrededor del mundo necesitan ejecutar ese código y llegar exactamente al mismo resultado. La VM proporciona:

- **Sandboxing**: el código no confiable no puede acceder al sistema anfitrión ni a la memoria de otros programas
- **Determinismo**: las mismas entradas siempre producen las mismas salidas, sin importar el hardware
- **Medición**: la ejecución puede medirse y limitarse \(gas/compute units\) para prevenir abusos
- **Portabilidad**: el código se ejecuta de forma idéntica en distintas máquinas y sistemas operativos

La **Ethereum Virtual Machine \(EVM\)** fue la primera VM de blockchain ampliamente adoptada. Usa una arquitectura basada en stack, ejecuta las transacciones de forma secuencial y almacena código y estado juntos en los contratos. Funciona, pero sus decisiones de diseño generan limitaciones fundamentales de throughput.

La **Solana Virtual Machine \(SVM\)** adopta un enfoque distinto. Usa una arquitectura basada en registros \(más similar a las CPU físicas\), separa el código del estado y, lo más importante, ejecuta las transacciones en paralelo.

## ¿Qué es la Solana virtual machine \(svm\)?

En esencia, la SVM es el motor de ejecución de Solana, el sistema responsable de correr la lógica de los programas, procesar transacciones y actualizar el estado. Si vienes de Ethereum, piénsala como la respuesta de Solana a la EVM, pero arquitectónicamente distinta en aspectos que importan.

Para entender la SVM, primero hay que entender sobre qué opera:

- **Accounts:** la estructura de datos universal de Solana. Todo es una account: las wallets de usuarios, los balances de tokens, el estado de los programas, incluso los propios programas. Las accounts guardan datos y tienen un owner \(el programa autorizado a modificarlas\). A diferencia de los contratos de la EVM, que combinan código y almacenamiento, Solana los separa por completo: todo el estado vive en accounts.
- **Programs:** es el término de Solana para los smart contracts. Los programs son _sin estado (stateless):_ contienen únicamente código ejecutable, compilado a un formato de bytecode llamado sBPF. La mayoría de los programs de Solana se escriben en Rust \(aunque también se admiten C y C\+\+\). Cuando un programa se ejecuta, lee y escribe en las accounts que se le pasan, pero no almacena nada internamente.
- **Transactions:** un conjunto de una o más instructions, cada una dirigida a un programa y especificando qué accounts necesita leer o escribir. Esta declaración previa de dependencias de estado es la clave de todo. Es lo que hace posible la ejecución paralela.

Con esa base, esta es la forma más simple de entender la SVM: es un entorno de runtime sandboxed que toma bytecode de programa compilado, lo ejecuta contra un conjunto de accounts y determina los cambios de estado resultantes. Cada transacción en Solana pasa por la SVM.

Lo que hace distinta a la SVM de la EVM no son solo detalles de implementación: es el diseño de base. La SVM se construyó en torno a la ejecución paralela desde el primer día. Las transacciones declaran sus dependencias de estado por adelantado, lo que permite al runtime identificar trabajo sin conflictos y procesarlo de forma concurrente entre núcleos de CPU. La EVM procesa las transacciones secuencialmente; la SVM procesa miles de forma simultánea.

_Una nota sobre terminología: el término "SVM" tiene distintos significados según el contexto. La definición estricta se refiere específicamente al intérprete de bytecode y al compilador JIT que ejecuta el código de los programas \(veremos sBPF, el formato de bytecode, más adelante\). La definición más amplia, que usa oficialmente equipos como Anza \(el equipo core del validador de Solana\), abarca todo el pipeline de ejecución de transacciones: scheduling, presupuesto de compute, carga de programas, ejecución y actualización de estado. Cuando los desarrolladores dicen "la SVM", normalmente se refieren a este sistema más amplio. Esta guía cubre ambas, y seremos claros sobre a cuál nos referimos en cada momento._

## Entendiendo la arquitectura de la SVM

Ahora que sabemos _qué_ es la SVM y en qué se diferencia de otras VMs de blockchain, veamos _cómo_ funciona realmente. Esta sección recorre la arquitectura completa, desde el momento en que llega una transacción hasta el cambio de estado final.

Cubriremos cuatro piezas interconectadas:

1. Cómo fluyen las transacciones a través del sistema \(el pipeline\)
1. El motor de ejecución que corre tu código \(eBPF, compilación, la VM en sí\)
1. El modelo de datos sobre el que operan los programs \(accounts, PDAs, rent, CPIs\)
1. La ejecución paralela y cómo Sealevel la hace posible

Cada pieza se apoya en la anterior. Al final, entenderás no solo los componentes individuales, sino cómo encajan entre sí para habilitar las características de desempeño de Solana.

## Parte 1: cómo fluyen las transacciones a través de la SVM

El primer paso para entender la SVM es rastrear el recorrido de una transacción, desde el momento en que presionas "enviar" hasta la confirmación del bloque. Este pipeline explica _por qué_ los programs de Solana están estructurados de la forma en que lo están, _por qué_ debes declarar las accounts por adelantado, y _dónde_ ocurre realmente el paralelismo.

Cuando envías una transacción a Solana, esta no simplemente entra en una cola y espera su turno. Fluye a través de una serie de subsistemas especializados, cada uno resolviendo un problema específico:

<CodeSnippet
  language="markdown"
  code={`Transaction submitted
        ↓
   Banking Stage
   (conflict detection, parallel scheduling)
        ↓
   The Bank
   (state snapshot for this slot)
        ↓
   BPF Loader
   (provisions sBPF VM instance)
        ↓
   Program executes
   (reads/writes accounts within budget)
        ↓
   State updates committed`}
/>

Recorramos cada etapa:

### El banking stage: donde ocurre el paralelismo

Este es el controlador de tráfico. Cuando llegan transacciones verificadas, el Banking Stage analiza cada una: ¿qué accounts necesita leer? ¿Cuáles necesita escribir?

Con esta información, determina qué transacciones pueden ejecutarse de forma segura al mismo tiempo:

- Transacciones que tocan accounts completamente distintas → se ejecutan en paralelo
- Transacciones que leen la misma account → se ejecutan en paralelo \(las lecturas no generan conflicto\)
- Transacciones que escriben en la misma account → deben ejecutarse secuencialmente

El scheduler usa bloqueo a nivel de account para hacer cumplir estas reglas. Los worker threads procesan lotes de transacciones sin conflictos de forma simultánea. Este es el corazón del modelo de ejecución paralela de Solana, llamado Sealevel \(profundizaremos en Sealevel en la Parte 4\).

### El bank: estado en un momento dado

Mientras el Banking Stage se encarga del _scheduling_, el Bank se encarga del _estado_. Piénsalo como una instantánea de todo el estado de Solana en un slot específico \(la unidad de tiempo de Solana, aproximadamente 400 ms\).

El Bank gestiona los datos de las accounts, coordina la ejecución y hace seguimiento de qué versión del estado es la canónica. Cada Bank pasa por tres etapas de su ciclo de vida:

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "Stage ", dataType: "object" },
      { key: "2", width: 200, title: "What's Happening", dataType: "object" },
    ],
    data: [
      {
        "1": { title: "<p>Active</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Procesando transacciones actualmente para este slot</p>",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        "1": { title: "<p>Frozen</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Slot completo: no se permiten más cambios</p>",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        "1": { title: "<p>Rooted</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Finalizado y guardado en almacenamiento persistente</p>",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
    ],
  }}
/>

Cuando el Banking Stage ejecuta transacciones, opera contra un Bank específico, una versión específica del mundo. Así es como Solana mantiene la consistencia mientras procesa miles de transacciones en paralelo.

### BPF loaders: poniendo en marcha la ejecución de programs

Cuando una transacción invoca un programa, algo necesita realmente _ejecutar_ el código de ese programa. Ese es el trabajo del BPF Loader.

El BPF Loader gestiona todo el ciclo de vida del programa:

- **Despliegue**: subir nuevo bytecode de programa a la red
- **Compilación JIT**: convertir el bytecode en código de máquina nativo para una ejecución más rápida
- **Actualizaciones**: publicar nuevas versiones de programs existentes
- **Ejecución**: aprovisionar instancias de VM aisladas cuando se invocan los programs

Cada invocación de programa obtiene su propia instancia de VM sBPF en sandbox con:

- Regiones de memoria dedicadas
- Un presupuesto de compute \(similar a los límites de gas\)
- Aislamiento estricto respecto a otros programs

¿El programa excede su presupuesto de compute? La ejecución se detiene. ¿Intenta acceder a memoria que no debería? La ejecución se detiene. El aislamiento es estricto por diseño. Así es como Solana ejecuta de forma segura código no confiable proveniente de miles de desarrolladores.

### Un flujo de transacción típico

Este es el flujo completo para una transacción típica:

1. Envías una transacción especificando qué programa llamar y qué accounts necesita
1. El Banking Stage la recibe, verifica conflictos con otras transacciones pendientes y la programa según corresponda
1. El Bank proporciona la instantánea de estado actual para este slot
1. El BPF Loader aprovisiona una instancia de VM sBPF para el programa objetivo
1. El programa se ejecuta, leyendo y escribiendo en las accounts especificadas
1. Los cambios de estado se confirman en el Bank
1. Eventualmente, el Bank se congela y se enraíza (roots), haciendo permanentes los cambios

Cada componente resuelve un problema específico: el Banking Stage habilita el paralelismo, el Bank ofrece un estado consistente y el BPF Loader garantiza una ejecución segura. Juntos, forman la "SVM" en su sentido más amplio.

¿Quieres profundizar más en las transacciones? Consulta estos recursos:

- [Transaction lifecycle](https://solana.com/docs/core/transactions): cómo se estructuran y procesan las transacciones
- [Fees on Solana](https://solana.com/docs/core/fees): compute units, priority fees y presupuesto
- [Clusters & endpoints](https://solana.com/docs/core/clusters): entendiendo la arquitectura de red de Solana

## Parte 2: el motor de ejecución

El BPF Loader aprovisiona instancias de VM para ejecutar el código de los programs. Pero, ¿qué sucede realmente dentro de esa instancia de VM?

La mayoría de las VMs de blockchain se diseñaron desde cero. Solana tomó un rumbo distinto: adoptó [eBPF](https://ebpf.io/) \(extended Berkeley Packet Filter\), una tecnología originalmente creada para el kernel de Linux.

BPF se originó en 1992 en el Lawrence Berkeley Laboratory para el filtrado eficiente de paquetes de red. Con el tiempo, evolucionó a eBPF, una VM de propósito general y en sandbox que se ejecuta de forma segura dentro del kernel de Linux. Si has usado herramientas de observabilidad como [bpftrace](https://github.com/bpftrace/bpftrace) o trabajado con networking basado en eBPF, ya te has topado con esta tecnología. Es infraestructura probada en batalla que impulsa sistemas críticos a gran escala.

El fundador de Solana, Anatoly Yakovenko, con su trayectoria en sistemas operativos \(más de 13 años en Qualcomm\), llegó a una idea clave: ¿por qué construir una nueva VM desde cero cuando ya existe una que resuelve los problemas difíciles?

eBPF ofrecía exactamente lo que Solana necesitaba:

- **Seguridad sin overhead:** los programas eBPF se ejecutan en un entorno restringido que no puede colapsar el sistema anfitrión ni corromper memoria. El bytecode se verifica estáticamente antes de cargarse: sin accesos inválidos a memoria, sin saltos fuera de rango, sin operaciones no autorizadas. Esta seguridad no implica overhead en tiempo de ejecución, a diferencia de los runtimes gestionados que necesitan garbage collection.
- **Desempeño casi nativo:** la arquitectura basada en registros \(a diferencia del diseño basado en stack de la EVM\) permite la compilación JIT a código de máquina nativo. Los programs se ejecutan a una velocidad casi nativa.
- **Toolchain maduro:** LLVM ya incluye un backend para eBPF. Rust, C, C\+\+ y otros lenguajes compatibles con LLVM compilan directamente a bytecode eBPF. Escribes en un lenguaje que conoces; el toolchain se encarga del resto.

### sBPF: la variante personalizada de solana

Solana no usa eBPF estándar. No podría, ya que el eBPF estándar fue diseñado para operaciones en espacio de kernel con restricciones estrictas que no se corresponden con la ejecución en blockchain. Así que Solana lo forkeó.

El resultado es sBPF \(Solana Bytecode Format\), una variante modificada adaptada para la ejecución de programs on-chain:

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "Feature", dataType: "object" },
      { key: "2", width: 200, title: "Standard eBPF", dataType: "object" },
      { key: "3", width: 200, title: "Solana sBPF", dataType: "object" },
    ],
    data: [
      {
        "1": { title: "<p>Environment</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Espacio de kernel</p>", tooltip: "", icon: "" },
        "3": { title: "<p>Espacio de usuario</p>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        "1": { title: "<p>Stack size</p>", tooltip: "", icon: "" },
        "2": { title: "<p>512 bytes</p>", tooltip: "", icon: "" },
        "3": { title: "<p>4KB por frame</p>", tooltip: "", icon: "" },
        id: 2,
      },
      {
        "1": { title: "<p>Loops</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Restringidos (deben terminar de forma demostrable)</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title: "<p>Permitidos (limitados por compute units)</p>",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
      {
        "1": { title: "<p>Custom syscalls</p>", tooltip: "", icon: "" },
        "2": { title: "<p>No</p>", tooltip: "", icon: "" },
        "3": {
          title: "<p>Sí (logging, CPI, criptografía)</p>",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
    ],
  }}
/>

Las restricciones que hacen seguro a eBPF en espacio de kernel —stack diminuto, sin loops— frenarían el desarrollo de smart contracts en Solana. sBPF relaja estas restricciones sin dejar de mantener la seguridad, mediante presupuestos de compute units: puedes iterar en un loop, pero eventualmente te quedarás sin compute.

Las syscalls personalizadas también importan. Los programs necesitan registrar mensajes (logging), invocar otros programs \(Cross-Program Invocation\) y realizar operaciones criptográficas. El eBPF estándar no contempla nada de esto, y sBPF lo agrega como primitivas de primera clase.

Si estás compilando programs de Solana, verás el target triple `sbf-solana-solana` en tu toolchain. Ese es el identificador de esta variante específica de Solana.

### De Rust a bytecode: el pipeline de compilación

Cuando ejecutas `cargo build-sbf`, tu código Rust pasa por un pipeline de compilación de varias etapas:

**1. Frontend de Rust:** el compilador analiza tu código, expande macros, realiza el chequeo de tipos y ejecuta el borrow checker para validar la seguridad de memoria. Para cuando el código sale de esta etapa, Rust ya eliminó clases enteras de bugs \(use-after-free, data races, punteros nulos\) que afectan a otros lenguajes de sistemas. Esta es una de las ventajas poco reconocidas de Solana: seguridad de memoria garantizada en tiempo de compilación, antes de que tu programa toque siquiera la chain.

**2. Optimización con LLVM:** el código se transforma a LLVM IR, una representación agnóstica de plataforma donde ocurre la optimización real: constant folding, inlining de funciones, eliminación de código muerto, loop unrolling. Estas optimizaciones importan porque las compute units cuestan dinero. Un bytecode más pequeño y ajustado significa transacciones más baratas.

**3. Backend sBPF:** el fork personalizado de Solana del backend BPF de LLVM convierte el IR optimizado en bytecode sBPF, empaquetado como un archivo ELF \(`.so`\). Esto es lo que se despliega a la red, y lo que el BPF Loader aprovisiona en una instancia de VM cuando se invoca tu programa.

<CodeSnippet
  language="text"
  code={`   Rust source (.rs)
          ↓
   Rust compiler (type checking, borrow checker)
          ↓
   LLVM IR (optimizations)
          ↓
   sBPF bytecode (.so)
          ↓
   Deployed to Solana`}
/>

### Dentro de la VM sBPF

Ahora estamos en el nivel más bajo: la máquina virtual real que ejecuta tu bytecode.

El conjunto de instrucciones sBPF usa instrucciones de 64 bits \(8 bytes cada una\) con un diseño similar a RISC y aproximadamente 100 opcodes. Los programs tienen acceso a 11 registros de 64 bits:

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "Column ", dataType: "object" },
      { key: "2", width: 200, title: "Purpose", dataType: "object" },
    ],
    data: [
      {
        "1": { title: "<p>R0</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Valores de retorno</p>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        "1": { title: "<p>R1-R5</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Argumentos de función</p>", tooltip: "", icon: "" },
        id: 2,
      },
      {
        "1": { title: "<p>R6-R9</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Callee-saved (se preservan entre llamadas)</p>",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
      {
        "1": { title: "<p>R10</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Frame pointer (solo lectura)</p>",
          tooltip: "",
          icon: "",
        },
        id: 4,
      },
    ],
  }}
/>

#### Layout de memoria

La VM organiza la memoria en regiones fijas, cada una comenzando en una dirección específica:

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "Address", dataType: "object" },
      { key: "2", width: 200, title: "Region", dataType: "object" },
      { key: "3", width: 200, title: "Purpose", dataType: "object" },
    ],
    data: [
      {
        "1": { title: "<p>0x000000000</p>", tooltip: "", icon: "" },
        "2": { title: "<p>.text</p>", tooltip: "", icon: "" },
        "3": { title: "<p>Código del programa</p>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        "1": { title: "<p>0x100000000</p>", tooltip: "", icon: "" },
        "2": { title: "<p>.rodata</p>", tooltip: "", icon: "" },
        "3": {
          title: "<p>Constantes y datos de solo lectura</p>",
          tooltip: "",
          icon: "",
        },
        id: 4,
      },
      {
        "1": { title: "<p>0x200000000</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Stack</p>", tooltip: "", icon: "" },
        "3": { title: "<p>4KB por call frame</p>", tooltip: "", icon: "" },
        id: 3,
      },
      {
        "1": { title: "<p>0x300000000</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Heap</p>", tooltip: "", icon: "" },
        "3": { title: "<p>32KB de asignación por defecto</p>", tooltip: "", icon: "" },
        id: 2,
      },
      {
        "1": { title: "<p>0x400000000</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Input</p>", tooltip: "", icon: "" },
        "3": {
          title: "<p>Accounts y datos de la instrucción</p>",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
    ],
  }}
/>

Este layout rígido permite que la VM haga cumplir límites estrictos, de modo que tu programa no pueda acceder accidentalmente \(o de forma maliciosa\) a memoria a la que no debería.

#### Compilación JIT y seguridad

La VM sBPF admite dos modos de ejecución:

- **Interpreter:** recorre cada instrucción una por una. Rápido de iniciar, más lento de ejecutar. Útil para testing local y debugging.
- **Compilación JIT:** transforma el bytecode sBPF en código de máquina x86_64 nativo antes de la ejecución. Inicio más lento, ejecución en tiempo de corrida mucho más rápida. Esto es lo que usan los validadores en producción.

El validador Agave almacena en caché los programas compilados con JIT en `ProgramCacheForTxBatch` para su reutilización. Los programs usados con frecuencia, como el Token Program, no se recompilan en cada transacción. Ya están en la caché.

La aplicación de la seguridad ocurre en dos niveles:

1. Verificación estática (antes de la ejecución):

- Rechaza instrucciones mal formadas o inválidas
- Valida todos los patrones de acceso a memoria
- Garantiza que los destinos de los saltos caigan en límites válidos de instrucción
- Detecta rutas de código inalcanzables

Si tu programa no pasa la verificación, no se desplegará. Punto.

1. Medición en tiempo de ejecución (durante la ejecución):

- Cada instrucción consume compute units
- La VM revisa el presupuesto después de cada paso
- Exceder el presupuesto detiene la ejecución de inmediato

Este enfoque de dos capas previene loops infinitos, ataques de agotamiento de recursos y programas descontrolados. Incluso si un bytecode malicioso de alguna forma pasara la verificación estática, no puede ejecutarse indefinidamente. Alcanzará su límite de compute y se detendrá.

Si quieres aprender más sobre el motor de ejecución, consulta estos recursos:

- [Programs overview](https://solana.com/docs/core/programs): cómo funcionan los programs de Solana
- [Developing programs in Rust](https://solana.com/docs/programs/rust): guía oficial de desarrollo en Rust

## Parte 3: el modelo de datos

Ya recorrimos cómo fluyen las transacciones a través de la SVM y cómo se ejecuta el bytecode dentro de la VM sBPF; ahora veamos sobre qué operan los programs.

En la mayoría de los entornos de programación, tienes variables, bases de datos, sistemas de archivos, distintas formas de almacenar y recuperar datos. Las blockchains necesitan algo similar: una forma de persistir el estado entre transacciones. La EVM resolvió esto dándole a cada contrato su propio almacenamiento, un key-value store incorporado en el propio contrato.

Solana adopta un enfoque radicalmente distinto, y entender esta diferencia es esencial, porque moldea todo lo relacionado con cómo se construye sobre la plataforma.

### Todo en Solana es una account

Piensa en Solana como una base de datos gigante de tipo key-value:

- **Key**: una dirección de 32 bytes \(típicamente una clave pública o una dirección derivada\)
- **Value**: una account \(estructura de datos que contiene bytes, un balance y metadatos\)

Esta uniformidad puede parecer extraña al principio, pero es lo que habilita las características de desempeño de Solana. Cada porción de estado tiene una dirección explícita, un owner explícito y reglas explícitas sobre quién puede modificarla. El runtime no necesita recorrer llamadas anidadas entre contratos para averiguar qué estado podría cambiar: lo sabe de antemano gracias a la lista de accounts de la transacción.

Veamos qué hay realmente dentro de una account; cada una contiene los mismos cinco campos:

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "Field", dataType: "object" },
      { key: "2", width: 200, title: "Description", dataType: "object" },
    ],
    data: [
      {
        "1": { title: "<p>lamports</p>", tooltip: "", icon: "" },
        "2": {
          title:
            "<p>Balance en la unidad más pequeña de Solana (1 SOL = mil millones de lamports)</p>",
          tooltip: "",
          icon: "",
        },
        id: 5,
      },
      {
        "1": { title: "<p>data</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Array de bytes arbitrario que almacena el estado de la account</p>",
          tooltip: "",
          icon: "",
        },
        id: 4,
      },
      {
        "1": { title: "<p>owner</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>El program ID autorizado a modificar los datos de esta account</p>",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
      {
        "1": { title: "<p>executable</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Flag booleano: true para las accounts de programa</p>",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        "1": { title: "<p>rent_epoch</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Campo legado para seguimiento de rent (mayormente obsoleto)</p>",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
    ],
  }}
/>

El campo `owner` es crucial. Solo el programa owner puede modificar el campo `data` de una account o debitar sus lamports. Cualquiera puede leer cualquier account \(todo el estado es público en Solana\), y cualquiera puede acreditar lamports a cualquier account. Pero las escrituras están controladas por la propiedad (ownership).

Este modelo de ownership es lo que hace posible la ejecución paralela. El runtime sabe exactamente qué programa puede modificar qué accounts, por lo que puede ejecutar de forma segura y simultánea transacciones sin conflictos.

### Programs: sin estado por diseño

Un programa de Solana es una account ejecutable que contiene bytecode sBPF compilado. Pero aquí está la idea clave: los programs no pueden almacenar estado internamente. Son funciones puras que procesan instructions y modifican las accounts que se les pasan.

Todos los programs de Solana comparten la misma firma de punto de entrada:

<CodeSnippet
  language="rust"
  code={`pub fn process_instruction(
    program_id: &Pubkey,           // This program's address
    accounts: &[AccountInfo],      // All accounts passed to this instruction
    instruction_data: &[u8],       // Arbitrary data (parameters, method selectors, etc.)
) -> ProgramResult`}
/>

Cuando tu programa se ejecuta, recibe:

1. Su propia dirección \(para poder verificar los PDAs que deriva\)
1. Un array de accounts que tiene permitido leer/escribir
1. Datos de instrucción con los parámetros que haya enviado quien llama

El programa ejecuta su lógica, modifica las accounts que tiene permitido modificar y devuelve éxito o un error. No almacena nada internamente entre llamadas.

¿Por qué sin estado? Porque habilita límites de ownership claros. Si los programs almacenaran su propio estado, se necesitarían reglas complejas sobre qué programs podrían acceder a qué almacenamiento. Al forzar todo el estado a vivir en accounts con owners explícitos, el modelo se mantiene simple y la paralelización sigue siendo posible.

_Nota de diseño: a diferencia de los contratos de la EVM, que son inmutables por defecto, los programs de Solana son actualizables (upgradeable) por defecto. La upgrade authority puede publicar nuevo bytecode en cualquier momento. Los desarrolladores pueden revocar la upgrade authority para hacer inmutable un programa, pero esa es una decisión explícita. Esto refleja el enfoque práctico de Solana: la mayoría de los programs necesitan correcciones de bugs y actualizaciones de funcionalidad._

### Program derived addresses \(PDAs\)

Si los programs no tienen estado y todos los datos viven en accounts, ¿cómo crean y gestionan los programs sus propias accounts? No pueden tener claves privadas. Ahí es donde entran en juego las Program Derived Addresses \(PDAs\).

Los PDAs son direcciones especiales que caen fuera de la curva elíptica Ed25519, lo que significa que no existe una clave privada válida para ellas. Esta propiedad criptográfica permite que los programs "firmen" para estas direcciones sin tener claves privadas; el runtime verifica la derivación internamente.

La derivación de un PDA funciona hasheando seeds más el program ID más un "bump seed":

<CodeSnippet
  language="rust"
  code={`// Find a PDA for storing a user's balance
let (user_balance_pda, bump) = Pubkey::find_program_address(
    &[
        b"balance",           // Static seed
        user.key().as_ref()   // User's public key as seed
    ],
    program_id
);`}
/>

El algoritmo prueba valores de bump desde 255 hacia abajo hasta encontrar uno que produzca una dirección fuera de la curva. Este primer bump válido es el "bump canónico".

#### Por qué importan los PDAs

- **Direccionamiento determinista**: dadas las mismas seeds, siempre obtienes la misma dirección. No hace falta almacenar las direcciones por separado.
- **Accounts controladas por el programa**: los programs pueden crear accounts en los PDAs que derivan, y solo ellos pueden firmar por esos PDAs.
- **Patrones de key-value**: las seeds pueden codificar relaciones \(usuario \+ tipo de token → account de balance\), habilitando estructuras de datos similares a un mapa.

<CodeSnippet language="rust" code={`// Common PDA patterns

// User-specific data
let (user*profile, *) = Pubkey::find_program_address(
&[b"profile", user.key().as_ref()],
program_id
);

// Token account for a specific mint
let (token*vault, *) = Pubkey::find_program_address(
&[b"vault", mint.key().as_ref()],
program_id
);

// Unique item with incrementing ID
let (item, \_) = Pubkey::find_program_address(
&[b"item", &item_id.to_le_bytes()],
program_id
);`} />

### Rent: pagar por el estado

El estado de la blockchain no es gratuito. Cada account ocupa espacio en los discos de los validadores, y ese espacio tiene costos reales. Distintas chains manejan esto de forma diferente. Ethereum cobra gas por las operaciones de almacenamiento, pero el estado persiste para siempre una vez escrito, lo que contribuye al crecimiento constante del state bloat.

Solana adopta un enfoque distinto. Existe algo llamado "rent" donde la red cobra aproximadamente 3480 lamports por byte por año para mantener datos on-chain. En la práctica, todas las accounts en mainnet deben ser "rent-exempt", manteniendo por adelantado al menos dos años de rent:

<CodeSnippet
  language="rust"
  code={`rent_exempt_minimum = (account_size + 128 bytes overhead) × 3,480 × 2`}
/>

Para una token account típica \(165 bytes\), esto equivale aproximadamente a 0.002 SOL.

Pero aquí está la diferencia clave respecto a otras chains: cerrar una account devuelve el depósito completo de rent. Esto crea un incentivo económico para limpiar el estado no utilizado, algo que no existe en modelos donde el almacenamiento persiste para siempre.

<CodeSnippet
  language="rust"
  code={`// Closing an account returns lamports to a recipient
ctx.accounts.account_to_close.close(ctx.accounts.recipient.to_account_info())?;`}
/>

### Cross-program invocations \(CPIs\)

Los programs no existen de forma aislada. Un protocolo DeFi podría llamar al Token Program para transferir tokens, el cual a su vez podría llamar al Associated Token Account Program. Estas Cross-Program Invocations son cómo se compone el ecosistema de Solana.

Dos funciones habilitan las CPIs:

<CodeSnippet language="rust" code={`// Standard CPI - passes existing signers through
invoke(
    &instruction,
    &[account1, account2, ...]
)?;

// CPI with PDA signing - program "signs" for a PDA it controls
invoke_signed(
&instruction,
&[account1, account2, ...],
&[&[b"seed", &[bump]]] // Seeds that derive the PDA
)?;`} />

Cuando llamas a `invoke\_signed` con seeds de PDA, el runtime verifica que la derivación coincida con la dirección esperada y otorga autoridad de firma para esa llamada. Así es como los programs pueden controlar activos sin tener claves privadas.

Restricciones importantes:

- Profundidad máxima de llamada de 5 \(4 CPIs anidadas a partir de la transacción inicial\)
- Los privilegios de signer se propagan a través de la cadena de llamadas
- El presupuesto de compute se comparte entre todas las CPIs de una transacción

Para aprender más sobre accounts, consulta lo siguiente:

- [Accounts Overview](https://solana.com/docs/core/accounts): guía completa de las accounts de Solana
- [PDAs](https://solana.com/docs/core/pda): explicación de las Program Derived Addresses
- [CPIs](https://solana.com/docs/core/cpi): guía de Cross-Program Invocations

## Parte 4: ejecución paralela \(sealevel\)

Ya cubrimos todas las piezas fundamentales: cómo fluyen las transacciones a través del pipeline, cómo la VM sBPF ejecuta el bytecode y cómo el modelo de accounts almacena el estado con ownership explícito.

Ahora finalmente podemos responder la pregunta hacia la que veníamos construyendo: ¿cómo logra Solana realmente la ejecución paralela?

Lo hemos insinuado a lo largo del texto: el Banking Stage programando transacciones sin conflictos, las accounts declarando owners por adelantado, las transacciones especificando qué accounts tocarán. Estas no son funcionalidades separadas. Son todas piezas de un único sistema llamado Sealevel.

Sealevel es el runtime de smart contracts paralelo de Solana, y es la innovación central que habilita el throughput de la SVM. Todo lo que hemos cubierto —el modelo de accounts, las reglas de ownership, las declaraciones previas de accounts— existe para hacer posible Sealevel.

La idea fundamental es engañosamente simple:

> Si las transacciones declaran de qué accounts leen y en cuáles escriben antes de que comience la ejecución, el runtime puede identificar transacciones que no se solapan y ejecutarlas de forma concurrente.

Eso es todo. Ese es el truco completo. Pero hacer que funcione en la práctica requirió diseñar cada otra parte del sistema en torno a esta restricción.

### Las reglas de la ejecución paralela

El scheduling de Sealevel sigue reglas simples:

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "Scenario", dataType: "object" },
      { key: "2", width: 200, title: "Execution", dataType: "object" },
    ],
    data: [
      {
        "1": {
          title:
            "<p>Transacciones que tocan <strong>accounts distintas</strong></p>",
          tooltip: "",
          icon: "",
        },
        "2": { title: "<p>Paralelo</p>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        "1": {
          title:
            "<p>Transacciones que <strong>solo leen</strong> las mismas accounts</p>",
          tooltip: "",
          icon: "",
        },
        "2": { title: "<p>Paralelo</p>", tooltip: "", icon: "" },
        id: 2,
      },
      {
        "1": {
          title:
            "<p>Transacciones que <strong>escriben</strong> en las mismas accounts</p>",
          tooltip: "",
          icon: "",
        },
        "2": { title: "<p>Secuencial</p>", tooltip: "", icon: "" },
        id: 1,
      },
    ],
  }}
/>

Eso es todo. Las lecturas no entran en conflicto con las lecturas. Las escrituras entran en conflicto con todo.

<CodeSnippet language="text" code={`TX1: [Account A (write), Account B (read)]
TX2: [Account C (write), Account D (read)]     ──► PARALLEL
TX3: [Account B (read), Account E (write)]

TX4: [Account A (write), Account F (read)] ──► SEQUENTIAL with TX1
(conflicts with TX1 on Account A write)`} />

Por eso debes declarar todas las accounts por adelantado en las transacciones de Solana. No es burocracia: es la información que el runtime necesita para paralelizar tu transacción.

### El algoritmo de scheduling

El Banking Stage implementa Sealevel mediante bloqueo a nivel de account:

1. Llega una transacción especificando accounts con flags de lectura/escritura
1. Para cada account escribible: se adquiere un lock exclusivo
1. Para cada account legible: se adquiere un lock compartido \(múltiples lectores están permitidos\)
1. Si se adquieren todos los locks: se programa para su ejecución
1. Si algún lock está bloqueado: se vuelve a encolar y se intenta más tarde

La implementación actual usa 6 threads: 4 para transacciones que no son votos y 2 para transacciones de voto. Cada thread mantiene una cola ordenada por priority fee \(fee por compute unit\) y hora de llegada.

Una arquitectura más nueva, el Central Scheduler, usa un único thread de scheduling con un algoritmo Prio-Graph, un grafo de dependencias que se llena de forma perezosa e identifica conflictos mediante una ventana de anticipación. Esto mejora la eficiencia del scheduling para cargas de trabajo con alta contención.

### Desempeño en la práctica

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "Metric", dataType: "object" },
      { key: "2", width: 200, title: "Value", dataType: "object" },
    ],
    data: [
      {
        "1": { title: "<p>TPS máximo teórico</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>~65 000 (transferencias simples)</p>",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        "1": { title: "<p>Benchmark en testnet</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>47 370 TPS (200 nodos, 23 regiones)</p>",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
      {
        "1": { title: "<p>Rango típico en mainnet</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>800–3600 TPS (transacciones reales de usuarios)</p>",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        "1": { title: "<p>Tiempo objetivo de bloque</p>", tooltip: "", icon: "" },
        "2": { title: "<p>400ms</p>", tooltip: "", icon: "" },
        id: 1,
      },
    ],
  }}
/>

El throughput en el mundo real depende en gran medida de la combinación de transacciones. Las transferencias simples que tocan accounts únicas se paralelizan perfectamente. Las transacciones DeFi complejas que impactan todas en el mismo liquidity pool generan contención y se serializan.

Esto en realidad es una ventaja: la contención está localizada. Un aumento de volumen en un exchange descentralizado no ralentiza las transferencias de tokens en un neobanco, porque tocan accounts distintas. Esto es fundamentalmente distinto de las chains donde todas las transacciones compiten por el mismo throughput global.

### Por qué las VMs secuenciales no pueden simplemente adoptar esto

Podrías preguntarte: ¿por qué la EVM no puede simplemente agregar ejecución paralela?

El problema fundamental es que el acceso al estado en la EVM se determina **en tiempo de ejecución**, no antes. Cuando llamas a un contrato de [Solidity](https://www.alchemy.com/overviews/solidity), no hay forma de saber qué storage slots leerá o escribirá hasta que realmente lo ejecutes. El contrato podría llamar a otro contrato, que llama a otro, cada uno accediendo a un estado impredecible.

Este modelo "ajeno a lecturas y escrituras" hace imposible la paralelización segura sin especulación. Algunas chains más nuevas implementan "ejecución paralela optimista": ejecutan de forma especulativa asumiendo que no hay conflictos, y luego detectan conflictos y vuelven a ejecutar secuencialmente cuando ocurren. Esto funciona, pero agrega complejidad y overhead.

El enfoque de Solana es distinto: los conflictos se evitan, no se resuelven. Al requerir la declaración previa, el runtime sabe exactamente qué necesita cada transacción antes de que comience la ejecución. La restricción habilita la optimización.

EIP-2930 introdujo "access lists" opcionales en Ethereum para descuentos de gas, pero no son obligatorias. Solana hace que la declaración sea obligatoria y universal; esa es la diferencia clave.

## El ecosistema de la SVM: más allá de Solana Mainnet

La SVM ya no es solo Solana. En junio de 2024, Anza presentó la SVM API, desacoplando el motor de ejecución del cliente validador de Solana. Esta modularización habilitó casos de uso completamente nuevos.

### Eclipse: SVM en Ethereum

Eclipse se lanzó en noviembre de 2024 como el primer rollup de SVM en producción sobre Ethereum:

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "Layer", dataType: "object" },
      { key: "2", width: 200, title: "Provider", dataType: "object" },
    ],
    data: [
      {
        "1": { title: "<p>Settlement</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Ethereum</p>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        "1": { title: "<p>Execution</p>", tooltip: "", icon: "" },
        "2": { title: "<p>SVM de Solana</p>", tooltip: "", icon: "" },
        id: 1,
      },
      {
        "1": { title: "<p>Data availability</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Celestia</p>", tooltip: "", icon: "" },
        id: 3,
      },
      {
        "1": { title: "<p>Fraud proofs</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>RISC Zero (acelerado con ZK)</p>",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
    ],
  }}
/>

Más de 60 apps se desplegaron en el lanzamiento, incluyendo Orca. Eclipse recaudó $65 millones para construir este puente, validando que la SVM tiene valor independiente de la capa de consenso de Solana.

### SOON network

SOON \(Solana Optimistic Network\) alcanzó su alpha mainnet a inicios de 2025 como el primer rollup de "SVM desacoplada". A diferencia de los forks simples, SOON separa la ejecución del consenso de forma limpia, implementando Merkle Patricia Tries para la gestión del estado \(distinto del AccountsDB de Solana\). Objetivo: 5K–600K TPS con integración de Firedancer.

### Sonic SVM

Sonic se lanzó en enero de 2025 como el primer Layer-2 atómico de SVM para gaming sobre Solana. Construido por [Mirror World](https://www.alchemy.com/dapps/mirror-world) Labs, incluye el HyperGrid Framework para levantar chains de SVM personalizadas por juego. La testnet procesó más de 600 millones de transacciones provenientes de más de 2 millones de wallets activas mensuales.

### MagicBlock: ephemeral rollups

MagicBlock introdujo los "ephemeral rollups", entornos de ejecución de SVM temporales y bajo demanda. Despliegas los contratos normalmente en Solana, y luego delegas accounts específicas a MagicBlock cuando necesitas latencia por debajo de 50 ms. Las escrituras ocurren en la sesión efímera y luego se confirman de vuelta en Solana.

Ideal para gaming y aplicaciones en tiempo real donde bloques de 400 ms siguen siendo demasiado lentos.

### Firedancer: el salto en desempeño

El cliente Firedancer de Jump Crypto podría ser el desarrollo de SVM más significativo. Escrito completamente en C sin componentes compartidos con Agave, usa una arquitectura basada en tiles donde cada función se ejecuta en un núcleo de CPU dedicado con networking kernel-bypass.

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "Benchmark", dataType: "object" },
      { key: "2", width: 200, title: "Result", dataType: "object" },
    ],
    data: [
      {
        "1": { title: "<p>Ingreso de paquetes</p>", tooltip: "", icon: "" },
        "2": { title: "<p>1 millón de TPS</p>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        "1": {
          title: "<p>Ejecución en SVM (programa simple)</p>",
          tooltip: "",
          icon: "",
        },
        "2": { title: "<p>500 millones de TPS</p>", tooltip: "", icon: "" },
        id: 1,
      },
    ],
  }}
/>

Estos son benchmarks sintéticos, pero sugieren un margen enorme de mejora respecto al desempeño actual de mainnet.

Cronología:

- **Septiembre de 2024**: Frankendancer \(híbrido\) en mainnet
- **Breakpoint 2024**: Firedancer completo en modo sin voto
- **2025**: lanzamiento completo en producción proyectado

## Construyendo sobre la SVM

Ya cubrimos la arquitectura; ahora pongámonos prácticos. Si quieres empezar a construir en Solana, ¿qué necesitas realmente?

### El toolchain de un vistazo

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "Tool", dataType: "object" },
      { key: "2", width: 200, title: "What It Does", dataType: "object" },
    ],
    data: [
      {
        "1": { title: "<p>Solana CLI</p>", tooltip: "", icon: "" },
        "2": {
          title:
            "<p>Toolkit central, gestión de keypairs, despliegue, interacción con el cluster</p>",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        "1": { title: "<p>Anchor</p>", tooltip: "", icon: "" },
        "2": {
          title:
            "<p>El framework dominante para construir programs: maneja boilerplate, serialización, validación de accounts y testing</p>",
          tooltip: "",
          icon: "",
        },
        id: 5,
      },
      {
        "1": { title: "<p>Rust + cargo-build-sbf</p>", tooltip: "", icon: "" },
        "2": {
          title:
            "<p>Compila tu código Rust a bytecode sBPF para su despliegue</p>",
          tooltip: "",
          icon: "",
        },
        id: 4,
      },
      {
        "1": { title: "<p>Bankrun / LiteSVM</p>", tooltip: "", icon: "" },
        "2": {
          title:
            "<p>Testing local rápido sin necesidad de levantar un validador completo</p>",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
      {
        "1": { title: "<p>solana-test-validator</p>", tooltip: "", icon: "" },
        "2": {
          title:
            "<p>Validador local completo para testing de integración con el estado de mainnet</p>",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        "1": { title: "<p>Alchemy</p>", tooltip: "", icon: "" },
        "2": {
          title:
            "<p>Ofrece nodos RPC de alto desempeño y APIs para Solana, brindando acceso confiable a los datos de la blockchain, consultas históricas mejoradas y herramientas para desarrollo, testing e interacción</p>",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
    ],
  }}
/>

Para la mayoría de los desarrolladores, el camino es: Solana CLI \+ Anchor \+ Bankrun. Esa combinación cubre el 90 % de los casos de uso.

### Empezando: la configuración de 5 minutos

<CodeSnippet language="bash" code={`# Install Solana CLI
sh -c "\$(curl -sSfL <https://release.anza.xyz/stable/install>)"

# Install anchor

cargo install --git <https://github.com/coral-xyz/anchor> anchor-cli

# Create a new project

anchor init my_project && cd my_project

# Build and test

anchor build
anchor test`} />

Eso es todo. Ahora tienes un entorno de desarrollo de Solana funcional, un programa de inicio, un test suite y la integración con un validador local listos para usar.

Desde aquí, el [Anchor Book](https://www.anchor-lang.com/docs/installation) te guía en la construcción de tu primer programa real, y el [Solana Cookbook](https://solanacookbook.com/) ofrece recetas para los patrones comunes con los que te vas a encontrar.

Dónde profundizar más:

- [Solana Developer Docs](https://solana.com/docs): documentación oficial
- [Anchor Book](https://www.anchor-lang.com/): guía completa del framework
- [Solana Cookbook](https://solanacookbook.com/): recetas y patrones prácticos
- [Alchemy Solana APIs](https://www.alchemy.com/solana): infraestructura RPC y herramientas para desarrolladores

## Conclusión: la apuesta arquitectónica

La SVM representa una visión arquitectónica coherente: aceptar restricciones por adelantado \(declaraciones explícitas de accounts, programs sin estado, construcción compleja de transacciones\) para desbloquear paralelismo, throughput y mercados de fees localizados. Estas restricciones no son incidentales: son el mecanismo que habilita el desempeño.

Si quieres explorar lo que es posible, las [APIs de Solana de Alchemy](https://www.alchemy.com/solana) te dan acceso a Solana mainnet, devnet y al ecosistema más amplio de la SVM desde una sola plataforma. Empieza a construir y compruébalo tú mismo.

## Preguntas frecuentes

### ¿Qué es la Solana Virtual Machine (SVM)?

La SVM es el motor de ejecución de Solana, un runtime basado en registros construido sobre bytecode eBPF que ejecuta transacciones en paralelo al requerir la declaración previa de todas las dependencias de estado, habilitando miles de transacciones concurrentes entre núcleos de CPU.

### ¿En qué se diferencia la SVM de la Ethereum Virtual Machine (EVM)?

A diferencia de la arquitectura secuencial y basada en stack de la EVM, la SVM usa un diseño basado en registros con ejecución paralela, separa el código del estado mediante accounts y requiere declaraciones previas de accounts para habilitar el procesamiento concurrente.

### ¿Qué es Sealevel y por qué importa?

Sealevel es el runtime de smart contracts paralelo de Solana que programa transacciones sin conflictos para que se ejecuten de forma simultánea entre núcleos de CPU, habilitando un throughput de miles de TPS al procesar en paralelo transacciones que tocan accounts distintas.

### ¿Qué lenguajes de programación puedo usar para construir sobre la SVM?

Los programs se escriben principalmente en Rust y se compilan a bytecode sBPF mediante LLVM, aunque también se admiten otros lenguajes compatibles con LLVM, como C, C++ y Zig.

### ¿Qué son las Program Derived Addresses (PDAs)?

Los PDAs son direcciones especiales que caen fuera de la curva Ed25519, sin una clave privada válida, lo que permite a los programs generar y "firmar" de forma determinista direcciones que controlan sin tener claves privadas, habilitando que los programs gestionen sus propias accounts.

### ¿Cómo funciona el modelo de accounts de la SVM?

Todo en Solana es una account, una estructura de datos que contiene lamports (balance), bytes de datos arbitrarios, un program ID como owner y metadatos. Los programs no tienen estado y solo pueden modificar las accounts que son de su propiedad, lo que habilita límites de ownership claros para la ejecución paralela.

### ¿Qué es sBPF y cómo se relaciona con eBPF?

sBPF (Solana Bytecode Format) es la variante personalizada de eBPF de Solana, modificada para uso en blockchain, con stacks más grandes (4KB frente a 512 bytes), soporte para loops limitados por compute units, y syscalls personalizadas para logging, CPIs y operaciones criptográficas.

### ¿Qué son las Cross-Program Invocations (CPIs)?

Las CPIs permiten que los programs de Solana llamen a otros programs durante la ejecución, con una profundidad máxima de llamada de 5, lo que habilita la composabilidad en todo el ecosistema mientras se mantienen presupuestos de compute compartidos y privilegios de signer en cascada.

### ¿Se puede usar la SVM fuera de Solana mainnet?

Sí, la SVM API modular habilita su uso más allá de Solana: Eclipse ejecuta la SVM como un rollup de Ethereum, SOON Network opera como un rollup de SVM desacoplada, y proyectos como Sonic y MagicBlock construyen entornos de ejecución de SVM especializados.

### ¿Cómo empiezo a construir sobre la SVM?

Instala la Solana CLI y el framework Anchor, y luego usa `anchor init` para crear un proyecto con programs de inicio, test suites e integración con un validador local; el Anchor Book y el Solana Cookbook ofrecen guías de desarrollo completas.