---
title: "EVM vs SVM: um guia para desenvolvedores"
description: "Uma comparação entre a EVM e a SVM para desenvolvedores, cobrindo modelos de contas, execução paralela, taxas, design de programas e migração, com exemplos de código."
---

# EVM vs SVM: um guia para desenvolvedores

<ImageBlock
  src="https://media.alchemy.com/overviews/evm-vs-svm-hero-20260924.png"
  alt="EVM vs SVM: um guia para desenvolvedores"
  width={1920}
  height={900}
  priority
/>

Toda blockchain roda sobre uma máquina virtual, o motor que executa programas e aplica suas mudanças de estado. O motor do Ethereum é a EVM (Ethereum Virtual Machine), que também alimenta a maioria de suas Layer 2s. O da Solana é a SVM (Solana Virtual Machine), construída para executar transações em paralelo. A diferença arquitetural central é que a EVM armazena o código e o estado de um contrato juntos, enquanto a SVM os mantém em accounts separadas. Essa diferença molda como os programas armazenam dados, como as transações são executadas e como as taxas respondem ao congestionamento.

Este guia compara as duas em modelos de contas, execução, taxas, design de programas e ferramentas, com exemplos curtos de código, e termina com um framework para decidir onde construir ou para onde portar. Se preferir vídeo, nosso [guia de SVM vs EVM para builders](https://www.youtube.com/watch?v=OsposMFk9Ro) cobre a mesma comparação.

## O que são a EVM e a SVM?

A EVM é uma máquina virtual baseada em pilha que processa [transações uma de cada vez](https://ethereum.org/en/developers/docs/evm/), atualizando uma única árvore de estado compartilhada. Sua principal vantagem é a compatibilidade. O mesmo contrato Solidity é implantado sem alterações no Ethereum, em suas Layer 2s (Arbitrum, Base, Optimism, Unichain, World Chain, Ink) e em chains EVM independentes (BNB Chain, Avalanche, Polygon, Monad, Berachain), e as ferramentas ao redor funcionam em qualquer lugar onde o bytecode funciona. Se a EVM é nova para você, nosso [explainer sobre a Ethereum Virtual Machine](https://www.alchemy.com/overviews/what-is-the-ethereum-virtual-machine-evm) cobre os fundamentos.

A SVM foi projetada em torno da execução paralela. Os programs são compilados para [bytecode sBPF](https://solana.com/docs/core/programs), um formato baseado em registradores derivado do eBPF (o mesmo design de bytecode que o kernel Linux usa), e toda transação declara antecipadamente quais accounts vai ler e escrever. Essa declaração permite que o Sealevel, [o runtime paralelo da Solana](https://solana.com/docs/references/terminology), execute transações sem conflito simultaneamente em vários núcleos de CPU. Nosso [explainer sobre a Solana Virtual Machine](https://www.alchemy.com/overviews/what-is-the-solana-virtual-machine) cobre o pipeline de execução em profundidade.

A tabela abaixo resume as principais diferenças.

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 240, title: "Dimensão", dataType: "object" },
      { key: "2", width: 240, title: "EVM", dataType: "object" },
      { key: "3", width: 240, title: "SVM", dataType: "object" },
    ],
    data: [
      {
        "1": {
          title: "<p>Modelo de contas</p>",
          tooltip: "",
          icon: "",
        },
        "2": {
          title:
            "<p>Código e armazenamento agrupados em contas de contrato</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title: "<p>Tudo é uma account; programs são stateless</p>",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        "1": {
          title: "<p>Execução</p>",
          tooltip: "",
          icon: "",
        },
        "2": {
          title: "<p>Sequencial dentro de um bloco</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title: "<p>Paralela entre transações sem conflito</p>",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        "1": {
          title: "<p>Máquina virtual</p>",
          tooltip: "",
          icon: "",
        },
        "2": {
          title: "<p>Baseada em pilha, palavras de 256 bits</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title: "<p>Baseada em registradores, derivada do eBPF</p>",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        "1": {
          title: "<p>Mercado de taxas</p>",
          tooltip: "",
          icon: "",
        },
        "2": {
          title: "<p>Uma taxa base global mais gorjetas</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title:
            "<p>Taxa base por assinatura mais priority fees restritas às accounts disputadas</p>",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
      {
        "1": {
          title: "<p>Linguagem principal</p>",
          tooltip: "",
          icon: "",
        },
        "2": {
          title: "<p>Solidity</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title: "<p>Rust com Anchor</p>",
          tooltip: "",
          icon: "",
        },
        id: 4,
      },
      {
        "1": {
          title: "<p>Tokens</p>",
          tooltip: "",
          icon: "",
        },
        "2": {
          title: "<p>Um contrato por token</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title:
            "<p>Token Program compartilhado, uma mint account por token</p>",
          tooltip: "",
          icon: "",
        },
        id: 5,
      },
      {
        "1": {
          title: "<p>Upgrades</p>",
          tooltip: "",
          icon: "",
        },
        "2": {
          title: "<p>Imutável por padrão, proxies para fazer upgrade</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title:
            "<p>Upgradeable por padrão, revogar a authority para congelar</p>",
          tooltip: "",
          icon: "",
        },
        id: 6,
      },
    ],
  }}
/>

## Como os modelos de contas diferem?

O Ethereum tem [dois tipos de conta](https://ethereum.org/en/developers/docs/accounts/): contas de propriedade externa (externally-owned accounts), controladas por chaves privadas, e contas de contrato, controladas por código. Uma conta de contrato mantém seu próprio armazenamento, um key-value store de slots de 32 bytes, junto com seu bytecode. Quando você chama `balanceOf` em um token ERC-20, o contrato lê seu saldo de um mapping no próprio armazenamento. Código e estado compartilham um endereço e não podem ser separados.

A Solana usa um [modelo único de accounts](https://www.alchemy.com/overviews/solana-account-model) para tudo. [Todo pedaço de estado na Solana é uma account](https://solana.com/docs/core/accounts) com a mesma estrutura: um saldo em lamports (a menor unidade da Solana, como o wei), um campo de dados, um owner e uma flag executable. Um program é uma account cujos dados são bytecode sBPF e cuja flag executable está definida como true. O estado que um program gerencia vive em data accounts separadas. O runtime impõe a ownership diretamente, já que só o program owner de uma account pode modificar seus dados, o que elimina grande parte da lógica de controle de acesso que um contrato Solidity implementa por conta própria. Nosso [guia sobre data accounts vs. program accounts da Solana](https://www.alchemy.com/overviews/solana-data-vs-program-accounts) cobre essa divisão em detalhes.

As program derived addresses (PDAs) costumam ser o conceito menos familiar para desenvolvedores EVM. Onde um contrato Solidity armazena dados por usuário em um mapping, um program da Solana deriva um endereço de account dedicado para cada usuário a partir [do ID do program e de um conjunto de seeds](https://solana.com/docs/core/pda), normalmente a chave pública do usuário. A derivação é determinística e produz um endereço fora da curva Ed25519, então não existe chave privada para ele. Só o program pode assinar em seu nome. Na prática, cada entrada de um mapping Solidity se torna sua própria account na Solana.

Os dois modelos também precificam o armazenamento de forma diferente. No Ethereum, você paga pelo armazenamento uma vez, em gas, quando o escreve. Na Solana, toda account precisa manter um [depósito reembolsável proporcional ao seu tamanho](https://solana.com/docs/core/accounts), conhecido como [isenção de rent](https://www.alchemy.com/overviews/how-to-calculate-rent-for-solana-programs). O depósito é devolvido quando a account é fechada, o que dá aos desenvolvedores um incentivo direto para remover estado não usado.

## Como funciona a execução paralela na SVM?

A EVM executa as transações de um bloco sequencialmente. Uma transação pode ler ou escrever qualquer storage slot, e esses acessos só são conhecidos quando ela roda, então a EVM não consegue executar duas transações ao mesmo tempo com segurança.

A Solana elimina essa incerteza exigindo que cada transação liste todas as accounts que vai ler e escrever antes da execução. O scheduler [executa em paralelo as transações que apenas leem accounts compartilhadas e serializa as transações que escrevem na mesma account](https://docs.anza.xyz/validator/runtime). Um lock de escrita permite uma thread por vez. Transações que precisam do mesmo lock entram em fila e são processadas em ordem, e não falham por causa do conflito.

Esse modelo afeta o design de programas. Estado que muitos usuários atualizam ao mesmo tempo deve ser dividido entre várias accounts, que é como os tokens SPL (o padrão de token da Solana) são estruturados. Duas transferências de USDC entre carteiras não relacionadas escrevem em quatro token accounts diferentes, então podem ser executadas ao mesmo tempo. No Ethereum, as mesmas duas transferências atualizam o armazenamento de um único contrato ERC-20 e são executadas uma após a outra.

A execução paralela também está chegando ao ecossistema EVM. A [Monad](https://docs.monad.xyz/introduction/why-monad) roda uma L1 EVM com execução paralela e compatibilidade total de bytecode, e a MegaETH aplica técnicas semelhantes como uma L2 do Ethereum. Essas chains detectam conflitos em tempo de execução, em vez de exigir que as transações declarem suas accounts, o que preserva a compatibilidade com a EVM e aumenta o throughput.

## Como as taxas se comparam?

O Ethereum usa um mercado de taxas global único. Toda transação paga a mesma [taxa base](https://ethereum.org/en/developers/docs/gas/), que o protocolo ajusta a cada bloco e queima, mais uma gorjeta de prioridade opcional para o validador. Uma transferência padrão de ETH custa 21.000 gas, e os blocos têm como meta 30 milhões de gas, com um [limite de 60 milhões de gas](https://ethereum.org/en/developers/docs/blocks/). Como a taxa base se aplica à chain inteira, a demanda de uma aplicação afeta todo mundo. Um mint de NFT popular ou um claim de airdrop eleva a taxa base para todos os usuários, incluindo os de aplicações não relacionadas.

A Solana usa uma estrutura de taxas diferente. Toda transação paga uma [taxa base de 5.000 lamports por assinatura](https://solana.com/docs/core/fees), metade da qual é queimada e metade paga ao validador. O compute é medido em compute units (CU), com um orçamento padrão de 200.000 CU por instruction e um máximo de 1,4 milhão de CU por transação. As transações também podem incluir uma taxa de priorização, cotada em micro-lamports por compute unit, para serem agendadas à frente de outras.

A diferença central é o escopo da competição por taxas. Como toda transação nomeia as accounts em que escreve, a competição por priority fees se concentra entre as transações que disputam as mesmas accounts. O ecossistema chama esse comportamento de local fee markets (mercados de taxas locais). O método RPC [`getRecentPrioritizationFees`](https://solana.com/docs/rpc/http/getrecentprioritizationfees) reflete esse design ao filtrar as amostras de taxas pelas accounts graváveis que uma transação vai travar. Durante um mint popular, as taxas sobem para as transações que escrevem nas accounts do mint, enquanto as transações não relacionadas praticamente não são afetadas.

Isso afeta o planejamento de capacidade. No Ethereum, a atividade de aplicações não relacionadas pode aumentar o custo das suas transações, e o design da aplicação não consegue evitar isso. Na Solana, a pressão sobre as taxas vem principalmente da contenção nas suas próprias accounts, então distribuir o estado escrito com frequência entre mais accounts a reduz.

## O que muda no design de programas?

Um contrato Solidity é uma unidade única de código e armazenamento, e é [imutável por design](https://ethereum.org/en/developers/docs/smart-contracts/upgrading/). Mudar sua lógica após o deploy exige um padrão de proxy construído sobre `delegatecall`, que roteia chamadas para um contrato de implementação substituível. Um contador mínimo em Solidity fica assim:

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

O program equivalente na Solana, escrito com [Anchor](https://www.alchemy.com/overviews/solana-anchor) (um framework amplamente usado para programs da Solana), não armazena estado próprio. O valor do contador vive em uma account separada que cada chamada passa explicitamente:

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

Uma versão completa também incluiria uma instruction de inicialização para criar e financiar a account do contador. Antes de o handler rodar, o Anchor valida cada account contra a struct `Increment`, o que confirma que a account tem o tipo e o owner esperados. Essa validação não restringe quem pode chamar a instruction. Do jeito que está, qualquer pessoa pode chamar `increment`, então um programa real adicionaria um requisito de signer ou uma restrição de endereço derivado para controlar quem pode atualizar o contador.

O comportamento padrão de upgrade é o inverso. Programs da Solana implantados com uma upgrade authority são [upgradeable nativamente](https://solana.com/docs/core/programs), e revogar essa authority torna o program imutável. Por isso, programs da Solana não precisam de contratos proxy, o que elimina uma categoria de código em que as auditorias EVM costumam se concentrar.

Os tokens seguem o mesmo padrão. Cada token ERC-20 é [seu próprio contrato](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/), que implementa uma interface padrão, então uma aplicação que suporta muitos tokens depende de muitos codebases independentes. Na Solana, os tokens são emitidos por meio de um [Token Program compartilhado](https://solana.com/docs/tokens), e o Token-2022 oferece uma versão estendida que suporta funcionalidades opcionais, como taxas de transferência. Cada token é uma mint account que registra o supply e as casas decimais, e o saldo de cada holder é armazenado em uma token account. Uma aplicação que integra esses programs pode suportar qualquer token SPL sem código específico por token.

O tratamento de eventos é uma área em que a EVM tem uma vantagem clara. Contratos EVM emitem eventos indexados que o `eth_getLogs` e os indexadores consomem nativamente. A Solana [não tem um sistema nativo de eventos](https://www.anchor-lang.com/docs/features/events). Os programs escrevem mensagens de log, e as macros de eventos do Anchor codificam dados estruturados nesses logs, que podem ser truncados. Como resultado, a indexação em produção na Solana normalmente depende de infraestrutura de streaming, como [webhooks](https://www.alchemy.com/webhooks) e [streaming gRPC da Solana](https://www.alchemy.com/solana-grpc).

## Como é o stack do cliente?

A escolha da VM também determina a linguagem e as ferramentas. O desenvolvimento EVM usa Solidity e uma toolchain madura (Foundry, Hardhat), com amplo suporte a testes, fuzzing e deploy. O desenvolvimento na Solana usa Rust e Anchor, que têm uma curva de aprendizado mais íngreme e um grupo de auditores menor, embora crescente. Nossa [visão geral das linguagens de programação web3](https://www.alchemy.com/overviews/web3-programming-languages) cobre as opções de linguagem em mais detalhes.

A diferença entre os modelos de dados também aparece no código do cliente. Na EVM, ler estado significa chamar uma função no contrato, que retorna dados do próprio armazenamento. Este exemplo usa viem:

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

Na Solana, ler estado significa buscar a account que contém os dados. Um saldo de token é armazenado em uma token account, e não no Token Program, então o cliente lê essa account diretamente. Este exemplo usa `@solana/kit`:

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

Esse padrão se aplica a toda a camada do cliente. Um cliente EVM consulta um contrato, enquanto um cliente Solana precisa saber qual account contém cada dado, o que torna o layout das accounts parte do design da aplicação.

## O que quebra quando você porta um app EVM para a Solana?

Mover uma aplicação da EVM para a Solana exige reescrever o código onchain, porque os modelos de contas e de execução são diferentes. As principais mudanças são:

- **`msg.sender` dá lugar a signer accounts.** A autorização na Solana vem de accounts marcadas como signers na transação e verificadas pelo seu program, além de [PDAs pelas quais o program assina](https://solana.com/docs/core/cpi) quando o próprio program detém a autoridade.
- **Mappings viram PDAs.** Cada chave de um mapping Solidity se torna uma account derivada que precisa ser criada e financiada com o depósito de rent antes do primeiro uso. A leitura dos dados também muda, já que os clientes buscam accounts em vez de consultar o armazenamento do contrato.
- **O armazenamento do contrato vira accounts com tamanho definido e financiadas com rent.** O estado precisa ser alocado antecipadamente com um tamanho conhecido, e o depósito é devolvido quando a account é fechada.
- **Padrões de upgrade por proxy deixam de ser necessários.** A upgrade authority do program substitui a configuração de proxy, e revogar essa authority torna o program imutável.
- **Eventos viram logs e streaming.** Qualquer sistema que consumia `eth_getLogs` precisa ser reconstruído em torno de parsing de logs, webhooks ou streams gRPC.
- **O stack de cliente e de testes muda.** O código do cliente passa de viem para `@solana/kit`, os testes passam do Foundry para o framework de testes do Anchor, e o CI precisa de um validador local.

Times que fazem o caminho inverso, da SVM para a EVM, normalmente ganham profundidade de ferramentas, indexação nativa de eventos e um mercado maior de auditores, e abrem mão da execução paralela, da confirmação em menos de um segundo e do isolamento de taxas por account.

Nas duas direções, a curva de aprendizado do time costuma ser o maior custo. Para engenheiros EVM que estão migrando para a Solana, nosso [roadmap de desenvolvimento na Solana](https://www.alchemy.com/overviews/learn-solana-development) é um bom ponto de partida.

## Como escolher entre a EVM e a SVM?

<EmbeddedTable
  table={{
    columns: [
      {
        key: "1",
        width: 240,
        title: "O que você está construindo",
        dataType: "object",
      },
      {
        key: "2",
        width: 240,
        title: "Ponto de partida sugerido",
        dataType: "object",
      },
      { key: "3", width: 240, title: "Por quê", dataType: "object" },
    ],
    data: [
      {
        "1": {
          title:
            "<p>Um app de consumo de alto throughput (pagamentos, trading, mints)</p>",
          tooltip: "",
          icon: "",
        },
        "2": {
          title: "<p>SVM</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title:
            "<p>A execução paralela e o isolamento de taxas por account mantêm os custos estáveis sob a sua própria carga</p>",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        "1": {
          title:
            "<p>Um protocolo DeFi que se compõe com a liquidez existente</p>",
          tooltip: "",
          icon: "",
        },
        "2": {
          title: "<p>EVM</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title:
            "<p>Protocolos DeFi consolidados, integrações e auditores estão concentrados no ecossistema EVM</p>",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        "1": {
          title:
            "<p>Um time experiente em Solidity com produtos tolerantes a latência</p>",
          tooltip: "",
          icon: "",
        },
        "2": {
          title: "<p>EVM, ou uma chain EVM paralela</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title:
            "<p>Permanecer no stack existente evita uma reescrita quando a carga de trabalho não exige o throughput da SVM</p>",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
    ],
  }}
/>

<ExternalVideo
  url="https://www.youtube.com/watch?v=OsposMFk9Ro"
  provider="youtube"
  providerUid="OsposMFk9Ro"
/>

## Como a Alchemy apoia o desenvolvimento em EVM e SVM?

Damos suporte aos dois ecossistemas a partir de uma única plataforma. Nossos [endpoints RPC](https://www.alchemy.com/rpc-api) cobrem o Ethereum, as principais L2s e o ecossistema EVM mais amplo. Nossa [infraestrutura para Solana](https://www.alchemy.com/blog/solana-infrastructure) entrega chamadas de archive até 20x mais rápidas, com 99,99% de uptime, e o [streaming gRPC](https://www.alchemy.com/solana-grpc) fornece os feeds de dados em tempo real dos quais a indexação na Solana depende. Se você está avaliando infraestrutura para Solana, nosso [guia de RPC da Solana](https://www.alchemy.com/overviews/solana-rpc) cobre o que observar em um provedor.

Uma API key gratuita dá a você endpoints para chains EVM e para a Solana em um único dashboard, sem contrato nem compromisso mínimo, e sem precisar integrar um provedor separado para cada ecossistema.