DEV Community: Edu

Solidity vs. Rust: o que aprendi construindo nos dois, não lendo sobre os dois

Edu — Sun, 19 Jul 2026 23:43:09 +0000

Todo conteúdo sobre “qual linguagem escolher pra Web3” que eu encontro é escrito por quem nunca fez deploy de nada. Compara sintaxe, compara popularidade no GitHub, compara vaga no LinkedIn. Útil até certo ponto, mas é comparação de fora.

Eu tive a oportunidade (ou o azar, dependendo do dia) de construir contratos reais nas duas:

CryptoMarket, um marketplace de NFTs em Solidity, e Stellar Charge EV, um protocolo de pagamento pra recarga de veículos elétricos em Rust, sobre Soroban (Stellar), feito pro hackathon Stellar 37° · NearX.

Este artigo é o que aprendi tendo as mãos sujas nas duas, não lendo comparação de blog.

O ponto de partida: dois problemas diferentes:

O CryptoMarket nasceu de um exercício que chamei de** “Cliente Imaginário”**: simular um pedido real de negócio e resolver com o rigor que teria num projeto de verdade. O pedido: “preciso conseguir pausar meu contrato em caso de bug, sem precisar fazer novo deploy”.

Solidity, com Foundry, resolveu isso rápido, com um padrão de projeto que qualquer dev que já mexeu com Ethereum reconhece de cara.

O Stellar Charge EV nasceu de um problema mais amplo: um protocolo completo de pagamento por sessão de recarga, integrando smart contract com um simulador OCPP 1.6J (o protocolo real que carregadores elétricos usam), backend, frontend, tudo em produção, sob prazo de hackathon.

Rust entrou porque Soroban, a plataforma de contratos da Stellar, usa Rust como linguagem nativa.

Dois problemas de tamanho e natureza diferentes, o que já é a primeira lição: a pergunta “qual linguagem é melhor” está incompleta.

A pergunta certa é “qual problema, em qual rede”.
Solidity: produtivo rápido, e isso tem preço
Escrever o contrato de manutenção em Solidity foi direto.

A sintaxe lembra JavaScript o suficiente pra não assustar quem já programa web, e o ecossistema em volta (Foundry pros testes, OpenZeppelin pros padrões prontos de segurança) resolve boa parte do trabalho pesado antes de você escrever a primeira linha de lógica de negócio.

O preço dessa produtividade aparece depois: Solidity dá liberdade demais em pontos onde liberdade demais é perigosa. Nada no compilador te impede, por padrão, de escrever um contrato vulnerável a reentrância, por exemplo, a não ser que você conheça o padrão de proteção e aplique manualmente (ou use a biblioteca certa pra isso). A linguagem confia no desenvolvedor.

Em contratos que guardam dinheiro de verdade, essa confiança tem custado caro pro setor inteiro, e não é conversa hipotética, é histórico documentado de exploits.
Rust: o compilador briga com você antes do mundo brigar
Construir o Stellar Charge EV foi outra experiência inteiramente.

Rust tem uma característica que, de início, é frustrante: o compilador não deixa o código rodar se tiver determinadas classes inteiras de erro, principalmente em torno de como a memória é gerenciada (o famoso borrow checker). Isso trava muita gente que vem de linguagem mais permissiva.

Mas depois de algumas semanas brigando com o compilador (literalmente: passei por incompatibilidade de toolchain, ajuste de otimização de wasm pra rodar na testnet, entre outros perrengues documentados no repositório do projeto), percebi o que estava acontecendo:

Rust me forçava a resolver, em tempo de compilação, problemas que em Solidity eu só descobriria em produção, ou pior, só descobriria quando alguém explorasse a falha. É desconfortável no dia, é proteção no longo prazo.

A resposta que eu daria hoje pra “qual escolher”
Não existe resposta universal, mas existe pergunta que ajuda a decidir:

Vai construir em Ethereum ou rede compatível com EVM?

Solidity não é opção, é requisito. O ecossistema, as ferramentas, a documentação, tudo gira em torno dele ali.

Vai construir em Solana, Stellar, Near? Rust entra em cena, e a dificuldade inicial compensa em segurança e em portabilidade, já que Rust serve pra muito mais coisa fora de Web3 também.
Prioridade é velocidade de lançamento, mercado maior de referência?

Solidity ainda ganha em volume de tutorial, biblioteca pronta e gente pra tirar dúvida.
Prioridade é diferenciação num mercado menos disputado, e você tem paciência pra curva de aprendizado mais dura?

Rust filtra concorrência só pela dificuldade de entrada, o que, ironicamente, vira vantagem pra quem persiste.

Links dos dois projetos, pra quem quiser ver o código

CryptoMarket (Solidity): github.com/Eduprogrammer/solidity-maintenance-mode

Stellar Charge EV (Rust/Soroban): github.com/Eduprogrammer/Stellar-Charge-EV

Se esse tipo de comparação prática te interessa
Estou escrevendo sobre isso com mais profundidade em formato de livro. Já saíram dois títulos, Entenda a Web3 (os fundamentos da tecnologia, sem jargão)

(https://www.amazon.com/author/entendaweb3))

e Migre para a Web3 (o mapa prático de carreira pra quem quer entrar no setor), ambos na Amazon.

Um terceiro, mais técnico, sobre construir de fato (linguagem, ambiente, primeiro contrato do zero), está a caminho, e vai usar esses dois projetos como estudo de caso real, não exemplo inventado.

Da Série Cliente Imaginário #1: Como resolvi o pedido "preciso pausar meu contrato sem novo deploy" usando Solidity + Foundry

Edu — Tue, 07 Jul 2026 14:59:23 +0000

Modo Manutenção em Solidity com Foundry

Ainda não tenho clientes reais em Web3. Mas ao invés de só fazer tutoriais soltos, decidi simular pedidos reais de clientes e resolvê-los como se fossem projetos de verdade do entendimento da dor até o deploy funcionando. Esse é o primeiro caso da série.

O pedido do Cliente (imaginário)

Imagine o seguinte cenário: CryptoMarket, um marketplace de NFTs, já está em produção com usuários reais. O dono me procura com uma dor bem específica:

"Se um bug aparecer no meio da noite, eu preciso conseguir travar as transações imediatamente, sem depender de ninguém, sem precisar rodar um novo deploy. E quando eu resolver, preciso poder destravar do mesmo jeito."

Duas alternativas ruins que ele tinha antes de me procurar:

Deixar o contrato ativo mesmo sabendo do risco
Fazer um novo deploy do zero (caro, quebra o endereço já divulgado, perde histórico)

O que eu vou construir

Um mecanismo de Modo Manutenção: um interruptor on-chain que só o dono do contrato pode ligar ou desligar, bloqueando funções críticas enquanto estiver ativo e permitindo que qualquer pessoa consulte o status a qualquer momento (transparência).

Arquitetura antes do código

Função	Quem pode chamar	O que faz
`toggleMaintenance()`	Só o owner	Liga/desliga o modo manutenção
`isUnderMaintenance()`	Qualquer um	Consulta o status atual
`buyNFT()` (exemplo)	Usuários	Só executa se não estiver em manutenção

O contrato

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract CryptoMarket {

    address public owner;
    bool public maintenanceMode;

    event MaintenanceToggled(bool novoStatus);

    constructor() {
        owner = msg.sender;
        maintenanceMode = false;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Apenas o owner pode fazer isso");
        _;
    }

    modifier notInMaintenance() {
        require(!maintenanceMode, "Contrato em manutencao no momento");
        _;
    }

    function toggleMaintenance() public onlyOwner {
        maintenanceMode = !maintenanceMode;
        emit MaintenanceToggled(maintenanceMode);
    }

    function isUnderMaintenance() public view returns (bool) {
        return maintenanceMode;
    }

    function buyNFT() public notInMaintenance {
    }
}

Testando com Foundry

Escrevi 8 testes cobrindo os cenários principais: deploy correto, estado inicial, toggle nos dois sentidos, bloqueio de acesso pra quem não é owner, bloqueio do buyNFT() durante manutenção, e emissão do evento.

forge test -vvv

Todos os 8 testes passaram (8 passed; 0 failed; 0 skipped).

Deploy local com Anvil

Subi uma blockchain local simulada:

anvil

E fiz o deploy do contrato usando a primeira conta pré-financiada como owner:

forge create src/CryptoMarket.sol:CryptoMarket \
  --rpc-url http://127.0.0.1:8545 \
  --private-key <CHAVE_PRIVADA> \
  --broadcast

Deploy feito com sucesso 🎉

Deployer (owner): 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266
Endereço do contrato: 0x5FbDB2315678afecb367f032d93F642f64180aa3

Interagindo com o contrato via Cast

Com o contrato no ar, testei o fluxo completo na prática não só nos testes, mas em uma blockchain local de verdade.

1. Consultar o status (leitura, sem gastar gas)

cast call 0x5FbDB2315678afecb367f032d93F642f64180aa3 "isUnderMaintenance()(bool)" --rpc-url http://127.0.0.1:8545

Retornou false — o contrato nasce operacional, como esperado.

2. Ativar o modo manutenção (escrita, precisa da chave do owner)

cast send 0x5FbDB2315678afecb367f032d93F642f64180aa3 "toggleMaintenance()" \
  --rpc-url http://127.0.0.1:8545 \
  --private-key <CHAVE_PRIVADA_DO_OWNER>

Transação minerada com status: 1 (success). Repare no campo logs: ali está o evento MaintenanceToggled sendo emitido on-chain — prova de auditoria, gravada permanentemente na blockchain.

3. Confirmar que mudou

cast call 0x5FbDB2315678afecb367f032d93F642f64180aa3 "isUnderMaintenance()(bool)" --rpc-url http://127.0.0.1:8545

Agora retorna true.

4. Testar o bloqueio

Tentei chamar buyNFT() enquanto o contrato está em manutenção:

cast send 0x5FbDB2315678afecb367f032d93F642f64180aa3 "buyNFT()" \
  --rpc-url http://127.0.0.1:8545 \
  --private-key <CHAVE_PRIVADA_DO_OWNER>

Error: execution reverted: Contrato em manutencao no momento

Exatamente o comportamento esperado: o modifier notInMaintenance bloqueou a função de negócio.

5. Voltar o status para operacional (false)

cast send 0x5FbDB2315678afecb367f032d93F642f64180aa3 "toggleMaintenance()" \
  --rpc-url http://127.0.0.1:8545 \
  --private-key <CHAVE_PRIVADA_DO_OWNER>

6. Confirmar que voltou

cast call 0x5FbDB2315678afecb367f032d93F642f64180aa3 "isUnderMaintenance()(bool)" --rpc-url http://127.0.0.1:8545

Retornou false novamente.

7. Testar buyNFT() com o contrato liberado

cast send 0x5FbDB2315678afecb367f032d93F642f64180aa3 "buyNFT()" \
  --rpc-url http://127.0.0.1:8545 \
  --private-key <CHAVE_PRIVADA_DO_OWNER>

status: 1 (success) sem nenhum erro. O contrato voltou a funcionar normalmente assim que a manutenção foi desativada.

O que essa simulação prova

Estado	`buyNFT()`
Em manutenção (`true`)	❌ Reverte com "Contrato em manutencao no momento"
Operacional (`false`)	✅ Executa normalmente

O ciclo completo — construção, teste, deploy e interação real — funcionou do início ao fim, exatamente como o cliente (imaginário) precisava.

Por que documentar assim

Não tenho clientes reais em Web3 ainda. Mas resolver problemas simulados com o mesmo rigor que teria com um cliente de verdade entender a dor antes de codar, testar com cobertura real, validar em ambiente local antes de qualquer coisa em produção é como estou construindo prática e portfólio ao mesmo tempo.

Código completo no GitHub: https://github.com/Eduprogrammer/solidity-maintenance-mode

Meu Linkedin: https://www.linkedin.com/in/educarlos29/

Se você é dev e tem uma dor parecida com essa (ou outra ideia de "cliente imaginário" pra próxima simulação), comenta aí 👇

#solidity #foundry #web3 #blockchain #smartcontracts #developer