Tutorial de Solidity sobre eficiência de gás: 12 dicas para lidar com o aumento das taxas na Base e outras cadeias L2

Para superar essas limitações, várias soluções de Camada 2, como a Base, foram desenvolvidas e são controladas pela escalabilidade e pela redução das despesas com gás. Embora as L2s tenham reduções significativas nas taxas em relação à rede principal Ethereum, os desenvolvedores de contratos inteligentes não podem ignorar a otimização do gás no seu desenvolvimento.

Este tutorial vai tentar consolidar a experiência do utilizador e criar aplicações descentralizadas mais competitivas através de estratégias avançadas que reduzem o custo do gás em contratos inteligentes que serão testados. Os exemplos que eles fornecem são simulados com contratos simples e levam em consideração principalmente os preços do gás em tempo de execução, já que os custos de implementação variam muito dependendo do tamanho do contrato.

A otimização do gás é importante para os desenvolvedores, usuários e sucesso do projeto a longo prazo. A utilização econômica do gás do contrato inteligente pode garantir que os protocolos sejam mais rentáveis e escaláveis e menos propensos a ameaças de segurança, como ataques de negação de serviço.

A otimização do gás permite que contratos inteligentes, protocolos e projetos funcionem em condições de redes congestionadas e os torna baratos e eficientes. Ao melhorar o código do contrato, existe a possibilidade de revelar possíveis vulnerabilidades e protocolos, e os utilizadores ficam mais seguros.

A otimização do gás também é um foco importante do desenvolvimento. Não é apenas um atributo agradável de se ter, mas uma chave para o sucesso e a segurança a longo prazo dos contratos inteligentes. O facto de ser possível construir em L2s com taxas comparativamente baixas não significa que as taxas de gás não serão significativamente mais altas do que as dos concorrentes.

Todos os testes estão a usar Foundry e Solidity versão 0.8.13, nó de blockchain local Anvil, comandos de teste forge e 100 execuções de otimização.

Os tokens não fungíveis (NFTs) ficaram populares em 2021 e chamaram a atenção para os NFTs totalmente na cadeia. Os NFTs na cadeia, em comparação com os NFTs tradicionais que usam dados fora da cadeia, incluindo metadados e referências de imagens, colocam todas as informações diretamente na blockchain.

Esses tokens são notoriamente caros para se comunicar e as soluções híbridas são o padrão quando os utilizadores são afetados pelas taxas. Independentemente de você estar a criar NFTs, jogos ou protocolos DeFi, deve sempre pensar sobre quais dados são realmente necessários para serem armazenados na blockchain e as vantagens e desvantagens de ambas as alternativas.

Reduza drasticamente o uso de gás armazenando informações fora da cadeia, exigindo menos armazenamento de variáveis. Um método específico é usar eventos para armazenar dados fora da cadeia, em vez de no armazenamento real na cadeia.

Os custos de gás das transações são aumentados por funções emit adicionais incorridas por eventos; mas, como as informações não são armazenadas na cadeia, as economias geralmente excedem os custos.

Considere um contrato inteligente que permite aos utilizadores votar verdadeiro ou falso. O primeiro é aquele que armazena os votos dos utilizadores em estruturas na cadeia. Uma demonstração do teste da função de votação com o Foundry com mais de 100 iterações exibe certos custos de gás.

Compare com um contrato inteligente que não armazenaria informações na cadeia, mas emitiria um evento quando a função de votação fosse invocada. Um teste envolvendo a Foundry mais de 100 vezes na nova funcionalidade de votação fornece resultados.

A redução dos dados na cadeia reduziu o gás médio em 90,34%.

Existem duas estruturas de dados principais no Solidity: matrizes e mapeamentos.

• •As matrizes são usadas para armazenar conjuntos de itens que são atribuídos a determinados índices
• •Mapeamentos de chave-valor são estruturas de dados que suportam o acesso direto aos dados usando chaves exclusivas

Embora as matrizes possam ser úteis no armazenamento de vetores e outros dados semelhantes, os mapeamentos são geralmente preferidos devido à sua eficiência de gás. Eles são especialmente adaptados de forma ideal para situações em que são necessários dados sob demanda, por exemplo, por nome, endereço de carteira ou saldo da conta.

Para entender o uso de gás ao usar matrizes ou mapeamentos, pode ser necessário consultar o gás usado pelos códigos de operação EVM associados. Os códigos de operação são instruções de baixo nível que a Máquina Virtual Ethereum executa na execução de contratos inteligentes, com cada código de operação tendo um custo de gás.

Para acessar os valores da matriz, é preciso pagar por unidade de gás usada pelos códigos de operação EVM. Armazenar os endereços dos utilizadores e os saldos correspondentes na forma de matriz requer um looping de todos os itens da matriz, verificando se o userAddress e o argumento fornecido correspondem e retornando o saldo em caso de correspondência.

Passar diretamente para o saldo específico do utilizador evitaria a necessidade de percorrer todos os itens da matriz. Depois que as matrizes foram substituídas por mapeamentos, 89% menos gás foi usado para acessar os dados.

Outra dica de otimização seria usar constantes e variáveis imutáveis. Ao declarar variáveis como imutáveis ou constantes, os seus valores são fornecidos apenas no momento da criação do contrato e não mais.

Elas não ocupam espaço de armazenamento na EVM, em comparação com outras variáveis. É possível codificar valores diretamente no bytecode do contrato inteligente, o que significa que o custo de armazenamento de dados é reduzido pelo facto de variáveis como maxSupply e owner não terem as palavras-chave constante ou imutável.

Quando os testes são executados 100 vezes, o custo médio do gás é de 112.222 unidades. Como maxSupply e owner são valores conhecidos que não devem ser alterados, declarar o fornecimento máximo e o proprietário que não usam espaço de armazenamento é a melhor opção.

Os testes com variáveis constantes ou imutáveis resultam numa economia média de 35,89% (de 112.222 para 71.940 unidades de gás).

É um conselho óbvio de otimização de gás otimizar variáveis em contratos inteligentes. No entanto, variáveis não úteis são, na maioria dos casos, mantidas na execução do contrato, levando ao uso desnecessário de gás.

A remoção de variáveis únicas não utilizadas pode ser usada para economizar custos de gás, em média, 18%, quando se consideram contratos com variáveis não utilizadas definidas e manipuladas em funções, mas nunca chamadas em outros lugares.

Eliminar variáveis não utilizadas é uma tentativa de atribuir valores padrão às variáveis depois de terem sido totalmente calculadas sem que os dados sejam armazenados na memória. A título de exemplo, o padrão das variáveis do tipo uint é 0.

Ao não destruir as variáveis da função quando as funções terminam, os custos médios de gás são de 100.300 unidades para atribuir variáveis aos dados. Em média, 19% de economia de gás usando a tecla delete para remover variáveis de dados (para definir variáveis como 0).

Use mapeamentos sempre que possível para reduzir os custos de gás do contrato inteligente. No entanto, quando forem necessárias matrizes, matrizes de tamanho fixo são mais econômicas em termos de gás do que matrizes de tamanho dinâmico, pois estas últimas podem ser expandidas indefinidamente, levando a custos de gás mais elevados.

As matrizes dinâmicas podem ser expandidas e, portanto, a EVM precisa monitorar os comprimentos e atualizá-los quando novos itens forem adicionados.

Considere o código que define matrizes de tamanho dinâmico e as atualiza com funções updateArray. As instruções Require garantirão que os índices fornecidos estejam dentro de um intervalo de matriz de tamanho fixo. Quando 100 repetições de um teste são executadas, a quantidade média de gás utilizada é 12.541.

Alterar as matrizes para tamanho fixo 5 cria matrizes de tamanho fixo com comprimento 5, tipo uint256. A EVM sabe que a fixedArray com tamanho de variável de estado 5 tem 5 slots, e o comprimento não é armazenado no armazenamento. Substituir matrizes dinâmicas por matrizes fixas economiza 17,99% de gás.

Isso é menos eficiente e pode ser mais caro de usar do que uint256 por causa do funcionamento do EVM. O EVM tem tamanhos de palavra de 256 bits. Operações com inteiros de 256 bits (uint256) tendem a ser as mais eficientes, porque se encaixam no tamanho de palavra do EVM, enquanto tipos menores (como uint8) exigem que o compilador Solidity crie operações adicionais para encaixar tipos menores em um único slot de armazenamento de 256 bits.

Em geral, embora tipos pequenos, como uint8, possam ser benéficos quando se trata de armazenamento (vários tipos pequenos podem ser agrupados numa única operação com um slot de armazenamento de 256 bits), verificou-se que tipos menores só ajudam no armazenamento. A economia de armazenamento pode ser anulada pela conversão de e para uint256 para fazer cálculos.

Combinar variáveis com tamanho inferior a 256 bits geralmente não é tão eficiente quanto variáveis de 256 bits. No entanto, situações de não interoperabilidade obrigam o uso de tipos menos potentes em tamanhos menores, por exemplo, booleanos que consomem 1 byte ou 8 bits para serem armazenados.

Ao usar tipos menos poderosos, é possível declarar variáveis de estado tendo em mente o espaço de armazenamento, e o Solidity pode agrupá-las e armazená-las usando o mesmo espaço de armazenamento. A vantagem do agrupamento de variáveis é geralmente considerada nas operações de armazenamento, em vez de nas operações de memória ou pilha.

Como os tamanhos das combinações bidirecionais são de 16 bits, ou 240 bits menores do que a capacidade de armazenamento de um único slot, o Solidity pode ser usado para compactar variáveis no mesmo slot, minimizando o uso de gás de implantação, pois não precisa de muitos slots para armazenar variáveis de estado.

Reorganizar as declarações de variáveis permite uma otimização média de 13% no gás.

Para maximizar o gás do contrato inteligente, é razoável selecionar a visibilidade correta das funções. Modificadores de visibilidade externa podem ser mais eficientes no uso de gás do que públicos, devido à forma como uma função pública gerencia os seus argumentos e à maneira como os dados são transferidos para as funções.

As funções externas podem aceder ao calldata, que é um espaço temporário somente leitura no EVM que contém os parâmetros de uma chamada de função. As funções públicas podem ser chamadas:

• •Externamente (quando são chamados externamente por uma transação usando calldata)
• •Internamente (quando são chamados dentro de um contrato usando calldata)

Como as funções são públicas, elas precisam receber matrizes na memória, o que pode ser caro em termos de custo de gás, caso sejam grandes. Mudar as funções para externas permite a recepção de matrizes em calldata, o que é mais económico em situações que envolvem matrizes grandes, economizando em média 0,3% de unidades de gás por chamada.

Uma boa técnica para economizar gás é não ler o mesmo valor no armazenamento várias vezes. Ler do armazenamento tem um custo mais alto do que ler na memória. Reler as mesmas variáveis no armazenamento várias vezes e gravar no armazenamento quando não é necessário pode ser um desperdício de gás em contratos inteligentes.

Isso pode ser evitado definindo variáveis que estão na memória no início das funções e atribuindo-lhes valores de variáveis numéricas.

Isso economiza 17% do gás consumido pelas funções sumNumbers, mas quanto maior for a matriz, maiores serão os números de iteração e o gás usado.

Ao declarar variáveis de estado sem as inicializar (ou seja, sem atribuir um valor inicial), essas variáveis são automaticamente inicializadas com valores padrão:

• •uint: 0
• •bool: false
• •endereço: endereço(0)

O último é mais barato do que declarar valores como padrão e simplesmente atualizá-los quando o utilizador interage com o sistema, o que não é eficiente em termos de gás. Sem inicialização de variáveis, a otimização indica uma economia média de gás de 4%.

O Solidity inclui compiladores com configurações fáceis de alterar para otimizar o código compilado. A compilação otimizada é executada centenas de vezes, otimizando o código e convertendo-o em formas mais baratas que requerem menos gás para funcionar.

Os compiladores podem ser ajustados para alcançar o equilíbrio adequado entre os custos de implementação e de tempo de execução. Definir o número estimado de contratos a serem executados com o uso dos comandos de execução:

• •Níveis mais altos são ideais em termos de preços baixos de gás ao fazer valer o contrato
• •Menos números são ideais em termos de redução dos custos de gás na implementação do contrato

Otimizar sinalizadores mais o valor de run=200 diz aos compiladores para otimizar o código para economizar gás ao executar funções incrementCount 200 vezes. Categorize essas configurações de acordo com os requisitos exclusivos da aplicação.

Ao escrever contratos inteligentes em Solidity, eles são compilados em bytecodes, uma sequência de códigos de operação EVM. Através da montagem, você pode simplesmente escrever código que roda em níveis mais compatíveis com códigos de operação e, em alguns casos, a capacidade de otimizar manualmente os códigos de operação dá uma vantagem sobre o bytecode Solidity.

Embora não seja a tarefa mais simples escrever código em um nível tão baixo, tem a vantagem de poder otimizar os códigos de operação manualmente e, portanto, é geralmente melhor em comparação com o bytecode Solidity. Esse nível de otimização proporciona mais eficiência e eficácia na execução do contrato.

Mesmo em casos simples, em que as duas funções devem somar dois números, as versões simples em Solidity e Assembly terão algumas diferenças, mas as versões em Assembly são mais baratas.

A implementação de projetos em L2s como o Base vai significar que os utilizadores vão ter um custo menor para usar protocolos, mas é dever dos desenvolvedores garantir que eles implementem as técnicas de otimização de gás. Essas dicas podem economizar significativamente os custos das transações, adicionar escalabilidade e aumentar a eficiência do contrato em geral.