Solidity

O que é Solidity?

Solidity é uma linguagem de programação de alto nível usada para escrever contratos inteligentes executados na Ethereum e em outras redes blockchain compatíveis com a Ethereum Virtual Machine.

O site oficial do Solidity descreve Solidity como uma linguagem de programação estaticamente tipada, com chaves, projetada para desenvolver contratos inteligentes executados na Ethereum.

Um contrato inteligente é um programa armazenado em uma blockchain que pode manter ativos, aplicar regras, executar lógica e responder a transações sem precisar de um servidor tradicional.

A documentação oficial sobre contratos inteligentes da Ethereum explica que um contrato inteligente é um programa executado na blockchain Ethereum.

No mercado cripto, Solidity é usada para criar tokens, protocolos DeFi, coleções de NFT, DAOs, sistemas de staking, mercados de empréstimos, bridges, sistemas de escrow, contratos de governança e muitas outras aplicações on-chain.

O código Solidity não é executado diretamente pelos usuários.

Os desenvolvedores escrevem o código-fonte em Solidity e, em seguida, o compilam em bytecode que a Ethereum Virtual Machine consegue executar.

A documentação oficial do Solidity explica que Solidity é uma linguagem orientada a objetos e de alto nível para implementar contratos inteligentes.

Em termos simples, Solidity é a principal linguagem de programação usada por muitos desenvolvedores para criar aplicações cripto programáveis em blockchains baseadas em EVM.

Por que Solidity é importante no mercado cripto

Solidity é importante porque viabiliza muitos dos contratos inteligentes com os quais os usuários interagem em todo o ecossistema cripto.

Quando um usuário troca tokens, cria um NFT, participa de uma votação de DAO, deposita garantia, resgata recompensas ou interage com um aplicativo DeFi, um contrato inteligente em Solidity pode processar parte dessa ação.

Solidity ajudou a tornar os ativos digitais programáveis viáveis, pois permite que desenvolvedores escrevam regras reutilizáveis para propriedade, transferências, permissões, taxas, liquidez e governança.

Tokens, incluindo ativos fungíveis e NFTs, frequentemente dependem de padrões de contratos inteligentes normalmente implementados em Solidity.

O padrão de token ERC-20 define uma interface comum para tokens fungíveis em contratos inteligentes.

O padrão de token ERC-721 define uma interface comum para tokens não fungíveis.

O padrão de token ERC-1155 define um padrão multitoquen que pode oferecer suporte a ativos fungíveis e não fungíveis em um sistema de contratos.

Esses padrões são importantes porque facilitam o suporte a comportamentos comuns de tokens por carteiras, exploradores, aplicativos e protocolos.

Solidity também é importante porque erros em contratos inteligentes podem afetar fundos reais dos usuários.

Um pequeno erro no código Solidity pode causar perda de tokens, permissões corrompidas, contabilidade incorreta, atualizações malsucedidas ou lógica DeFi explorável.

Como Solidity funciona

Solidity permite que os desenvolvedores descrevam regras de contratos inteligentes em código-fonte legível por humanos.

O código é então compilado em bytecode da EVM pelo compilador Solidity, geralmente chamado de solc.

A documentação do compilador Solidity explica que o compilador pode gerar resultados como binários, dados ABI, assembly, estimativas de gas e árvores sintáticas abstratas.

Após a compilação, o bytecode de implantação é enviado em uma transação blockchain para criar uma conta de contrato.

Depois de implantado, o contrato possui um endereço que usuários e outros contratos podem chamar.

Normalmente, os usuários não chamam contratos inteligentes escrevendo bytecode bruto.

Em geral, eles interagem por carteiras, aplicativos, scripts ou interfaces que codificam chamadas de funções usando a ABI do contrato.

O contrato recebe dados da transação, executa as regras da EVM, atualiza o armazenamento se permitido, emite eventos se tiver sido programado para isso e retorna dados ou erros.

Toda ação que altera o estado exige uma transação blockchain e uma taxa paga pelo remetente da transação.

Por isso, o desenvolvimento em Solidity deve considerar tanto a correção quanto o custo de gas.

Solidity e a Ethereum Virtual Machine

A Ethereum Virtual Machine, ou EVM, é o ambiente de execução que executa o bytecode compilado de contratos inteligentes.

A introdução do Solidity aos contratos inteligentes explica que a EVM é o ambiente de execução dos contratos inteligentes da Ethereum e é isolada do sistema ao redor.

Solidity é projetada para a EVM, o que significa que seu código é compilado em instruções compreendidas pela EVM.

Esse projeto permite que os contratos inteligentes sejam executados de forma determinística em muitos nós.

Execução determinística significa que todo nó honesto deve chegar ao mesmo resultado ao processar a mesma transação sob o mesmo estado da cadeia.

Isso é essencial porque as blockchains precisam concordar sobre saldos, propriedade, armazenamento de contratos e resultados de transações.

A EVM também cria um ambiente em sandbox que limita o que os contratos podem fazer.

Um contrato Solidity não pode chamar diretamente um site aleatório, ler dados privados de um servidor ou acessar informações off-chain, exceto quando essas informações são levadas on-chain por uma transação ou sistema de oráculo.

Essa limitação melhora o determinismo, mas exige que os desenvolvedores projetem cuidadosamente soluções para necessidades de dados externos.

Assim, Solidity não é apenas uma linguagem normal de programação web, pois funciona em um modelo de execução blockchain com regras rígidas.

Solidity e contratos inteligentes

Um contrato inteligente em Solidity é um conjunto de código e armazenamento que passa a existir em um endereço blockchain após a implantação.

O código define quais funções podem ser chamadas e o que elas fazem.

O armazenamento mantém estados de longo prazo, como saldos, endereços de proprietários, valores de configuração, mapeamentos, votos, dívidas, reservas e metadados de tokens.

Um contrato pode receber transações de contas externas controladas por usuários.

Também pode chamar outros contratos, criando sistemas on-chain componíveis.

A composabilidade é um dos recursos cripto mais importantes de Solidity, pois um protocolo pode se basear na interface de contrato de outro protocolo.

Um contrato de token pode ser usado por um protocolo de empréstimos, um protocolo de swap, um contrato de staking e um sistema de governança.

Isso torna Solidity poderosa, mas também cria riscos, pois um bug em um contrato pode afetar muitas aplicações conectadas.

Os contratos inteligentes geralmente são transparentes após a verificação, mas transparência não significa segurança automaticamente.

Os usuários devem tratar cada interação com contrato como uma transação com risco técnico e financeiro.

Sintaxe do Solidity

Solidity usa chaves, declarações de funções, variáveis, tipos, structs, mappings, eventos, modificadores e padrões de herança que podem ser familiares a desenvolvedores que conhecem JavaScript, C++, Java ou linguagens semelhantes.

A documentação oficial do Solidity informa que a linguagem é influenciada por C++, Python e JavaScript.

Um arquivo Solidity geralmente começa com um identificador de licença e uma instrução pragma.

A instrução pragma indica às ferramentas quais versões do compilador são pretendidas para o arquivo-fonte.

Uma definição de contrato contém então variáveis de estado, eventos, erros, construtores, funções, modificadores e, em alguns casos, tipos aninhados.

Solidity é estaticamente tipada, o que significa que variáveis e parâmetros de funções têm tipos declarados.

Tipos comuns incluem bool, uint256, int256, address, bytes, string, arrays, structs, enums e mappings.

Os desenvolvedores devem considerar cuidadosamente armazenamento, memória, calldata, visibilidade, mutabilidade e controle de acesso.

Esses detalhes são importantes porque o código Solidity controla ativos e pode se tornar difícil de alterar após a implantação.

Uma sintaxe aparentemente simples ainda pode produzir um comportamento on-chain complexo.

Contratos

Um contrato é o principal bloco de construção em Solidity.

Um contrato pode armazenar dados, definir funções, emitir eventos, herdar de outros contratos e interagir com outros contratos.

Um contrato de token pode armazenar saldos e permissões de gasto.

Um contrato de empréstimos pode armazenar garantias, dívidas, índices de juros e configurações de liquidação.

Um contrato de governança pode armazenar propostas, votos, regras de quórum e atrasos de execução.

Um contrato de staking pode armazenar depósitos, taxas de recompensa, regras de saque e dados de resgate.

Cada contrato implantado recebe seu próprio endereço na blockchain.

Os usuários chamam esse endereço para interagir com as funções do contrato.

O código do contrato só é executado quando uma transação ou chamada o aciona.

Um contrato não é executado continuamente como um aplicativo de servidor normal.

Variáveis de estado

Variáveis de estado são variáveis armazenadas permanentemente no armazenamento do contrato.

Elas são usadas para dados que precisam continuar disponíveis entre transações.

Exemplos incluem saldos de tokens, endereços de proprietários, oferta total, configurações de taxas, reservas de protocolo, contagens de votos e posições de usuários.

O armazenamento é caro porque os nós blockchain precisam manter e verificar esses dados.

Os desenvolvedores devem evitar armazenar dados desnecessários on-chain.

Também devem projetar cuidadosamente o layout de armazenamento, especialmente em contratos atualizáveis.

Um erro de layout de armazenamento pode corromper estados importantes do contrato durante uma atualização.

Solidity pode gerar informações de layout de armazenamento pelo compilador, ajudando desenvolvedores e auditores a analisar o risco de atualizações.

Os usuários raramente veem as variáveis de estado diretamente, a menos que um contrato seja verificado ou que um explorador de blockchain exponha chamadas legíveis.

Contudo, essas variáveis frequentemente determinam como fundos e permissões dos usuários são tratados.

Funções

As funções definem as ações que um contrato Solidity pode realizar.

Uma função pode ler dados, atualizar o armazenamento, transferir tokens, chamar outro contrato, emitir um evento ou reverter quando as condições não são atendidas.

A visibilidade da função controla quem pode chamá-la e como ela pode ser acessada.

Palavras-chave comuns de visibilidade incluem public, external, internal e private.

A mutabilidade indica se uma função lê ou modifica o estado.

Palavras-chave comuns de mutabilidade incluem view, pure e payable.

Uma função view pode ler o estado sem alterá-lo.

Uma função pure não deve ler nem alterar o estado do contrato.

Uma função payable pode receber o ativo nativo da rede quando é chamada com valor.

O projeto das funções é importante porque muitas vulnerabilidades de contratos inteligentes decorrem de verificações ausentes, permissões incorretas, chamadas externas inseguras ou contabilidade errada.

Eventos

Eventos são logs emitidos por contratos Solidity durante a execução.

Eles ajudam carteiras, exploradores, indexadores e aplicativos a acompanhar o que ocorreu em uma transação.

Uma transferência de token geralmente emite um evento Transfer quando implementada segundo padrões de token comuns.

Um protocolo DeFi pode emitir eventos de depósitos, saques, empréstimos, pagamentos, liquidações, swaps, votos ou alterações de configuração.

Eventos são úteis porque são mais baratos de armazenar do que o armazenamento completo do contrato e fáceis de indexar por sistemas off-chain.

No entanto, eventos não são o mesmo que o estado do contrato.

Um contrato só pode emitir um evento quando seu código determina isso.

Aplicativos não devem confiar cegamente em logs de eventos sem compreender a lógica do contrato.

Eventos são excelentes para transparência e análises, mas devem ser interpretados junto com o código subjacente.

Para os usuários, os eventos geralmente alimentam os históricos de transações legíveis exibidos em carteiras e exploradores.

Modificadores

Modificadores são partes reutilizáveis da lógica Solidity capazes de alterar ou restringir o comportamento de funções.

Um modificador comum verifica se o chamador é proprietário, administrador, responsável pela governança ou possui uma função autorizada antes de permitir que a função seja executada.

Os modificadores podem reduzir código repetido e tornar o controle de acesso mais fácil de ler.

No entanto, também podem ocultar lógica importante quando usados em excesso ou escritos de forma pouco clara.

Uma função pode parecer simples enquanto um modificador executa verificações importantes ou alterações de estado em segundo plano.

Os desenvolvedores devem manter os modificadores claros e focados.

Auditores devem revisar os modificadores cuidadosamente, pois eles frequentemente protegem funções sensíveis.

Usuários que analisam código verificado não devem avaliar uma função apenas por seu corpo visível.

Também devem verificar modificadores herdados e condições de controle de acesso.

Um modificador ausente ou defeituoso pode criar um risco grave de segurança.

Mappings

Um mapping é uma estrutura de dados de chave-valor usada com frequência em contratos Solidity.

Saldos de tokens geralmente são armazenados em um mapping de endereço para valor.

Permissões de gasto podem ser armazenadas em um mapping aninhado de proprietário para gastador e valor.

Sistemas de governança podem usar mappings para rastrear se um endereço votou.

Sistemas de empréstimos podem usar mappings para acompanhar a garantia e a dívida de cada usuário.

Mappings são eficientes para consultar valores por chave.

Entretanto, não é fácil iterar diretamente sobre mappings on-chain.

Os desenvolvedores frequentemente usam eventos ou estruturas de dados adicionais quando sistemas off-chain precisam listar entradas de mapping.

Mappings são poderosos, mas exigem contabilidade cuidadosa.

Uma atualização incorreta de mapping pode levar a saldos incorretos, permissões corrompidas ou perda de fundos.

Interfaces

Uma interface define assinaturas de funções que outro contrato pode chamar.

As interfaces são importantes porque contratos inteligentes frequentemente precisam interagir com outros contratos inteligentes.

Uma interface de token pode informar a um contrato DeFi como chamar transfer, transferFrom, approve, balanceOf ou allowance.

Uma interface de oráculo pode informar a um protocolo de empréstimos como ler dados de preço.

Uma interface de governança pode permitir que outro contrato verifique o estado de uma proposta ou o poder de voto.

Interfaces melhoram a composabilidade porque os contratos podem depender de formatos comuns de funções.

No entanto, uma interface apenas descreve chamadas e valores de retorno esperados.

Ela não comprova que o contrato por trás de um endereço se comporta de forma honesta ou segura.

Os desenvolvedores devem validar pressupostos sobre contratos externos antes de integrá-los.

Os usuários devem lembrar que a composabilidade de contratos pode espalhar riscos entre sistemas conectados.

Bibliotecas

Bibliotecas são unidades reutilizáveis de código Solidity que ajudam desenvolvedores a evitar reescrever lógica comum.

Uma biblioteca pode fornecer funções matemáticas, utilitários de endereço, auxiliares de transferência segura, ferramentas para arrays e strings ou operações com estruturas de dados.

Algumas bibliotecas são incorporadas ao bytecode do contrato durante a compilação.

Outras podem ser implantadas separadamente e vinculadas por endereço.

O uso de bibliotecas pode melhorar a qualidade do código quando a biblioteca é bem testada e amplamente revisada.

Também pode adicionar riscos se a biblioteca estiver desatualizada, for maliciosa, estiver vinculada incorretamente ou for usada da maneira errada.

Os desenvolvedores devem fixar versões de dependências e revisar o código importado.

Os auditores devem examinar bibliotecas como parte de toda a base de código.

Os usuários devem entender que um contrato verificado pode depender de bibliotecas importadas e código herdado.

Um contrato é tão seguro quanto o conjunto completo de código que afeta seu comportamento.

Herança

A herança permite que um contrato Solidity reutilize e estenda código de outros contratos.

Isso é útil para lógica compartilhada de propriedade, comportamento de token, controle de acesso, controles de pausa, padrões de atualização e módulos reutilizáveis.

A herança pode facilitar a organização do código quando usada com cuidado.

Também pode tornar o código mais difícil de revisar quando muitos contratos herdados interagem de formas complexas.

Um contrato filho pode substituir uma função do contrato pai.

A herança múltipla pode criar problemas sutis de ordem e substituição.

Os desenvolvedores devem manter as estruturas de herança simples quando possível.

Os auditores devem revisar toda a árvore de herança, e não apenas o contrato final.

Usuários que leem código verificado devem conferir os contratos-pai importados, e não somente o nome do contrato mostrado na página.

A herança é poderosa, mas a lógica herdada oculta pode ser perigosa quando ignorada.

ABI

ABI significa Application Binary Interface.

A especificação ABI do Solidity explica que a ABI é a forma padrão de interagir com contratos no ecossistema Ethereum.

A ABI informa ao software como codificar chamadas de funções e decodificar valores de retorno.

Carteiras, scripts, aplicativos e exploradores de blockchain usam ABIs para exibir nomes de funções e campos de parâmetros legíveis.

Sem uma ABI, os usuários precisariam trabalhar com calldata bruta, que é muito mais difícil de compreender.

A ABI pode incluir funções, eventos, erros, entradas, saídas e informações de tipo.

A ABI não prova que um contrato é seguro.

Ela apenas descreve como chamar a interface exposta pelo contrato.

Um contrato malicioso ainda pode ter uma ABI aparentemente limpa.

Os usuários devem tratar dados ABI como uma camada de usabilidade, não como uma garantia de confiança.

Compilador Solidity

O compilador Solidity, ou solc, transforma código-fonte Solidity em bytecode EVM e artefatos de suporte.

O solc também pode gerar dados ABI, metadados, estimativas de gas, layout de armazenamento, avisos, erros e resultados intermediários.

A versão exata e as configurações do compilador são importantes porque afetam o bytecode final.

O anúncio de lançamento do Solidity 0.8.35 informa que a versão 0.8.35 introduziu um builtin erc7201, uma flag experimental de nível superior e um gerador experimental de código SSA CFG.

As versões do compilador importam porque Solidity evolui com novos recursos, correções de bugs, avisos e mudanças no destino EVM.

Um contrato compilado com uma versão pode não corresponder ao mesmo código-fonte compilado com outra versão.

Configurações como status do otimizador, execuções do otimizador, versão EVM, via-IR e endereços de bibliotecas também afetam o resultado.

Por isso, contratos verificados geralmente mostram a versão e as configurações do compilador usadas para corresponder ao bytecode implantado.

Os desenvolvedores devem fixar versões do compilador para implantações em produção.

Os usuários devem entender que o código-fonte verificado depende de configurações de compilação correspondentes, não apenas de texto correspondente.

Bytecode

Bytecode é o código de baixo nível executado pela EVM depois que um contrato Solidity é compilado e implantado.

O bytecode de implantação é usado para criar o contrato.

O bytecode de execução é o código que permanece no endereço do contrato após a implantação.

As blockchains executam bytecode, e não o texto-fonte original em Solidity.

Por isso, a verificação do código-fonte é importante.

A verificação demonstra que o código-fonte visível e as configurações do compilador podem reproduzir o bytecode implantado.

A documentação de verificação de contratos inteligentes da Ethereum explica que a verificação compara o código-fonte com o bytecode compilado.

O bytecode é difícil de ler diretamente para a maioria dos usuários.

O código-fonte verificado torna o bytecode mais compreensível.

No entanto, mesmo bytecode verificado requer revisão de segurança antes de os usuários confiarem fundos ao contrato.

Gas

Gas é a unidade usada para medir o trabalho computacional necessário para executar transações e operações de contratos inteligentes.

Desenvolvedores Solidity precisam se preocupar com gas porque códigos caros podem tornar um contrato custoso ou impraticável de usar.

Gravar no armazenamento geralmente custa mais do que ler memória ou calldata.

Loops sobre grandes conjuntos de dados podem se tornar perigosos se exigirem gas demais.

Chamadas externas podem adicionar custos e riscos de segurança.

A implantação de contratos também custa gas, pois o bytecode deve ser armazenado on-chain.

O otimizador Solidity pode, em alguns casos, reduzir o custo de gas ou o tamanho do bytecode, mas precisa ser configurado e testado cuidadosamente.

A otimização de gas não deve ocorrer à custa de lógica pouco clara ou insegura.

No mercado cripto, um contrato caro demais para usar pode prejudicar usuários durante congestionamentos da rede.

Um bom desenvolvimento em Solidity equilibra segurança, clareza e eficiência.

Solidity e tokens

Solidity é amplamente usada para criar e gerenciar contratos de tokens.

Um contrato de token fungível pode rastrear saldos, permissões de gasto, oferta total, transferências, aprovações, emissão, queima e controles de acesso.

Um contrato NFT pode rastrear IDs únicos de tokens, proprietários, aprovações, links de metadados e regras de transferência.

Um contrato multitoquen pode gerenciar muitos tipos de tokens em um sistema de contrato.

Os padrões de tokens são importantes porque facilitam o suporte a tokens por carteiras, exploradores e aplicativos.

Os padrões ERC-20, ERC-721 e ERC-1155 estão entre os mais importantes padrões de token na camada de aplicação do ecossistema Ethereum.

No entanto, o fato de um token ser escrito em Solidity ou seguir um padrão não o torna seguro ou valioso.

Um contrato de token pode incluir autoridade de emissão, lógica de blacklist, taxas, controles de pausa, possibilidade de atualização ou permissões administrativas perigosas.

Os usuários devem revisar permissões do token, distribuição entre holders, liquidez, regras de oferta e código-fonte verificado antes de confiar em um token.

Solidity torna possível criar tokens, mas a qualidade do token depende de seu design e governança.

Solidity e DeFi

Solidity é central para muitas aplicações de finanças descentralizadas (DeFi).

Contratos DeFi podem gerenciar swaps, pools de liquidez, mercados de empréstimos, vaults, derivativos, staking, estratégias de rendimento e sistemas de governança.

Esses sistemas frequentemente detêm grandes volumes de ativos dos usuários, tornando a segurança em Solidity extremamente importante.

Um protocolo DeFi pode falhar por bug de código, problema de oráculo, modelo contábil inadequado, regra de liquidação defeituosa, atualização insegura ou ataque de governança.

Solidity permite que contratos chamem uns aos outros, tornando o DeFi altamente componível.

A composabilidade pode criar componentes financeiros úteis.

Também pode criar risco de dependência quando um protocolo depende do comportamento de outro.

Os desenvolvedores devem testar integrações em muitas condições de mercado e cenários de falha.

Os usuários devem entender que contratos inteligentes DeFi podem ser transparentes e arriscados ao mesmo tempo.

Alto rendimento ou alto volume não comprovam que o código Solidity é seguro.

Solidity e NFTs

Solidity é frequentemente usada para criar contratos NFT que definem regras de propriedade e transferência de ativos digitais únicos.

Um contrato inteligente NFT pode atribuir IDs de tokens, armazenar registros de propriedade, gerenciar aprovações e criar links para metadados.

Os metadados de NFT frequentemente apontam para imagens, atributos, descrições ou arquivos externos.

O contrato inteligente pode não armazenar toda a mídia diretamente on-chain, pois armazenar grandes volumes de dados on-chain pode ser caro.

Os usuários devem verificar se os metadados do NFT estão on-chain, são descentralizados, mutáveis ou controlados por uma autoridade do projeto.

Um contrato NFT em Solidity verificado pode mostrar regras de mint, limites de oferta, comportamento de royalties, restrições de transferência e permissões administrativas.

No entanto, muitos riscos de NFTs não são apenas riscos de código.

Os riscos também incluem coleções falsas, arte copiada, liquidez fraca, metadados corrompidos, promessas enganosas e manipulação de marketplace.

Solidity fornece a lógica de propriedade, mas não garante valor cultural ou demanda futura.

Compradores de NFT devem combinar a revisão do contrato com a verificação da coleção e a análise de liquidez.

Solidity e DAOs

Solidity é frequentemente usada para criar contratos de governança de DAOs.

Um contrato de DAO pode gerenciar propostas, poder de voto, delegação, timelocks, execução de tesouraria e permissões de funções.

Contratos de governança podem permitir que holders de tokens ou membros votem em mudanças de protocolo.

Eles também podem controlar ações sensíveis, como atualizações, transferências da tesouraria, alterações de parâmetros e pausas de emergência.

Contratos de DAO exigem projeto cuidadoso, pois ataques de governança podem afetar ativos reais.

Um sistema de votação mal projetado pode ser vulnerável a baixa participação, compra de votos, votação com flash loans, controle de baleias ou execução apressada.

Timelocks podem dar aos usuários tempo para reagir antes que mudanças aprovadas entrem em vigor.

Controles de emergência podem reduzir danos, mas também introduzir poder centralizado.

Solidity oferece ferramentas de governança programável às DAOs, mas a segurança da governança depende tanto do código quanto da coordenação humana.

Os usuários devem revisar quem pode alterar um protocolo e com que rapidez as alterações podem ocorrer.

Riscos de segurança do Solidity

A segurança em Solidity é um dos temas mais importantes do desenvolvimento cripto.

A documentação de considerações de segurança do Solidity aborda riscos como reentrância, limites de gas, envio e recebimento de ether, tx.origin, detalhes menores e questões relacionadas ao compilador.

A reentrância pode ocorrer quando um contrato chama um contrato externo antes de atualizar seu próprio estado de forma segura.

Erros de controle de acesso podem permitir que usuários não autorizados chamem funções sensíveis.

Erros em inteiros e contabilidade podem criar saldos incorretos ou lógica de taxas defeituosa.

Erros de oráculos podem causar preços incorretos e liquidações injustas.

Erros de atualização podem substituir lógica segura por lógica insegura.

Chamadas externas não verificadas podem criar caminhos de execução inesperados.

Erros na verificação de assinaturas podem permitir ataques de repetição ou aprovações falsas.

A segurança de contratos inteligentes exige modelagem de ameaças, testes, revisões, auditorias, monitoramento e projeto conservador.

Reentrância

Reentrância é uma vulnerabilidade conhecida de contratos inteligentes na qual uma chamada externa permite que outro contrato faça uma chamada de volta antes que o primeiro contrato conclua a atualização de seu estado.

Isso pode permitir saques repetidos, contabilidade corrompida ou fluxo de controle inesperado.

A documentação de segurança do Solidity recomenda o padrão Checks-Effects-Interactions como uma maneira de reduzir o risco de reentrância.

O padrão significa que um contrato deve primeiro verificar condições, depois atualizar o estado interno e, por último, interagir com contratos externos.

A proteção contra reentrância também pode incluir bloqueios, designs de pagamento por retirada e revisão cuidadosa de chamadas externas.

Os desenvolvedores não devem presumir que enviar ativos é inofensivo.

Chamadas externas podem executar código e alterar o fluxo de controle.

Os usuários devem ter cuidado com protocolos que apresentam lógica de saque não auditada ou caminhos complexos de callback.

A reentrância não é o único risco de Solidity, mas é um dos exemplos mais importantes de por que a lógica de contratos inteligentes difere do software normal.

Uma transferência aparentemente segura pode se tornar perigosa se as atualizações de estado ocorrerem na ordem errada.

Controle de acesso

O controle de acesso decide quem pode chamar funções Solidity sensíveis.

Funções importantes podem incluir emissão de tokens, pausa de transferências, atualização de contratos, mudança de taxas, definição de oráculos, saque de fundos da tesouraria ou concessão de funções.

O controle de acesso pode se basear em um endereço de proprietário, funções, carteiras multisig, contratos de governança, timelocks ou sistemas de permissões personalizados.

Um controle de acesso fraco pode permitir que invasores ou insiders alterem o comportamento do contrato.

Um controle de acesso excessivamente centralizado também pode criar risco de confiança para os usuários.

Um contrato pode funcionar tecnicamente, mas ainda ser inseguro se uma única chave privada puder drenar fundos ou mudar regras instantaneamente.

Os desenvolvedores devem projetar permissões com privilégio mínimo, separação clara de funções e planos de recuperação.

Os usuários devem revisar poderes administrativos antes de depositar fundos em um protocolo.

O código Solidity verificado pode revelar a lógica de permissões quando o código-fonte está disponível.

O risco administrativo é um risco de contrato inteligente mesmo quando não há bug de código.

Segurança de inteiros

Operações com inteiros são importantes em Solidity porque os contratos frequentemente tratam saldos, participações, preços, taxas, juros e recompensas.

Versões mais antigas de Solidity exigiam mais cuidado manual com overflow e underflow de inteiros.

Solidity 0.8.x introduziu aritmética verificada por padrão, que reverte na maioria das condições de overflow e underflow, exceto quando blocos unchecked são usados.

Essa melhoria de segurança não elimina todos os riscos matemáticos.

Os desenvolvedores ainda podem errar em arredondamento, precisão, fatores de escala, diferenças decimais, ordem de taxas e contabilidade de participações.

Blocos unchecked podem melhorar a eficiência de gas em casos selecionados, mas devem ser usados cuidadosamente.

Contratos DeFi frequentemente usam matemática de ponto fixo e decimais de tokens, o que pode criar erros sutis.

Os auditores devem revisar premissas matemáticas e casos extremos.

Os usuários devem entender que aritmética segura não significa automaticamente economia segura.

Fórmulas corretas são tão importantes quanto a proteção contra overflow.

Oráculos e dados externos

Contratos Solidity não podem acessar dados off-chain diretamente por conta própria.

A documentação de oráculos da Ethereum explica que os oráculos fornecem aos contratos inteligentes dados do mundo externo.

Oráculos podem fornecer preços, aleatoriedade, dados de prova, dados climáticos, dados esportivos, informações de identidade ou outras entradas off-chain.

No DeFi, oráculos de preço são especialmente importantes porque podem determinar valores de garantia, liquidações, emissão, resgates e liquidação financeira.

Um projeto ruim de oráculo pode causar perdas significativas mesmo quando o código Solidity está correto.

Os desenvolvedores devem evitar depender de preços Spot facilmente manipuláveis em mercados com pouca liquidez.

Também devem considerar frequência de atualização, comportamento de fallback, atrasos de dados e circuit breakers.

Os usuários devem verificar qual fonte de oráculo um protocolo utiliza antes de depositar garantia ou tomar ativos emprestados.

Solidity pode aplicar regras baseadas em oráculos, mas não pode tornar bons dados ruins.

Dados externos são uma das maiores premissas de confiança em muitos sistemas de contratos inteligentes.

Possibilidade de atualização

Contratos Solidity são frequentemente descritos como imutáveis, mas muitos projetos usam padrões de atualização para alterar a lógica após a implantação.

Contratos atualizáveis normalmente separam um contrato proxy de um contrato de implementação.

O proxy mantém o endereço e o armazenamento, enquanto a implementação contém a lógica que pode ser substituída por uma função de atualização.

A possibilidade de atualização pode corrigir bugs e adicionar recursos.

Também pode criar risco de confiança porque administradores ou a governança podem alterar regras após os usuários depositarem fundos.

O layout de armazenamento deve ser tratado cuidadosamente, pois atualizações incorretas podem corromper o estado.

Os usuários devem verificar se um contrato é atualizável, quem controla as atualizações, se existe um timelock e se as atualizações são anunciadas publicamente.

Desenvolvedores devem documentar claramente os poderes de atualização.

Auditores devem revisar tanto a implementação atual quanto os controles de atualização.

A capacidade de atualização é útil, mas altera o modelo de confiança dos contratos Solidity.

Verificação do código-fonte

A verificação do código-fonte ajuda os usuários a confirmar se o código Solidity publicado corresponde ao bytecode implantado.

A documentação de verificação da Ethereum explica que a verificação compara o código-fonte do contrato com o bytecode compilado usado durante a criação do contrato.

Em geral, a verificação exige os arquivos-fonte exatos, a versão do compilador, as configurações do compilador, os argumentos do construtor, os endereços das bibliotecas e a configuração dos metadados.

O código-fonte verificado aumenta a transparência porque permite que os usuários leiam a lógica por trás do contrato.

Também ajuda carteiras e exploradores de blockchain a decodificar chamadas de funções e eventos.

No entanto, a verificação do código-fonte não é o mesmo que uma auditoria.

Mesmo um contrato verificado pode conter bugs, controles administrativos inseguros, riscos de atualização ou um design econômico inadequado.

É mais difícil confiar em contratos não verificados, pois os usuários não conseguem comparar facilmente o código legível por humanos com o bytecode implantado.

Os usuários devem ter cautela quando um site solicita aprovações ou depósitos em um contrato não verificado.

A verificação é um ponto de partida para a diligência prévia, não o fim dela.

Versões do Solidity

As versões do Solidity são importantes porque a linguagem muda ao longo do tempo.

Novas versões podem introduzir recursos, aprimorar avisos, alterar configurações padrão, corrigir bugs do compilador e oferecer suporte a novos comportamentos da EVM.

Os anúncios oficiais de lançamento do Solidity publicam detalhes sobre versões do compilador e mudanças na linguagem.

De acordo com as informações oficiais de lançamento disponíveis em 2026, o Solidity 0.8.35 é uma versão recente do compilador que inclui novas funcionalidades e recursos experimentais.

Projetos em produção não devem atualizar as versões do compilador sem planejamento.

Toda atualização do compilador deve ser testada, pois o bytecode, o comportamento das taxas de gas, os avisos e os resultados da compilação podem mudar.

Desenvolvedores devem ler as notas de lançamento antes de alterar as versões do compilador.

Auditores devem revisar a versão do compilador usada na compilação auditada.

Ao analisar contratos verificados, os usuários devem conferir a versão do compilador exibida no explorador de blockchain.

A escolha da versão do Solidity faz parte da segurança e da reprodutibilidade dos contratos inteligentes.

Bugs do compilador Solidity

Bugs do compilador são raros, mas importantes, porque o compilador converte o código-fonte no bytecode que realmente é executado on-chain.

A documentação oficial sobre bugs conhecidos do Solidity acompanha os bugs conhecidos do compilador e as versões afetadas.

Um contrato pode ser afetado por um problema no compilador mesmo que o código-fonte pareça correto.

Desenvolvedores devem verificar os bugs conhecidos do compilador antes de implantar contratos em produção.

Auditores devem incluir a revisão da versão do compilador em seu processo.

Os usuários devem ter cautela quando um contrato utiliza uma versão muito antiga do compilador sem uma justificativa clara.

Uma versão antiga do compilador não é automaticamente insegura, mas pode não incluir verificações e correções mais recentes.

Equipes de contratos inteligentes devem tratar o compilador como parte da cadeia de fornecimento de software confiável.

Compilações reproduzíveis e configurações registradas do compilador ajudam a identificar se um bug conhecido pode ser aplicável.

O risco relacionado ao compilador é mais um motivo para preservar os artefatos de implantação.

Ferramentas de desenvolvimento Solidity

Desenvolvedores Solidity geralmente usam ferramentas para escrever, compilar, testar, implantar, verificar e monitorar contratos.

O Remix IDE oficial é um ambiente baseado em navegador comumente usado para aprender, escrever, compilar e testar contratos Solidity.

Frameworks de linha de comando e ambientes locais de desenvolvimento podem automatizar compilação, testes, implantações, testes em forks e verificação.

Ferramentas de análise estática podem examinar o código Solidity em busca de vulnerabilidades comuns e padrões arriscados.

Ferramentas de fuzz testing podem gerar muitos dados de entrada para identificar comportamentos inesperados.

Ferramentas de verificação formal podem provar propriedades específicas sob premissas definidas.

Nenhuma ferramenta isolada pode garantir a segurança.

O desenvolvimento profissional em Solidity geralmente combina testes unitários, testes de integração, fuzz tests, revisão de código, auditorias, scripts de implantação, monitoramento e planejamento de resposta a incidentes.

Iniciantes devem começar com contratos pequenos e redes de teste antes de lidar com fundos reais.

Equipes avançadas devem usar pipelines de compilação reproduzíveis e controles rigorosos de lançamento.

Testes de contratos Solidity

Os testes são essenciais porque contratos inteligentes implantados podem controlar ativos valiosos.

Testes unitários verificam funções individuais e os comportamentos esperados.

Testes de integração verificam como vários contratos funcionam em conjunto.

Testes em forks simulam o comportamento de contratos usando dados reais da blockchain copiados para um ambiente local.

Fuzz tests tentam várias entradas aleatórias ou estruturadas para encontrar casos extremos.

Testes de invariantes verificam se regras importantes permanecem válidas após várias ações.

Os testes devem incluir fluxos normais, fluxos de falha, verificações de permissões, casos extremos e cenários com usuários maliciosos.

Desenvolvedores devem testar com casas decimais de tokens realistas, comportamentos incomuns de tokens, valores altos, valores zero e condições de limite.

Os testes não conseguem provar que todos os comportamentos possíveis são seguros, mas reduzem significativamente erros evitáveis.

Não se deve confiar fundos significativos a código Solidity que não foi testado.

Auditorias

Uma auditoria de contrato inteligente é uma revisão de segurança realizada por especialistas que analisam o código Solidity, a arquitetura, as permissões, os testes e as premissas de risco.

Uma auditoria pode identificar bugs, falhas de design, problemas de controle de acesso, riscos econômicos, problemas de atualização e lacunas na documentação.

Uma auditoria não garante que um contrato seja seguro.

É um processo de redução de riscos, não uma proteção perfeita.

A qualidade de uma auditoria depende do escopo, do tempo, da experiência do auditor, da cobertura dos testes, da documentação e de como a equipe corrige os problemas encontrados.

Os usuários devem verificar se os problemas identificados na auditoria foram corrigidos ou aceitos.

Também devem conferir se o contrato implantado corresponde ao commit auditado e às configurações do compilador.

Um projeto pode passar por uma auditoria e, posteriormente, implantar atualizações não auditadas.

As auditorias são mais úteis quando combinadas com verificação pública, programas de recompensa por bugs, monitoramento e limites conservadores de lançamento.

Contratos Solidity que gerenciam grandes quantidades de valor devem ser analisados com rigor antes da implantação na mainnet.

Solidity e interações com carteiras

As carteiras ajudam os usuários a assinar transações que chamam contratos Solidity.

Uma carteira pode exibir o endereço do contrato, o nome da função, os parâmetros, as aprovações de ativos, a taxa de gas e mensagens de aviso.

A carteira nem sempre sabe se um contrato é seguro.

Alguns sites maliciosos podem pedir que os usuários assinem transações perigosas que chamam funções Solidity legítimas de maneiras prejudiciais.

As aprovações de tokens são especialmente importantes, pois uma aprovação pode permitir que um contrato gaste tokens de uma carteira até um valor definido.

Os usuários devem verificar os valores aprovados e os endereços dos contratos antes de assinar.

Devem evitar assinar transações que não entendem.

Devem ter cautela quando uma interface oculta os dados de chamada (calldata) ou solicita aprovações ilimitadas.

O Solidity permite interações programáveis, mas os usuários continuam controlando as assinaturas feitas em suas carteiras.

Uma assinatura de transação pode transferir fundos permanentemente ou conceder permissões.

Solidity e aprovações de tokens

As aprovações de tokens são um padrão comum em Solidity que permite que um endereço gaste tokens em nome de outro endereço.

Em um token no padrão ERC-20, a função approve define uma permissão de gasto (allowance), e a função transferFrom utiliza essa permissão.

Esse design possibilita swaps em DeFi, depósitos, pagamentos e ações automatizadas.

Também cria riscos, pois um gastador malicioso ou comprometido pode usar uma aprovação para transferir tokens dentro do limite aprovado.

Aprovações ilimitadas são convenientes, mas aumentam a exposição a riscos.

Quando viável, os usuários devem aprovar apenas o necessário.

Devem revogar aprovações não utilizadas usando ferramentas confiáveis de carteira ou de segurança.

Desenvolvedores devem criar interfaces que expliquem as aprovações com clareza.

Auditores devem verificar o tratamento das permissões de gasto para identificar condições de corrida, verificações ausentes e premissas inseguras.

As aprovações são uma das formas mais comuns de usuários comuns interagirem com os riscos do Solidity.

Solidity e verificação formal

A verificação formal usa métodos matemáticos para provar que determinadas propriedades de um contrato são válidas sob premissas definidas.

Isso pode ser útil para sistemas de alto valor, protocolos financeiros, bridges, módulos de governança e lógica central de contabilidade.

Uma propriedade pode determinar, por exemplo, que a oferta total nunca exceda um limite ou que os usuários não possam sacar mais do que seu saldo.

A verificação formal não elimina a necessidade de testes e auditorias.

Ela prova apenas as propriedades que foram especificadas.

Se a especificação estiver incompleta ou incorreta, a prova poderá não identificar riscos reais.

Métodos formais podem ser caros e exigem conhecimento especializado.

Eles são mais eficazes quando aplicados a lógicas críticas com regras claras.

No Solidity, a verificação formal faz parte de um processo de segurança maduro.

Ela é especialmente útil quando uma falha do contrato pode causar grandes perdas.

Vantagens do Solidity

A primeira vantagem do Solidity é sua ampla adoção no ecossistema.

Muitas ferramentas para contratos inteligentes, tutoriais, auditorias, padrões, bibliotecas e comunidades de desenvolvedores oferecem suporte ao Solidity.

A segunda vantagem é a compatibilidade com a EVM.

Os contratos Solidity podem ser direcionados à Ethereum e a outros ambientes compatíveis com a EVM, desde que as regras da rede e as configurações de implantação sejam compatíveis.

A terceira vantagem é a composabilidade.

Contratos Solidity podem chamar outros contratos e se basear em padrões de tokens e interfaces de protocolos existentes.

A quarta vantagem é a expressividade.

Desenvolvedores podem criar tokens, sistemas DeFi, DAOs, jogos, NFTs e lógica financeira automatizada.

A quinta vantagem é a transparência, pois o código-fonte Solidity verificado pode ser lido e analisado por usuários e auditores.

Essas vantagens explicam por que o Solidity continua sendo uma das linguagens de contratos inteligentes mais importantes do mercado cripto.

Riscos e limitações do Solidity

O primeiro risco é que bugs podem ser custosos e difíceis de corrigir após a implantação.

O segundo risco é que qualquer usuário que encontre uma vulnerabilidade pode explorar a lógica do contrato inteligente.

O terceiro risco é que contratos Solidity costumam interagir com outros contratos, o que cria riscos relacionados a dependências.

O quarto risco é que os custos de gas podem tornar alguns designs inviáveis.

O quinto risco é que a capacidade de atualização pode criar riscos de confiança relacionados à administração ou à governança.

O sexto risco é que o código-fonte verificado ainda pode ser malicioso ou mal projetado.

O sétimo risco é que desenvolvedores podem interpretar incorretamente o comportamento da EVM, o layout de armazenamento, a reentrância ou chamadas externas.

O oitavo risco é que usuários podem assinar transações prejudiciais sem entender o que o contrato Solidity fará.

O nono risco é que problemas com oráculos e com o design econômico podem comprometer um protocolo mesmo quando a sintaxe está correta.

O décimo risco é que as configurações do compilador e as versões das dependências podem alterar o bytecode final implantado.

Erros comuns em Solidity

Um erro comum é criar um controle de acesso que não proteja funções sensíveis.

Outro erro é fazer chamadas externas antes de atualizar o estado interno de forma segura.

Um terceiro erro é confiar em tx.origin para autorização, prática contra a qual a documentação de segurança do Solidity alerta.

Um quarto erro é ignorar as casas decimais dos tokens e problemas de precisão nos cálculos.

Um quinto erro é presumir que todos os tokens no padrão ERC-20 se comportam exatamente da mesma forma.

Um sexto erro é usar contratos atualizáveis sem preservar o layout de armazenamento.

Um sétimo erro é implantar com configurações do compilador diferentes das usadas na compilação auditada.

Um oitavo erro é ignorar os avisos do compilador.

Um nono erro é conceder poder excessivo a uma única chave administrativa.

Um décimo erro é lançar contratos antes de testar casos extremos e cenários de falha.

Como avaliar um contrato Solidity

Comece verificando se o código-fonte do contrato foi verificado.

Depois, confira a versão do compilador, as configurações do otimizador, os argumentos do construtor e as bibliotecas vinculadas.

Verifique se o contrato é atualizável e quem controla as atualizações.

Confira os cargos administrativos, as permissões do proprietário, os controles de multisig, os timelocks e as funções de emergência.

Ao avaliar contratos de tokens, analise as restrições de emissão, queima, pausa, lista de bloqueio, taxas e transferências.

Ao avaliar contratos DeFi, analise as fontes dos oráculos, as regras de garantia, a lógica de liquidação e a contabilidade.

Verifique se há auditorias e se os problemas identificados foram corrigidos.

Compare o endereço do contrato implantado com as fontes oficiais do projeto.

Analise transações e eventos recentes para entender como o contrato está sendo usado.

Um contrato Solidity deve ser avaliado como código, infraestrutura, governança e design econômico em conjunto.

Boas práticas para desenvolvedores

Use uma versão estável recente do compilador Solidity após ler as notas de lançamento e testar o comportamento.

Fixe as versões do compilador e das dependências nas compilações de produção.

Trate os avisos do compilador como itens que precisam ser revisados, e não como ruído inofensivo.

Use controle de acesso claro e permissões de privilégio mínimo.

Quando aplicável, siga padrões seguros para chamadas externas, como Checks-Effects-Interactions.

Escreva testes para fluxos normais, fluxos de falha, casos extremos e comportamentos de usuários maliciosos.

Use análise estática, fuzz testing e auditorias para contratos que gerenciam valores significativos.

Documente poderes administrativos, poderes de atualização, premissas dos oráculos e controles de emergência.

Após a implantação, verifique o código-fonte usando as configurações exatas do compilador.

Monitore os contratos implantados e prepare planos de resposta a incidentes antes do lançamento.

Boas práticas para usuários

Verifique se o contrato foi verificado antes de interagir com ele.

Compare os endereços dos contratos com fontes oficiais do projeto, em vez de confiar em links recebidos em mensagens aleatórias.

Revise as aprovações de tokens antes de assinar transações.

Tenha cautela com aprovações ilimitadas e, quando viável, revogue permissões não utilizadas.

Verifique se o contrato é atualizável e quem controla as atualizações.

Não presuma que um contrato verificado foi auditado ou é seguro.

Não deposite fundos em contratos que você não consegue entender ou nos quais não confia de forma independente.

Use carteiras de hardware ou medidas robustas de segurança da carteira para interações de alto valor.

Tenha cautela com contratos Solidity novos, não auditados, de alto rendimento ou anônimos.

Lembre-se de que uma transação na blockchain geralmente é irreversível depois de confirmada.

Perguntas frequentes

Para que serve o Solidity?

O Solidity é usado para escrever contratos inteligentes para a Ethereum e outros ambientes blockchain compatíveis com a EVM.

Solidity é uma criptomoeda?

Não. Solidity é uma linguagem de programação, não uma criptomoeda ou um token.

O Solidity é usado apenas na Ethereum?

O Solidity foi desenvolvido para a Ethereum, mas também é usado em outras redes blockchain que oferecem suporte à Ethereum Virtual Machine ou a ambientes de execução compatíveis.

O que é um contrato inteligente Solidity?

Um contrato inteligente Solidity é um código na blockchain que define regras para armazenar dados, processar transações, gerenciar ativos e interagir com usuários ou outros contratos.

O que é o compilador Solidity?

O compilador Solidity, chamado solc, converte o código-fonte Solidity em bytecode da EVM, dados ABI, metadados e outros artefatos de compilação.

O que é ABI em Solidity?

ABI é a Application Binary Interface, que informa a carteiras, aplicativos e scripts como chamar as funções de um contrato e decodificar as respostas.

Solidity é seguro?

O Solidity pode ser usado com segurança, mas a segurança dos contratos inteligentes depende de um design seguro, testes, auditorias, configurações do compilador, controle de acesso e implantação cuidadosa.

Os contratos Solidity podem ser alterados após a implantação?

Em geral, contratos básicos já implantados são imutáveis, mas padrões de proxy atualizáveis podem permitir alterações na lógica do contrato se houver permissões de atualização.

Por que contratos Solidity precisam de auditorias?

Contratos Solidity costumam controlar ativos valiosos. Por isso, auditorias ajudam a identificar bugs, problemas de permissão, falhas econômicas e premissas inseguras antes ou depois da implantação.

Como os usuários podem verificar um contrato Solidity?

Os usuários podem verificar a validação do código-fonte, as configurações do compilador, o endereço do contrato, as auditorias, as permissões administrativas, a capacidade de atualização, as aprovações de tokens, o histórico de transações e a documentação oficial do projeto.

Conclusão

O Solidity é uma das linguagens de programação mais importantes do ecossistema cripto porque permite criar contratos inteligentes para tokens, DeFi, NFTs, DAOs, sistemas de staking e muitos outros aplicativos on-chain.

Ele permite que desenvolvedores escrevam regras legíveis por humanos, que são compiladas em bytecode da EVM e executadas por nós da blockchain.

Os pontos fortes do Solidity estão em seu amplo ecossistema, nos padrões de contratos inteligentes, na composabilidade, nas ferramentas e no amplo suporte à EVM.

Os riscos decorrem do fato de que o código implantado pode controlar ativos reais e ser difícil de corrigir após a implantação.

Um bom desenvolvimento em Solidity exige configurações cuidadosas do compilador, testes, auditorias, controle de acesso, planejamento de atualizações, atenção aos custos de gas e análise de segurança.

Para usar Solidity com segurança, os usuários devem verificar endereços de contratos, analisar permissões, gerenciar aprovações, conferir auditorias e evitar contratos desconhecidos ou não verificados.

Para iniciantes, o Solidity é mais fácil de entender como a linguagem usada por desenvolvedores para escrever programas de blockchain.

Para usuários avançados, o Solidity é uma linguagem de contratos inteligentes cuja segurança depende da qualidade do código, do comportamento da EVM, da configuração do compilador, das dependências externas, da governança e do design econômico.

No contexto de um glossário cripto, Solidity significa a principal linguagem de alto nível usada para criar e implantar contratos inteligentes executados em ambientes blockchain no estilo da Ethereum.

A principal conclusão é que o Solidity torna possível programar no universo cripto, mas todo contrato Solidity deve ser tratado como um software de alto risco, que exige verificação, análise de segurança e cautela por parte dos usuários.