Técnicas de otimização de gas

O que são técnicas de otimização de gas?

Técnicas de otimização de gas são métodos usados para reduzir os recursos computacionais e o armazenamento na blockchain necessários para uma transação de criptomoeda ou contrato inteligente.

Na Ethereum e em outras redes compatíveis com EVM, cada operação realizada pela Ethereum Virtual Machine tem um custo de gas.

Ler o armazenamento de um contrato, alterar o estado da blockchain, copiar dados, chamar outro contrato, emitir um evento e implantar bytecode podem consumir gas.

Normalmente, o usuário que envia uma transação paga uma taxa com base no gas cobrado e no preço efetivo do gas da transação.

A fórmula básica é: Taxa da transação = Gas cobrado × Preço efetivo do gas.

A otimização de gas reduz a parte de gas cobrado nessa fórmula.

Ela não controla diretamente o preço de mercado de cada unidade de gas, que muda conforme a demanda por espaço nos blocos.

Um contrato bem otimizado pode reduzir os custos para usuários, incluir mais atividade em cada bloco, aumentar a confiabilidade das transações e tornar um aplicativo descentralizado mais prático durante períodos de alta demanda na rede.

No entanto, a otimização de gas nunca deve enfraquecer os controles de acesso, a segurança aritmética, a proteção contra reentrância, a precisão contábil ou outras propriedades de segurança.

Em geral, a melhor otimização é um design mais simples, que executa menos trabalho, e não um código complexo escrito apenas para economizar algumas unidades de gas.

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

Cada operação on-chain desnecessária gera um custo para a pessoa ou o aplicativo que envia a transação.

Uma pequena diferença pode parecer insignificante em uma transação, mas se tornar relevante quando um contrato inteligente processa milhares ou milhões de interações.

Um menor uso de gas pode tornar mais acessíveis transferências de tokens, operações de finanças descentralizadas, atividades com NFT, votações de governança e jogos blockchain.

Contratos eficientes também podem ser mais fáceis de processar para validadores e nós, pois exigem menos leituras e gravações de armazenamento e menos etapas computacionais.

A otimização de gas é especialmente importante para aplicativos que executam loops repetidos, atualizam muitos saldos, criam novos contratos ou chamam vários sistemas externos em uma transação.

Ela também é importante para estratégias automatizadas de criptomoedas, pois custos de execução mais altos podem eliminar o lucro esperado de uma negociação ou liquidação.

A otimização de gas não garante que uma transação terá um custo baixo em moeda nacional, pois o preço do gas e o preço de mercado da criptomoeda nativa ainda podem subir.

Ela reduz a quantidade de trabalho da rede pela qual o usuário precisa pagar.

Entenda onde o gas é gasto

Antes de alterar o código de um contrato inteligente, os desenvolvedores devem entender as principais fontes de consumo de gas.

O armazenamento persistente costuma ser um dos recursos mais caros, pois os dados resultantes precisam permanecer no estado da blockchain.

A memória é um espaço de dados temporário usado durante uma execução e geralmente custa menos que o armazenamento persistente, embora seu custo aumente conforme a área de memória alocada cresce.

Calldata contém dados de entrada de uma transação ou função externa e não se torna memória modificável do contrato, a menos que seja copiada.

A implantação de um contrato consome gas para executar o código de inicialização e armazenar o bytecode de execução resultante.

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

Cálculos criptográficos, registros de eventos, criação de contratos e loops grandes também podem contribuir significativamente para o uso total de gas.

A documentação oficial sobre gas da Ethereum explica como o gas mede o esforço computacional exigido por transações e operações da EVM.

Meça o gas antes de otimizar

A otimização de gas deve começar com medições, não com suposições.

Os desenvolvedores devem registrar o custo de implantação e o custo de execução das funções importantes antes de alterar o código.

Os testes devem abranger tamanhos de transação realistas, comportamento normal dos usuários, entradas máximas compatíveis, caminhos de falha e estados incomuns da blockchain.

Uma função barata com um elemento em um array pode se tornar insegura ou cara demais com mil elementos.

Registros de gas podem comparar o custo das funções entre revisões do código e detectar aumentos acidentais.

Rastros de execução podem mostrar quais opcodes, posições de armazenamento, chamadas internas e chamadas externas consomem mais gas.

O compilador Solidity pode gerar estimativas de gas, conforme descrito em sua documentação, mas algumas estimativas podem não estar disponíveis ou ser pouco confiáveis quando a execução depende de loops dinâmicos ou do comportamento de contratos externos.

Testes em uma blockchain local ou em uma testnet pública mantida podem fornecer medições mais realistas.

Os desenvolvedores devem otimizar os caminhos caros que os usuários realmente executam, em vez de gastar tempo com código chamado raramente.

Use uma versão atual do compilador Solidity

Versões mais recentes do compilador Solidity frequentemente incluem melhorias na geração de código, correções do otimizador, suporte a novas instruções da EVM e atualizações de segurança.

Em julho de 2026, o site oficial da Solidity indicava a versão 0.8.36 como a versão mais recente do compilador.

Antes de selecionar um compilador para produção, os desenvolvedores devem consultar o site oficial da Solidity e a lista de bugs conhecidos do compilador.

A versão escolhida deve ser fixada na configuração de compilação para que todos os desenvolvedores, sistemas de teste e pipelines de implantação produzam bytecode consistente.

Usar uma diretiva de versão ampla sem controlar o ambiente real de compilação pode fazer diferentes versões do compilador gerarem códigos diferentes.

Mesmo assim, uma versão mais recente do compilador deve ser testada cuidadosamente, pois otimizações e alterações na linguagem podem afetar o bytecode, o custo de implantação e o comportamento do contrato.

Ative e configure o otimizador Solidity

O otimizador Solidity simplifica expressões, remove operações desnecessárias, combina cálculos repetidos e pode reduzir tanto o bytecode de implantação quanto o consumo de gas em execução.

A documentação do otimizador Solidity explica que a otimização pode reduzir o tamanho do código e o custo de execução.

A configuração runs do otimizador representa a frequência esperada de execução do código implantado.

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

Um valor maior de runs geralmente permite que o compilador gere um código que pode ser maior na implantação, mas mais barato em chamadas repetidas durante a execução.

Não existe um valor de runs universalmente ideal para todos os contratos de criptomoedas.

Um contrato implantado muitas vezes, mas raramente chamado, pode se beneficiar de configurações diferentes das de um contrato que deverá processar milhões de transações.

Os desenvolvedores devem comparar várias configurações usando testes reais e avaliar o custo total ao longo do ciclo de vida, em vez de considerar apenas o custo de implantação ou de execução.

O pipeline de compilação via-IR pode gerar otimizações diferentes das do pipeline legado, mas a mudança de pipeline deve ser tratada como uma alteração significativa na compilação e testada por completo.

Reduza as gravações no armazenamento persistente

As gravações no armazenamento persistente costumam oferecer uma das maiores oportunidades de economizar gas.

Um contrato deve evitar armazenar informações que possam ser calculadas com segurança a partir do estado existente ou fornecidas pelo usuário quando necessário.

Também deve evitar gravar repetidamente o mesmo valor quando puder primeiro verificar que nenhuma alteração é necessária.

Atualizar cinco variáveis de estado separadas pode custar mais do que usar um modelo contábil mais simples, com menos gravações.

Os desenvolvedores também devem avaliar se a informação precisa estar disponível para outros contratos inteligentes ou apenas para aplicativos off-chain.

Dados que precisam afetar a execução futura do contrato geralmente devem permanecer no armazenamento.

Informações necessárias apenas para carteiras, interfaces ou análises às vezes podem ser registradas em um evento.

Apagar dados do armazenamento pode gerar um reembolso limitado de gas pelas regras atuais da Ethereum, mas o reembolso tem um limite e não deve ser tratado como uma forma de tornar o armazenamento gratuito.

Os contratos devem remover estados obsoletos por razões sólidas de design, e não criar dados desnecessários na esperança de receber um reembolso posteriormente.

Armazene em cache leituras repetidas

Ler repetidamente uma posição de armazenamento custa mais do que lê-la uma vez e reutilizar um valor local quando o estado subjacente não precisa mudar entre as leituras.

A Ethereum diferencia o acesso a estado frio e aquecido de acordo com a EIP-2929.

O primeiro acesso a uma posição de armazenamento ainda não acessada em uma transação é frio e tem um custo maior.

Os acessos seguintes à mesma posição durante essa transação são aquecidos e custam menos.

Mesmo uma leitura aquecida do armazenamento pode custar mais do que usar um valor de stack ou de memória já disponível para a função.

Muitas vezes, uma função pode copiar uma variável de estado usada com frequência para uma variável local, executar os cálculos e gravar o resultado final apenas uma vez.

Esse método não deve ser usado quando uma chamada externa puder alterar o estado relevante ou tornar o valor em cache desatualizado.

Os desenvolvedores devem seguir os princípios checks-effects-interactions e analisar cuidadosamente a reentrância antes de armazenar o estado em cache ao redor de chamadas externas.

Empacote variáveis de estado com cuidado

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

Várias variáveis pequenas de tipos de valor podem compartilhar uma posição quando sua ordem e tamanho total permitem o empacotamento.

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

A documentação de layout de armazenamento da Solidity explica como variáveis, structs, arrays, herança e empacotamento afetam a atribuição de posições.

Por isso, a ordem das variáveis pode alterar o número de posições exigidas por um contrato.

No entanto, usar o menor tipo inteiro possível nem sempre é mais barato.

A EVM normalmente faz cálculos com palavras de 256 bits, então tipos inteiros menores podem exigir operações adicionais de máscara ou conversão.

O empacotamento traz o benefício mais claro quando vários valores empacotados são lidos ou gravados juntos com frequência.

Atualizar apenas um valor em uma posição empacotada pode exigir a leitura da posição, a modificação de parte da palavra e a gravação do valor combinado.

O layout do armazenamento também faz parte da compatibilidade de contratos atualizáveis. Por isso, os desenvolvedores não devem reordenar variáveis de estado existentes após a implantação apenas para economizar gas.

Use variáveis constant e immutable

Quando um valor nunca muda após a compilação, geralmente ele deve ser declarado

, quando a Solidity permitir.

Um valor definido durante a construção do contrato, mas fixo depois disso, pode ser declarado

.

Constantes e variáveis imutáveis evitam o acesso normal ao armazenamento persistente, pois seus valores são incorporados ao código ou armazenados junto dele.

A documentação oficial de contratos Solidity explica como essas variáveis diferem das variáveis de estado comuns.

Entre os exemplos comuns estão valores de configuração fixos, endereços permanentes, constantes matemáticas e limites que não podem mudar após a implantação.

Uma variável não deve ser declarada imutável quando o aplicativo realmente precisa que a governança ou outro processo autorizado possa atualizá-la.

Remover uma flexibilidade necessária apenas para economizar gas pode criar um problema operacional maior no futuro.

Use calldata para entradas externas somente para leitura

Argumentos de funções externas que não precisam ser modificados geralmente podem usar o local de dados

.

Calldata é somente para leitura e evita copiar toda a entrada para a memória no início da execução.

As orientações da Solidity sobre locais de dados recomendam usar calldata quando possível, pois isso evita cópias e impede modificações.

Essa técnica é especialmente útil para arrays, sequências de bytes, strings e structs passados a funções externas.

A memória continua sendo adequada quando o contrato precisa modificar os dados ou construir um novo valor em memória.

Os desenvolvedores não devem presumir que mudar o parâmetro de uma função de

para um inteiro menor reduz automaticamente o tamanho de calldata.

A codificação ABI padrão geralmente coloca valores estáticos em palavras de 32 bytes, e tipos menores podem gerar trabalho de conversão ou validação.

As economias de gas devem ser confirmadas por medições, e não deduzidas apenas do nome do tipo no código-fonte.

Minimize a calldata das transações

Cada byte incluído na calldata da transação contribui para o custo intrínseco da transação.

Arrays desnecessários, campos duplicados, strings longas e codificações ineficientes podem encarecer as transações dos usuários.

Às vezes, os desenvolvedores podem substituir valores completos repetidos por identificadores compactos que o contrato associa à configuração armazenada.

Também podem evitar enviar informações que o contrato consiga derivar com segurança do estado existente ou do remetente da transação.

A compressão pode ajudar em sistemas especializados, mas a descompressão consome gas e pode eliminar a economia esperada.

A Pectra ativou a EIP-7623, que introduziu um limite mínimo de gas mais alto para transações com muitos dados.

Isso torna a eficiência da calldata especialmente relevante para transações que transportam grandes quantidades de dados e executam relativamente pouca computação na EVM.

Os desenvolvedores devem comparar o custo de uma calldata compacta com o custo adicional de execução para decodificá-la.

Use armazenamento transitório para estado limitado à transação

O armazenamento transitório permite que contratos armazenem valores disponíveis durante chamadas internas em uma transação, mas que são apagados automaticamente quando a transação termina.

A Ethereum introduziu os opcodes

e por meio da EIP-1153.

O armazenamento transitório custa menos do que o persistente, pois os dados não passam a fazer parte do estado permanente da blockchain.

Um uso comum é um bloqueio de reentrância necessário apenas durante a execução de uma transação.

As versões atuais da Solidity aceitam variáveis de estado transitórias de tipos de valor quando os contratos têm como alvo a EVM Cancun ou uma versão compatível mais recente.

O armazenamento transitório não deve ser usado para informações que precisam persistir em transações futuras.

Também é necessário compreender seu comportamento em chamadas, delegate calls e contratos combináveis.

A documentação da Solidity sobre armazenamento transitório alerta que o estado transitório é limitado à transação e tem regras específicas de propriedade entre tipos de chamadas.

Os desenvolvedores não devem substituir um mecanismo de segurança comprovado por armazenamento transitório sem testar e auditar cuidadosamente a nova implementação.

Use erros personalizados em vez de strings longas de reversão

Erros personalizados oferecem um método eficiente em gas para retornar informações estruturadas sobre falhas.

Uma string longa de reversão integra o bytecode implantado e cria dados de retorno codificados quando a condição falha.

Um erro personalizado usa um seletor de quatro bytes e os parâmetros declarados, o que pode reduzir o tamanho da implantação e o custo do caminho de falha.

A documentação da Solidity sobre erros personalizados descreve esse recurso como uma forma prática e eficiente em gas de tratar erros.

Os nomes dos erros e seus parâmetros ainda devem ser claros o suficiente para que carteiras, desenvolvedores e sistemas de monitoramento diagnostiquem o problema.

Remover todas as informações úteis sobre falhas pode economizar uma pequena quantidade de gas, mas dificultar muito a investigação de transações cripto malsucedidas.

Otimize loops e o processamento de arrays

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

Um loop sem limite pode acabar exigindo mais gas do que uma transação pode fornecer, tornando inutilizável uma função importante do contrato.

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

Às vezes, um loop que lê repetidamente do armazenamento o tamanho de um array pode guardar esse tamanho em uma variável local.

Os valores de armazenamento usados em cada iteração também podem ser armazenados em cache quando isso for seguro.

Os desenvolvedores podem usar aritmética

para o contador de um loop somente quando puderem provar que o overflow é impossível.

Os compiladores modernos da Solidity já otimizam vários padrões comuns de loop. Por isso, uma alteração manual deve ser comparada antes de ser adotada.

Distribuir o trabalho entre várias transações pode melhorar a confiabilidade, mas o contrato precisa acompanhar o progresso com segurança e impedir trabalho ignorado, duplicado ou fora de ordem.

Evite chamadas externas redundantes

Chamar outro contrato consome gas e expõe a transação ao comportamento de execução do contrato chamado.

Uma função deve evitar solicitar repetidamente o mesmo valor externo quando puder fazer uma chamada segura e reutilizar o resultado.

Às vezes, várias ações relacionadas podem ser combinadas em uma chamada de contrato.

No entanto, o agrupamento aumenta o trabalho que pode falhar em conjunto e pode gerar uma carga maior de calldata.

Chamadas externas também podem permitir reentrância, retornar dados inesperados, consumir muito gas ou reverter a transação inteira.

A economia de gas nunca deve justificar a remoção de verificações de valores retornados ou de um tratamento seguro das chamadas.

Os desenvolvedores devem avaliar se um valor externo armazenado em cache continuará válido durante toda a execução e se o sistema externo pode alterá-lo por meio de um callback.

Use eventos em vez de armazenamento quando apropriado

Eventos registram informações em logs de transação, que podem ser indexados por aplicativos off-chain.

Muitas vezes, são menos caros do que armazenar as mesmas informações no estado do contrato.

Eventos são adequados para históricos de atividade, notificações em interfaces, análises e registros que a execução futura de contratos inteligentes não precisa consultar.

Eventos não substituem estados necessários para determinar saldos, propriedade, permissões, dívidas, garantias ou outros comportamentos do contrato.

Em geral, os contratos inteligentes não podem recuperar logs históricos durante a execução normal da EVM.

Um sistema que armazena informações contábeis críticas apenas em eventos precisaria de um serviço off-chain para reconstruí-las e não poderia aplicá-las diretamente on-chain.

Os parâmetros dos eventos também devem ser projetados com cuidado, pois os tópicos indexados e os dados de log têm custos de gas e propriedades de pesquisa diferentes.

Reduza o tamanho da implantação do contrato

A implantação de contratos cobra pela execução da lógica de inicialização e pelo armazenamento do bytecode de execução.

Funções não utilizadas, lógica duplicada, strings longas de reversão e dados incorporados podem aumentar o custo de implantação.

Os desenvolvedores devem remover código sem uso e evitar importar bibliotecas grandes quando precisarem de apenas uma pequena parte delas.

Bibliotecas externas podem reduzir a duplicação de bytecode entre implantações, embora chamá-las possa adicionar custos de execução e dependências operacionais.

Padrões factory e clone podem reduzir o custo de implantação de muitas instâncias semelhantes de contratos, compartilhando o código de implementação.

Padrões proxy podem permitir atualizações e implantações repetidas, mas adicionam custos de delegate call e criam considerações importantes de layout de armazenamento, governança e segurança.

A Ethereum limita o bytecode comum de execução implantado pela EIP-170, enquanto a EIP-3860 mede e limita o código de inicialização.

Dividir o código apenas para respeitar um limite de tamanho pode aumentar os custos das chamadas. Por isso, a arquitetura deve ser avaliada ao longo de todo o ciclo de vida do contrato.

Use a versão correta da EVM

O resultado do compilador depende da versão da EVM selecionada.

Um compilador direcionado a uma EVM mais recente pode usar instruções indisponíveis em uma rede mais antiga.

Por exemplo, Shanghai introduziu a instrução

por meio da EIP-3855, permitindo inserir o valor zero usando uma instrução menor e mais barata.

Dencun introduziu

por meio da EIP-5656, oferecendo um método mais eficiente para copiar memória.

Compiladores modernos podem usar essas instruções automaticamente quando configurados para uma rede compatível.

Em geral, os desenvolvedores não devem recriar manualmente essas otimizações do compilador em assembly.

Um contrato compilado para uma atualização de protocolo ainda não ativada na rede de destino pode falhar durante a implantação ou execução.

Por isso, os sistemas de compilação devem definir a versão correta da EVM para cada rede de destino.

Considere listas de acesso apenas depois de testar

As listas de acesso permitem que uma transação identifique as contas e chaves de armazenamento que espera acessar.

Os itens listados são tratados como aquecidos no início da execução, reduzindo a cobrança posterior pelo acesso frio.

A EIP-2930 cobra por cada endereço e chave de armazenamento incluídos na lista.

Uma lista de acesso precisa pode reduzir o custo de determinadas transações previsíveis.

Uma lista incompleta ou desnecessária pode aumentar a taxa total, pois o usuário paga por itens que oferecem pouco benefício ou não são usados.

Gerar listas de acesso pode ser difícil quando o caminho exato de execução depende de mudanças no estado da blockchain.

Os desenvolvedores devem simular a transação completa com e sem uma lista de acesso, em vez de presumir que pré-carregar o estado sempre é mais barato.

Agrupe as ações do usuário com cuidado

Combinar várias ações em uma transação pode evitar o pagamento repetido do custo básico da transação.

Por exemplo, um aplicativo pode permitir que o usuário aprove e execute uma ação por meio de um único fluxo coordenado.

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

O agrupamento não reduz automaticamente todos os componentes do custo de execução, pois cada ação ainda exige seu próprio trabalho de contrato.

Um lote grande pode exceder os limites práticos de gas, gerar mais calldata ou fazer todas as ações serem revertidas caso uma etapa falhe.

Os aplicativos devem definir se a conclusão parcial é permitida e como as ações secundárias malsucedidas são informadas.

As autorizações da carteira e o código delegado precisam ser analisados com cuidado, pois sistemas de agrupamento podem obter amplos poderes sobre os ativos do usuário.

Use redes de camada 2 quando apropriado

A otimização no nível do aplicativo reduz o número de unidades de gas consumidas, enquanto uma rede de camada 2 pode reduzir o preço que os usuários pagam pela execução e pelos dados.

Rollups processam atividade fora da Ethereum mainnet e publicam dados ou provas de volta na Ethereum.

A Dencun introduziu transações com blobs por meio da EIP-4844, oferecendo aos rollups um canal de dados temporário e mais especializado.

Posteriormente, Pectra e Fusaka ampliaram os recursos de escalabilidade e disponibilidade de dados da Ethereum.

As orientações atuais para desenvolvedores da Ethereum explicam como as atualizações recentes alteraram as taxas da mainnet, os recursos de contas e a economia dos rollups.

Implantar em uma rede de camada 2 não elimina a necessidade de contratos eficientes, pois armazenamento e computação desnecessários ainda aumentam as taxas dos usuários e reduzem a capacidade.

Antes de selecionar uma rede, os desenvolvedores também devem avaliar os requisitos de bridge, saque, liquidez, segurança e interoperabilidade.

Use inline assembly apenas quando necessário

Inline assembly pode dar aos desenvolvedores controle preciso sobre as operações da EVM e, ocasionalmente, reduzir o gas.

Também elimina ou contorna algumas verificações de tipos, proteções de memória e recursos de segurança de alto nível da Solidity.

Uma rotina curta em assembly pode ser difícil de entender para quem faz a revisão e introduzir corrupção de memória, codificação incorreta ou comportamento inseguro em chamadas.

O compilador talvez já otimize a Solidity comum e gere um código tão eficiente quanto uma implementação manual.

Por isso, o assembly deve ser reservado para gargalos medidos, criptografia especializada, processamento de dados de baixo nível ou funcionalidades que a Solidity não consiga expressar com eficiência.

Toda otimização em assembly deve incluir testes que comparem o resultado com uma implementação de referência clara.

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

Não sacrifique a segurança para economizar gas

Um contrato inteligente mais barato não é melhor se puder causar a perda das criptomoedas dos usuários.

Os desenvolvedores não devem remover verificações de controle de acesso, validação de entradas, proteção contra reentrância, verificação de prazo, proteção contra slippage ou verificações contábeis apenas para economizar gas.

A aritmética

só deve ser usada quando for matematicamente impossível ocorrer overflow ou underflow em qualquer condição alcançável.

Combinar várias variáveis em um valor compactado pode economizar armazenamento, mas aumentar a chance de erros na manipulação de bits.

Usar um proxy pode reduzir o custo de implantação, mas cria riscos relacionados à autoridade de atualização e a conflitos de armazenamento.

Usar uma assinatura off-chain pode reduzir o número de transações, mas exige tratamento correto de nonce, expiração, separação de domínio e proteção contra replay.

Além do custo de gas, toda otimização deve ser avaliada quanto à legibilidade, auditabilidade, risco operacional e manutenção futura.

Erros comuns de otimização de gas

Um erro comum é escolher tipos inteiros menores sem empacotá-los com outros valores.

A EVM opera com palavras de 256 bits, então um tipo menor pode não reduzir o custo de execução por si só.

Outro erro é copiar todos os dados de calldata para a memória quando a função só precisa lê-los.

Um terceiro erro é limpar o armazenamento apenas para tentar obter um reembolso, planejando recriar o mesmo estado depois.

Um quarto erro é usar um loop sem limite sobre um array de armazenamento em crescimento.

Um quinto erro é definir um valor alto de runs do otimizador sem comparar o comportamento da implantação e da execução.

Um sexto erro é escrever assembly manualmente antes de analisar o desempenho do contrato.

Um sétimo erro é presumir que uma otimização continuará válida depois que uma atualização do compilador ou da rede alterar o comportamento dos opcodes.

Um oitavo erro é medir apenas transações bem-sucedidas e ignorar caminhos de reversão caros.

Um nono erro é tratar uma estimativa menor de gas como prova de que duas implementações têm a mesma lógica de segurança e de negócio.

Como criar um processo de otimização de gas

Um processo confiável começa com a definição do comportamento exigido do contrato e de suas propriedades de segurança.

A equipe deve criar testes funcionais antes de tentar otimizações de baixo nível.

Depois, deve medir o custo de implantação e o gas utilizado em cada caminho importante de transação.

As gravações de armazenamento, os loops, os dados de entrada de calldata e as chamadas externas mais caros devem ser identificados por meio de análise de desempenho.

Os desenvolvedores podem simplificar a arquitetura, reduzir alterações de estado, selecionar locais de dados adequados e ativar configurações testadas de otimização do compilador.

Cada alteração deve ser comparada à versão original e analisada quanto a novos riscos de segurança.

Os testes de regressão de gas devem permanecer no projeto para impedir que o desenvolvimento futuro elimine silenciosamente as economias.

O bytecode final de produção deve ser compilado com um compilador fixo, configuração verificada, versão correta da EVM e versões revisadas das dependências.

Contratos de criptomoedas de alto valor devem passar por auditoria de segurança independente, mesmo quando o código otimizado for aprovado nos testes internos.

Perguntas frequentes

Qual é a melhor técnica de otimização de gas?

Em geral, a técnica mais eficaz é reduzir as operações de armazenamento persistente e simplificar o trabalho on-chain realizado em cada transação.

O otimizador Solidity sempre reduz o gas?

Não. Uma configuração do otimizador pode reduzir o gas de execução e aumentar o custo de implantação. Por isso, os desenvolvedores devem testar o ciclo de vida completo do contrato.

O que significa a configuração runs do otimizador?

Ela informa ao compilador com que frequência o desenvolvedor espera que o código de execução seja usado e influencia o equilíbrio entre o tamanho da implantação e o custo de execuções repetidas.

O armazenamento é mais caro que a memória?

Sim. Em geral, o armazenamento persistente custa muito mais, pois os dados continuam 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 contrato consegue acessá-la sem antes copiá-la toda para a memória.

Tipos inteiros menores sempre economizam gas?

Não. Eles são mais úteis quando vários valores podem ser empacotados em uma única posição de armazenamento. Tipos pequenos isolados podem exigir operações adicionais de conversão.

Por que os desenvolvedores devem armazenar valores em cache?

O cache pode evitar leituras repetidas do armazenamento quando um valor não muda e pode ser reutilizado com segurança a partir da stack ou da memória.

O que é armazenamento transitório?

É um armazenamento da EVM limitado à transação, apagado automaticamente, que pode oferecer estado temporário de menor custo, como bloqueios contra reentrância.

Erros personalizados custam menos que strings de reversão?

Em geral, sim. Erros personalizados são mais eficientes em gas porque usam um seletor compacto e parâmetros codificados, em vez de armazenar e retornar strings longas.

Eventos podem substituir o armazenamento do contrato?

Eventos podem substituir o armazenamento apenas para informações que a execução futura de contratos inteligentes não precise consultar nem aplicar.

Apagar dados do armazenamento reembolsa todo o gas gasto?

Não. Os reembolsos por limpeza do armazenamento são limitados e estão sujeitos ao teto de reembolso de gas do protocolo.

Os desenvolvedores devem usar aritmética unchecked para economizar gas?

A aritmética unchecked só deve ser usada quando for possível provar que overflow ou underflow não pode ocorrer e que a justificativa de segurança está documentada e foi testada.

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 de execução e o risco de falha total.

Uma rede de camada 2 pode substituir a otimização de contratos?

Não. Taxas menores na rede podem reduzir o custo para os usuários, mas contratos ineficientes ainda desperdiçam capacidade de execução e custam mais do que contratos otimizados na mesma rede.

As listas de acesso sempre reduzem o gas?

Não. Os itens de uma lista de acesso têm custo próprio e podem aumentar a taxa quando a lista é imprecisa ou desnecessária.

Inline assembly sempre usa menos gas?

Não. O compilador pode gerar um código igualmente eficiente, enquanto assembly inseguro pode introduzir sérios problemas de segurança e manutenção.

Como os desenvolvedores podem medir o uso de gas?

Podem usar estimativas do compilador, registros automatizados de gas, testes de transações locais, rastros de execução e ferramentas de análise de desempenho.

Por que os custos de gas podem mudar após uma atualização de rede?

Atualizações da Ethereum podem adicionar opcodes, alterar o preço de operações existentes, mudar as regras de calldata ou introduzir recursos mais eficientes de armazenamento e memória.

A otimização de gas pode impedir taxas altas na rede?

Ela reduz as unidades de gas consumidas, mas não impede que o preço de mercado do gas suba quando muitos usuários disputam o espaço dos blocos.

O contrato mais barato é sempre o melhor?

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

Conclusão

As técnicas de otimização de gas reduzem os recursos computacionais, de armazenamento, de calldata e de implantação exigidos por contratos inteligentes de criptomoedas.

As maiores economias costumam vir da redução de gravações no armazenamento persistente, do armazenamento seguro de leituras em cache, da escolha dos locais de dados corretos, da redução de calldata desnecessária e da prevenção de chamadas externas redundantes.

Compiladores Solidity modernos podem otimizar o bytecode automaticamente, mas as configurações do otimizador devem ser escolhidas com base em medições realistas, não em suposições.

Recursos atuais da Ethereum, como armazenamento transitório,

, , código delegado de conta e preços atualizados de calldata, mudaram a forma como os desenvolvedores devem abordar a otimização.

Os desenvolvedores devem usar a versão correta da EVM e manter atualizados o compilador, os testes e o conhecimento das regras do protocolo.

Técnicas como empacotamento de variáveis, erros personalizados, loops limitados, agrupamento, eventos, bibliotecas e implantação em camada 2 podem reduzir custos quando são compatíveis com o design do aplicativo.

Listas de acesso, proxies, inline assembly, aritmética unchecked e armazenamento compactado exigem cautela adicional, pois um pequeno benefício em gas pode introduzir complexidade ou riscos significativos.

Toda otimização deve ser medida considerando implantação, execução bem-sucedida, caminhos de falha e uso do contrato a longo prazo.

Verificações de segurança nunca devem ser removidas apenas para reduzir um relatório de gas.

A melhor estratégia de otimização de gas é executar apenas o trabalho on-chain mínimo necessário para operações de criptomoedas seguras e verificáveis.