SolanaVM Explicada: Máquina Virtual Solana

Nota de precisão: O desempenho da rede, o número de validadores, as taxas, as funcionalidades do protocolo, o suporte de carteiras e as integrações de terceiros mudam com o tempo. Trate figuras desatualizadas como instantâneos históricos e verifique a documentação primária atual.

SolanaVM (também referida como Máquina Virtual Solana ou SVM) é o ambiente de execução da blockchain Solana: a camada de software que processa e executa programas na blockchain. Lida com a computação, impõe a lógica do programa e confirma os resultados de volta para a rede. SolanaVM não é um produto ou token separado; é o motor de execução principal integrado no protocolo Solana.

Nota de terminologia: Em contextos de blockchain, SVM significa Solana Virtual Machine. SVM também abrevia Support Vector Machine, um algoritmo de aprendizagem automática sem relação com blockchain. Ao longo deste artigo, SVM refere-se exclusivamente à Máquina Virtual Solana.

Conteúdos: Como Funciona a SolanaVM | SolanaVM vs. EVM | Construir na SolanaVM | Adoção Multi-Cadeia | Como a Adoção da SolanaVM Está a Desenvolver-se | FAQ

Uma blockchain é um ledger distribuído que regista transações numa rede de computadores sem depender de uma autoridade central. As blockchains modernas fazem mais do que registar transferências de valor. Executam programas: software que lida com empréstimos, negociação, governança e milhares de outras funções na blockchain. Para executar programas, uma blockchain necessita de um ambiente de execução, uma camada de software controlada que recebe instruções, processa-as de acordo com regras definidas e escreve os resultados na blockchain. Toda a blockchain de contratos inteligentes necessita de um ambiente de execução. Na Solana, esse ambiente é a SolanaVM.

A Solana é uma blockchain de Camada 1 (L1), uma rede de camada base com o seu próprio mecanismo de consenso e token nativo chamado SOL. A SolanaVM não é o mesmo que a Solana. A relação é análoga a um motor de carro e ao carro em si: a SolanaVM é o motor; a Solana é o veículo completo. SOL é o combustível que paga pela execução. Estas são três entidades distintas, e confundi-las cria uma confusão genuína ao avaliar a arquitetura da Solana.

A SolanaVM foi construída em torno de uma filosofia de design focada em alto débito, traçada diretamente a Anatoly Yakovenko, cofundador da Solana e antigo engenheiro da Qualcomm, que identificou o tempo de processamento da ordenação de transações como o principal gargalo nos designs de blockchain existentes.

Como Funciona a SolanaVM: Arquitetura e Modelo de Execução

A SolanaVM executa programas Solana através de um pipeline de cinco fases que funciona na infraestrutura de validadores distribuída da rede, processando transações não conflituantes em paralelo em vez de em sequência.

Na SolanaVM, os contratos inteligentes são chamados programas Solana (o termo da SolanaVM para contratos inteligentes). Este é o termo oficial da Solana Foundation, não uma variação estilística. A diferença de nomenclatura reflete uma distinção arquitetónica real. Os contratos inteligentes EVM armazenam tanto a lógica do programa como os dados de estado dentro do mesmo objeto de contrato. Os programas Solana são sem estado: o código do programa reside numa conta na blockchain, e os dados nos quais opera residem em contas de dados separadas. Esta separação é o que torna a execução paralela tratável em escala.

O pipeline de execução da SolanaVM segue cinco fases:

1. Um programador escreve um programa Solana em Rust
2. O código Rust compila para bytecode sBPF
3. O bytecode compilado é implementado como uma conta de programa na blockchain
4. Um utilizador submete uma transação que invoca o programa com dados de instrução
5. Os validadores Solana (os nós da rede que executam a SolanaVM) executam o bytecode sBPF, consomem unidades de computação e confirmam o resultado no ledger

Os validadores Solana executam a SolanaVM em hardware dedicado e alcançam consenso através de dois mecanismos separados: Proof of History (PoH) para a ordenação de transações e Tower BFT, um mecanismo de consenso Proof of Stake, para a validação de resultados. A rede de validadores da Solana é protegida pelo Tower BFT. Enquanto o PoH ordena transações, o Tower BFT determina o consenso sobre a sua validade. Estes são papéis distintos e não devem ser confundidos.

Proof of History é um mecanismo criptográfico de ordenação inventado por Anatoly Yakovenko, detalhado no Whitepaper Proof of History da Solana.) O PoH funciona como um relógio sincronizado que permite a todos os validadores concordar sobre quando cada transação ocorreu sem precisar de se perguntar uns aos outros, eliminando um grande gargalo de coordenação. Ao pré-ordenar transações criptograficamente, o PoH dá à SolanaVM a base temporal de que necessita para processar múltiplas transações simultaneamente. O PoH não é um mecanismo de consenso; é um protocolo de marcação de tempo e ordenação que alimenta o consenso Tower BFT.

O Que É sBPF? Formato de Bytecode da SolanaVM

sBPF (Solana Berkeley Packet Filter) é o formato de bytecode que a SolanaVM executa: a versão modificada da Solana do conjunto de instruções Berkeley Packet Filter, adaptada especificamente para a execução de programas blockchain.

Quando um programador escreve um programa Solana em Rust, esse código Rust não é executado diretamente na blockchain. O compilador Rust traduz-o para bytecode sBPF, um formato de instrução compacto e de baixo nível que o motor de execução da SolanaVM pode processar eficientemente. Os validadores executam bytecode sBPF diretamente; é aqui que a computação acontece fisicamente na rede.

sBPF é distinto do BPF original (Berkeley Packet Filter), uma tecnologia de rede utilizada em kernels de sistemas operativos para filtragem de pacotes. O sBPF da Solana é um fork modificado adaptado às restrições da execução de máquinas virtuais blockchain. Use sempre "sBPF" em vez de "BPF" sozinho ao referir-se ao formato de bytecode da Solana.

Para programadores vindos do ecossistema EVM, o sBPF ocupa o mesmo papel funcional que os opcodes EVM: é o conjunto de instruções de baixo nível que a máquina virtual interpreta e executa.

Execução Paralela: Como a SolanaVM Processa Múltiplas Transações Simultaneamente

A SolanaVM processa transações não conflituantes simultaneamente em vez de uma de cada vez, uma partida fundamental do modelo de execução sequencial da EVM.

Imagine um banco onde cada funcionário atende um cliente diferente ao mesmo tempo, em vez de uma longa fila servida por uma única janela. A execução paralela da SolanaVM funciona de forma semelhante para transações que não tocam nas mesmas contas.

O mecanismo é Sealevel, o motor de execução paralela da SolanaVM. Antes de executar qualquer transação, o Sealevel analisa as dependências de conta de cada transação: de quais contas esta transação lê e para quais escreve? Se duas transações acedem a contas totalmente diferentes, não têm conflito e podem ser executadas simultaneamente em múltiplos núcleos de CPU. Transações que partilham contas são colocadas em fila sequencialmente para essas contas específicas, enquanto todas as transações não relacionadas continuam em paralelo.

O resultado é um limite de débito que escala com o hardware do validador, em vez de um gargalo sequencial fixo. O débito máximo teórico da Solana atinge aproximadamente 65.000 transações por segundo em condições ideais, em comparação com aproximadamente 15 a 30 TPS na Mainnet Ethereum (Fonte: Solana Foundation, solana.com; ethereum.org, a partir do Q1 2025). O débito em tempo real sob carga é inferior em ambas as redes, e as cadeias de Camada 2 (L2) compatíveis com EVM, construídas sobre a Ethereum, alcançam um débito substancialmente superior ao da própria Mainnet Ethereum.

SolanaVM vs. EVM: Como os Dois Ambientes de Execução se Comparam

SolanaVM e a Máquina Virtual Ethereum (EVM) representam duas abordagens arquitetónicas distintas para a execução de programas em blockchain, cada uma com compromissos mensuráveis que favorecem diferentes casos de uso. Um terceiro padrão de máquina virtual, WebAssembly (WASM), é utilizado por cadeias como NEAR Protocol e Polkadot, representando uma escolha arquitetónica diferente tanto da EVM como da SolanaVM.

A Máquina Virtual Ethereum (EVM): O Padrão Estabelecido

A Máquina Virtual Ethereum (EVM), originalmente concebida por Vitalik Buterin e pela equipa Ethereum, é o ambiente de execução partilhado entre a Ethereum e todas as cadeias compatíveis com EVM. A documentação completa da Máquina Virtual Ethereum está disponível em ethereum.org.

A EVM processa transações sequencialmente: uma de cada vez, em ordem estrita. Cada transação num bloco é executada após a conclusão da anterior. Os programas são escritos em Solidity ou Vyper e compilados para opcodes da EVM. Este modelo sequencial cria um teto de débito ligado ao tempo de bloco, em vez da capacidade do hardware, mas também simplifica o raciocínio sobre o estado. Em qualquer ponto da execução, todo o estado é determinístico e totalmente consistente.

A vantagem competitiva mais duradoura da EVM é o seu efeito de rede. Mais de 100 cadeias compatíveis com EVM, incluindo Polygon, Arbitrum, Avalanche C-Chain e BNB Chain, partilham o mesmo padrão de execução. Desenvolvedores que aprendem Solidity podem implementar em qualquer cadeia compatível com EVM sem reescrever o seu código. Esta portabilidade acumulou-se ao longo de uma década, criando um ecossistema de ferramentas (Hardhat, Foundry, Remix, OpenZeppelin) e uma comunidade de desenvolvedores que a SolanaVM ainda não igualou em escala.

SolanaVM vs. EVM: Comparação Lado a Lado

SolanaVM e a EVM diferem mais fundamentalmente na forma como processam transações: a SolanaVM executa transações não conflituantes em paralelo, enquanto a EVM processa transações sequencialmente. A tabela abaixo mapeia estas diferenças arquitetónicas em seis dimensões principais.

Os números de TPS representam máximos teóricos em condições ideais e variam significativamente sob carga de rede real. As cadeias L2 compatíveis com EVM alcançam um débito substancialmente superior ao da Mainnet Ethereum. Última atualização: Q1 2025. Fontes: Solana Foundation (solana.com), ethereum.org.

O efeito de rede da EVM em mais de 100 cadeias é a sua vantagem competitiva duradoura. A arquitetura de execução paralela da SolanaVM oferece vantagens de débito mensuráveis para casos de uso específicos de alta frequência, mas a velocidade bruta é apenas uma dimensão numa decisão de construir ou investir.

Programas Solana vs. Contratos Smart Contract Ethereum: Qual é a Diferença?

Os programas Solana (o termo oficial da Solana Foundation para contratos inteligentes na SolanaVM) diferem dos contratos inteligentes EVM não apenas em nome, mas em arquitetura estrutural.

Os programas Solana são sem estado. A lógica do programa vive numa conta na blockchain; os dados em que o programa opera vivem em contas de dados separadas que o programa lê e escreve. Um contrato inteligente EVM, por contraste, agrupa tanto a lógica como o estado num único objeto de contrato. O contrato detém o seu próprio armazenamento. Esta separação no modelo da Solana é o que permite ao Sealevel determinar as dependências das contas antes da execução: as contas envolvidas em qualquer transação são declaradas explicitamente com antecedência, dando ao motor de execução a informação de que necessita para agendar a execução paralela em segurança.

SolanaVM não é compatível com EVM. A fonte cita Neon EVM como um ambiente EVM de terceiros separado associado à Solana. Não torna a SVM em si compatível, e a sua arquitetura atual, estado de implementação, suporte de ferramentas e limitações devem ser avaliados independentemente.

Construir na SolanaVM: Linguagens, Ferramentas e Primeiros Passos

Os programas Solana são escritos principalmente em Rust, uma linguagem de programação de sistemas escolhida pelas suas garantias de segurança de memória e características de desempenho, e compilados para bytecode sBPF antes da implementação na SolanaVM.

Rust impõe a segurança de memória no tempo de compilação através de um modelo de propriedade que elimina classes inteiras de bugs: desreferências de ponteiro nulo, corridas de dados e overflows de buffer, tudo sem depender de um coletor de lixo. Estas propriedades alinham-se com os requisitos de segurança e desempenho da execução na blockchain, onde os bugs não podem ser corrigidos após a implementação e os custos de execução importam ao nível da instrução. C e C++ são também tecnicamente suportados pela SolanaVM, mas Rust é o padrão de facto em todo o ecossistema de desenvolvedores Solana.

O Anchor Framework para desenvolvimento Solana abstrai grande parte da complexidade de baixo nível de Rust e sBPF, funcionando analogamente ao Hardhat ou Foundry no ecossistema EVM. O Anchor fornece validação estruturada de contas, tratamento de erros e definições de interface de programa, reduzindo significativamente o código repetitivo necessário para escrever um programa Solana correto. Note que o Anchor Framework para Solana não está relacionado com o Anchor Protocol, o protocolo de empréstimo Terra/Luna DeFi que colapsou em 2022.

A arquitetura de execução paralela da SolanaVM torna-a particularmente adequada para aplicações DeFi que requerem alto débito: livros de ordens na blockchain, motores de liquidação e programas de otimização de rendimento que exigem baixa latência e alta densidade de transações. Os principais protocolos nativos da SolanaVM DeFi incluem Raydium (market maker automatizado), Jupiter (agregador DEX), e Kamino (otimização de rendimento). SOL pode ser adquirido nas principais exchanges de criptomoedas e utilizado para pagar unidades de computação ao interagir com programas SolanaVM.

Para um quickstart completo para desenvolvedores, visite a documentação oficial para desenvolvedores da Solana.

Unidades de Computação: Como a SolanaVM Mede a Execução de Programas

As unidades de computação (CU) são o equivalente da SolanaVM ao gás da Ethereum: a unidade que mede os recursos computacionais consumidos pela execução de um programa Solana.

Cada transação SolanaVM opera dentro de um orçamento de unidades de computação. O máximo atual é de 1,4 milhões de CU por transação, conforme especificado na documentação da Solana Foundation (Fonte: docs.solana.com, a partir do Q1 2025). Um programa que excede o seu orçamento de CU a meio da execução é abortado, e a transação falha. Os desenvolvedores solicitam um limite específico de CU para cada transação; solicitar em excesso desperdiça potenciais poupanças de taxas, enquanto solicitar a menos causa falhas evitáveis.

As taxas de transação em Solana são pagas em SOL e são parcialmente determinadas pelo consumo de CU. Uma Taxa-base aplica-se a todas as transações; um mercado opcional de taxas de prioridade permite que os utilizadores paguem mais para avançar no agendamento de slots durante períodos de alta procura. As unidades de computação (CU) funcionam de forma semelhante ao gas da Ethereum, na medida em que ambas medem o custo computacional, mas o sistema de CU da Solana utiliza uma Taxa-base de preço fixo em vez de um leilão totalmente dinâmico, com taxas de prioridade adicionadas por cima.

Pode Fazer o Port de Smart Contracts da EVM para a SolanaVM?

O port direto de contratos da EVM para a SolanaVM não é possível sem reescrita. Os programas da Solana requerem Rust e bytecode sBPF, não Solidity e opcodes de EVM. Os modelos de execução são arquiteturalmente diferentes ao ponto de não existir uma tradução linha a linha.

Os contratos da EVM e os programas da Solana utilizam modelos de estado e de conta diferentes, pelo que uma migração nativa requer geralmente mudanças arquiteturais. Um ambiente EVM separado pode preservar partes de um fluxo de trabalho Solidity, enquanto o desenvolvimento nativo em SVM utiliza toolchains diferentes. Compare a compatibilidade, o desempenho, as auditorias, as dependências operacionais e o suporte atual em vez de tratar qualquer um dos caminhos como padrão.

SolanaVM Além da Solana: Adoção Multi-Chain e o Ecossistema SVM

A SolanaVM opera além da mainnet da Solana, com projetos de Camada 2 a implementá-la como um ambiente de execução autónomo noutras blockchains de camada base.

Embora a SolanaVM tenha sido concebida como um ambiente de execução de Camada 1, a sua adoção por projetos de Camada 2 marca uma evolução arquitetural significativa. A tese da portabilidade, de que a SolanaVM pode funcionar como um padrão de execução partilhado entre múltiplas cadeias, tal como a EVM faz, está a passar da teoria à produção.

A tabela seguinte lista as atuais cadeias SVM por tipo e estado:

Última atualização: 1.º trimestre de 2025. Verifique o estado atual do projeto antes de republicar. Fontes: eclipse.xyz, documentação da Solana Foundation. Estão em desenvolvimento projetos adicionais de rollup de SVM; esta tabela requer atualizações periódicas à medida que o ecossistema evolui.

Em todas as cadeias SVM, as aplicações de DeFi, particularmente DEXs, protocolos de empréstimo e programas de otimização de rendimento, representam o principal caso de uso para as capacidades de execução paralela da SolanaVM. A Neon EVM representa uma dimensão diferente do crescimento do ecossistema SVM, permitindo que contratos compatíveis com EVM sejam executados na SolanaVM da Solana e unindo os dois maiores ecossistemas de Smart Contract.

Eclipse: SolanaVM como uma Camada 2 da Ethereum

A fonte cita a Eclipse como um exemplo de tecnologia SVM utilizada fora da Solana. A sua arquitetura atual, modelo de quitação, disponibilidade de dados, pressupostos de segurança e desempenho medido devem ser verificados a partir de fontes primárias datadas, em vez de serem resumidos como herdando uma garantia de segurança genérica.

A arquitetura separa duas funções que a maioria das blockchains agrupa. A SolanaVM gere a execução: recebe transações, processa programas Solana em paralelo utilizando o Sealevel e produz outputs de estado a alta velocidade. A Ethereum gere a quitação: a Eclipse envia os dados das transações de volta para a Ethereum, herdando o seu modelo de segurança e finalidade. A Eclipse desacopla a velocidade de execução do modelo de segurança da cadeia base, acedendo a ambos de forma independente.

Esta arquitetura demonstra que a SolanaVM pode funcionar como um padrão de execução portátil fora da própria rede Solana. Segue a mesma portabilidade arquitetural que permitiu à EVM espalhar-se por dezenas de cadeias. A implementação da Eclipse é a evidência atual mais clara para a tese da portabilidade da SVM.

Para detalhes arquiteturais completos, visite a documentação oficial da Eclipse em eclipse.xyz.

SVM Rollups: A Próxima Fronteira da Adoção da SolanaVM

Um rollup de SVM (uma solução de Camada 2 alimentada pela SolanaVM) é uma blockchain que utiliza a SolanaVM como o seu ambiente de execução enquanto envia dados de transações para uma cadeia de camada base para quitação e disponibilidade de dados.

A arquitetura de rollup desacopla a velocidade de execução da SolanaVM do modelo de segurança de qualquer cadeia individual. Em vez de exigir uma nova cadeia autónoma, um rollup de SVM pode ligar-se a uma camada base existente (Ethereum, Celestia ou a própria Solana) para disponibilidade de dados e finalidade. O desempenho de execução paralela da SolanaVM torna-se acessível em todo o ecossistema de blockchain mais amplo, em vez de ser exclusivo da própria rede da Solana.

A implementação da mainnet da Eclipse representa a arquitetura de rollup de SVM mais avançada atualmente em produção. Estão em desenvolvimento projetos adicionais de rollup de SVM, embora o seu estado mude frequentemente. Se a adoção de rollups de SVM continuar na sua trajetória atual, a presença multi-chain da SolanaVM poderá aproximar-se da amplitude da adoção da EVM, embora o tamanho do ecossistema de programadores continue a ser a variável diferenciadora chave.

Esta secção abrange desenvolvimentos do ecossistema virados para o futuro. Os estados dos projetos requerem verificação periódica. Última atualização: 1.º trimestre de 2025.

Como se Está a Desenvolver a Adoção da SolanaVM Além da Solana

A SolanaVM está a mostrar sinais precoces de adoção multi-chain, com projetos como o Eclipse a implementá-la como uma camada de execução fora da rede Solana. O facto de a SolanaVM alcançar ou não uma padronização multi-chain semelhante à da EVM depende das taxas de adoção dos programadores, da maturidade das ferramentas e do sucesso dos projetos de rollup de SVM.

A evidência do alcance crescente da SolanaVM é concreta. A Eclipse opera uma mainnet ativa utilizando a SolanaVM como o seu ambiente de execução na Ethereum. Os projetos de rollup de SVM estão a passar da fase de anúncio para a fase ativa. O Anchor Framework amadureceu ao ponto de o desenvolvimento na SolanaVM ser substancialmente mais acessível do que era há dois anos. Os protocolos de DeFi na Solana (Raydium, Jupiter, Kamino) demonstram que a arquitetura de execução paralela da SolanaVM gera atividade económica real, e não apenas números teóricos de processamento.

Os obstáculos são igualmente concretos. A EVM tem uma vantagem de uma década na adoção por programadores, na maturidade das ferramentas e na implementação multi-chain. Um programador que conheça Solidity pode implementar em mais de 100 cadeias hoje; um programador que conheça Rust e o Anchor Framework pode implementar na mainnet da Solana e na Eclipse, com mais cadeias SVM a chegar gradualmente. O efeito de rede da EVM representa uma barreira competitiva genuína, não um passivo herdado que a SolanaVM desloca automaticamente. A arquitetura de execução paralela da SolanaVM oferece vantagens mensuráveis para casos de uso de DeFi de alto débito, mas a superioridade técnica numa dimensão não se traduz automaticamente em adoção pelo ecossistema.

A crescente adoção da SolanaVM na rede nativa da Solana aumenta a procura por SOL como o token de taxa para pagamentos de unidades de computação. As cadeias SVM que liquidam noutras redes (como a Eclipse que faz a quitação na Ethereum) podem utilizar estruturas de taxas diferentes; a relação de procura de SOL varia consoante a arquitetura da cadeia.

Este conteúdo serve apenas para fins informativos e não constitui aconselhamento financeiro ou de investimento. A SolanaVM e o SOL (a criptomoeda nativa da Solana) acarretam riscos inerentes à tecnologia blockchain e aos ativos digitais. Os leitores devem realizar pesquisas independentes antes de tomarem qualquer decisão de investimento.

A trajetória da adoção da SolanaVM na mainnet da Solana, na Eclipse e nos rollups de SVM emergentes será determinada tanto pelo crescimento da comunidade de programadores como pelo mérito arquitetural. O caso arquitetural para a SolanaVM está bem estabelecido. O caso do ecossistema ainda está a ser construído.

Explorar SOL no Bybit

Os leitores podem rever as informações atuais do mercado de SOL ou o mercado Spot SOL/USDT. Estes links fornecem acesso ao mercado e não provam que a Solana, uma carteira ou um protocolo de terceiros seja adequado para todos os leitores.

Perguntas Frequentes: Explicação da SolanaVM

O que é a SolanaVM?

SolanaVM (também referida como Solana Virtual Machine ou SVM) é o ambiente de execução da blockchain Solana: a camada de software que processa os programas Solana e regista os seus resultados na rede. SolanaVM não é um token ou produto separado; é um componente arquitetónico central da Solana. Em contextos de blockchain, SVM significa Solana Virtual Machine, não Support Vector Machine.

Como é que a SolanaVM difere da EVM?

A SolanaVM e a Máquina Virtual Ethereum (EVM) diferem em três dimensões arquitetónicas principais. Primeiro, a SolanaVM processa transações não conflituantes em paralelo utilizando o motor Sealevel; a EVM processa transações sequencialmente. Segundo, a SolanaVM executa bytecode sBPF compilado de Rust; a EVM executa opcodes compilados de Solidity ou Vyper. Terceiro, a SolanaVM mede o custo de execução em unidades de computação (CU); a EVM utiliza gas. A EVM tem um ecossistema multichain substancialmente maior.

Que linguagem de programação é utilizada para a SolanaVM?

Os programas Solana são escritos principalmente em Rust, uma linguagem de programação de sistemas valorizada pelas suas garantias de segurança de memória e desempenho. O código Rust compila para bytecode sBPF antes da implementação na blockchain. O Anchor Framework para Solana simplifica o desenvolvimento em Rust, tratando da validação de contas boilerplate e da estrutura do programa. C e C++ são tecnicamente suportados, mas Rust é o padrão de facto.

A SolanaVM é mais rápida que a EVM?

A taxa de transferência máxima teórica da SolanaVM atinge aproximadamente 65.000 TPS em condições ótimas; a Ethereum Mainnet processa aproximadamente 15 a 30 TPS sequencialmente (Fonte: Solana Foundation, ethereum.org, a partir do Q1 2025). A execução paralela da SolanaVM confere-lhe uma vantagem de velocidade mensurável para cargas de trabalho de transações não conflituantes. As cadeias Camada 2 compatíveis com EVM, como Arbitrum e Optimism, atingem valores de taxa de transferência que diminuem significativamente esta diferença na prática.

O que é sBPF na Solana?

sBPF (Solana Berkeley Packet Filter) é o formato de bytecode que a SolanaVM executa: a versão modificada da Solana do conjunto de instruções Berkeley Packet Filter, adaptada para a execução de programas na blockchain. Quando um programador escreve um programa Solana em Rust, o compilador Rust traduz-o para bytecode sBPF antes da implementação. Os validadores executam esse bytecode sBPF diretamente. sBPF distingue-se da tecnologia BPF original utilizada nos kernels dos sistemas operativos.

É possível executar contratos EVM na SolanaVM?

O bytecode EVM não é executado nativamente na SolanaVM porque os modelos de execução e de contas diferem. Um ambiente EVM de terceiros separado pode suportar partes de um fluxo de trabalho Solidity, enquanto uma implementação nativa SVM requer uma linguagem e arquitetura compatíveis. Verifique o suporte de ferramentas atual e compare o desempenho da carga de trabalho real antes de escolher um caminho.

O que é a blockchain Eclipse e como utiliza a SolanaVM?

Eclipse é uma blockchain Camada 2 Ethereum que utiliza a SolanaVM como o seu ambiente de execução, enquanto liquida transações na Ethereum. Eclipse processa transações utilizando o motor de execução paralela Sealevel da SolanaVM, atingindo uma taxa de transferência ao nível da Solana. A quitação e a disponibilidade de dados são tratadas pela Ethereum, herdando o seu modelo de segurança. Eclipse demonstra que a SolanaVM pode funcionar como um padrão de execução portátil para além da rede Solana.

O que são programas Solana?

Programas Solana é o termo oficial da SolanaVM para contratos inteligentes: código autoexecutável na blockchain que a SolanaVM processa quando invocado por uma transação. Ao contrário dos contratos inteligentes EVM, que armazenam a lógica e o estado dentro do mesmo objeto de contrato, os programas Solana são stateless. A lógica do programa reside numa conta de programa; os dados com os quais opera residem em contas de dados separadas. Este design stateless permite que o motor de execução paralela da SolanaVM execute com segurança múltiplos programas simultaneamente.

O que são unidades de computação na Solana?

Unidades de computação (CU) são o equivalente na SolanaVM ao gas da Ethereum: a unidade que mede os recursos computacionais consumidos pela execução de um programa Solana. Cada transação SolanaVM opera dentro de um orçamento de CU limitado a 1,4 milhões de CU por transação (Fonte: documentação Solana Foundation, docs.solana.com, a partir do Q1 2025). Programas que excedam o seu orçamento de CU são abortados. As taxas de transação na Solana são pagas em SOL, parcialmente determinadas pelo consumo de CU, com um mercado de taxas de prioridade para períodos de alta demanda.

A SolanaVM está a tornar-se um novo padrão de blockchain?

A fonte identifica a adoção precoce da SVM para além da Solana, incluindo Eclipse e outros projetos anunciados. As implementações e atividade atuais devem ser verificadas. Se a tecnologia SVM se tornará amplamente padronizada permanece incerto e não deve ser apresentado como uma previsão.

Leitura Relacionada

• Arquitetura Solana
• A Solana é compatível com EVM?
• Padrões de Tokens Solana