src-https://makeameme.org/meme/you-get-a-595d57

Você sabia que a EVM tem a funcionalidade de recompensar os usuários com um reembolso de gás para limpar o armazenamento on-chain ocupado pelos dados do contrato? Vamos aprender mais sobre isso. Houve algumas mudanças após o fork London. Mas, para entender melhor, veremos o cenário antes da atualização London e depois veremos as mudanças propostas na atualização London.

Mas antes de começar com os reembolsos, devemos entender um pouco sobre o consumo de gás de armazenamento, isso tornará os cálculos de gás fáceis de entender para você.

Copiei algumas quantidades de gás diretamente do Ethereum Yellow Paper, vamos ver quais são.

1.Gcoldsload—2100 Custo de um acesso de armazenamento a frio.

2.Gsset—20000 Pago por uma operação SSTORE quando o valor de armazenamento é definido como diferente de zero a partir de zero.

3.Gsreset—2900 Pago por uma operação SSTORE quando o zero do valor de armazenamento permanece inalterado ou é definido como zero.

4.Rsclear—15000 Reembolso concedido (adicionado ao contador de reembolso) quando o valor de armazenamento é definido como zero a partir de zero.

Vamos entender isso rapidamente.

1.Gcoldsload — Você tem que pagar toda vez que acessar qualquer variável de armazenamento pela primeira vez em uma função, a segunda ou consecutivas vezes custa 100 gás._

2.Gsset — Pague sempre que definir qualquer variável de valor zero para diferente de zero (falso para verdadeiro no caso de bools). Em palavras simples, você está alterando o valor padrão e os nós agora precisam acompanhar esse slot.

3.Gsreset — Pague sempre que definir um valor diferente de zero para um valor diferente de zero ou zero.

4.Rsclear — Sempre que você definir qualquer valor para seu valor padrão, você receberá o reembolso.

Lembre-se destes pontos antes de começarmos

• Sempre que definimos qualquer valor diferente de zero para diferente de zero ou diferente de zero para zero, dizemos coletivamente que o gás consumido é 5000, adicionando Gcoldsload e Gsreset.
• Cada transação consumirá todo o gás relacionado durante a execução e o reembolso é calculado no final da transação.
• Existe um gás inicial associado a cada transação que é 21000. Esse gás é consumido pelo validador para garantir que a transação seja válida ou não. 21000 é adicionado a cada transação e não está sob nosso controle, então cada transação consome 21000 + qualquer gás que os dados da função precisem.

• Os cálculos de gás abaixo incluirão implicitamente o gás de 21000.

  Os reembolsos funcionam sempre que você define algo para seu valor-padrão: para uint é zero, para um booleano é falso, etc. Para facilitar o entendimento, darei exemplos de uint.

Antes do London Fork

A EVM reembolsa o gás ao usuário em dois casos. Primeiro, se você estiver chamando a função de selfdestruct (autodestruição), 24.000 de gás serão reembolsados ​​do total de gás consumido. Isso foi simples e não há nada para falar sobre isso, pois a funcionalidade de reembolso de gás para selfdestruct foi removida na EIP-3529 e, recentemente, o método selfdestruct também foi descontinuado. Portanto, não há razão para falar sobre isso.

Em segundo lugar, se você definir qualquer variável para seu valor-padrão, receberá um reembolso de 15.000. Por que isso acontece? Definir o valor para o valor-padrão significa que você está limpando o armazenamento porque os nós não precisam rastrear aquele slot específico de armazenamento que você acabou de limpar.

Esta é uma captura de tela do documento Ethereum Yellow Paper informando o valor do reembolso.

Mas existe uma forma correta de calcular o gás a reembolsar.

Aqui está a referência do Ethereum Yellow Paper.

Mecanismo: O reembolso é dado no final de qualquer transação e limitado a um número máximo. Esse número máximo é metade do gás total usado. Vamos entender isso com o exemplo de uint. O que acontece quando definimos qualquer valor uint diferente de zero como zero?

Suponha que você esteja definindo uma única variável uint como zero em uma transação para que o reembolso total aplicável seja 15.000, mas o total de gás consumido nessa transação é 24.000, metade dos quais é 12.000, agora 12.000 se torna a quantidade máxima de gás que pode ser reembolsado, o que significa que a transação agora custará a você

24000 — MAXIMUM_GAS_REFUNDABLE = 24000–12000 = 12000 gás.

Embora estivéssemos esperando receber 15.000 de gás de volta, o limite foi limitado a 12.000, reduzindo assim o valor para 12.000. E se nossa transação estiver consumindo 40.000 de gás? Nesse caso, metade de 40.000 é 20.000, que é maior que 15.000, portanto, obteremos o reembolso de 15.000 de gás.

Este foi o caso quando você está definindo apenas uma variável uint como zero, o que acontecerá se estivermos definindo múltiplas variáveis ​​uint como zero? Por exemplo

contrato {
   contagem uint256 = 1;
   uint256 contagem2 = 2;
   uint256 contagem3 = 3;
   uint256 contagem4 = 3;
   uint256 contagem5 = 3;
   uint256 contagem6 = 5;
   uint256 contagem7 = 6;
   uint256 contagem8 = 6;


  function setTOzero() externo {
       contagem = 0;
       contagem2 = 0;
       contagem3 = 0;
       contagem4 = 0;
       contagem5 = 0;
       contagem6 = 0;
       contagem7 = 0;
       contagem8 = 0;
   }
}
//O custo da transação será de 21.000+ custo de execução
//custo de execução = 8 * (Gcoldsload +Gsreset) = 8 * 5000 = 40000
// Custo da transação = 21000 + 40000 = 61000

Qualquer que seja o custo da sua transação, temos EXECUTION_COST+ 21000. Agora, o reembolso é calculado com base em quantas variáveis ​​você está definindo como padrão. Neste caso, estamos definindo 8 variáveis ​​uint como zero para que o valor reembolsável seja 15.000 * 8 = 1,20.000.

Espere, se este é o valor do reembolso, quanto de gás nossa transação está consumindo? Quando você calcular o gás a ser consumido, obterá o valor de aproximadamente 61.000. Agora, o que acontecerá se 1,20.000 de gás forem devolvidos em uma transação de 61.000? O minerador acabará pagando pela transação, é por isso que o mecanismo de limite foi introduzido.

De acordo com a fórmula, o gás máximo a ser reembolsado será 61000/2 = 30500. Assim, o gás consumido será 61000–30500 =30500 em vez de 61000 – 1,20,000. Agora, acho que isso está bem claro para você, mas esse método não é mais válido agora após a atualização London. Se você quiser testar isso, pode mudar para a versão Berlin da Máquina Virtual no Remix IDE e observar tudo funcionando.

Agora vamos ver o que mudou na atualização London.

Após a Atualização London

Esses números mudaram após a introdução da EIP-3529 na atualização de Londres. Vejamos o que mudou. O valor do gás reembolsado agora é reduzido para 4800 e o valor máximo que pode ser reembolsado agora é um quinto do gás consumido. Vamos entender com a mesma abordagem de antes.

No primeiro caso, se estamos zerando apenas uma variável, a transação está consumindo 26000. Quando verificamos a regra de gás máximo na EIP-3529, ela diz TOTAL_GAS_CONSUMED dividido por 5, que no nosso caso é 26000/5 igual a 5200 , isso significa que fomos elegíveis para um reembolso máximo de 5200 nesta transação, mas, conforme mencionado na EIP-3529, o valor do reembolso é de 4800. Desta vez, 4800 nos é reembolsado e a transação custa 21400 gás (algum gás adicional).

Vamos pegar o segundo caso em que definimos 8 variáveis ​​para zero. O gás consumido ainda é 61000. Falando sobre o reembolso, esperamos um reembolso total de 4800 * 8 =38400, ou seja, o consumo que esperamos é 61000–38400 = 22600. Mas quando você executar esta transação, notará que o gás consumido é 49000, agora você percebe que o gás a ser devolvido é limitado a um máximo de 61000/5 = 12200, o que significa que a transação consumirá um total de 61.000–12.200 ~ 49.000.

Você pode estar pensando o que fez com que os reembolsos de gás diminuíssem na atualização London. Veja os motivos que copiei do site oficial da EIP:

_Os reembolsos de gás para SSTORE e SELFDESTRUCT foram originalmente introduzidos para motivar os desenvolvedores de aplicativos a escrever aplicativos que pratiquem “boa higiene de estado”, limpando slots de armazenamento e contratos que não são mais necessários. No entanto, os benefícios dessa técnica provaram ser muito menores do que o previsto, e os reembolsos de gás tiveram várias consequências prejudiciais inesperadas:

• Reembolsos dão origem a GasToken. O GasToken tem benefícios em mover o espaço de gás de períodos de baixa taxa para períodos de alta taxa, mas também tem desvantagens para a rede, particularmente na exacerbação do tamanho do estado (já que os slots de estado são efetivamente usados ​​como uma “bateria” para economizar gás) e obstruindo ineficientemente o uso de gás da blockchain
• Os reembolsos aumentam a variação do tamanho do bloco. A quantidade máxima teórica de gás real consumida em um bloco é quase o dobro do limite de gás no papel (uma vez que os reembolsos adicionam espaço de gás para transações subsequentes em um bloco, embora os reembolsos sejam limitados a 50% do gás usado em uma transação). Isso não é fatal, mas ainda é indesejável, especialmente considerando que os reembolsos podem ser usados ​​para manter picos de uso 2x por muito mais tempo do que a EIP-1559.

O conceito de reembolso de gás deve estar claro para você agora. Quanto mais você brincar com isso no remix, mais entenderá os cálculos. Por que não tentar executar algumas funções do mundo real, uma vez que as que escrevi acima são apenas exemplos. Você pode tentar ver o consumo de gás em contratos reais como a função de transferência ERC20 quando o saldo está prestes a chegar a zero. Deixe-me saber o que você encontrar nestes experimentos :)

Tem alguma dúvida sobre este tema? Pergunte-me a qualquer hora, em Twitter, LinkedIn, ou telegram.

Este artigo foi escrito por Zartaj Afser e traduzido por Diogo Jorge. O artigo original pode ser encontrado aqui.