A Solana Virtual Machine (SVM) é o ambiente de execução que processa programas da Solana e aplica suas mudanças de estado em toda a rede. Os programas são compilados no Solana Bytecode Format, ou sBPF, e rodam dentro de um runtime em sandbox. As transações identificam os programas que chamam e as contas que cada instrução pode ler ou gravar, dando ao runtime as informações necessárias para carregar o estado e agendar trabalho compatível.

A SVM separa o código executável dos programas dos dados mutáveis das contas e usa unidades de computação (compute units) para medir o consumo de recursos. Esse modelo sustenta o runtime paralelo Sealevel da Solana, porque transações que não solicitam contas graváveis conflitantes podem ser processadas simultaneamente. A SVM é uma camada de execução, não o mecanismo de consenso da Solana, o cliente validador ou o relógio Proof of History.

O que é a Solana Virtual Machine?

A Solana Virtual Machine (SVM) é o ambiente de execução que roda programas de smart contract e processa instruções de transações na Solana. Diferentemente de sistemas em que um smart contract armazena seu próprio estado, a Solana separa o código do programa das contas de dados. As transações especificam quais programas e contas usarão, permitindo que a rede processe transações independentes em paralelo.

O termo SVM também pode se referir a ambientes de execução compatíveis com a Solana usados por outras redes blockchain. Essas redes podem dar suporte a programas e ferramentas de desenvolvimento semelhantes, mas usam sistemas diferentes de consenso, sequenciamento, disponibilidade de dados ou liquidação. A compatibilidade com a SVM, portanto, descreve o ambiente de execução, não o modelo de segurança da rede subjacente.

Como funciona a Solana Virtual Machine?

A Solana Virtual Machine processa cada transação usando os programas e as contas listados nessa transação.

1. Carregar as contas necessárias: a SVM identifica o pagador da taxa, os signatários, as contas graváveis e os programas de que a transação precisa.

2. Executar as instruções: as instruções rodam em ordem pelos programas Solana relevantes, que também podem chamar outros programas quando necessário.

3. Aplicar permissões e limites: o runtime verifica a propriedade das contas, as permissões de signatário, o acesso de gravação e os limites de unidades de computação durante a execução.

4. Verificar o resultado: após a execução, a SVM confirma que os saldos e os dados das contas seguem as regras do protocolo da Solana.

5. Confirmar a transação: se todas as instruções forem bem-sucedidas, as mudanças de estado são registradas em conjunto. Se uma falhar, a transação não atualiza parcialmente o estado da aplicação.

Como as transações declaram quais contas acessam, a Solana pode executar em paralelo transações que usam contas diferentes, o que ajuda a rede a suportar maior throughput.

Quais são os principais benefícios e casos de uso da SVM?

A SVM foi projetada para aplicações que precisam de execução previsível dos programas e que se beneficiam do acesso explícito às contas. Seu desempenho depende tanto do design do runtime quanto de as transações disputarem o mesmo estado gravável.

1. O acesso declarado às contas permite o agendamento paralelo. As transações listam as contas de que precisam antes da execução, permitindo ao agendador rodar transações sem conflito em núcleos de processamento diferentes, ao mesmo tempo que protege o estado gravável compartilhado.

2. Programas e estado permanecem separados. Um programa sem estado pode operar sobre muitas contas de dados, o que favorece a lógica de aplicação reutilizável e permite aos desenvolvedores organizar o estado para concorrência em vez de duplicar código.

3. Transações atômicas podem compor várias instruções. Uma transação pode chamar vários programas em sequência e confirmar todas as mudanças de estado bem-sucedidas em conjunto, ou rejeitar a transação inteira quando uma instrução falha.

4. As unidades de computação tornam explícito o uso de recursos. O runtime mede o trabalho dos programas e permite que as transações solicitem um orçamento adequado, ajudando os validadores a limitar a execução enquanto os usuários expressam prioridade pelos mecanismos de taxa da rede.

Quais são exemplos de programas e redes SVM?

A tecnologia SVM aparece em aplicações Solana e em redes que reutilizam a execução compatível com a Solana. Os exemplos diferem em liquidação e infraestrutura, de modo que o suporte à SVM por si só não faz deles a mesma rede.

• Programas nativos da Solana. O System Program cria contas, enquanto os programas de voto, stake, compute-budget e address-lookup-table oferecem funções essenciais diretamente suportadas pelo runtime da Solana.

• Programas de aplicação da Solana. DEXs, mercados de empréstimo, plataformas de NFT e jogos implantam programas sBPF que operam sobre contas de usuário, mercado, vault, mint e posição fornecidas com cada instrução.

• Execução da Eclipse. A Eclipse usa um ambiente de execução baseado em SVM enquanto faz a liquidação por meio de infraestrutura relacionada ao Ethereum, ilustrando como o runtime pode estar dentro de uma pilha modular de blockchain diferente.

• Ferramentas locais de teste da SVM. Ferramentas como o LiteSVM reproduzem o comportamento relevante do runtime para desenvolvimento e testes, sem exigir que cada caso de teste envie transações a um cluster de validadores em produção.

Quais são as limitações e os riscos da SVM?

O modelo de desempenho da SVM cria restrições específicas de design. Os desenvolvedores precisam declarar as contas com precisão, reduzir contenção desnecessária e respeitar os limites do runtime, enquanto os usuários ainda enfrentam os riscos comuns de smart contracts e transações.

1. Contas graváveis compartilhadas podem limitar o paralelismo. Transações que exigem a mesma conta gravável não podem rodar juntas com segurança, então uma conta de estado global popular pode se tornar um gargalo da aplicação, apesar do runtime paralelo.

2. Os programas exigem conhecimento específico de desenvolvimento na Solana. Os desenvolvedores precisam entender a compilação de sBPF, a propriedade de contas, os endereços derivados de programas, as invocações entre programas, os orçamentos de computação e os requisitos de contas relacionados a rent.

3. Limites de computação e de contas podem rejeitar chamadas complexas. Uma transação pode falhar quando excede seu orçamento de computação, referencia recursos demais, aumenta os dados de uma conta de forma indevida ou atinge restrições de profundidade de chamada e do runtime.

4. Compatibilidade com a SVM não equivale à segurança da Solana. Uma cadeia SVM separada pode usar validadores, bridges, sequenciadores, disponibilidade de dados ou controles de upgrade diferentes, criando premissas de confiança sem relação com o bytecode de execução.

Qual é a diferença entre a SVM e a EVM?

A SVM difere da EVM principalmente por seu modelo de contas, seu bytecode e sua abordagem de concorrência. As transações da Solana declaram o acesso às contas antes da execução, e os programas operam sobre contas de estado separadas, permitindo que o Sealevel agende trabalho sem conflito em paralelo. Os contratos da Ethereum normalmente mantêm código e armazenamento no mesmo endereço, e a execução tradicional da EVM segue a ordem sequencial das transações. Ambos os ambientes exigem resultados determinísticos em todos os nós validadores, mas suas ferramentas de desenvolvimento, medição de taxas, layouts de estado e padrões de compatibilidade são diferentes.

Conceitos relacionados

1. O que é Smart Contract?

2. O que é Gas?

3. O que é Validador?

4. O que é Blockchain?

Leitura adicional

1. Quais são os principais projetos de Solana Virtual Machine (SVM) de 2025?

2. O que é a Eclipse (ES), a primeira Layer 2 com SVM na Ethereum?

3. O que é o Solscan e como usar o explorador de blockchain da Solana?

4. Solana vs. Ethereum: uma análise comparativa