---
title: "O que é a Solana virtual machine (SVM) e como ela funciona?"
description: "Uma análise aprofundada da arquitetura por trás da Solana e por que ela importa para devs."
---

# O que é a Solana virtual machine (SVM) e como ela funciona?

<ImageBlock
  src="https://media.alchemy.com/1766069216-blog-solana-virtual-machine-1.png"
  alt="Uma visualização da máquina virtual"
  width={1920}
  height={900}
  priority
/>

Solana se tornou uma das blockchains mais usadas ativamente no mercado cripto, ficando consistentemente entre as cinco primeiras em endereços ativos diários e volume de transações. Só em outubro de 2025, a rede Solana processou aproximadamente [70 milhões de transações diárias e movimentou $143 bilhões](https://liquidityfinder.com/news/solanas-transaction-volume-and-revenue-surpass-all-major-layer-1-blockchains-c3df7) em volume de DEX, com throughput em picos que paralisaria a maioria das outras chains.

O que torna isso possível não é apenas um consenso rápido ou requisitos de hardware robustos, mas sim, no núcleo do desempenho da Solana está um motor de execução fundamentalmente diferente: a Solana Virtual Machine \(SVM\).

A Solana Virtual Machine é um runtime baseado em registradores, construído sobre bytecode eBPF, que executa transações em paralelo exigindo a declaração prévia de todas as dependências de estado. Diferente do modelo de transações sequencial da [Ethereum Virtual Machine](https://www.alchemy.com/overviews/what-is-the-ethereum-virtual-machine-evm), a SVM foi projetada desde o início em torno da execução paralela, processando milhares de transações simultaneamente em vários núcleos de CPU, em vez de uma por vez.

Essa escolha arquitetural afeta tudo: como os programas armazenam estado, como as transações são construídas, como as taxas são calculadas e como os desenvolvedores pensam ao construir aplicações on-chain.

Este guia detalha a SVM a partir dos princípios básicos. Vamos começar pelos componentes centrais, explicar como funcionam individualmente e depois mostrar como se combinam para viabilizar o desempenho da Solana. Ao final, você entenderá não só _o que_ a SVM faz, mas _por que_ ela é construída dessa forma.

## O que é uma máquina virtual?

Antes de entrar na SVM especificamente, vamos estabelecer o que é de fato uma máquina virtual e por que as blockchains precisam delas.

Uma máquina virtual \(VM\) é um computador baseado em software que roda dentro de outro computador. Ela fornece um ambiente controlado onde o código pode ser executado sem acessar diretamente os recursos do sistema hospedeiro. VMs estão por toda parte: a Java Virtual Machine executa bytecode Java, seu navegador roda JavaScript em uma VM, e servidores em nuvem frequentemente rodam dentro de VMs.

As blockchains precisam de VMs por uma razão específica: execução determinística de código não confiável. Quando você implanta um smart contract, milhares de validadores ao redor do mundo precisam executar esse código e chegar _exatamente_ ao mesmo resultado. A VM fornece:

- **Sandboxing**: código não confiável não pode acessar o sistema hospedeiro ou a memória de outros programas
- **Determinismo**: as mesmas entradas sempre produzem as mesmas saídas, independentemente do hardware
- **Medição**: a execução pode ser medida e limitada \(gas/compute units\) para evitar abusos
- **Portabilidade**: o código roda de forma idêntica em diferentes máquinas e sistemas operacionais

A **Ethereum Virtual Machine \(EVM\)** foi a primeira VM de blockchain amplamente adotada. Ela usa uma arquitetura baseada em pilha, executa transações sequencialmente e armazena código e estado juntos nos contratos. Funciona, mas suas escolhas de design criam limitações fundamentais de throughput.

A **Solana Virtual Machine \(SVM\)** adota uma abordagem diferente. Ela usa uma arquitetura baseada em registradores \(mais parecida com CPUs físicas\), separa código de estado e, o mais importante, executa transações em paralelo.

## O que é a Solana virtual machine \(svm\)?

Em sua essência, a SVM é o motor de execução da Solana, o sistema responsável por rodar a lógica dos programas, processar transações e atualizar o estado. Se você vem do Ethereum, pense nela como a resposta da Solana à EVM, mas arquiteturalmente distinta em pontos que importam.

Para entender a SVM, primeiro você precisa entender sobre o que ela opera:

- **Accounts:** a estrutura de dados universal da Solana. Tudo é uma account: carteiras de usuário, saldos de tokens, estado de programas, até mesmo os próprios programas. As accounts armazenam dados e têm um owner \(o programa autorizado a modificá-las\). Diferente dos contratos EVM, que agrupam código e armazenamento juntos, a Solana os separa completamente, todo o estado vive em accounts.
- **Programs:** este é o termo da Solana para smart contracts. Programs são _stateless_: contêm apenas código executável, compilado em um formato de bytecode chamado sBPF. A maioria dos programs da Solana é escrita em Rust \(embora C e C\+\+ também sejam suportados\). Quando um program é executado, ele lê e escreve nas accounts passadas para ele, mas não armazena nada internamente.
- **Transactions:** um pacote de uma ou mais instructions, cada uma direcionada a um program e especificando quais accounts precisa ler ou escrever. Essa declaração prévia das dependências de estado é a chave para tudo. É o que torna a execução paralela possível.

Com essa base, aqui está a forma mais simples de entender a SVM: é um ambiente de runtime em sandbox que recebe bytecode compilado de um program, o executa contra um conjunto de accounts e determina as mudanças de estado resultantes. Toda transação na Solana passa pela SVM.

O que diferencia a SVM da EVM não são só detalhes de implementação — é o design fundamental. A SVM foi construída em torno da execução paralela desde o primeiro dia. As transações declaram suas dependências de estado antecipadamente, permitindo que o runtime identifique trabalho sem conflitos e o processe simultaneamente em vários núcleos de CPU. A EVM processa transações sequencialmente; a SVM processa milhares simultaneamente.

_Uma observação sobre terminologia: o termo "SVM" carrega significados diferentes dependendo do contexto. A definição estrita se refere especificamente ao interpretador de bytecode e ao compilador JIT que executa o código do program \(abordaremos o sBPF, o formato de bytecode, mais adiante\). A definição mais ampla, usada oficialmente por times como a Anza \(o time principal de validadores da Solana\), abrange todo o pipeline de execução de transações: scheduling, orçamento de compute, carregamento de programs, execução e atualizações de estado. Quando desenvolvedores dizem "a SVM", geralmente se referem a esse sistema mais amplo. Este guia cobre ambos, e deixaremos claro a qual estamos nos referindo ao longo do texto._

## Entendendo a arquitetura da SVM

Agora que sabemos _o que_ é a SVM e como ela difere de outras VMs de blockchain, vamos entender _como_ ela realmente funciona. Esta seção percorre toda a arquitetura, desde o momento em que uma transação chega até a mudança de estado final.

Vamos cobrir quatro partes interconectadas:

1. Como as transações fluem pelo sistema \(o pipeline\)
1. O motor de execução que roda seu código \(eBPF, compilação, a VM em si\)
1. O modelo de dados sobre o qual os programs operam \(accounts, PDAs, rent, CPIs\)
1. Execução paralela e como o Sealevel a torna possível

Cada parte se apoia na anterior. Ao final, você entenderá não só os componentes individuais, mas como eles se encaixam para viabilizar as características de desempenho da Solana.

## Parte 1: como as transações fluem pela SVM

O primeiro passo para entender a SVM é traçar a jornada de uma transação, desde o momento em que você clica em "enviar" até a confirmação do bloco. Esse pipeline explica _por que_ os programs da Solana são estruturados da forma como são, _por que_ você precisa declarar accounts antecipadamente, e _onde_ o paralelismo de fato acontece.

Quando você envia uma transação para a Solana, ela não simplesmente entra em uma fila e espera sua vez. Ela passa por uma série de subsistemas especializados, cada um resolvendo um 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`}
/>

Vamos percorrer cada etapa:

### O banking stage: onde o paralelismo acontece

Este é o controlador de tráfego. Quando transações verificadas chegam, o Banking Stage analisa cada uma: quais accounts ela precisa ler? Quais precisa escrever?

Com essa informação, ele determina quais transações podem rodar com segurança ao mesmo tempo:

- Transações que tocam accounts completamente diferentes → rodam em paralelo
- Transações que apenas leem a mesma account → rodam em paralelo \(leituras não conflitam\)
- Transações que escrevem na mesma account → precisam rodar sequencialmente

O scheduler usa locking em nível de account para impor essas regras. Threads worker processam lotes de transações sem conflito simultaneamente. Este é o coração do modelo de execução paralela da Solana, chamado Sealevel \(vamos aprofundar no Sealevel na Parte 4\).

### O bank: estado em um momento no tempo

Enquanto o Banking Stage cuida do _scheduling_, o Bank cuida do _estado_. Pense nele como um snapshot de todo o estado da Solana em um slot específico \(a unidade de tempo da Solana, aproximadamente 400ms\).

O Bank gerencia dados de accounts, coordena a execução e rastreia qual versão do estado é a canônica. Cada Bank passa por três estágios de 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>Currently processing transactions for this slot</p>",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        "1": { title: "<p>Frozen</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Slot complete: no more changes allowed</p>",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        "1": { title: "<p>Rooted</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Finalized and committed to persistent storage</p>",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
    ],
  }}
/>

Quando o Banking Stage executa transações, ele opera contra um Bank específico, uma versão específica do mundo. É assim que a Solana mantém consistência enquanto processa milhares de transações em paralelo.

### BPF loaders: iniciando a execução dos programs

Quando uma transação invoca um program, algo precisa de fato _executar_ o código desse program. Esse é o trabalho do BPF Loader.

O BPF Loader cuida de todo o ciclo de vida do program:

- **Deployment**: envio de novo bytecode de program para a rede
- **Compilação JIT**: conversão de bytecode em código de máquina nativo para execução mais rápida
- **Upgrades**: envio de novas versões de programs existentes
- **Execução**: provisionamento de instâncias isoladas de VM quando programs são invocados

Cada invocação de program recebe sua própria instância de VM sBPF em sandbox, com:

- Regiões de memória dedicadas
- Um orçamento de compute \(similar aos limites de gas\)
- Isolamento estrito de outros programs

Se o program exceder seu orçamento de compute? A execução para. Tenta acessar memória que não deveria? A execução para. O isolamento é rígido por design. É assim que a Solana executa com segurança código não confiável de milhares de desenvolvedores.

### Um fluxo típico de transação

Aqui está o fluxo completo para uma transação típica:

1. Você envia uma transação especificando qual program chamar e quais accounts ele precisa
1. O Banking Stage a recebe, verifica conflitos com outras transações pendentes e a agenda adequadamente
1. O Bank fornece o snapshot de estado atual para esse slot
1. O BPF Loader provisiona uma instância de VM sBPF para o program alvo
1. O program executa, lendo e escrevendo nas accounts especificadas
1. As mudanças de estado são commitadas no Bank
1. Eventualmente, o Bank congela (freeze) e é enraizado (root), tornando as mudanças permanentes

Cada componente resolve um problema específico: o Banking Stage viabiliza o paralelismo, o Bank fornece estado consistente, e o BPF Loader garante execução segura. Juntos, formam a "SVM" em seu sentido mais amplo.

Quer se aprofundar mais em transações? Confira estes recursos:

- [Transaction lifecycle](https://solana.com/docs/core/transactions): como as transações são estruturadas e processadas
- [Fees on Solana](https://solana.com/docs/core/fees): compute units, priority fees e orçamento
- [Clusters & endpoints](https://solana.com/docs/core/clusters): entendendo a arquitetura de rede da Solana

## Parte 2: o motor de execução

O BPF Loader provisiona instâncias de VM para rodar o código dos programs. Mas o que de fato acontece dentro dessa instância de VM?

A maioria das VMs de blockchain foi projetada do zero. A Solana seguiu uma direção diferente: adotou o [eBPF](https://ebpf.io/) \(extended Berkeley Packet Filter\), uma tecnologia originalmente construída para o kernel Linux.

O BPF surgiu em 1992 no Lawrence Berkeley Laboratory para filtragem eficiente de pacotes de rede. Com o tempo, evoluiu para o eBPF, uma VM de propósito geral e em sandbox que roda com segurança dentro do kernel Linux. Se você já usou ferramentas de observabilidade como o [bpftrace](https://github.com/bpftrace/bpftrace) ou trabalhou com redes baseadas em eBPF, já encontrou essa tecnologia. É uma infraestrutura testada em batalha, sustentando sistemas críticos em grande escala.

O fundador da Solana, Anatoly Yakovenko, com sua experiência em sistemas operacionais \(mais de 13 anos na Qualcomm\), chegou a um insight chave: por que construir uma nova VM do zero quando uma já existente resolve os problemas difíceis?

O eBPF oferecia exatamente o que a Solana precisava:

- **Segurança sem overhead:** programs eBPF rodam em um ambiente restrito que não pode travar o hospedeiro nem corromper memória. O bytecode é verificado estaticamente antes de ser carregado — sem acesso inválido à memória, sem jumps fora dos limites, sem operações não autorizadas. Essa segurança vem sem overhead de runtime, diferente de runtimes gerenciados que precisam de garbage collection.
- **Desempenho quase nativo:** a arquitetura baseada em registradores \(diferente do design baseado em pilha da EVM\) permite compilação JIT para código de máquina nativo. Os programs rodam em velocidade quase nativa.
- **Toolchain madura:** o LLVM já inclui um backend eBPF. Rust, C, C\+\+ e outras linguagens suportadas pelo LLVM compilam diretamente para bytecode eBPF. Você escreve em uma linguagem que conhece; a toolchain cuida do resto.

### sBPF: a variante customizada da Solana

A Solana não usa eBPF padrão. Não poderia, já que o eBPF padrão foi projetado para operações em kernel-space, com restrições rígidas que não se aplicam à execução de blockchain. Então a Solana o fez um fork.

O resultado é o sBPF \(Solana Bytecode Format\), uma variante modificada, adaptada para a execução 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>Kernel-space</p>", tooltip: "", icon: "" },
        "3": { title: "<p>User-space</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 per frame</p>", tooltip: "", icon: "" },
        id: 2,
      },
      {
        "1": { title: "<p>Loops</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Restricted (must provably terminate)</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title: "<p>Allowed (bounded by 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>Yes (logging, CPI, crypto)</p>",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
    ],
  }}
/>

As restrições que tornam o eBPF seguro em kernel-space — pilha minúscula, sem loops — inviabilizariam o desenvolvimento de smart contracts na Solana. O sBPF relaxa essas restrições mantendo a segurança por meio de orçamentos de compute units: você pode fazer loops, mas eventualmente vai ficar sem compute.

As syscalls customizadas também importam. Programs precisam registrar mensagens de log, invocar outros programs \(Cross-Program Invocation\) e realizar operações criptográficas. O eBPF padrão não tem noção disso, e o sBPF os adiciona como primitivas de primeira classe.

Se você estiver compilando programs da Solana, verá o target triple `sbf-solana-solana` na sua toolchain. Esse é o identificador dessa variante específica da Solana.

### De Rust a bytecode: o pipeline de compilação

Quando você executa `cargo build-sbf`, seu código Rust passa por um pipeline de compilação em múltiplos estágios:

**1. Frontend do Rust:** o compilador analisa seu código, expande macros, faz verificação de tipos e roda o borrow checker para validar a segurança de memória. Quando o código sai desse estágio, o Rust já eliminou classes inteiras de bugs \(use-after-free, data races, ponteiros nulos\) que afetam outras linguagens de sistemas. Essa é uma das vantagens pouco valorizadas da Solana: segurança de memória garantida em tempo de compilação, antes mesmo de o program tocar a chain.

**2. Otimização com LLVM:** o código se transforma em LLVM IR, uma representação agnóstica de plataforma onde ocorrem otimizações sérias: constant folding, inlining de funções, eliminação de código morto, loop unrolling. Essas otimizações importam porque compute units custam dinheiro. Bytecode menor e mais enxuto significa transações mais baratas.

**3. Backend sBPF:** o fork customizado da Solana do backend BPF do LLVM converte o IR otimizado em bytecode sBPF, empacotado como um arquivo ELF \(`.so`\). É isso que você faz deploy na rede — e o que o BPF Loader provisiona em uma instância de VM quando seu program é invocado.

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

### Dentro da VM sBPF

Agora estamos no nível mais baixo: a máquina virtual real que executa seu bytecode.

O conjunto de instruções sBPF usa instruções de 64 bits \(8 bytes cada\), com um design tipo RISC e aproximadamente 100 opcodes. Os programs têm acesso a 11 registradores 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>Return values</p>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        "1": { title: "<p>R1-R5</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Function arguments</p>", tooltip: "", icon: "" },
        id: 2,
      },
      {
        "1": { title: "<p>R6-R9</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Callee-saved (preserved across calls)</p>",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
      {
        "1": { title: "<p>R10</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Frame pointer (read-only)</p>",
          tooltip: "",
          icon: "",
        },
        id: 4,
      },
    ],
  }}
/>

#### Layout de memória

A VM organiza a memória em regiões fixas, cada uma começando em um endereço específico:

<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>Program code</p>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        "1": { title: "<p>0x100000000</p>", tooltip: "", icon: "" },
        "2": { title: "<p>.rodata</p>", tooltip: "", icon: "" },
        "3": {
          title: "<p>Constants and read-only data</p>",
          tooltip: "",
          icon: "",
        },
        id: 4,
      },
      {
        "1": { title: "<p>0x200000000</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Stack</p>", tooltip: "", icon: "" },
        "3": { title: "<p>4KB per 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 default allocation</p>", tooltip: "", icon: "" },
        id: 2,
      },
      {
        "1": { title: "<p>0x400000000</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Input</p>", tooltip: "", icon: "" },
        "3": {
          title: "<p>Accounts and instruction data</p>",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
    ],
  }}
/>

Esse layout rígido permite que a VM imponha limites estritos, de modo que seu program não consiga acessar acidentalmente \(ou maliciosamente\) memória que não deveria.

#### Compilação JIT e segurança

A VM sBPF suporta dois modos de execução:

- **Interpretador:** percorre cada instrução uma por uma. Rápido para iniciar, mais lento para executar. Útil para testes locais e debugging.
- **Compilação JIT:** transforma bytecode sBPF em código de máquina nativo x86_64 antes da execução. Inicialização mais lenta, runtime muito mais rápido. É isso que os validadores usam em produção.

O validador Agave armazena programs compilados via JIT em cache, em `ProgramCacheForTxBatch`, para reutilização. Programs usados com frequência, como o Token Program, não são recompilados a cada transação. Já estão no cache.

A aplicação de segurança acontece em dois níveis:

1. Verificação estática (antes da execução):

- Rejeita instruções malformadas ou inválidas
- Valida todos os padrões de acesso à memória
- Garante que os alvos de jump caiam em limites válidos de instrução
- Detecta caminhos de código inalcançáveis

Se seu program falhar na verificação, ele não será implantado. Ponto final.

1. Medição em tempo de execução (durante a execução):

- Cada instrução consome uma compute unit
- A VM verifica o orçamento após cada passo
- Exceder o orçamento interrompe a execução imediatamente

Essa abordagem em duas camadas previne loops infinitos, ataques de esgotamento de recursos e programs descontrolados. Mesmo que um bytecode malicioso de alguma forma passasse pela verificação estática, ele não pode rodar para sempre. Vai atingir seu limite de compute e parar.

Se quiser saber mais sobre o motor de execução, confira estes recursos:

- [Programs overview](https://solana.com/docs/core/programs): como os programs da Solana funcionam
- [Developing programs in Rust](https://solana.com/docs/programs/rust): guia oficial de desenvolvimento em Rust

## Parte 3: o modelo de dados

Já traçamos como as transações fluem pela SVM e como o bytecode é executado dentro da VM sBPF, agora vamos dar uma olhada sobre o que os programs operam.

Na maioria dos ambientes de programação, você tem variáveis, bancos de dados, sistemas de arquivos, várias formas de armazenar e recuperar dados. As blockchains precisam de algo similar: uma forma de persistir estado entre transações. A EVM resolveu isso dando a cada contrato seu próprio armazenamento, um key-value store embutido no próprio contrato.

A Solana adota uma abordagem radicalmente diferente, e entender essa diferença é essencial, porque ela molda tudo sobre como você constrói na plataforma.

### Tudo na Solana é uma account

Pense na Solana como um enorme banco de dados key-value:

- **Key**: um endereço de 32 bytes \(tipicamente uma chave pública ou endereço derivado\)
- **Value**: uma account \(estrutura de dados contendo bytes, um saldo e metadados\)

Essa uniformidade pode parecer estranha à primeira vista, mas é o que viabiliza as características de desempenho da Solana. Cada pedaço de estado tem um endereço explícito, um owner explícito e regras explícitas sobre quem pode modificá-lo. O runtime não precisa rastrear chamadas de contratos aninhadas para descobrir qual estado pode mudar, ele já sabe antecipadamente pela lista de accounts da transação.

Vamos ver o que de fato está dentro de uma account, cada uma contém os mesmos 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 in Solana's smallest unit (1 SOL = 1 billion lamports)</p>",
          tooltip: "",
          icon: "",
        },
        id: 5,
      },
      {
        "1": { title: "<p>data</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Arbitrary byte array storing the account's state</p>",
          tooltip: "",
          icon: "",
        },
        id: 4,
      },
      {
        "1": { title: "<p>owner</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>The program ID allowed to modify this account's data</p>",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
      {
        "1": { title: "<p>executable</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Boolean flag—true for program accounts</p>",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        "1": { title: "<p>rent_epoch</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Legacy field for rent tracking (mostly deprecated)</p>",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
    ],
  }}
/>

O campo `owner` é fundamental. Só o program owner pode modificar o campo `data` de uma account ou debitar seus lamports. Qualquer um pode ler qualquer account \(todo estado é público na Solana\), e qualquer um pode creditar lamports em qualquer account. Mas as escritas são controladas pela ownership.

Esse modelo de ownership é o que torna a execução paralela possível. O runtime sabe exatamente qual program pode modificar quais accounts, então pode executar com segurança transações sem conflitos simultaneamente.

### Programs: stateless por design

Um program da Solana é uma account executável contendo bytecode sBPF compilado. Mas aqui está o insight chave: programs não podem armazenar estado internamente. São funções puras que processam instructions e modificam as accounts passadas a eles.

Todo program da Solana compartilha a mesma assinatura de entry point:

<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`}
/>

Quando seu program é executado, ele recebe:

1. Seu próprio endereço \(para poder verificar PDAs que deriva\)
1. Um array de accounts que está autorizado a ler/escrever
1. Dados de instruction contendo os parâmetros que o chamador passou

O program executa sua lógica, modifica as accounts que está autorizado a modificar e retorna sucesso ou um erro. Não armazena nada internamente entre chamadas.

Por que stateless? Porque isso viabiliza limites de ownership limpos. Se os programs armazenassem seu próprio estado, você precisaria de regras complexas sobre quais programs poderiam acessar qual armazenamento. Ao forçar todo o estado em accounts com owners explícitos, o modelo permanece simples e a paralelização permanece possível.

_Nota de design: diferente dos contratos EVM, que são imutáveis por padrão, os programs da Solana são upgradeable por padrão. A upgrade authority pode enviar novo bytecode a qualquer momento. Os desenvolvedores podem revogar a upgrade authority para tornar os programs imutáveis, mas essa é uma escolha explícita. Isso reflete a abordagem prática da Solana — a maioria dos programs precisa de correções de bugs e atualizações de funcionalidades._

### Program derived addresses \(PDAs\)

Se os programs são stateless e todos os dados vivem em accounts, como os programs criam e gerenciam suas próprias accounts? Eles não podem ter chaves privadas. É aí que entram as Program Derived Addresses \(PDAs\).

PDAs são endereços especiais que caem fora da curva elíptica Ed25519, o que significa que não existe chave privada válida para eles. Essa propriedade criptográfica permite que os programs "assinem" por esses endereços sem ter chaves privadas, o runtime verifica a derivação internamente.

A derivação de PDA funciona fazendo hash de seeds, mais o program ID, mais um "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
);`}
/>

O algoritmo testa valores de bump a partir de 255 para baixo, até encontrar um que produza um endereço fora da curva. Esse primeiro bump válido é o "bump canônico".

#### Por que as PDAs importam

- **Endereçamento determinístico**: dadas as mesmas seeds, você sempre obtém o mesmo endereço. Não é necessário armazenar endereços separadamente.
- **Accounts controladas por program**: programs podem criar accounts em PDAs que derivam, e só eles podem assinar por essas PDAs.
- **Padrões key-value**: seeds podem codificar relações \(user \+ token type → account de saldo\), viabilizando estruturas de dados parecidas com mapeamentos.

<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: pagando pelo estado

O estado da blockchain não é gratuito. Cada account ocupa espaço nos discos dos validadores, e esse espaço tem custos reais. Chains diferentes lidam com isso de formas diferentes. O Ethereum cobra gas por operações de armazenamento, mas o estado persiste para sempre depois de escrito, contribuindo para o crescimento contínuo do estado \(state bloat\).

A Solana adota uma abordagem diferente. Existe algo chamado "rent", em que a rede cobra aproximadamente 3.480 lamports por byte por ano para manter dados on-chain. Na prática, todas as accounts na mainnet precisam ser "rent-exempt", mantendo pelo menos dois anos de rent antecipadamente:

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

Para uma token account típica \(165 bytes\), isso resulta em aproximadamente 0,002 SOL.

Mas aqui está a diferença chave em relação a outras chains: fechar uma account devolve o depósito integral de rent. Isso cria um incentivo econômico para limpar estado não usado, algo que não existe em modelos onde o armazenamento persiste para sempre.

<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\)

Os programs não existem isoladamente. Um protocolo DeFi pode chamar o Token Program para transferir tokens, que por sua vez pode chamar o Associated Token Account Program. Essas Cross-Program Invocations são como o ecossistema da Solana se compõe.

Duas funções viabilizam 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
)?;`} />

Quando você chama `invoke\_signed` com seeds de PDA, o runtime verifica se a derivação corresponde ao endereço esperado e concede autoridade de assinatura para essa chamada. É assim que os programs conseguem controlar assets sem ter chaves privadas.

Restrições importantes:

- Profundidade máxima de chamada de 5 \(4 CPIs aninhadas a partir da transação inicial\)
- Privilégios de signer se propagam pela cadeia de chamadas
- O orçamento de compute é compartilhado entre todas as CPIs de uma transação

Para saber mais sobre accounts, confira o seguinte:

- [Accounts Overview](https://solana.com/docs/core/accounts): guia completo sobre accounts da Solana
- [PDAs](https://solana.com/docs/core/pda): Program Derived Addresses explicadas
- [CPIs](https://solana.com/docs/core/cpi): guia de Cross-Program Invocations

## Parte 4: execução paralela \(sealevel\)

Já cobrimos todas as peças fundamentais: como as transações fluem pelo pipeline, como a VM sBPF executa bytecode e como o modelo de accounts armazena estado com ownership explícita.

Agora podemos finalmente responder à pergunta que vínhamos construindo: como a Solana de fato alcança execução paralela?

Já demos indícios disso ao longo do texto: o Banking Stage agendando transações sem conflito, accounts declarando owners antecipadamente, transações especificando quais accounts vão tocar. Essas não são funcionalidades separadas. São todas peças de um único sistema chamado Sealevel.

Sealevel é o runtime de smart contracts paralelo da Solana, e é a inovação central que viabiliza o throughput da SVM. Tudo o que cobrimos, o modelo de accounts, as regras de ownership, as declarações antecipadas de accounts, existe para tornar o Sealevel possível.

O insight fundamental é enganosamente simples:

> Se as transações declaram quais accounts leem e escrevem antes de a execução começar, o runtime pode identificar transações que não se sobrepõem e executá-las simultaneamente.

É isso. Esse é o truque inteiro. Mas fazer isso funcionar na prática exigiu projetar cada outra parte do sistema em torno dessa restrição.

### As regras da execução paralela

O scheduling do Sealevel segue regras diretas:

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "Scenario", dataType: "object" },
      { key: "2", width: 200, title: "Execution", dataType: "object" },
    ],
    data: [
      {
        "1": {
          title:
            "<p>Transactions touching <strong>different accounts</strong></p>",
          tooltip: "",
          icon: "",
        },
        "2": { title: "<p>Parallel</p>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        "1": {
          title:
            "<p>Transactions <strong>only reading</strong> the same accounts</p>",
          tooltip: "",
          icon: "",
        },
        "2": { title: "<p>Parallel</p>", tooltip: "", icon: "" },
        id: 2,
      },
      {
        "1": {
          title:
            "<p>Transactions <strong>writing</strong> to the same accounts</p>",
          tooltip: "",
          icon: "",
        },
        "2": { title: "<p>Sequential</p>", tooltip: "", icon: "" },
        id: 1,
      },
    ],
  }}
/>

É isso. Leituras não conflitam com leituras. Escritas conflitam com tudo.

<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 isso que você precisa declarar todas as accounts antecipadamente nas transações da Solana. Não é burocracia: é a informação que o runtime precisa para paralelizar sua transação.

### O algoritmo de scheduling

O Banking Stage implementa o Sealevel por meio de locking em nível de account:

1. A transação chega especificando accounts com flags de leitura/escrita
1. Para cada account gravável: adquire lock exclusivo
1. Para cada account legível: adquire lock compartilhado \(múltiplos leitores são permitidos\)
1. Se todos os locks forem adquiridos: agenda para execução
1. Se algum lock for bloqueado: recoloca na fila e tenta depois

A implementação atual usa 6 threads: 4 para transações que não são vote e 2 para transações de vote. Cada thread mantém uma fila ordenada por priority fee \(taxa por compute unit\) e horário de chegada.

Uma arquitetura mais nova, o Central Scheduler, usa uma única thread de scheduling com um algoritmo Prio-Graph, um grafo de dependências populado de forma preguiçosa (lazy) que identifica conflitos por meio de uma janela de antecipação (look-ahead). Isso melhora a eficiência de scheduling para workloads de alta contenção.

### Desempenho na prática

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "Metric", dataType: "object" },
      { key: "2", width: 200, title: "Value", dataType: "object" },
    ],
    data: [
      {
        "1": { title: "<p>Theoretical max TPS</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>~65,000 (simple transfers)</p>",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        "1": { title: "<p>Testnet benchmark</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>47,370 TPS (200 nodes, 23 regions)</p>",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
      {
        "1": { title: "<p>Mainnet typical range</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>800–3,600 TPS (real user transactions)</p>",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        "1": { title: "<p>Block time target</p>", tooltip: "", icon: "" },
        "2": { title: "<p>400ms</p>", tooltip: "", icon: "" },
        id: 1,
      },
    ],
  }}
/>

O throughput no mundo real depende muito da composição das transações. Transferências simples que tocam accounts únicas paralelizam perfeitamente. Transações complexas de DeFi que atingem todas o mesmo liquidity pool geram contenção e são serializadas.

Isso é, na verdade, uma vantagem: a contenção é localizada. Um pico de volume em uma exchange descentralizada não deixa mais lentas as transferências de tokens em um neobank, porque elas tocam accounts diferentes. Isso é fundamentalmente diferente de chains onde todas as transações competem pelo mesmo throughput global.

### Por que VMs sequenciais não conseguem simplesmente adotar isso

Você pode se perguntar: por que a EVM simplesmente não pode adicionar execução paralela?

O problema fundamental é que o acesso ao estado na EVM é determinado **em tempo de execução**, não antes. Quando você chama um contrato [Solidity](https://www.alchemy.com/overviews/solidity), não há como saber quais storage slots ele vai ler ou escrever até você realmente executá-lo. O contrato pode chamar outro contrato, que chama outro, cada um acessando estado imprevisível.

Esse modelo "read-write oblivious" torna a paralelização segura impossível sem especulação. Algumas chains mais novas implementam "execução paralela otimista", executando especulativamente assumindo que não há conflitos, e depois detectando conflitos e reexecutando sequencialmente quando eles ocorrem. Isso funciona, mas adiciona complexidade e overhead.

A abordagem da Solana é diferente: os conflitos são evitados, não resolvidos. Ao exigir declaração antecipada, o runtime sabe exatamente do que cada transação precisa antes de a execução começar. A restrição viabiliza a otimização.

O EIP-2930 introduziu "access lists" opcionais no Ethereum para descontos de gas, mas elas não são obrigatórias. A Solana torna a declaração obrigatória e universal, essa é a diferença chave.

## O ecossistema da SVM: além da Solana Mainnet

A SVM não é mais só a Solana. Em junho de 2024, a Anza introduziu a SVM API, desacoplando o motor de execução do cliente validador da Solana. Essa modularização viabilizou casos de uso totalmente novos.

### Eclipse: SVM no Ethereum

A Eclipse foi lançada em novembro de 2024 como o primeiro rollup SVM em produção no 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>Solana's SVM</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 (ZK-accelerated)</p>",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
    ],
  }}
/>

Mais de 60 aplicações foram implantadas no lançamento, incluindo a Orca. A Eclipse levantou $65 milhões para construir essa ponte, validando que a SVM tem valor independente da camada de consenso da Solana.

### SOON network

A SOON \(Solana Optimistic Network\) alcançou a alpha mainnet no início de 2025 como o primeiro rollup "SVM desacoplada". Diferente de forks simples, a SOON separa execução de consenso de forma limpa, implementando Merkle Patricia Tries para gerenciamento de estado \(diferente do AccountsDB da Solana\). Meta: 5K–600K TPS com integração ao Firedancer.

### Sonic SVM

A Sonic foi lançada em janeiro de 2025 como o primeiro Layer-2 SVM atômico para jogos na Solana. Construída pela [Mirror World](https://www.alchemy.com/dapps/mirror-world) Labs, inclui o HyperGrid Framework para criar chains SVM customizadas por jogo. A testnet processou mais de 600 milhões de transações vindas de mais de 2 milhões de carteiras ativas mensais.

### MagicBlock: ephemeral rollups

A MagicBlock introduziu "ephemeral rollups", ambientes de execução SVM temporários e sob demanda. Você implanta contratos normalmente na Solana e depois delega accounts específicas à MagicBlock quando precisa de latência abaixo de 50ms. As escritas ocorrem na sessão efêmera e depois são commitadas de volta na Solana.

Perfeito para jogos e aplicações em tempo real onde blocos de 400ms ainda são muito lentos.

### Firedancer: o avanço de desempenho

O cliente Firedancer, da Jump Crypto, pode ser o desenvolvimento mais significativo da SVM. Escrito inteiramente em C, sem nenhum componente compartilhado com a Agave, ele usa uma arquitetura baseada em tiles, onde cada função roda em um núcleo de CPU dedicado, com networking que contorna o kernel (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>Packet ingress</p>", tooltip: "", icon: "" },
        "2": { title: "<p>1 million TPS</p>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        "1": {
          title: "<p>SVM execution (simple program)</p>",
          tooltip: "",
          icon: "",
        },
        "2": { title: "<p>500 million TPS</p>", tooltip: "", icon: "" },
        id: 1,
      },
    ],
  }}
/>

Esses são benchmarks sintéticos, mas sugerem uma margem enorme além do desempenho atual da mainnet.

Linha do tempo:

- **Setembro de 2024**: Frankendancer \(híbrido\) na mainnet
- **Breakpoint 2024**: Firedancer completo em modo non-voting
- **2025**: lançamento em produção completa projetado

## Construindo sobre a SVM

Já cobrimos a arquitetura, agora vamos ao prático. Se você quer começar a construir na Solana, o que de fato precisa?

### A toolchain em resumo

<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>Core toolkit, keypair management, deployment, cluster interaction</p>",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        "1": { title: "<p>Anchor</p>", tooltip: "", icon: "" },
        "2": {
          title:
            "<p>The dominant framework for building programs—handles boilerplate, serialization, account validation, and testing</p>",
          tooltip: "",
          icon: "",
        },
        id: 5,
      },
      {
        "1": { title: "<p>Rust + cargo-build-sbf</p>", tooltip: "", icon: "" },
        "2": {
          title:
            "<p>Compiles your Rust code to sBPF bytecode for deployment</p>",
          tooltip: "",
          icon: "",
        },
        id: 4,
      },
      {
        "1": { title: "<p>Bankrun / LiteSVM</p>", tooltip: "", icon: "" },
        "2": {
          title:
            "<p>Fast local testing without spinning up a full validator</p>",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
      {
        "1": { title: "<p>solana-test-validator</p>", tooltip: "", icon: "" },
        "2": {
          title:
            "<p>Full local validator for integration testing with mainnet state</p>",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        "1": { title: "<p>Alchemy</p>", tooltip: "", icon: "" },
        "2": {
          title:
            "<p>Provides high-performance RPC nodes and APIs for Solana, offering reliable access to blockchain data, enhanced historical queries, and tools for development, testing, and interaction</p>",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
    ],
  }}
/>

Para a maioria dos desenvolvedores, o caminho é: Solana CLI \+ Anchor \+ Bankrun. Essa combinação cobre 90% dos casos de uso.

### Começando: a configuração 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`} />

É isso. Agora você tem um ambiente de desenvolvimento Solana funcionando, um program inicial, um test suite e integração com validador local prontos para uso.

A partir daqui, o [Anchor Book](https://www.anchor-lang.com/docs/installation) guia você na construção do seu primeiro program de verdade, e o [Solana Cookbook](https://solanacookbook.com/) fornece receitas para padrões comuns que você vai encontrar.

Para ir mais fundo:

- [Solana Developer Docs](https://solana.com/docs): documentação oficial
- [Anchor Book](https://www.anchor-lang.com/): guia completo do framework
- [Solana Cookbook](https://solanacookbook.com/): receitas e padrões práticos
- [Alchemy Solana APIs](https://www.alchemy.com/solana): infraestrutura de RPC e ferramentas para desenvolvedores

## Conclusão: a aposta arquitetural

A SVM representa uma visão arquitetural coerente: aceitar restrições antecipadas \(declarações explícitas de accounts, programs stateless, construção complexa de transações\) para viabilizar paralelismo, throughput e mercados de taxas localizados. Essas restrições não são incidentais — são o mecanismo que viabiliza o desempenho.

Se você quiser explorar o que é possível, as [Alchemy's Solana APIs](https://www.alchemy.com/solana) dão acesso à Solana mainnet, devnet e ao ecossistema SVM mais amplo a partir de uma única plataforma. Comece a construir e veja por si mesmo.

## Perguntas frequentes

### O que é a Solana Virtual Machine (SVM)?

A SVM é o motor de execução da Solana, um runtime baseado em registradores construído sobre bytecode eBPF, que executa transações em paralelo exigindo a declaração antecipada de todas as dependências de estado, viabilizando milhares de transações simultâneas em vários núcleos de CPU.

### Como a SVM difere da Ethereum Virtual Machine (EVM)?

Diferente da arquitetura sequencial baseada em pilha da EVM, a SVM usa um design baseado em registradores com execução paralela, separa código de estado por meio de accounts e exige declarações antecipadas de accounts para viabilizar processamento concorrente.

### O que é o Sealevel e por que ele importa?

O Sealevel é o runtime de smart contracts paralelo da Solana, que agenda transações sem conflito para serem executadas simultaneamente em vários núcleos de CPU, viabilizando um throughput de milhares de TPS ao processar em paralelo transações que tocam accounts diferentes.

### Quais linguagens de programação posso usar para construir na SVM?

Os programs são escritos principalmente em Rust e compilados para bytecode sBPF via LLVM, embora outras linguagens compatíveis com LLVM, como C, C++ e Zig, também sejam suportadas.

### O que são Program Derived Addresses (PDAs)?

PDAs são endereços especiais que caem fora da curva Ed25519, sem nenhuma chave privada válida, permitindo que os programs gerem e "assinem" deterministicamente endereços que controlam sem ter chaves privadas, viabilizando que programs gerenciem suas próprias accounts.

### Como funciona o modelo de accounts da SVM?

Tudo na Solana é uma account, uma estrutura de dados contendo lamports (saldo), bytes de dados arbitrários, um program ID de owner e metadados. Os programs são stateless e só podem modificar accounts que possuem, viabilizando limites claros de ownership para a execução paralela.

### O que é o sBPF e como ele se relaciona com o eBPF?

O sBPF (Solana Bytecode Format) é a variante customizada do eBPF criada pela Solana, modificada para uso em blockchain, com tamanhos de pilha maiores (4KB contra 512 bytes), suporte a loops limitados por compute units e syscalls customizadas para logging, CPIs e operações criptográficas.

### O que são Cross-Program Invocations (CPIs)?

CPIs permitem que programs da Solana chamem outros programs durante a execução, com profundidade máxima de chamada de 5, viabilizando composabilidade em todo o ecossistema, mantendo orçamentos de compute compartilhados e privilégios de signer em cascata.

### A SVM pode ser usada fora da Solana mainnet?

Sim, a SVM API modular viabiliza o uso além da Solana: a Eclipse roda a SVM como um rollup do Ethereum, a SOON Network opera como um rollup SVM desacoplado, e projetos como Sonic e MagicBlock constroem ambientes de execução SVM especializados.

### Como começo a construir na SVM?

Instale a Solana CLI e o framework Anchor, depois use `anchor init` para criar um projeto com programs iniciais, test suites e integração com validador local, o Anchor Book e o Solana Cookbook fornecem guias de desenvolvimento completos.