EVM vs SVM: um guia para desenvolvedores

Publicado em 25 de setembro de 202610 min de leitura

EVM vs SVM: um guia para desenvolvedores

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 contas 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 portar. Se preferir vídeo, nosso SVM vs EVM builders guide 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, 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 funcione. Se a EVM é nova para você, nosso Ethereum Virtual Machine explainer cobre os fundamentos.

A SVM foi projetada em torno da execução paralela. Os programas são compilados para bytecode sBPF, um formato baseado em registradores derivado do eBPF (o mesmo design de bytecode usado pelo kernel do Linux), e cada transação declara antecipadamente quais contas irá ler e escrever. Essa declaração permite que o Sealevel, o runtime paralelo da Solana, execute simultaneamente transações que não conflitam entre si em múltiplos núcleos de CPU. Nosso Solana Virtual Machine explainer cobre o pipeline de execução em profundidade.

A tabela abaixo resume as principais diferenças.

Dimensão	EVM	SVM
Modelo de contas	Código e armazenamento agrupados em contas de contrato	Tudo é uma conta; programas não têm estado
Execução	Sequencial dentro de um bloco	Paralela entre transações que não conflitam
Máquina virtual	Baseada em pilha, palavras de 256 bits	Baseada em registradores, derivada do eBPF
Mercado de taxas	Uma base fee global mais gorjetas	Base fee por assinatura mais priority fees restritas às contas disputadas
Linguagem principal	Solidity	Rust com Anchor
Tokens	Um contrato por token	Token Program compartilhado, uma mint account por token
Atualizações	Imutável por padrão, proxies para atualizar	Atualizável por padrão, revogar autoridade para congelar

Como os modelos de conta diferem?

O Ethereum tem dois tipos de conta: contas de propriedade externa, controladas por chaves privadas, e contas de contrato, controladas por código. Uma conta de contrato mantém seu próprio armazenamento, um armazenamento de chave-valor 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 em seu próprio armazenamento. Código e estado compartilham um único endereço e não podem ser separados.

A Solana usa um modelo de conta único para tudo. Cada pedaço de estado na Solana é uma conta com a mesma estrutura: um saldo em lamports (a menor unidade da Solana, como o wei), um campo de dados, um proprietário e uma flag executável. Um programa é uma conta cujos dados são bytecode sBPF e cuja flag executável está definida como true. O estado que um programa gerencia vive em contas de dados separadas. O runtime aplica a propriedade diretamente, já que somente o programa que possui uma conta pode modificar seus dados, o que remove boa parte da lógica de controle de acesso que um contrato Solidity implementa por conta própria. Nosso Solana data accounts vs. program accounts guide cobre essa separação em detalhe.

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 programa Solana deriva um endereço de conta dedicado para cada usuário a partir do ID do programa e um conjunto de seeds, tipicamente 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. Somente o programa pode assinar em seu nome. Na prática, cada entrada em um mapping Solidity se torna sua própria conta na Solana.

Os dois modelos também precificam o armazenamento de forma diferente. No Ethereum, você paga pelo armazenamento uma vez, em gas, no momento em que o escreve. Na Solana, toda conta precisa manter um depósito reembolsável proporcional ao seu tamanho, conhecido como rent exemption. O depósito é devolvido quando a conta é fechada, o que dá aos desenvolvedores um incentivo direto para remover estado não utilizado.

Como funciona a execução paralela na SVM?

A EVM executa as transações de um bloco de forma sequencial. Uma transação pode ler ou escrever em qualquer slot de armazenamento, e esses acessos não são conhecidos até que ela seja executada, 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 contas que irá ler e escrever antes da execução. O scheduler executa em paralelo transações que apenas leem contas compartilhadas e serializa transações que escrevem na mesma conta. Um write lock permite uma thread por vez. Transações que precisam do mesmo lock são enfileiradas e 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 contas, 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 roda uma EVM L1 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 contas, o que preserva a compatibilidade com a EVM enquanto aumenta o throughput.

Como as taxas se comparam?

O Ethereum usa um único mercado de taxas global. Toda transação paga a mesma base fee, 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 alvo 30 milhões de gas com um limite de 60 milhões de gas. Como a base fee se aplica à chain inteira, a demanda de uma aplicação afeta todo mundo. Um mint de NFT popular ou uma claim de airdrop eleva a base fee para todos os usuários, inclusive os de aplicações não relacionadas.

A Solana usa uma estrutura de taxas diferente. Toda transação paga uma base fee de 5.000 lamports por assinatura, 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 instrução e um máximo de 1,4 milhão de CU por transação. As transações também podem incluir uma prioritization fee, precificada em micro-lamports por compute unit, para serem agendadas à frente de outras.

A diferença chave é o escopo da competição por taxas. Como toda transação nomeia as contas em que escreve, a competição por priority fee se concentra entre transações que disputam as mesmas contas. O ecossistema se refere a esse comportamento como mercados de taxas locais. O método RPC getRecentPrioritizationFees reflete esse design ao filtrar amostras de taxas pelas contas graváveis que uma transação vai travar. Durante um mint popular, as taxas sobem para transações que escrevem nas contas do mint, enquanto transações não relacionadas ficam, em grande parte, imunes.

Isso afeta o planejamento de capacidade. No Ethereum, atividade de aplicações não relacionadas pode elevar seus custos de transação, e o design da aplicação não consegue evitar isso. Na Solana, a pressão de taxas vem principalmente da contenção nas suas próprias contas, então distribuir o estado frequentemente escrito entre mais contas reduz essa pressão.

O que muda no design de programas?

Um contrato Solidity é uma única unidade de código e armazenamento, e é imutável por design. Alterar sua lógica após a implantação requer um padrão de proxy construído sobre delegatecall, que roteia chamadas para um contrato de implementação substituível. Um contador Solidity mínimo se parece com isto:

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

O programa Solana equivalente, escrito com Anchor (um framework de programas Solana amplamente utilizado), não armazena nenhum estado por conta própria. O valor do contador vive em uma conta separada que cada chamada passa explicitamente:

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

Uma versão completa também incluiria uma instrução initialize para criar e financiar a conta do contador. Antes de o handler ser executado, o Anchor verifica cada conta contra a struct Increment, que confirma que a conta tem o tipo e o proprietário esperados. Essa verificação não restringe quem pode chamar a instrução. Do jeito que está escrito, qualquer pessoa pode chamar increment, então um programa real adicionaria uma exigência de signer ou uma restrição de endereço derivado para controlar quem pode atualizar o contador.

O comportamento padrão de atualização é invertido. Programas Solana implantados com uma upgrade authority são atualizáveis nativamente, e revogar essa autoridade torna o programa imutável. Programas Solana, portanto, não precisam de contratos proxy, o que remove uma categoria de código na qual as auditorias EVM frequentemente se concentram.

Os tokens seguem o mesmo padrão. Cada token ERC-20 é seu próprio contrato implementando uma interface padrão, então uma aplicação que suporta muitos tokens depende de muitas bases de código independentes. Na Solana, os tokens são emitidos através de um Token Program compartilhado, com o Token-2022 oferecendo uma versão estendida que suporta recursos opcionais, como taxas de transferência. Cada token é uma mint account que registra supply e decimals, e o saldo de cada titular é armazenado em uma token account. Uma aplicação que integra esses programas 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 eth_getLogs e indexadores consomem nativamente. A Solana não tem um sistema de eventos nativo. Os programas escrevem mensagens de log, e as macros de evento do Anchor codificam dados estruturados nesses logs, que podem ser truncados. Como resultado, a indexação em produção na Solana costuma depender de infraestrutura de streaming, como webhooks e Solana gRPC streaming.

Como é a 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 para testes, fuzzing e implantação. O desenvolvimento Solana usa Rust e Anchor, que tem uma curva de aprendizado mais íngreme e um pool de auditores menor, embora crescente. Nosso web3 programming languages overview cobre as opções de linguagem em mais detalhe.

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

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

Na Solana, ler estado significa buscar a conta 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 conta diretamente. Este exemplo usa @solana/kit:

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

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

O que quebra quando você porta uma aplicação EVM para a Solana?

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

msg.sender se torna signer accounts. A autorização na Solana vem de contas marcadas como signers na transação e verificadas pelo seu programa, além de PDAs pelas quais o programa assina quando o próprio programa detém a autoridade.
Mappings se tornam PDAs. Cada chave em um mapping Solidity se torna uma conta derivada que precisa ser criada e financiada com rent antes do primeiro uso. A leitura dos dados também muda, já que os clientes buscam contas em vez de consultar o armazenamento do contrato.
O armazenamento do contrato se torna contas dimensionadas e financiadas com rent. O estado precisa ser alocado com antecedência, com um tamanho conhecido, e o depósito é devolvido quando a conta é fechada.
Padrões de proxy para atualização deixam de ser necessários. A upgrade authority do programa substitui a configuração de proxy, e revogar essa autoridade torna o programa imutável.
Eventos se tornam logs e streaming. Qualquer sistema que consumia eth_getLogs precisa ser reconstruído em torno de parsing de logs, webhooks ou streams gRPC.
A stack de cliente e testes muda. O código do cliente migra de viem para @solana/kit, os testes migram do Foundry para o framework de testes do Anchor, e o CI precisa de um validator local.

Times que migram na direção contrária, da SVM para a EVM, costumam ganhar profundidade de ferramentas, indexação de eventos nativa e um mercado de auditores maior, e abrem mão de execução paralela, confirmação em menos de um segundo e isolamento de taxas por conta.

Em ambas as direções, a curva de aprendizado do time costuma ser o maior custo. Para engenheiros EVM migrando para a Solana, nosso Solana development roadmap é um bom ponto de partida.

Como escolher entre a EVM e a SVM?

Você está construindo	Ponto de partida sugerido	Por quê
Uma aplicação de consumo de alto throughput (pagamentos, trading, mints)	SVM	Execução paralela e isolamento de taxas por conta mantêm os custos estáveis sob sua própria carga
Um protocolo DeFi que compõe com liquidez existente	EVM	Protocolos DeFi estabelecidos, integrações e auditores estão concentrados no ecossistema EVM
Um time experiente em Solidity com produtos tolerantes a latência	EVM, ou uma chain EVM paralela	Manter a stack existente evita uma reescrita quando a carga de trabalho não exige o throughput da SVM

Como a Alchemy dá suporte ao desenvolvimento EVM e SVM?

Damos suporte aos dois ecossistemas a partir de uma única plataforma. Nossos RPC endpoints cobrem o Ethereum, as principais L2s e o restante do ecossistema EVM. Nossa infraestrutura Solana entrega chamadas de archive até 20x mais rápidas com 99,99% de uptime, e o gRPC streaming fornece os feeds de dados em tempo real dos quais a indexação na Solana depende. Se você está avaliando infraestrutura Solana, nosso Solana RPC guide cobre o que buscar em um provedor.

Uma API key gratuita dá acesso a endpoints para chains EVM e Solana a partir de um único dashboard, sem contrato ou compromisso mínimo, e sem necessidade de integrar um provedor separado para cada ecossistema.