SolanaVM Explicada: Máquina Virtual Solana

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

SolanaVM (também referida como Solana Virtual Machine ou SVM) é o ambiente de execução da blockchain Solana: a camada de software que processa e executa programas on-chain. Ela 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 central integrado ao protocolo Solana.

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

Conteúdo: Como a SolanaVM Funciona | SolanaVM vs. EVM | Construindo na SolanaVM | Adoção Multi-Chain | Como a Adoção da SolanaVM Está Desenvolvendo | FAQ

Uma blockchain é um ledger distribuído que registra transações em uma rede de computadores sem depender de uma autoridade central. Blockchains modernas fazem mais do que registrar transferências de valor. Elas executam programas: software que lida com empréstimos, negociações, governança e milhares de outras funções on-chain. Para executar programas, uma blockchain precisa de um ambiente de execução, uma camada de software controlada que recebe instruções, as processa de acordo com regras definidas e escreve os resultados na blockchain. Toda blockchain de contrato inteligente precisa de um ambiente de execução. Na Solana, esse ambiente é a SolanaVM.

Solana é uma blockchain Camada 1 (L1), uma rede de base com seu próprio mecanismo de consenso e token nativo chamado SOL. SolanaVM não é o mesmo que Solana. A relação é análoga à de um motor de carro e o próprio carro: SolanaVM é o motor; 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 confusão genuína ao avaliar a arquitetura da Solana.

SolanaVM foi construída com uma filosofia de design voltada para alto desempenho, rastreada diretamente a Anatoly Yakovenko, cofundador da Solana e ex-engenheiro da Qualcomm, que identificou o overhead de ordenação de transações como o principal gargalo nos projetos de blockchain existentes.

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

SolanaVM executa programas Solana através de um pipeline de cinco estágios que roda na infraestrutura de validadores distribuídos da rede, processando transações não conflitantes em paralelo em vez de em sequência.

Na SolanaVM, contratos inteligentes são chamados de 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 na nomenclatura reflete uma distinção arquitetural real. Contratos inteligentes EVM armazenam a lógica do programa e os dados de estado dentro do mesmo objeto de contrato. Programas Solana são sem estado: o código do programa vive em uma conta on-chain, e os dados nos quais ele opera vivem em contas de dados separadas. Essa separação é o que torna a execução paralela tratável em escala.

O pipeline de execução da SolanaVM segue cinco estágios:

1. Um desenvolvedor escreve um programa Solana em Rust
2. O código Rust compila para bytecode sBPF
3. O bytecode compilado é implantado como uma conta de programa on-chain
4. Um usuário submete uma transação que invoca o programa com dados de instrução
5. Validadores Solana (os nós da rede que executam SolanaVM) executam o bytecode sBPF, consomem unidades de computação e confirmam o resultado no ledger

Validadores Solana executam SolanaVM em hardware dedicado e alcançam consenso através de dois mecanismos separados: Proof of History (PoH) para ordenação de transações, e Tower BFT, um mecanismo de consenso Proof of Stake, para validação de resultados. A rede de validadores da Solana é protegida pelo Tower BFT. Enquanto PoH ordena transações, Tower BFT determina o consenso sobre sua validade. Esses 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. PoH funciona como um relógio sincronizado que permite a todos os validadores concordarem sobre quando cada transação ocorreu sem precisar perguntar uns aos outros, eliminando um grande gargalo de coordenação. Pré-ordenando transações criptograficamente, PoH fornece à SolanaVM a base temporal necessária para processar múltiplas transações simultaneamente. PoH não é um mecanismo de consenso; é um protocolo de timestamping 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 de blockchain.

Quando um desenvolvedor escreve um programa Solana em Rust, esse código Rust não é executado diretamente na blockchain. O compilador Rust o traduz 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 o bytecode sBPF diretamente; é aqui que a computação ocorre fisicamente na rede.

sBPF é distinto do BPF original (Berkeley Packet Filter), uma tecnologia de rede usada em kernels de sistemas operacionais para filtragem de pacotes. O sBPF da Solana é um fork modificado adaptado para as restrições da execução de máquina virtual de blockchain. Sempre use "sBPF" em vez de "BPF" sozinho ao se referir ao formato de bytecode da Solana.

Para desenvolvedores vindos do ecossistema EVM, sBPF ocupa a mesma função dos 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

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

Imagine um banco onde cada caixa 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, Sealevel analisa as dependências de conta de cada transação: de quais contas esta transação lê e para quais ela escreve? Se duas transações acessam contas totalmente diferentes, elas não têm conflito e podem ser executadas simultaneamente em múltiplos núcleos de CPU. Transações que compartilham contas são enfileiradas sequencialmente para essas contas específicas, enquanto todas as transações não relacionadas continuam em paralelo.

O resultado é um teto de rendimento que escala com o hardware do validador em vez de um gargalo sequencial fixo. O rendimento máximo teórico da Solana atinge aproximadamente 65.000 transações por segundo sob condições ideais, em comparação com aproximadamente 15 a 30 TPS na Mainnet do Ethereum (Fonte: Solana Foundation, solana.com; ethereum.org, em 1º trimestre de 2025). O rendimento no mundo real sob carga é menor para ambas as redes, e as redes de Camada 2 (L2) compatíveis com EVM construídas no Ethereum alcançam um rendimento substancialmente maior do que a própria Mainnet do Ethereum.

SolanaVM vs. EVM: Como os dois ambientes de execução se comparam

A 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 compensações mensuráveis que favorecem diferentes casos de uso. Um terceiro padrão de máquina virtual, WebAssembly (WASM), é usado por redes como NEAR Protocol e Polkadot, representando uma escolha arquitetônica diferente tanto da EVM quanto da SolanaVM.

A Máquina Virtual Ethereum (EVM): O padrão estabelecido

A Máquina Virtual Ethereum (EVM), originalmente projetada por Vitalik Buterin e a equipe do Ethereum, é o ambiente de execução compartilhado entre o Ethereum e todas as redes 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 em um bloco é executada após a conclusão da anterior. Os programas são escritos em Solidity ou Vyper e compilados para opcodes da EVM. Esse modelo sequencial cria um teto de rendimento atrelado ao tempo de bloco em vez da capacidade do hardware, mas também simplifica o raciocínio do 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 redes compatíveis com EVM, incluindo Polygon, Arbitrum, Avalanche C-Chain e BNB Chain, compartilham o mesmo padrão de execução. Desenvolvedores que aprendem Solidity podem implantar em qualquer rede compatível com EVM sem reescrever seu código. Essa 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

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

Os números de TPS representam máximos teóricos sob condições ideais e variam significativamente sob carga real da rede. Redes L2 compatíveis com EVM alcançam um rendimento substancialmente maior do que a Mainnet do Ethereum. Última atualização: 1º trimestre de 2025. Fontes: Solana Foundation (solana.com), ethereum.org.

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

Programas Solana vs. Smart Contracts do Ethereum: Qual é a diferença?

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

Os programas Solana são sem estado (stateless). A lógica do programa reside em uma conta on-chain; os dados sobre os quais o programa opera residem em contas de dados separadas que o programa lê e grava. Um contrato inteligente da EVM, por outro lado, agrupa lógica e estado em um único objeto de contrato. O contrato possui seu próprio armazenamento. Essa 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 antecipadamente, fornecendo ao mecanismo de execução as informações necessárias para agendar a execução paralela com segurança.

A SolanaVM não é compatível com a EVM. A fonte cita a Neon EVM como um ambiente EVM de terceiros separado associado à Solana. Ela não torna a própria SVM compatível, e sua arquitetura atual, status de implantação, suporte a ferramentas e limitações devem ser avaliados de forma independente.

Desenvolvendo na SolanaVM: Linguagens, Ferramentas e Primeiros Passos

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

O Rust reforça a segurança da memória no momento da compilação por meio de um modelo de propriedade que elimina classes inteiras de bugs: desreferências de ponteiro nulo, corridas de dados e transbordamentos de buffer (buffer overflows), tudo sem depender de um coletor de lixo. Essas propriedades se alinham aos requisitos de segurança e desempenho da execução em blockchain (on-chain), onde os bugs não podem ser corrigidos após a implantação e os custos de execução importam no nível da instrução. C e C++ também são tecnicamente suportados pela SolanaVM, mas o Rust é o padrão de fato em todo o ecossistema de desenvolvedores Solana.

O Framework Anchor para desenvolvimento na Solana abstrai grande parte da complexidade de baixo nível do Rust e do sBPF, funcionando de forma análoga ao Hardhat ou Foundry no ecossistema EVM. O Anchor fornece validação de conta estruturada, tratamento de erros e definições de interface de programa, reduzindo significativamente o código clichê (boilerplate) necessário para escrever um programa Solana correto. Observe que o Framework Anchor para Solana não tem relação com o Anchor Protocol, o protocolo de empréstimo da Terra/Luna DeFi que colapsou em 2022.

A arquitetura de execução paralela da SolanaVM a torna particularmente adequada para aplicações DeFi que exigem alto rendimento: livros de ordens on-chain, mecanismos de liquidação e programas de otimização de rendimento que exigem baixa latência e alta densidade de transações. Os principais protocolos DeFi nativos da SolanaVM incluem Raydium (Market Maker automatizado), Jupiter (agregador DEX) e Kamino (otimização de rendimento). O SOL pode ser adquirido em grandes exchanges de criptomoedas e usado para pagar por unidades de computação ao interagir com programas da SolanaVM.

Para um guia de início rápido completo para desenvolvedores, visite a documentação oficial do desenvolvedor Solana.

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

Unidades de computação (CU) são o equivalente da SolanaVM ao gas do Ethereum: a unidade que mede os recursos computacionais consumidos por uma execução de programa na Solana.

Cada transação na SolanaVM opera dentro de um orçamento de unidades de computação. O máximo atual é de 1,4 milhão de CU por transação, conforme especificado na documentação da Solana Foundation (Fonte: docs.solana.com, em 1º trimestre de 2025). Um programa que excede seu orçamento de CU no 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 o potencial de investimento (savings) em taxas, enquanto solicitar a menos causa falhas evitáveis.

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

É Possível Portar Contratos EVM para SolanaVM?

A portabilidade direta de contratos EVM para SolanaVM não é possível sem reescrita. Os programas Solana exigem Rust e bytecode sBPF, não Solidity e opcodes EVM. Os modelos de execução são arquiteturalmente diferentes o suficiente para que uma tradução linha por linha não exista.

Contratos EVM e programas Solana usam modelos de estado e conta diferentes, portanto, uma migração nativa geralmente requer alterações arquiteturais. Um ambiente EVM separado pode preservar partes de um fluxo de trabalho Solidity, enquanto o desenvolvimento nativo SVM usa diferentes toolchains. Compare compatibilidade, desempenho, auditorias, dependências operacionais e suporte atual em vez de tratar qualquer caminho como padrão.

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

SolanaVM opera além da mainnet da Solana, com projetos de Camada 2 implantando-a como um ambiente de execução independente em outras blockchains de base.

Embora SolanaVM tenha sido projetada como um ambiente de execução de Camada 1, sua adoção por projetos de Camada 2 marca uma evolução arquitetural significativa. A tese de portabilidade, de que SolanaVM pode funcionar como um padrão de execução compartilhado entre várias cadeias, assim como o EVM faz, está passando da teoria para a produção.

A tabela a seguir lista as cadeias SVM atuais por tipo e status:

Última atualização: T1 2025. Verifique o status atual do projeto antes de republicar. Fontes: eclipse.xyz, documentação da Solana Foundation. Projetos adicionais de rollup SVM estão em desenvolvimento; esta tabela requer atualizações periódicas conforme o ecossistema evolui.

Em todas as cadeias SVM, aplicações DeFi, particularmente DEXs, protocolos de empréstimo e programas de otimização de rendimento, representam o caso de uso principal para as capacidades de execução paralela da SolanaVM. 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 interligando os dois maiores ecossistemas de Smart Contract.

Eclipse: SolanaVM como uma Camada 2 do Ethereum

A fonte cita Eclipse como um exemplo de tecnologia SVM usada fora da Solana. Sua arquitetura atual, modelo de quitação, disponibilidade de dados, suposições de segurança e desempenho medido devem ser verificados em 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. SolanaVM lida com a execução: recebe transações, processa programas Solana em paralelo usando Sealevel e produz saídas de estado em alta velocidade. Ethereum lida com a quitação: Eclipse posta dados de transação de volta ao Ethereum, herdando seu modelo de segurança e finalidade. Eclipse desacopla a velocidade de execução do modelo de segurança da cadeia base, acessando ambos independentemente.

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

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

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

Um rollup SVM (uma solução de Camada 2 alimentada por SolanaVM) é uma blockchain que usa SolanaVM como seu ambiente de execução, enquanto posta dados de transação em uma cadeia de 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. Em vez de exigir uma nova cadeia independente, um rollup SVM pode se conectar 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 se torna acessível em todo o ecossistema blockchain mais amplo, em vez de ser exclusivo da rede da própria Solana.

A implantação principal da Eclipse representa a arquitetura de rollup SVM mais avançada atualmente em produção. Projetos adicionais de rollup SVM estão em desenvolvimento, embora seus status mudem com frequência. Se a adoção de rollup SVM continuar em sua trajetória atual, a presença multi-chain da SolanaVM poderá se aproximar da amplitude da adoção EVM, embora o tamanho do ecossistema de desenvolvedores permaneça a variável chave de diferenciação.

Esta seção cobre desenvolvimentos futuros do ecossistema. Os status dos projetos requerem verificação periódica. Última atualização: T1 2025.

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

SolanaVM está mostrando sinais iniciais de adoção multi-chain, com projetos como Eclipse implantando-a como uma camada de execução fora da rede Solana. Se SolanaVM alcançará a padronização multi-chain semelhante à EVM depende das taxas de adoção de desenvolvedores, maturidade das ferramentas e sucesso dos projetos de rollup SVM.

A evidência do alcance crescente da SolanaVM é concreta. Eclipse opera uma mainnet ativa usando SolanaVM como seu ambiente de execução no Ethereum. Projetos de rollup SVM estão passando de anunciados para ativos. O Anchor Framework amadureceu a ponto de o desenvolvimento SolanaVM ser substancialmente mais acessível do que era há dois anos. Protocolos DeFi na Solana (Raydium, Jupiter, Kamino) demonstram que a arquitetura de execução paralela da SolanaVM gera atividade econômica real, não apenas números teóricos de throughput.

Os obstáculos são igualmente concretos. O EVM tem uma vantagem de uma década em adoção de desenvolvedores, maturidade de ferramentas e implantação multi-chain. Um desenvolvedor que conhece Solidity pode implantar em mais de 100 cadeias hoje; um desenvolvedor que conhece Rust e o Anchor Framework pode implantar na mainnet da Solana e na Eclipse, com mais cadeias SVM chegando gradualmente. O efeito de rede do EVM representa um verdadeiro fosso competitivo, não uma responsabilidade legada que SolanaVM desloca automaticamente. A arquitetura de execução paralela da SolanaVM oferece vantagens mensuráveis para casos de uso de DeFi de alto throughput, mas a superioridade técnica em uma dimensão não se traduz automaticamente em adoção de ecossistema.

O crescimento da adoção SolanaVM na rede nativa da Solana aumenta a demanda por SOL como token de taxa para pagamentos de unidades de computação. Cadeias SVM que liquidam em outras redes (como Eclipse liquidando no Ethereum) podem usar estruturas de taxa diferentes; a relação de demanda por SOL varia pela arquitetura da cadeia.

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

A trajetória da adoção SolanaVM através da mainnet Solana, Eclipse e futuros rollups SVM será determinada tanto pelo crescimento da comunidade de desenvolvedores quanto pelo mérito arquitetural. O caso arquitetural para SolanaVM está bem estabelecido. O caso do ecossistema ainda está sendo construído.

Explore SOL em Bybit

Os leitores podem revisar informações atuais do mercado de SOL) ou o mercado spot SOL/USDT.). Esses links fornecem acesso ao mercado e não provam que a Solana, uma carteira ou um protocolo de terceiros é adequado para todos os leitores.

Perguntas Frequentes: SolanaVM Explicada

O que é 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 programas da Solana e confirma seus resultados na rede. A SolanaVM não é um token ou produto separado; é um componente arquitetural central da Solana. Em contextos de blockchain, SVM significa Solana Virtual Machine, não Support Vector Machine.

Como a SolanaVM difere da EVM?

A SolanaVM e a Máquina Virtual Ethereum (EVM) diferem em três dimensões arquiteturais primárias. Primeiro, a SolanaVM processa transações não conflitantes em paralelo usando 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 usa gas. A EVM possui um ecossistema multichain substancialmente maior.

Qual linguagem de programação é usada para a SolanaVM?

Os programas da Solana são escritos principalmente em Rust, uma linguagem de programação de sistemas valorizada por suas garantias de segurança de memória e desempenho. O código Rust é compilado para bytecode sBPF antes da implantação on-chain. O Anchor Framework para Solana simplifica o desenvolvimento em Rust ao lidar com a validação de contas e estrutura de programas repetitivas. C e C++ também são tecnicamente suportados, mas o Rust é o padrão de fato.

A SolanaVM é mais rápida que a EVM?

A capacidade máxima teórica da SolanaVM atinge aproximadamente 65.000 TPS sob condições ideais; a Mainnet da Ethereum processa aproximadamente 15 a 30 TPS sequencialmente (Fonte: Solana Foundation, ethereum.org, em 1º trimestre de 2025). A execução paralela da SolanaVM oferece uma vantagem de velocidade mensurável para cargas de trabalho de transações não conflitantes. Cadeias de Camada 2 compatíveis com EVM, como Arbitrum e Optimism, alcançam números de processamento que reduzem significativamente essa lacuna 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 execução de programas em blockchain. Quando um desenvolvedor escreve um programa Solana em Rust, o compilador Rust o traduz em bytecode sBPF antes da implantação. Os validadores então executam esse bytecode sBPF diretamente. O sBPF é distinto da tecnologia original de rede BPF usada em kernels de sistemas operacionais.

É possível executar contratos EVM na SolanaVM?

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

O que é a blockchain Eclipse e como ela usa a SolanaVM?

A Eclipse é uma blockchain de Camada 2 da Ethereum que utiliza a SolanaVM como seu ambiente de execução enquanto realiza a quitação das transações na Ethereum. A Eclipse processa transações usando o motor de execução paralela Sealevel da SolanaVM, alcançando um rendimento de nível Solana. A quitação e a disponibilidade de dados são gerenciadas pela Ethereum, herdando seu modelo de segurança. A Eclipse demonstra que a SolanaVM pode funcionar como um padrão de execução portátil 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 on-chain que a SolanaVM processa quando invocado por uma transação. Ao contrário dos contratos inteligentes da EVM, que armazenam lógica e estado dentro do mesmo objeto de contrato, os programas Solana não possuem estado (stateless). A lógica do programa reside em uma conta de programa; os dados sobre os quais ele opera residem em contas de dados separadas. Esse design stateless permite que o motor de execução paralela da SolanaVM execute simultaneamente vários programas de forma segura.

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

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

A SolanaVM está se tornando um novo padrão de blockchain?

A fonte identifica a adoção precoce da SVM além da Solana, incluindo a Eclipse e outros projetos anunciados. As implantações e atividades 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 Token da Solana