Gas golfing

O que é gas golfing?

Gas golfing é a prática de fazer pequenas alterações pontuais no código de contratos inteligentes para reduzir o consumo de gas.O termo vem de code golf, um desafio de programação em que desenvolvedores tentam resolver um problema usando a menor quantidade possível de código-fonte.No desenvolvimento de criptomoedas, o objetivo não é necessariamente escrever o menor número de caracteres.O objetivo é produzir bytecode que consuma menos recursos da blockchain e, ao mesmo tempo, preserve o comportamento exigido do contrato.Gas golfing é mais associado à Ethereum e a outras redes que executam contratos inteligentes por meio da Ethereum Virtual Machine.Desenvolvedores podem aplicar gas golfing a um contrato reduzindo operações de armazenamento, simplificando cálculos, encurtando dados de reversão (revert), evitando cópias desnecessárias de memória ou escolhendo instruções EVM de menor custo.Em geral, gas golfing se concentra em micro-otimizações, e não em uma reformulação completa do aplicativo.Por isso, é mais específico do que a otimização de gas em geral, que pode envolver arquitetura do contrato, agrupamento de transações, implantação em Layer 2, design do aplicativo e computação off-chain.Uma alteração bem-sucedida de gas golfing deve preservar a segurança, a correção, a legibilidade e a compatibilidade.Economizar uma pequena quantidade de gas não vale a pena se a alteração criar uma vulnerabilidade ou tornar impossível manter o contrato com segurança.

Por que se chama gas golfing?

A palavra golfing se refere ao objetivo de obter uma pontuação menor.No golfe tradicional, um número menor de tacadas é melhor.No gas golfing de contratos inteligentes, uma quantidade menor de gas costuma ser considerada melhor quando o código otimizado executa a mesma tarefa com segurança.Desenvolvedores podem comparar duas implementações medindo o gas de implantação, o gas em tempo de execução, o tamanho do bytecode ou o custo total ao longo da vida útil esperada do contrato.Um desafio de gas golfing pode pedir que os participantes implementem uma função usando a menor quantidade possível de gas.O desenvolvimento de produção é mais complexo, pois a solução que consome menos gas pode não ser a mais segura nem a mais fácil de auditar.O termo é informal e não descreve um protocolo, token, tipo de transação ou padrão oficial de programação da Ethereum.

Como funciona o gas golfing

A Ethereum atribui um custo de gas a cada operação executada pela Ethereum Virtual Machine.

A documentação oficial de gas da Ethereum explica que o gas mede o esforço computacional necessário para executar transações e operações de contratos inteligentes.

Aritmética, uso de memória, armazenamento persistente, logs de eventos, chamadas de contratos, criação de contratos e dados de transação contribuem para o consumo de gas.O gas golfing busca uma sequência de operações menos custosa que produza o mesmo resultado exigido.Por exemplo, um desenvolvedor pode substituir várias leituras de armazenamento por uma única leitura e reutilizar o valor carregado em uma variável local.Outro desenvolvedor pode substituir uma longa mensagem de revert por um erro personalizado compacto.Em um nível mais baixo, um desenvolvedor pode substituir um loop de cópia de memória criado manualmente por uma instrução EVM projetada especificamente para copiar memória.A melhoria final deve ser medida no bytecode compilado, pois um código Solidity visualmente mais curto nem sempre resulta em uma execução EVM mais barata.

Gas golfing vs. otimização de gas

Otimização de gas é o processo amplo de reduzir o custo de implantação e execução de contratos inteligentes.Gas golfing é uma forma mais restrita de otimização, que normalmente enfatiza pequenas economias no nível do código.Um projeto completo de otimização de gas pode reformular o modelo de armazenamento do aplicativo, transferir para off-chain computações adequadas, usar uma rede Layer 2 ou reduzir o número de transações necessárias de cada usuário.Já o gas golfing pode comparar duas estruturas de loop, dois métodos de tratamento de erros ou duas formas de carregar o mesmo valor.A otimização arquitetural costuma proporcionar economias maiores do que a micro-otimização.No entanto, uma pequena economia recorrente pode se tornar significativa quando uma função é executada milhões de vezes.Desenvolvedores profissionais devem primeiro eliminar trabalho desnecessário no nível arquitetural e, depois, aplicar gas golfing aos caminhos de execução importantes que restarem.

Gas golfing vs. code golf

Code golf tenta minimizar o tamanho do código-fonte, muitas vezes sem priorizar a legibilidade ou a manutenção no longo prazo.Gas golfing tenta minimizar o custo de execução na blockchain.A expressão Solidity mais curta pode ser compilada em mais instruções do que uma expressão mais longa e clara.A otimização do compilador também pode transformar diferentes estilos de código-fonte em bytecode idêntico.Por isso, os desenvolvedores devem comparar o resultado compilado e o gas medido, em vez de contar caracteres do código-fonte.Uma solução de code golf pode ser divertida, mas inadequada para um contrato que controla criptomoedas de valor.O gas golfing em produção deve sempre incluir testes de segurança, documentação e revisão.

Gas golfing vs. preços de gas mais baixos

Gas golfing reduz o número de unidades de gas consumidas por uma transação.Ele não reduz diretamente o preço de mercado pago por cada unidade de gas.A taxa de transação pode ser representada por Gas cobrado × preço efetivo do gas.Uma alteração de gas golfing tem como alvo a parte referente ao gas cobrado nessa fórmula.A demanda da rede, a taxa-base do protocolo e a taxa de prioridade do usuário afetam o preço efetivo do gas.Um contrato pode ser altamente otimizado e ainda assim ser caro de usar durante um congestionamento intenso da rede.Um contrato mal otimizado também pode continuar desperdiçando recursos mesmo quando o preço do gas está temporariamente baixo.

Por que desenvolvedores praticam gas golfing

Gas golfing pode reduzir o custo pago por cada usuário que interage com uma função de contrato inteligente chamada com frequência.Taxas de transação mais baixas podem tornar as finanças descentralizadas, transferências de tokens, jogos blockchain, operações com NFTs e sistemas de governança mais acessíveis.Gas golfing também pode reduzir o custo de implantação de um contrato quando a otimização diminui o trabalho de inicialização ou o tamanho do bytecode em tempo de execução.Estratégias automatizadas de criptomoedas podem depender de pequenas economias de gas, pois as taxas de transação reduzem diretamente os retornos esperados.Protocolos que executam muitas operações internas repetidas podem economizar quantias substanciais, mesmo quando cada melhoria individual é pequena.O menor consumo de gas também deixa mais capacidade de bloco disponível para outras transações.No entanto, a otimização deve se basear no uso esperado, e não no desejo de obter o menor benchmark possível em um caso de teste irrealista.

Meça antes de aplicar gas golfing

Os desenvolvedores devem medir o consumo de gas antes de tentar uma micro-otimização.O compilador existente pode já remover a operação que parece desnecessária.Uma alteração que reduzia o gas em uma versão antiga do Solidity pode não trazer benefício em um compilador atual.Outra alteração pode reduzir o gas em tempo de execução, mas aumentar o custo de implantação do contrato.Os testes de gas devem abranger as funções executadas com mais frequência pelos usuários.Também devem abranger entradas mínimas, entradas máximas compatíveis, execução bem-sucedida e caminhos de falha.

A documentação do compilador Solidity descreve opções de saída do compilador e estimativas de gas.

As estimativas do compilador podem ser incompletas quando loops, chamadas externas ou o estado dinâmico da blockchain afetam a execução.Por isso, os desenvolvedores devem combinar a saída do compilador com testes de transações reais e rastros de execução.

Use um compilador Solidity atualizado

As versões do compilador Solidity adicionam regularmente otimizações, suporte à EVM, recursos de linguagem e correções de segurança.

O anúncio oficial da versão Solidity 0.8.36 identifica a versão 0.8.36 como a versão atual em julho de 2026.

Essa versão inclui correções de segurança e avanços adicionais em um pipeline experimental de geração de código em formato SSA.Um resultado de gas golfing obtido com uma versão do compilador pode não corresponder ao resultado de outra versão.Os desenvolvedores devem fixar a versão do compilador, a configuração do otimizador, o alvo EVM e as versões das dependências usadas em builds de produção.

Também devem consultar a lista oficial de bugs do compilador Solidity antes de implantar contratos que controlam criptomoedas de valor.

Atualizar o compilador apenas para reduzir o consumo de gas, sem testar novamente o aplicativo inteiro, pode introduzir comportamentos inesperados ou diferenças no bytecode.

Use o otimizador Solidity antes do gas golfing manual

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

A documentação oficial do otimizador Solidity explica que a otimização pode reduzir tanto o tamanho da implantação quanto o custo de execução.

O gas golfing manual deve levar em conta o que o otimizador já faz.Duas funções Solidity visivelmente diferentes podem ser compiladas no mesmo bytecode otimizado.A configuração runs do otimizador influencia o equilíbrio entre um código de implantação menor e custos recorrentes de execução mais baixos.Um valor baixo de runs geralmente dá mais peso ao tamanho da implantação.Um valor alto de runs geralmente dá mais peso à execução repetida em tempo de execução.A melhor configuração depende da frequência de implantação do contrato e da frequência com que cada função será chamada.Os desenvolvedores devem comparar várias configurações testadas, em vez de usar um valor tradicional sem medi-lo.

Armazene em cache leituras repetidas de storage

O acesso ao armazenamento persistente costuma ser mais caro do que usar um valor já disponível na pilha da EVM ou na memória.Uma técnica comum de gas golfing é carregar um valor de storage uma vez em uma variável local e reutilizá-lo.

A Ethereum aplica custos de acesso cold e warm conforme a EIP-2929.

O primeiro acesso a um slot de storage em uma transação geralmente é mais caro do que os acessos posteriores ao mesmo slot.Até mesmo leituras warm de storage podem ser evitadas quando o contrato já tem uma cópia local correta.O desenvolvedor também pode calcular o resultado final localmente e fazer uma única gravação em storage, em vez de gravar cada valor intermediário.O cache não é seguro quando uma chamada externa pode alterar o estado relevante antes que o valor armazenado em cache seja usado novamente.É preciso considerar reentrância, callbacks, chamadas delegate e comportamentos herdados antes de aplicar essa técnica.

Reduza as gravações em storage

Gravar estado persistente é uma das operações comuns mais caras em contratos inteligentes.Um contrato deve evitar gravar um valor quando o valor solicitado já está armazenado.Também deve evitar registrar informações que possam ser derivadas com segurança do estado existente.Às vezes, vários valores relacionados podem ser representados por um único índice acumulado ou ponto de controle contábil.Uma função também pode fazer cálculos localmente e gravar em storage apenas o resultado final.Essas alterações podem gerar economias muito maiores do que reescrever uma pequena expressão aritmética.Os desenvolvedores devem confirmar que o modelo de estado simplificado ainda permite saldos, permissões, registros históricos e upgrades corretos.

Empacote variáveis de storage

A Ethereum divide o storage dos contratos em slots de 32 bytes.O Solidity pode empacotar várias variáveis menores de tipo valor em um único slot quando a ordem e o tamanho combinado permitem.

A documentação de layout de storage do Solidity explica como as variáveis são atribuídas e empacotadas.

Reduzir o número de slots de storage necessários pode diminuir o gas de implantação e de execução em casos adequados.Tipos inteiros menores não economizam gas automaticamente quando são armazenados separadamente.A EVM normalmente realiza operações aritméticas com palavras de 256 bits, portanto tipos menores podem exigir máscaras ou conversões adicionais.O empacotamento é mais útil quando os valores empacotados são acessados ou alterados juntos com frequência.Variáveis de storage não devem ser reordenadas em um contrato atualizável já implantado, pois o novo layout pode interpretar incorretamente os dados existentes.

Use valores constant e immutable

Uma variável de estado comum gera custos de storage quando o valor precisa ser lido do estado persistente.

Um valor conhecido em tempo de compilação pode ser declarado como

.

Um valor escolhido durante a construção e fixado após a implantação pode ser declarado como

.

A documentação de contratos do Solidity explica que esses valores não usam slots de storage comuns da mesma forma que variáveis de estado mutáveis.

Endereços permanentes, valores matemáticos e limites de configuração fixos são candidatos comuns.Um valor não deve ser declarado immutable quando o aplicativo realmente exige um processo autorizado de atualização.Economizar gas removendo uma flexibilidade de configuração necessária pode criar uma limitação operacional dispendiosa ou perigosa.

Use calldata para entradas somente leitura

As entradas de funções externas que não precisam ser modificadas muitas vezes podem permanecer em

.

Usar calldata pode evitar copiar uma string, sequência de bytes, array ou struct grande para a memória.

A documentação sobre localização de dados do Solidity explica as diferenças entre calldata, memory, storage e transient storage.

Essa técnica é mais útil para entradas externas dinâmicas que a função apenas lê.A memória continua sendo necessária quando o contrato precisa modificar o valor ou construir novos dados em memória.Os desenvolvedores também devem remover dados de entrada de transação desnecessários, pois os bytes de calldata contribuem para o custo intrínseco de gas.Codificar um valor de forma mais compacta pode economizar gas de calldata, mas o cálculo deve incluir o custo da decodificação.

Use erros personalizados

Erros personalizados podem reduzir o bytecode do contrato e o custo dos dados de revert em comparação com mensagens de erro longas.Um erro personalizado usa um seletor compacto de quatro bytes e pode incluir parâmetros estruturados.

A documentação oficial do Solidity sobre erros personalizados os descreve como um método eficiente em gas para informar falhas.

Por exemplo, um erro pode incluir o endereço de quem chamou e o saldo necessário sem incorporar uma frase longa ao bytecode em tempo de execução.Um erro personalizado não torna gratuita a execução bem-sucedida, pois o contrato ainda precisa avaliar a condição.Os erros devem continuar compreensíveis o suficiente para que carteiras, interfaces, auditores e desenvolvedores diagnostiquem transações de criptomoedas com falha.

Ordene condições para avaliação de curto-circuito

Expressões booleanas do Solidity podem parar antes do fim quando o resultado final já é conhecido.Em uma expressão com AND lógico, a avaliação pode parar após a primeira condição falsa.Em uma expressão com OR lógico, a avaliação pode parar após a primeira condição verdadeira.Colocar uma condição barata antes de uma condição cara pode reduzir o gas médio quando a condição barata costuma determinar o resultado.Essa técnica deve preservar o comportamento lógico pretendido e quaisquer pressupostos sobre funções que possam causar revert ou efeitos colaterais.As condições não devem ser reordenadas sem critério quando a ordem for relevante para a segurança ou para a comunicação de erros.

Otimize loops com cuidado

Um loop pode consumir grandes quantidades de gas quando processa muitos elementos.Os desenvolvedores podem armazenar em cache o tamanho de um array acessado repetidamente quando a coleção não puder mudar durante o loop.Também podem armazenar em cache valores de storage usados em cada iteração.

Um contador de loop pode usar um incremento

quando for matematicamente impossível ocorrer overflow.

Compiladores modernos já otimizam alguns padrões comuns de incremento, então a economia deve ser medida com o compilador escolhido.A afirmação comum de que o incremento prefixado é sempre mais barato do que o pós-fixado não é uma regra universal confiável para o código Solidity otimizado atual.Um loop sem limite sobre uma coleção de storage em crescimento é um problema arquitetural, não uma pequena oportunidade de gas golfing.Cargas de trabalho grandes devem ser divididas em lotes limitados ou reformuladas para que os usuários processem seus próprios estados independentes.

Use aritmética unchecked somente com comprovação

O Solidity 0.8 e versões posteriores normalmente verificam overflow e underflow em operações com inteiros.Essas verificações consomem algum gas, mas evitam classes importantes de erros de programação.

Um bloco

remove a verificação automática das operações realizadas dentro dele.

Isso pode economizar gas quando limites matemáticos já comprovam que não pode ocorrer overflow.Um contador de loop limitado é um exemplo comum, embora o argumento exato de segurança dependa do design do loop.A aritmética unchecked não deve ser usada apenas porque se espera que a entrada normalmente continue pequena.O código deve incluir testes e documentação clara demonstrando por que toda entrada alcançável permanece segura.

Use transient storage para estado temporário

Transient storage fornece estado limitado à transação, que é apagado automaticamente quando ela termina.

A Ethereum introduziu as operações

e por meio da EIP-1153.

Transient storage pode ser mais barato do que storage persistente quando os dados são necessários entre chamadas, mas não entre transações.Um bloqueio de reentrância é um exemplo comum de informação limitada à transação.Transient storage não pode substituir saldos persistentes, propriedade, dívidas ou configurações necessárias em transações futuras.Os desenvolvedores devem entender como o estado transitório se comporta entre chamadas, chamadas delegate e reverts.Substituir um controle de segurança comprovado por uma implementação transitória de menor custo exige testes e revisão completos.

Use instruções EVM modernas

Atualizações da Ethereum podem introduzir instruções que substituem sequências mais caras de operações antigas.

A EIP-3855 introduziu

, que coloca zero na pilha usando uma instrução compacta.

A EIP-5656 introduziu

, uma operação dedicada à cópia de memória.

Um compilador Solidity atualizado pode usar automaticamente instruções EVM compatíveis quando a versão EVM correta é selecionada.Em geral, os desenvolvedores não devem substituir código gerado pelo compilador por assembly escrito à mão apenas para forçar o uso de uma instrução.Um contrato compilado para um novo alvo EVM pode falhar em uma rede que ainda não ativou as instruções necessárias.Por isso, os resultados de gas golfing devem identificar exatamente o compilador e o alvo EVM usados na medição.

Reduza chamadas externas

Chamadas a contratos externos geram custos de acesso à conta, codificação de argumentos, processamento de dados de retorno e execução do contrato chamado.Um contrato pode economizar gas evitando chamadas repetidas que retornam o mesmo valor durante uma transação.Às vezes, várias leituras relacionadas podem ser combinadas em uma chamada que retorna um resultado estruturado.No entanto, alterar a estrutura das chamadas pode afetar a reentrância, o tratamento de erros, a composabilidade e os limites entre contratos.Os valores de retorno e as condições de sucesso ainda devem ser verificados corretamente.Uma chamada barata que leve a uma suposição insegura não é uma otimização válida.

Use eventos em vez de storage quando apropriado

Logs de eventos costumam ser menos caros do que storage persistente para informações usadas apenas por aplicativos off-chain.Eventos podem dar suporte a históricos de transações, análises, feeds de atividade e notificações de interface.Em geral, futuras execuções de contratos inteligentes não conseguem pesquisar logs históricos de eventos.Por isso, saldos, permissões, propriedade, garantias e outros estados aplicáveis devem continuar acessíveis ao contrato.Gas golfing com eventos só é apropriado quando o valor removido do storage não é necessário para futuras decisões on-chain.Os desenvolvedores também devem considerar o custo de tópicos de eventos indexados e dos dados de log ao projetar o evento.

Reduza o bytecode de implantação

A Ethereum cobra gas para armazenar o bytecode em tempo de execução de um contrato durante a implantação.Remover funções não utilizadas, lógica duplicada, mensagens longas de revert e dados incorporados desnecessários pode reduzir o custo de implantação.Erros personalizados, bibliotecas internas, implementações compartilhadas e uma configuração cuidadosa da otimização do compilador podem reduzir o tamanho do código.

A Ethereum limita o código de execução implantado normalmente conforme a EIP-170.

O código de inicialização é medido e limitado separadamente pela EIP-3860.

Um contrato menor não é automaticamente mais barato ao longo de toda a sua vida útil, pois dividir o código entre vários contratos pode adicionar custos repetidos de chamadas externas.Os desenvolvedores devem avaliar juntos o custo de implantação e o custo recorrente de execução.

Entenda as limitações dos reembolsos de gas

Estratégias antigas de gas golfing na Ethereum às vezes dependiam fortemente da criação e posterior exclusão de storage.As regras atuais da Ethereum limitam muito essa abordagem.

A EIP-3529 reduziu os reembolsos por limpeza de storage, removeu o antigo reembolso de

e limitou os reembolsos aplicados a 20% do consumo bruto de gas.

Um contrato não deve criar estado desnecessário na esperança de receber depois um reembolso igual ou maior.Os reembolsos de gas são aplicados após a execução e não podem impedir uma falha por falta de gas.

também não é uma técnica moderna de gas golfing, pois não oferece reembolso e seu comportamento de exclusão foi restringido.

Gas golfing de calldata e EIP-7623

Às vezes, desenvolvedores aplicam gas golfing aos dados de entrada da transação usando tipos compactos, empacotamento de bits, codificações personalizadas ou representações mais curtas.Reduzir os bytes da transação pode diminuir o gas intrínseco, principalmente quando muitas ocorrências de valores repetidos são eliminadas.

No entanto, a Pectra ativou a EIP-7623, que introduziu um piso de gas mais alto para transações com muitos dados e pouca execução.

As operações de decodificação necessárias para um formato compacto também consomem gas.Uma codificação personalizada pode reduzir o custo em grandes cargas de trabalho repetidas, mas não trazer benefício para transações pequenas.Uma codificação não padronizada pode dificultar carteiras, auditorias, integrações e depuração.Os desenvolvedores devem fazer benchmark de todo o processo de codificação e decodificação conforme as regras atuais do protocolo.

Quando o inline assembly é apropriado

O inline assembly dá aos desenvolvedores controle direto sobre instruções EVM, memória, storage, chamadas e dados de retorno.Ele pode gerar economias de gas quando o Solidity de alto nível não consegue expressar uma operação especializada com eficiência.O assembly costuma ser considerado para rotinas criptográficas, análise de dados compactos, operações incomuns de memória e funções de baixo nível executadas repetidamente.Ele também contorna muitas das proteções de tipo, memória e segurança fornecidas pelo Solidity.Um erro de assembly pode corromper a memória, codificar dados incorretamente, tratar mal valores de retorno ou expor criptomoedas a roubo.Cada implementação em assembly deve ser comparada com uma implementação de referência clara em uma linguagem de alto nível.Os testes devem confirmar comportamento idêntico para entradas normais, de limite e maliciosas, além de reverts.

Quando o gas golfing se torna perigoso

Gas golfing se torna perigoso quando o custo de gas recebe prioridade maior do que a segurança e a clareza do contrato.Remover verificações de controle de acesso para economizar gas pode permitir que usuários não autorizados controlem o contrato.Remover uma proteção contra reentrância pode expor saldos a chamadas externas repetidas.Remover limites de slippage ou prazos pode expor usuários a uma execução desfavorável de transações de criptomoedas.Combinar muitos valores em uma única palavra empacotada pode introduzir erros de máscaras de bits e conversão.Substituir uma codificação padrão por um formato personalizado pode criar vulnerabilidades de assinatura, replay ou análise de dados.Uma otimização que economiza 100 gas, mas cria a possibilidade de perda de fundos dos usuários, tem valor prático negativo.

Conselhos desatualizados sobre gas golfing

Conselhos sobre gas golfing podem ficar desatualizados quando o Solidity e a EVM mudam.Um compilador pode começar a otimizar um padrão que antes exigia uma reescrita manual.Uma atualização da rede pode alterar o custo de um opcode ou adicionar uma instrução mais eficiente.

A recomendação antiga de usar

para obter reembolsos não é mais válida na Ethereum atual.

A afirmação de que um estilo de incremento é sempre mais barato pode não se aplicar ao bytecode moderno otimizado.A recomendação de usar um inteiro muito pequeno pode não economizar gas se não houver empacotamento de storage.Antes de adotar qualquer dica de gas golfing, os desenvolvedores devem exigir benchmarks atuais e configurações de compilador reproduzíveis.

Como avaliar uma alteração de gas golfing

A implementação otimizada deve primeiro produzir o mesmo comportamento exigido da implementação original.Os desenvolvedores devem comparar o gas de implantação, o gas de execução bem-sucedida, o gas dos caminhos de falha e o custo total esperado ao longo da vida útil.Devem identificar o compilador, as configurações do otimizador, a versão EVM e o estado da blockchain usados nos testes.Testes unitários devem verificar o comportamento normal das funções.Testes fuzz devem explorar entradas inesperadas e condições de limite.Testes de invariantes devem confirmar que as propriedades essenciais de contabilidade e segurança continuam válidas.Rastros de execução devem confirmar que a economia vem das operações esperadas, e não de um requisito ignorado por acidente.Revisores humanos devem avaliar se a alteração continua compreensível e fácil de manter.

Gas golfing em contratos de produção

O gas golfing em produção deve se concentrar em funções muito usadas e gargalos medidos de forma confiável.Uma economia pequena em uma função executada milhões de vezes pode justificar um trabalho de implementação cuidadoso.Uma economia semelhante em uma função administrativa executada uma única vez pode não justificar o aumento da complexidade.As interfaces públicas e o comportamento esperado devem permanecer estáveis, a menos que a otimização faça parte de uma atualização planejada do protocolo.Contratos atualizáveis devem preservar o layout de storage e o modelo de autorização.Contratos de alto valor devem passar por uma revisão de segurança independente após uma otimização substancial de baixo nível.O bytecode implantado deve poder ser reproduzido a partir do código-fonte publicado e da configuração de build.

Erros comuns de gas golfing

Um erro comum é comparar o tamanho do código-fonte, em vez do consumo de gas do código compilado.Outro erro é testar sem ativar as mesmas configurações do otimizador usadas em produção.Desenvolvedores podem medir apenas transações bem-sucedidas e ignorar um caminho de revert excepcionalmente caro.Podem otimizar uma função raramente usada enquanto ignoram uma gravação repetida em storage em todas as transações.Podem usar tipos inteiros menores sem obter qualquer benefício de empacotamento de storage.Podem substituir Solidity claro por assembly antes de confirmar que o código gerado pelo compilador realmente é caro.Podem se basear em uma tabela antiga de custos de gas que já não representa a EVM atual.O erro mais grave é aceitar um resultado com gas menor sem comprovar que a versão otimizada mantém exatamente o mesmo comportamento seguro.

Perguntas frequentes

O que é gas golfing em termos simples?

Gas golfing significa fazer pequenas alterações no nível do código que reduzem o gas consumido por um contrato inteligente sem mudar o comportamento pretendido.

Gas golfing é o mesmo que otimização de gas?

Não. Gas golfing costuma ser uma forma restrita de micro-otimização, enquanto a otimização de gas também inclui arquitetura, design de storage, computação off-chain, agrupamento de transações e seleção de rede.

Gas golfing é um recurso do protocolo Ethereum?

Não. É um termo informal usado por desenvolvedores, não um opcode, tipo de transação ou padrão oficial da Ethereum.

Um código Solidity mais curto sempre consome menos gas?

Não. O tamanho do código-fonte não prevê de forma confiável o tamanho ou o custo de execução do bytecode EVM compilado.

O otimizador Solidity consegue fazer gas golfing automaticamente?

O otimizador realiza muitas transformações semelhantes, mas os desenvolvedores ainda precisam projetar com eficiência o storage, o fluxo de dados e a arquitetura do contrato.

Qual é a melhor técnica de gas golfing?

A técnica de maior valor costuma depender do contrato, embora reduzir acessos repetidos ao storage geralmente traga mais benefícios do que alterar pequenas expressões aritméticas.

Inteiros menores são sempre mais baratos?

Não. Inteiros menores são mais úteis quando permitem armazenar vários valores em um único slot de storage.

Calldata é sempre mais barata do que memory?

Calldata costuma ser mais barata para entradas externas somente leitura, pois evita uma cópia, mas a localização correta depende de como os dados serão usados.

Por que erros personalizados são úteis para gas golfing?

Erros personalizados usam seletores e parâmetros compactos em vez de incorporar e retornar mensagens longas de revert.

Armazenar em cache um valor de storage sempre economiza gas?

Pode economizar gas quando o valor continua válido, mas o cache pode ser inseguro se uma chamada externa puder alterar o estado.

A aritmética unchecked é uma otimização segura?

Só é segura quando os desenvolvedores conseguem provar que overflow ou underflow é impossível para toda entrada alcançável.

Quem aplica gas golfing deve usar inline assembly?

O inline assembly deve se limitar a gargalos medidos, pois pode introduzir erros graves de memória, codificação e segurança.

O incremento prefixado sempre custa menos do que o pós-fixado?

Não. A otimização atual do compilador pode gerar código equivalente, portanto o resultado exato deve ser medido.

Eventos podem substituir o storage do contrato?

Eventos só podem substituir o storage para informações que futuras execuções de contratos inteligentes não precisem ler nem aplicar.

Gas golfing pode deixar uma transação gratuita?

Não. Toda transação continua pagando pela execução, pelos dados e pelo uso de estado exigidos pelas regras de taxas da rede.

Gas golfing reduz o preço do gas?

Não. Ele reduz o consumo de gas, enquanto o preço do gas varia conforme a demanda da rede e as configurações de taxa da transação.

Reembolsos de gas são um método de gas golfing?

A limpeza elegível de storage pode gerar um reembolso limitado, mas as regras atuais limitam os reembolsos e já não permitem estratégias antigas que dependiam fortemente deles.

Gas golfing pode criar riscos de segurança?

Sim. Compressão agressiva, aritmética unchecked, assembly e remoção de validações podem criar vulnerabilidades se não forem revisados com cuidado.

Como os resultados de gas golfing devem ser testados?

Devem ser testados com configurações fixas do compilador, entradas realistas, rastros de execução, testes fuzz, invariantes e revisão de segurança.

Quando vale a pena aplicar gas golfing?

Vale mais a pena quando uma alteração segura reduz o custo de uma função executada com frequência por usuários ou sistemas automatizados.

Conclusão

Gas golfing é a prática de fazer alterações pontuais em contratos inteligentes para reduzir o gas de implantação ou execução.Está relacionado à otimização de gas, mas geralmente se concentra em melhorias menores no nível do código, e não na reformulação completa do aplicativo.Métodos comuns de gas golfing incluem armazenar em cache leituras de storage, reduzir gravações em storage, empacotar variáveis, usar calldata, escolher erros personalizados, simplificar loops e usar recursos modernos da EVM.O efeito de cada método depende da versão do compilador, das configurações do otimizador, do alvo EVM, dos valores de entrada e do estado da blockchain.Conselhos que geravam economias em um ambiente antigo da Ethereum podem não funcionar mais conforme as regras atuais do compilador e do protocolo.Os desenvolvedores devem medir o bytecode compilado, em vez de avaliar a eficiência pela aparência ou pelo tamanho do código-fonte Solidity.Em geral, melhorias arquiteturais devem ser consideradas antes de micro-otimizações de baixo nível.Inline assembly e operações unchecked devem se limitar a situações em que as economias possam ser medidas e a segurança comprovada.Toda alteração de gas golfing deve preservar o comportamento, a segurança, a legibilidade e a compatibilidade do contrato.O melhor resultado de gas golfing não é simplesmente o menor número de gas, mas o menor custo seguro para oferecer a funcionalidade de criptomoeda exigida.