Desenvolvimento Solana para devs EVM

Quando estamos iniciando nossos estudos para virar dev de alguma área é natural termos de priorizar algumas tecnologias em detrimento de outras para garantir foco e consequentemente produtividade. Mais tarde, podemos ir adicionando novas tecnologias conforme interesses próprios e demandas do mercado e com web3/blockchain não é diferente. Em um cenário onde temos diversas redes diferentes, linguagens, frameworks, etc é natural que tenhamos de fazer uma escolha inicial e é ainda mais natural que essa escolha seja pelas redes compatíveis com EVM, ou seja, o protocolo da Ethereum. Esse protocolo representa quase 80% das blockchains do mercado, que juntas 56% dos projetos que foram desenvolvidos ao longo de 2025, segundo a Electric Capital, o que lhe garante acesso a imensa maioria das vagas e projetos, além do volume de usuários, é claro.

Depois de aprender uma base sólida do protocolo Ethereum, o segundo maior padrão para desenvolvimento de smart contracts é o da Solana. No entanto, a programação para Solana é bem diferente do que para EVM e o máximo que podemos fazer é traçar alguns paralelos para ajudar você a se achar nesse novo universo de coisas para estudar. Este post é sobre isso, para te ajudar com associações do que é cada coisa no ecossistema Solana, traçando paralelos com o ecossistema EVM. Além é claro, de te fornecer recursos para estudo.

Importate salientar que aqui o comparativo não tem nada a ver com dizer ou sugerir qual a melhor rede, até porque estamos estudando padrões e não implementações em si a escolha da blockchain certa depende de muitos fatores, como já citei aqui antes.

Se preferir, você pode assistir ao vídeo abaixo ao invés de ler, o conteúdo é o mesmo.

Vamos lá!

Diferenças de Arquitetura

Vamos começar pelos fundamentos?

A moeda padrão da Ethereum é o ETH, enquanto que na Solana temos o SOL. Cada ETH é dividido em 18 casas decimais, que chamamos de wei, enquanto que a SOL possui 9 casas decimais que chamamos de lamports.

Essas moedas são utilizadas para pagamento das taxas de transação nas operações com smart contracts que rodam na EVM, que na Solana chamamos apenas de programs/programas, que rodam na SVM. Essas taxas são calculadas em gás na EVM e Computer Units (CUs) na SVM, mas é aqui que começam as principais diferenças pois na Solana não temos diferença entre leituras e escritas quanto o assunto é execução de programas: todos pagam.

Isso porque existe uma diferença arquitetural importantíssima entre smart contracts EVM e programas SVM: execution code e storage ficam separados neste segundo. Enquanto os smart contracts guardam dados e código juntos, nos Solana programs você tem o conceito de accounts, que são espaços de armazenamento, similares aos storage slots da EVM, que podem ser:

• carteiras com chave pública e privada (pode assinar e pagar transações);
• código executável (pode escrever dados, controla accounts de dados);
• dados de algum programa (“passivos”);

Mas nunca as três coisas juntas. Qualquer leitura a dados de algum programa Solana é gratuito (chamado fetch) assim como na Ethereum (onde chama-se call), mas qualquer chamada a código executável é tratada como algo que consome Computer Units e por isso é cobrado, mesmo que seja um processamento somente de leitura. Essa foi uma dentre várias alterações que os desenvolvedores da Solana criaram para que a rede fosse mais sustentável no longo prazo, um desafio constante para a Ethereum.

Nessa mesma linha, outra alternativa para resolver um problema antigo da Ethereum é o Rent. Rent é uma taxa cobrada no deploy de um programa e é calculada pegando o custo de armazenamento do mesmo e multiplicado por um aluguel de 2 anos. Ao pagar adiantado um aluguel de 2 anos para aquele programa ele se torna Rent-Exempt, ou seja, nunca mais pagará aluguel enquanto existir na rede. Esta é uma taxa inexistente na Ethereum que cobra apenas a transação de deploy mesmo e nada mais, o que acaba sendo teoricamente mais barato mas ao mesmo tempo um problema para a rede que cresce rapidamente e torna cada vez mais difícil a sua existência.

Ainda falando de coisas para diminuir o tamanho da rede, se na Ethereum nós temos as bibliotecas de contrato e padrões ERC, na Solana nós vamos além com os programas reutilizáveis. Como o código-executável é separado dos dados, existem muitos programas na Solana que podem ser usados por você, com os seus dados, evitando ter de subir códigos repetidos na rede, evitando seu inchaço por repetição;

Outras diferenças fundamentais de programas Solana para smart contracts é que muita coisa que mais tarde acabou se tornando comum no desenvolvimento para Ethereum já existe por padrão no desenvolvimento para Solana, por exemplo:

• Ownable x Authority: o padrão para “administrador” de contrato é nativo na Solana, bem como a possibilidade dele ser renunciado em favor de dar mais segurança à comunidade;
• Transparent Proxy x Upgrade: programas Solana são atualizáveis por padrão, pela carteira authority do mesmo e desde que não tenha sido renunciado. E isso sem risco de perder qualquer dado já que eles ficam em accounts separadas como já citei antes;
• Storage Contracts x Program Derived Addresses (PDA): não é incomum termos smart contracts apenas para guardar dados e outros para a lógica de execução, seja em padrões como Transparent Proxy ou Adapter, algo que obviamente na Solana não é necessário dada a sua arquitetura, mas ela vai além com os PDAs. PDAs são endereços de accounts “burras”, apenas para guardar dados e que ficam sob controle do programa que as gerou;

Acredito que estas sejam as diferenças mais fundamentais, ligadas à arquitetura e aspectos gerais da Solana em relação à Ethereum, mas abaixo vamos entrar em alguns detalhes de programação que são importantes também.

Diferenças de Programação

Primeiro, vamos tirar o elefante branco da sala: Solidity x Rust. Enquanto que a Ethereum optou por desenvolver uma linguagem própria para sua blockchain, que você nunca ouvirá falar exceto se for desenvolver para ela, em Solana optou-se por usar uma linguagem de programação de mercado, Rust, que talvez você possa conhecer ou usar em outros tipos de aplicações, principalmente as de baixo nível já que Rust compete muito com C e C++ neste mercado.

Essa diferença crucial impacta diretamente na forma como você vai escrever os programas para blockchain, por exemplo, na escolha dos tipos de dados. Do ponto de vista de primitivas nós temos praticamente as mesmas opções, tais como:

• int32 no Solidity e i32 no Rust (além de suas variações para inteiros com sinal);
• uint32 no Solidity e u32 no Rust (além de suas variações para inteiros sem sinal);
• address x Pubkey;
• bools são iguais, até mesmo no consumo de armazenamento (1 byte cada);
• strings são iguais em ambos;
• tipos de ponto flutuante são desencorajados em ambos (fixed x f32);
• structs também são iguais, com a diferença que na Solana elas ficam nas accounts e não nos programas;

Mas é nas estruturas de dados mais tradicionais onde a forma de programar para Ethereum x Solana volta a se distanciar enormemente. Nos smart contracts Solidity temos o controle dos storage slots com os dados daquele contrato que podem crescer quase indefinidamente, permitindo arrays virtualmente infinitos, mappings, etc. Claro que isso tem seu custo em performance e, dependendo do algoritmo, até mesmo em taxas, mas o fato é que você pode criar um smart contract e ir cadastrando livros dentro de um mesmo array e tá tudo certo. Já em Solana não é bem assim…

Embora em Solana você possa optar por um array tradicional, de tamanho fixo, ou um Vec que permite alocação dinâmica, o tamanho de uma account, ou seja: onde vão ser escritos os dados dos programas, tem de ser planejado antecipadamente, como em toda linguagem de baixo nível. Então se você quer criar um array de 50 números de 32-bit, ok, calcula aí 50 x 32 + 32 para guardar o length do array e tá tudo certo. Mesmo que você não saia logo de cara usando as 50 posições, o espaço foi alocado e o rent pago no deploy do programa. Mas e se você precisar mais? Ou nem saiba qual vai ser o tamanho total? Ou você precisar de tanto espaço que seja inviável pagar o rent no deploy? Em todos os casos a resposta para isso são os PDAs, que já citei antes.

Sempre que você precisar de armazenamento virtualmente ilimitado, ou apenas estruturar seus dados de maneira que seja fácil achá-los mesmo estando em accounts diferentes, você vai gerar novas accounts com seu programa usando endereços derivados (Program-Derived Addresses). Esse mecanismo garante que somente o seu programa possa mexer nessas accounts e que seja fácil achar elas na blockchain usando um gerador de endereços determinístico que usa seeds que você define no programa.

Eu sei, isso tem mais a ver com as diferenças fundamentais do que com a linguagem de programação, já que não é algo do Rust mas da Solana. Mas como isso impacta diretamente a forma como você estrutura os dados da sua aplicação, vale entrar aqui. Assim, se você quer um array de vários números, não importa quantos, pode ir criando uma account para cada um deles, todas sob controle do seu programa (como se fosse os storage slots) definindo que o gerador de endereços use o padrão: program id + “number” + index autoincremental, por exemplo.

Outra diferença que está mais para equivalência, pelo menos na ideia, são os Function Modifiers do Solidity vs as Constraint Macros do Rust. Enquanto no primeiro você cria funções para validar outras funções, como require, revert, etc; no segundo o Rust usa muito do conceito de macros, sejam attribute macros, constraint macros e outras. Macros são códigos que executam antes do código principal, alguns deles até mesmo em etapas de pré-compilação, garantindo diversos aspectos do programa e consequentemente a sua segurança.

Por exemplo, se você quer que somente o dono de um dado possa alterar ele, em Solidity você poderia escrever um require para comparar endereços e aceitar ou não a transação, certo? Em Rust você faz o mesmo, mas com constraint macros dizendo que quem assinar a transação deve ter a mesma Pubkey que quem é o dono da account que vai ser modificada. É a mesma coisa, mas com menos código no caso do Rust e essa é justamente a ideia das macros: mais segurança com menos código.

Eu poderia escrever muito mais sobre este assunto, mas acho que cobri os principais pontos.

Ferramentas Equivalentes

Agora vamos fazer um apanhado de ferramentas, toolkits, frameworks e até mesmo alguns conceitos equivalentes em ambos, para fechar este artigo com chave de ouro, ajudando você a entender o que deve estudar.

Toolkit

Enquanto no mundo EVM nós trabalhamos com HardHat ou Foundry, no mundo SVM quem manda absoluto é o Anchor. A própria documentação oficial da Solana estimula seu uso ao invés do Rust “puro”, já que ele acelera muito o desenvolvimento e diminui a quantidade de código a ser escrito. Anchor fornece testes em TypeScript, macros utilitárias, um CLI e uma estrutura padronizada para codificar suas aplicações no VS Code.

Ambiente de Desenvolvimento

Eu mencionei antes o VS Code, muito usado com Anchor, certo? Pois é, ele de fato é muito usado em projetos profissionais, mas querendo algo mais simples, enquanto na Ethereum temos o Remix, na Solana temos o Playground, que cumpre o mesmo papel.

Ainda dentro do assunto “ambiente”, via de regra desenvolvedores não usam nós Ethereum localmente para desenvolver, salvo simulações como na HardHat Network ou no Foundry Anvil. No caso da Solana o simulador oficial é o Solana Surfpool, que substituiu o antigo Solana-Test-Validator.

Para interagir com esses simuladores, enquanto que no mundo Ethereum temos o HardHat Console e o Foundry Cast, na Solana usamos um CLI oficial mesmo, chamado Solana CLI mesmo.

E para carteira, o melhor equivalente à MetaMask em popularidade seria a Phantom, que na minha opinião é até mais simples, a MM acabou ficando muito complicada nos últimos anos.

Bibliotecas de “contratos”

Enquanto no mundo EVM a OpenZeppelin reina absoluta, com algumas menções honrosas como a Azuki, no mundo SVM nós temos algumas opções consolidadas e com muito mais poder de fogo já que muitos programas encontram-se deployados na blockchain e podem ser usados por qualquer um.

Quer criar um novo token na Solana? A Solana Program Library (SPL) tem um programa padrão de token pra você usar com seus dados (nome, supply, etc), já com todas as regras comuns do mercado implementados, você só configura.

Quer criar uma coleção NFT na Solana? A Metaplex é um protocolo para todo tipo de coleção e programas derivados como marketplaces, “candy machines” e muito mais. Você só configura com as suas accounts/dados.

Então embora ainda seja possível pegar o código-aberto desses projetos e fazer seu próprio deploy, como faria com a OpenZeppelin, na prática não há muita vantagem se o seu caso de uso é algo comum de mercado.

Bibliotecas Web3

Quando estiver fazendo seus dapps, é comum querer utilizar bibliotecas web3, certo? Para smart contracts Solidity nós temos algumas opções bem famosas como EthersJS, Viem e Wagmi. Já no mundo Solana nós usamos a Solana Web3.js, uma variação da antiga Web3.js que existia para Ethereum (deprecated), mas focada no mundo Solana.

Independente da escolha, as bibliotecas web3 precisam das especificações do contrato/programa com o qual vão interagir para poder fazer a comunicação fluir. Após compilar um smart contract Solidity você recebe um ABI (Application Binary Interface), justamente para fazer esse tipo de interação. Já no Rust você recebe o IDL (Interface Definition Language), que tem a mesma função, servir como especificação do programa para que aplicações terceiras possam utilizá-lo.

Exploradores e Faucets

E por fim, outra ferramenta muito usada no dia a dia pelos devs são os exploradores de blocos e endereços. No mundo EVM os mais famosos são os criados pela empresa EtherScan, enquanto que no mundo Solana usa-se o oficial Solana Explorer.

Querendo verificar contratos? Você pode usar o HardHat Verify ou o Foundry Forge, enquanto que no mundo Solana é o Solana Verify que você vai usar.

E precisando de fundos para seus deploys e testes, os faucets oficiais podem ou não existir conforme cada rede, já na Solana como é uma única, existe o faucet oficial.

Então é isso, acredito que eu tenha abordado os principais elementos diferentes e equivalentes na programação para os dois maiores padrões do mercado blockchain. A ideia é que eu vá incrementando este artigo com o passar do tempo, conforme for pegando mais experiência com Solana, mas espero que ele o ajude desde já.

Até a próxima!