Otimização de gas

O que é otimização de gas?

Otimização de gas é o processo de reduzir os recursos da blockchain necessários para implantar ou executar um contrato inteligente de criptomoeda.

Na Ethereum, toda transação e operação da Ethereum Virtual Machine consome uma quantidade mensurável de gas.

Normalmente, o remetente da transação paga uma taxa de rede com base no gas cobrado e no preço efetivo de cada unidade de gas.

O cálculo básico é: Taxa da transação = Gas cobrado × Preço efetivo do gas.

A otimização de gas reduz a quantidade de gas cobrada ao tornar mais eficientes o código do contrato, o uso do armazenamento, os dados da transação e os caminhos de execução.

Ela não controla diretamente o preço do gas, que muda conforme a demanda pela capacidade da blockchain.

Um contrato devidamente otimizado pode tornar mais acessíveis transferências de tokens, operações de finanças descentralizadas, ações de governança, atividades com NFT e outras transações cripto.

No entanto, a otimização de gas nunca deve remover verificações de segurança nem dificultar a compreensão do comportamento do contrato.

O objetivo é executar o mínimo de trabalho on-chain seguro e verificável exigido pelo aplicativo.

Como funciona a otimização de gas

A Ethereum cobra quantidades diferentes de gas por diferentes tipos de trabalho computacional e relacionado ao estado.

Cálculos simples geralmente são baratos, enquanto alterações no armazenamento persistente, criação de contratos, operações criptográficas e chamadas externas podem custar bem mais.

A documentação oficial sobre gas da Ethereum explica que o gas mede o esforço computacional necessário para processar transações na blockchain.

A otimização de gas começa pela identificação das operações que mais consomem gas e pela avaliação de como o aplicativo pode executar menos trabalho sem alterar o comportamento pretendido.

Um desenvolvedor pode reduzir leituras repetidas do armazenamento, combinar alterações de estado, encurtar os dados das transações, remover cálculos duplicados ou usar recursos mais eficientes da EVM.

O compilador também pode transformar o código-fonte Solidity em bytecode mais eficiente.

Algumas otimizações reduzem o custo de implantação do contrato, enquanto outras diminuem o custo de cada interação do usuário.

A abordagem mais adequada depende da frequência de implantação do contrato e da frequência com que suas funções serão chamadas.

Otimização de gas vs. otimização do preço do gas

A otimização de gas e a otimização do preço do gas tratam de partes diferentes da taxa de uma transação.

A otimização de gas reduz o número de unidades consumidas pela transação.

A otimização do preço do gas busca enviar a transação em um momento em que cada unidade custe menos.

Um contrato que consome 100,000 unidades de gas continua sendo computacionalmente mais caro do que outro que executa a mesma tarefa com segurança usando 60,000 unidades.

No entanto, o contrato mais barato ainda pode gerar uma taxa alta em moeda nacional quando a rede está congestionada ou o valor do ETH está elevado.

Às vezes, os usuários podem reduzir o preço do gas esperando uma diminuição da demanda na rede, mas os desenvolvedores controlam o uso de gas pelo design do contrato e do aplicativo.

Combinar as duas abordagens pode reduzir o custo total da transação de forma mais eficaz do que depender de apenas uma delas.

Por que a otimização de gas é importante em cripto

Custos altos de transação podem impedir que os usuários interajam com um aplicativo de criptomoedas, mesmo quando o serviço subjacente é útil.

Uma pequena redução de gas se torna economicamente significativa quando a mesma função é executada milhares ou milhões de vezes.

Um menor uso de gas pode aumentar a acessibilidade para usuários com saldos menores de cripto.

Também pode ajudar transações urgentes a competir pela inclusão sem exigir uma taxa total desnecessariamente alta.

A eficiência de gas é especialmente importante para estratégias automatizadas de criptomoedas, pois os custos de execução podem superar o lucro esperado de uma negociação ou liquidação.

Contratos eficientes também usam menos da capacidade limitada dos blocos, permitindo que mais transações caibam nos recursos disponíveis da rede.

Assim, a otimização pode beneficiar tanto os usuários individuais quanto o ecossistema blockchain como um todo.

Meça o gas antes de alterar o código

Os desenvolvedores devem medir o consumo de gas antes de decidir quais partes de um contrato precisam de otimização.

Um código-fonte que parece ineficiente talvez já seja simplificado pelo compilador.

Um atalho no código-fonte também pode gerar bytecode mais caro do que uma implementação mais clara.

Os relatórios de gas devem incluir a implantação do contrato, transações bem-sucedidas, transações revertidas, entradas de tamanho máximo e caminhos de execução incomuns.

Uma função barata para um usuário pode se tornar inacessível quando processa um array grande ou muitas entradas de armazenamento.

Registros automatizados de gas podem comparar custos entre revisões de software e detectar aumentos inesperados.

Rastros de execução podem identificar opcodes, posições de armazenamento, expansão de memória e chamadas a contratos externos que custam caro.

A documentação do compilador Solidity descreve as saídas disponíveis, as configurações de otimização e as estimativas de gas.

Os desenvolvedores devem tratar essas estimativas como uma referência, pois loops dinâmicos e chamadas externas podem fazer o uso exato de gas depender do estado da blockchain.

Otimize a arquitetura do contrato inteligente

As maiores economias de gas geralmente vêm de alterações na arquitetura do contrato, e não da reescrita de expressões individuais.

Um contrato que armazena informações desnecessárias continuará caro mesmo que sua aritmética seja altamente otimizada.

Os desenvolvedores devem determinar quais informações precisam ser aplicadas on-chain e quais podem ser calculadas ou indexadas fora do contrato.

Saldos críticos, permissões, registros de propriedade e dados de garantias normalmente exigem estado persistente on-chain.

Informações de exibição, histórico de atividade e análises podem ser adequadas para logs de eventos quando a execução futura do contrato não precisa consultá-las.

Os desenvolvedores também devem avaliar se várias atualizações de estado podem ser representadas por um único valor acumulado ou índice contábil.

Modelos de estado mais simples geralmente exigem menos operações de armazenamento e são mais fáceis de auditar.

Reduza as gravações no armazenamento persistente

O armazenamento persistente é um dos recursos mais caros disponíveis para um contrato inteligente da Ethereum.

Os dados armazenados continuam fazendo parte do estado da Ethereum após o fim da transação.

Os nós da rede precisam processar e manter cada valor de armazenamento novo ou alterado.

Um contrato deve evitar gravar informações que possa calcular com segurança a partir do estado existente.

Também deve evitar gravar um valor quando o valor solicitado já está armazenado.

Às vezes, várias atualizações intermediárias podem ser substituídas por uma única gravação final após a conclusão de todos os cálculos.

Os desenvolvedores não devem armazenar cópias duplicadas dos mesmos dados, a menos que a duplicação ofereça um benefício necessário de segurança ou desempenho.

Reduzir as gravações no armazenamento costuma gerar economias maiores do que pequenas alterações aritméticas.

Armazene em cache leituras repetidas

Carregar repetidamente o mesmo valor do armazenamento pode desperdiçar gas quando ele não muda durante a execução.

Muitas vezes, um contrato pode carregar o valor uma vez em uma variável local e reutilizá-lo nos cálculos seguintes.

A Ethereum aplica custos diferentes a acessos frios e aquecidos ao estado, de acordo com a EIP-2929.

Em geral, o primeiro acesso a uma conta ou posição de armazenamento durante uma transação custa mais do que os acessos seguintes ao mesmo local.

No entanto, até mesmo uma leitura aquecida do armazenamento pode custar mais do que usar um valor já disponível na stack ou na memória.

O cache deve ser evitado quando uma chamada externa puder alterar o estado relevante do contrato antes do uso do valor armazenado.

A reentrância e o comportamento de callbacks devem ser analisados sempre que o estado for armazenado em cache durante uma interação externa.

Empacote variáveis de estado

O armazenamento da Ethereum é dividido em posições de 32 bytes.

A Solidity pode colocar várias variáveis menores de tipos de valor na mesma posição quando seus tamanhos e sua ordem permitem.

A documentação oficial de layout de armazenamento da Solidity explica como as variáveis são atribuídas às posições de armazenamento.

Uma ordem cuidadosa das variáveis pode reduzir o número de posições necessárias pelo contrato.

Por exemplo, vários inteiros menores ou valores booleanos podem caber em uma posição, em vez de ocupar posições separadas.

Usar um inteiro menor não reduz automaticamente o gas de execução, pois a EVM normalmente realiza operações aritméticas com palavras de 256 bits.

O empacotamento é mais vantajoso quando vários valores empacotados são lidos ou gravados juntos com frequência.

Atualizar apenas um campo em uma posição empacotada pode exigir operações adicionais de mascaramento e combinação.

Os desenvolvedores não devem reordenar variáveis de armazenamento existentes em um contrato atualizável, pois isso pode corromper dados já armazenados.

Use variáveis constant e immutable

Um valor que nunca muda não deve ser armazenado como uma variável de estado mutável comum.

A Solidity permite declarar valores definidos em tempo de compilação com a palavra-chave

.

Valores definidos durante a construção do contrato e fixos depois disso muitas vezes podem usar a palavra-chave

.

Constantes e valores imutáveis evitam leituras normais do armazenamento, pois são incorporados ao bytecode do contrato ou referenciados por ele.

A documentação da Solidity sobre variáveis constant e immutable explica as diferenças entre essas declarações.

Entre os exemplos comuns estão endereços permanentes, limites fixos, valores matemáticos e configurações que não podem ser alteradas depois da implantação.

Uma variável deve permanecer mutável quando o aplicativo realmente precisa que a governança ou uma administração autorizada possa atualizá-la.

Escolha o local de dados correto

Os dados da Solidity podem ficar em storage, memory, calldata ou armazenamento transitório, conforme o uso necessário.

Storage persiste entre transações e geralmente é o local mais caro.

Memory é temporária e fica disponível apenas durante a execução atual.

Calldata contém entradas externas somente para leitura, fornecidas com a transação ou chamada ao contrato.

O armazenamento transitório persiste entre chamadas durante uma transação, mas é apagado automaticamente quando ela termina.

Escolher um local de dados desnecessariamente caro aumenta o custo da transação sem melhorar a funcionalidade.

A documentação da Solidity sobre locais de dados explica como eles afetam a cópia, a mutabilidade e o tempo de vida dos dados.

Use calldata para entradas externas somente para leitura

Parâmetros de funções externas que não precisam ser modificados muitas vezes podem permanecer em calldata.

Usar calldata pode evitar copiar grandes arrays, strings, sequências de bytes ou structs para a memória.

Isso pode reduzir o gas quando a função só precisa examinar os valores enviados.

A memória continua sendo adequada quando o contrato precisa modificar a entrada ou criar um novo valor em memória.

Os desenvolvedores também devem minimizar dados desnecessários nas transações, pois cada byte de calldata contribui para o custo intrínseco de gas.

Às vezes, valores repetidos podem ser substituídos por identificadores compactos quando o contrato já armazena a configuração completa.

A compressão deve ser medida com cuidado, pois o cálculo necessário para decodificar os dados pode custar mais do que a economia obtida.

Considere os preços atuais da calldata

A atualização Pectra da Ethereum foi ativada em 7 de maio de 2025 e incluiu mudanças que afetam a economia de transações com muitos dados.

A EIP-7623 introduziu um limite mínimo de gas mais alto para transações com muita calldata e relativamente pouca execução na EVM.

A regra foi projetada para limitar o tamanho máximo de blocos com muitos dados e melhorar a resiliência da rede.

Os desenvolvedores não devem presumir que uma transação com computação mínima será sempre barata quando incluir uma grande carga de calldata.

Aplicativos que enviam provas, assinaturas, lotes ou informações compactadas de transações devem testar o comportamento atual do protocolo.

Novas atualizações da rede podem alterar o custo relativo de calldata, computação, armazenamento e outros recursos.

Use armazenamento transitório quando o estado for temporário

O armazenamento transitório foi criado para informações que precisam continuar disponíveis durante uma transação, mas não devem persistir depois dela.

A Ethereum introduziu os opcodes

e por meio da EIP-1153.

Os valores transitórios são descartados automaticamente no fim da transação.

Isso torna o armazenamento transitório mais barato que o persistente, pois os dados não precisam ser salvos permanentemente.

Um caso de uso comum é um bloqueio contra reentrância compartilhado por várias chamadas internas ou externas durante uma transação.

O armazenamento transitório também pode ser usado em contabilidade temporária, callbacks e permissões limitadas à transação.

Ele não pode substituir o armazenamento de saldos ou informações que precisam permanecer disponíveis em transações futuras.

Antes de usá-lo em aplicativos cripto combináveis, os desenvolvedores devem entender seu comportamento em chamadas normais e delegate calls.

Use o otimizador Solidity

O otimizador Solidity pode simplificar expressões, remover operações desnecessárias, combinar cálculos e reduzir o tamanho do bytecode.

A documentação oficial do otimizador Solidity descreve várias etapas de otimização aplicadas ao código gerado.

O otimizador pode reduzir o gas de implantação, o gas de execução ou ambos.

A configuração runs representa uma estimativa de quantas vezes se espera que o código implantado seja executado.

Um valor menor de runs geralmente prioriza um bytecode de implantação menor.

Um valor maior de runs geralmente permite uma implantação maior em troca de custos mais baixos em execuções repetidas.

Nenhuma configuração de runs é ideal para todos os contratos inteligentes.

Os desenvolvedores devem comparar configurações de acordo com as expectativas reais de implantação e uso do contrato.

O pipeline de compilação baseado em IR pode produzir resultados diferentes do pipeline antigo e deve ser avaliado com testes completos.

Use um compilador atual e verificado

As versões do compilador Solidity podem incluir melhorias de gas, suporte a novas versões da EVM, correções de bugs e atualizações de segurança.

Antes de escolher um compilador para implantação em produção, os desenvolvedores devem consultar o site oficial da Solidity.

A documentação da Solidity geralmente recomenda usar uma versão lançada atual, a menos que o projeto tenha uma razão específica de compatibilidade para não fazê-lo.

Os desenvolvedores também devem consultar a lista oficial de bugs conhecidos do compilador Solidity.

A versão do compilador e as configurações de otimização devem ser fixadas no processo de compilação.

Recompilar o mesmo código-fonte com outro compilador pode produzir bytecode e comportamento de gas diferentes.

Use erros personalizados

Em geral, erros personalizados são mais eficientes em gas do que strings longas de reversão.

Uma string de reversão aumenta o bytecode de implantação e gera texto codificado quando a transação falha.

Um erro personalizado usa um seletor compacto e pode incluir parâmetros estruturados.

A documentação da Solidity sobre erros personalizados explica como os contratos podem definir e retornar esses erros.

Mesmo assim, os erros devem comunicar informações suficientes para que carteiras, usuários e desenvolvedores compreendam a falha.

Remover informações úteis sobre falhas para economizar uma quantidade muito pequena de gas pode dificultar o suporte e a auditoria do aplicativo.

Otimize loops

Loops podem ficar perigosamente caros quando o número de iterações depende de uma coleção que pode crescer sem um limite rígido.

Um loop sem limite pode acabar exigindo mais gas do que uma única transação pode fornecer.

Quando possível, grandes cargas de trabalho devem ser divididas em lotes previsíveis.

Um loop pode armazenar em cache o tamanho de um array ou um valor usado repetidamente, desde que essas informações não mudem durante a execução.

Às vezes, os desenvolvedores podem usar aritmética unchecked para um contador de loop quando o overflow for matematicamente impossível.

Código unchecked deve ser acompanhado de testes e de uma explicação clara de segurança.

Os compiladores modernos já otimizam muitos padrões comuns de loop. Por isso, alterações manuais devem ser medidas, em vez de presumidas mais baratas.

Reduza as chamadas a contratos externos

Chamadas a contratos externos geram custos de gas para acesso à conta, codificação de argumentos, processamento dos dados de retorno e execução do contrato chamado.

Um contrato deve evitar chamar repetidamente a mesma função externa quando uma única chamada segura puder fornecer o valor necessário.

Às vezes, várias ações relacionadas podem ser combinadas em uma chamada ou transação.

No entanto, o agrupamento pode aumentar a calldata, a complexidade da execução e a quantidade de trabalho revertida se uma etapa falhar.

Chamadas externas também trazem considerações de segurança relacionadas a reentrância, dados de retorno maliciosos, consumo de gas e falhas inesperadas.

A otimização de gas nunca deve remover verificações de valores retornados ou padrões seguros de interação.

Use eventos em vez de armazenamento quando apropriado

Eventos podem registrar a atividade da blockchain para carteiras, interfaces, sistemas de análise e indexadores off-chain.

Muitas vezes, eles custam menos do que armazenar as mesmas informações no estado persistente do contrato.

Eventos são adequados quando a execução futura de contratos inteligentes não precisa consultar nem aplicar as informações.

Histórico de transações, notificações de atividade e metadados descritivos podem ser apropriados para logs.

Saldos, permissões, dívidas, garantias e propriedade não devem ser armazenados apenas em eventos, pois a execução normal da EVM não consegue pesquisar logs históricos.

O contrato precisa manter em um estado acessível todas as informações necessárias para suas próprias decisões futuras.

Reduza o custo de implantação do contrato

A implantação de um contrato consome gas para executar sua lógica de inicialização e armazenar o bytecode de execução.

Funções não utilizadas, código duplicado, dados incorporados e mensagens de erro longas podem aumentar o custo de implantação.

Os desenvolvedores devem remover código inacessível e evitar importar uma biblioteca grande quando apenas uma pequena parte for necessária.

Bibliotecas podem reduzir a duplicação de bytecode entre vários contratos, embora chamadas a bibliotecas externas tenham seus próprios custos de execução e dependências.

Padrões factory e clone podem reduzir o custo de implantação quando são necessárias muitas instâncias semelhantes de contratos.

Padrões proxy também podem compartilhar o código de implementação, mas introduzem custos de delegate call, permissões de atualização e riscos relacionados ao layout do armazenamento.

A arquitetura deve ser escolhida com base nos requisitos de segurança e de ciclo de vida, e não apenas no gas de implantação.

Direcione o contrato para a versão correta da EVM

O compilador Solidity pode gerar bytecode diferente conforme a versão da EVM selecionada.

Versões mais recentes da EVM podem aceitar instruções mais eficientes que redes antigas não conseguem executar.

Por exemplo, a EIP-3855 introduziu a instrução compacta

para inserir zero na stack.

A EIP-5656 introduziu

para copiar memória com mais eficiência.

Os compiladores atuais podem usar automaticamente as instruções compatíveis quando configurados para a rede correta.

Um contrato compilado para uma EVM mais recente pode falhar em uma rede que ainda não ativou a atualização necessária.

Por isso, os desenvolvedores devem selecionar um destino EVM compatível com a blockchain em que pretendem implantar o contrato.

Entenda os reembolsos de gas

Os reembolsos de gas podem reduzir o gas final cobrado após determinadas operações de armazenamento elegíveis.

As regras atuais da Ethereum limitam os reembolsos previstos pelo protocolo a 20% do uso bruto de gas.

A EIP-3529 reduziu o reembolso pela limpeza de armazenamento elegível e removeu o reembolso anterior para

.

A limpeza do armazenamento ainda pode oferecer um benefício limitado, mas não torna gratuita a criação e a remoção de estados.

Os desenvolvedores não devem gravar dados desnecessários apenas para removê-los depois e receber um reembolso.

O reembolso também é aplicado depois da execução e, por isso, não pode evitar uma falha por falta de gas.

não é um método moderno de otimização de gas e tem comportamento restrito pela EIP-6780.

Considere o agrupamento com cuidado

Agrupar várias ações em uma transação pode evitar o pagamento repetido dos custos de transação.

Também pode melhorar a experiência do usuário ao reduzir o número de confirmações da carteira.

No entanto, cada ação ainda consome o gas necessário para sua própria computação e suas alterações de estado.

Um lote grande pode se aproximar dos limites de gas da transação ou gerar uma falha cara que reverta tudo.

Os aplicativos devem definir se falhas em ações secundárias revertem todo o lote ou permitem a conclusão parcial.

A autorização deve ser projetada com cuidado, pois uma assinatura ampla para um lote pode permitir mais atividade do que o usuário espera.

A EIP-7702 da Pectra permite que contas de propriedade externa deleguem a execução a código de contrato inteligente, dando suporte a recursos de carteira como agrupamento e patrocínio de gas.

A lógica de contas delegadas deve ser analisada com o mesmo cuidado que qualquer outro contrato que controle criptomoedas.

Use redes de camada 2 para economizar ainda mais

A otimização de contratos inteligentes reduz a quantidade de computação exigida por um aplicativo.

A implantação em uma rede de camada 2 adequada pode reduzir ainda mais o preço pago por essa computação e pelos dados associados.

Rollups processam transações fora da Ethereum mainnet e publicam dados ou provas de volta na Ethereum.

A atualização Dencun introduziu blobs por meio da EIP-4844, oferecendo aos rollups um mercado de dados temporários separado.

Taxas menores em camada 2 não eliminam a necessidade de otimizar o gas, pois contratos ineficientes continuam desperdiçando capacidade e custando mais do que contratos eficientes na mesma rede.

Os desenvolvedores também precisam avaliar a segurança das bridges, as regras de saque, a liquidez, a finalização e os cálculos de taxas específicos da rede.

Evite otimizações de baixo nível prematuras

Os desenvolvedores não devem começar com inline assembly ou manipulação complexa de bits antes de medir o código Solidity comum.

O compilador pode já gerar bytecode eficiente a partir de uma implementação clara de alto nível.

Às vezes, assembly pode reduzir o gas em operações especializadas, mas contorna várias proteções da linguagem.

Erros em assembly podem causar corrupção de memória, codificação incorreta, chamadas inseguras ou perda de fundos dos usuários.

Uma otimização de baixo nível deve ter uma implementação de referência legível e testes que comprovem o comportamento equivalente.

Uma revisão de segurança independente é especialmente importante quando assembly trata de saldos, assinaturas, permissões ou chamadas externas.

Não sacrifique a segurança para economizar gas

Um contrato não serve se, apesar de barato, permitir que invasores roubem as criptomoedas dos usuários.

Controles de acesso, validação de entradas, proteção contra reentrância, verificações de slippage, prazos e verificações contábeis não devem ser removidos apenas para reduzir o uso de gas.

A aritmética unchecked só deve ser usada quando overflow e underflow forem impossíveis em todas as condições alcançáveis.

O armazenamento compactado pode economizar gas, mas aumentar a probabilidade de erros na manipulação de bits.

Um proxy pode reduzir o custo de implantação e, ao mesmo tempo, introduzir controle centralizado de atualizações ou conflitos de armazenamento.

Uma assinatura off-chain pode eliminar uma transação, mas introduzir requisitos de nonce, expiração, proteção contra replay e separação de domínio.

As decisões de otimização devem ser avaliadas quanto à segurança, legibilidade, capacidade de atualização e risco operacional.

Testes de otimização de gas

Toda otimização deve ser testada em comparação com a implementação original.

Os testes funcionais devem confirmar que as duas versões produzem as mesmas alterações de estado e saídas.

Os testes de gas devem medir o uso médio, o uso máximo compatível e as condições de falha.

Testes fuzz podem explorar entradas incomuns que revelem um caminho de execução caro ou incorreto.

Testes de invariantes podem confirmar que propriedades essenciais de contabilidade e segurança continuam válidas após a otimização.

Os desenvolvedores também devem testar com a versão exata do compilador, as configurações do otimizador e o destino EVM previstos para produção.

Os registros de gas devem ser mantidos para que o desenvolvimento futuro não reverta silenciosamente a melhoria.

Erros comuns de otimização de gas

Um erro comum é presumir que todo tipo inteiro menor reduz o gas.

Outro erro é copiar dados externos somente para leitura de calldata para a memória sem necessidade funcional.

Os desenvolvedores também podem criar loops sem limite sobre coleções de armazenamento que se tornam impossíveis de executar conforme o aplicativo cresce.

Algumas equipes otimizam uma função raramente usada e ignoram um custo pequeno repetido em todas as transações dos usuários.

Outras escolhem configurações do otimizador sem testar o equilíbrio entre os custos de implantação e de execução.

Assembly escrito manualmente pode ser adicionado antes que a operação realmente cara tenha sido identificada.

Os desenvolvedores também podem confiar em tabelas de gas desatualizadas depois que uma atualização da Ethereum altera o preço de uma operação.

O erro mais perigoso é remover uma verificação de segurança necessária para obter um resultado impressionante em um benchmark de gas.

Como criar uma estratégia de otimização de gas

Uma estratégia de otimização de gas deve começar com a definição clara do comportamento e dos requisitos de segurança do contrato.

A equipe de desenvolvimento deve criar testes completos antes de alterar a implementação.

Em seguida, deve medir os custos de implantação e transação em condições realistas.

As operações de armazenamento, os loops, os dados de calldata e as chamadas externas mais caros devem ser priorizados.

A simplificação da arquitetura deve ser considerada antes da reescrita de código de baixo nível.

As configurações do compilador e a versão de destino da EVM devem ser testadas e registradas.

Toda otimização deve passar por uma revisão funcional, de gas e de segurança.

A implantação final deve usar bytecode reproduzível, compilado com ferramentas e dependências fixadas.

Perguntas frequentes

O que é otimização de gas em termos simples?

Otimização de gas significa reduzir a computação, o armazenamento e os dados de transação exigidos pela blockchain para executar um contrato inteligente com segurança.

A otimização de gas reduz o preço do gas?

Não. Ela reduz o uso de gas, enquanto o preço do gas é determinado pela demanda na rede e pelas configurações de taxa da transação.

Qual é a otimização de gas mais eficaz?

Reduzir operações desnecessárias de armazenamento persistente e simplificar a arquitetura do contrato costuma gerar as maiores economias.

O armazenamento é mais caro que a memória?

Sim. Em geral, o armazenamento persistente custa mais porque continua fazendo parte do estado da blockchain depois que a transação termina.

Calldata custa menos que memória?

Calldata pode custar menos para entradas externas somente para leitura, pois o valor completo não precisa ser copiado para a memória.

Tipos inteiros pequenos sempre economizam gas?

Não. Eles geralmente oferecem economias significativas de armazenamento apenas quando vários valores podem ser empacotados em uma posição.

O que é armazenamento transitório?

É um armazenamento da EVM limitado à transação, apagado automaticamente, que pode reduzir o custo de estados temporários do contrato.

O otimizador Solidity sempre reduz os custos?

Não. Uma configuração do otimizador pode reduzir o gas de execução e aumentar o custo de implantação. Por isso, cada configuração deve ser medida.

O que significa optimizer runs?

A configuração runs influencia o equilíbrio do compilador entre um bytecode de implantação menor e um custo menor para execuções repetidas.

Erros personalizados custam menos que strings de reversão?

Em geral, sim. Erros personalizados são mais eficientes porque usam seletores compactos e parâmetros codificados, em vez de strings de texto longas.

Eventos podem substituir o armazenamento?

Eventos podem substituir o armazenamento apenas quando a execução futura de contratos inteligentes não precisa consultar nem aplicar as informações.

Limpar o armazenamento gera um reembolso de gas?

A limpeza de armazenamento elegível pode gerar um reembolso limitado, mas ele tem um teto e não recupera todo o custo original do armazenamento.

Um reembolso de gas pode impedir uma falha por falta de gas?

Não. Os reembolsos de gas são calculados após a execução e não podem fornecer gas adicional enquanto a transação está em andamento.

Agrupar transações sempre economiza gas?

Não. O agrupamento pode reduzir custos repetidos de transação, mas também pode aumentar a calldata, a complexidade e o risco de falha.

Os desenvolvedores devem usar inline assembly para otimizar?

Inline assembly deve ser usado apenas em gargalos medidos, pois pode introduzir riscos sérios de segurança e manutenção.

Redes de camada 2 podem substituir a otimização de gas?

Não. Redes de camada 2 podem reduzir as taxas, mas contratos ineficientes continuam consumindo mais recursos do que contratos otimizados na mesma rede.

Por que os custos de gas podem mudar com o tempo?

Atualizações da Ethereum podem introduzir novos opcodes, alterar o preço de operações existentes, mudar as regras de calldata ou ampliar a capacidade da rede.

Como os desenvolvedores podem medir o uso de gas?

Os desenvolvedores podem usar relatórios de gas, recibos de transação, rastros de execução, saídas do compilador, registros automatizados e testes realistas.

A implementação que usa menos gas é sempre a melhor?

Não. Segurança, correção, legibilidade e facilidade de manutenção do contrato são mais importantes do que pequenas economias de gas.

Os usuários podem otimizar o gas sem alterar um contrato?

Os usuários podem escolher períodos de menor demanda ou redes adequadas, mas apenas o desenvolvedor do contrato pode alterar a eficiência de execução subjacente do aplicativo.

Conclusão

A otimização de gas é o processo de engenharia que reduz os recursos consumidos por contratos inteligentes e transações de criptomoedas.

Ela reduz o uso de gas, mas não altera diretamente o preço de mercado de cada unidade.

As otimizações mais eficazes geralmente vêm de uma arquitetura mais simples, menos operações de armazenamento, locais de dados eficientes, loops limitados e menos chamadas externas.

Otimização do compilador, constantes, valores imutáveis, erros personalizados, empacotamento de variáveis, armazenamento transitório e agrupamento adequado também podem gerar economias.

Os desenvolvedores devem usar um compilador atual, verificar os bugs conhecidos do compilador e definir a versão correta da EVM.

Toda otimização deve ser testada em transações bem-sucedidas, falhas, entradas grandes e caminhos de execução incomuns.

Os controles de segurança nunca devem ser removidos apenas para reduzir um relatório de gas.

Um contrato bem otimizado executa apenas o trabalho on-chain necessário para oferecer funcionalidades de criptomoedas seguras, transparentes e confiáveis.