DR: Os reembolsos de compensação de armazenamento são valiosos, mas podem inflar os valores do block gas – guarde-os para os usuários, mas não os conte no block gas usado. EIP-7778 restaura a contabilidade precisa de gás na cadeia para armazenamento.
O mecanismo de gás do Ethereum visa refletir com precisão o consumo de recursos computacionais. Para incentivar os usuários a manter o estado limpo e gerenciável, o Ethereum concede reembolsos de gás quando os slots de armazenamento são zerados. Embora sejam eficazes na redução do inchaço estatal, estes reembolsos complicam atualmente a contabilização do gás, fazendo parecer que os blocos consomem menos recursos do que realmente consomem.
Como funcionam os reembolsos de gás hoje
Transações que liberam slots de armazenamento por meio de SSTORE operações, redefinindo um slot para zero, qualificam-se para reembolsos de gás (ver EIP-3529). Por exemplo, uma transação que consome 45 milhões de gás com um reembolso de 20% custa efetivamente ao usuário:
tx.gas_used = 45,000,000 - (0.20 × 45,000,000) = 36,000,000 gas
Da mesma forma, outra transação que consome 9 milhões de gás com reembolso de 20% resulta em:
tx.gas_used = 9,000,000 - (0.20 × 9,000,000) = 7,200,000 gas
É importante ressaltar que o reembolso do gás de um transação pode ser consumida por outro transação.
O que há de problemático no mecanismo atual?
Embora os reembolsos de gás incentivem efetivamente a limpeza do armazenamento, a sua implementação atual reduz o uso total de gás contabilizado no limite de gás do bloco. Como resultado, o uso de gás do bloco subestima o esforço computacional real realizado. Crucialmente, os incentivos de longo prazo contra o inchaço estatal não devem distorcer os mecanismos controladores de feedback de curto prazo, como a taxa básica do EIP-1559.
Para compreender claramente o impacto dos reembolsos de gás na contabilização do gás em bloco, vamos formalizar isto de forma mais sistemática.
Modelo Formal de Contrabando de Gás
Definições
- Bloquear Limite de Gás: G_0
- Taxa de reembolso: r = 0,2 (20%)
- Gás mínimo exigido por transação: G_{\text{min}} = 21.000
Reembolso de gás em etapa eu
O reembolso do gás em cada etapa iterativa eu (a partir de eu=1) é dado por:
R_i = G_0 \vezes r^i
Por exemplo:
- Etapa 1: R_1 = G_0 \vezes r
- Etapa 2: R_2 = G_0 \vezes r^2etc.
Condição de parada
Continuamos gerando transações que acionam mais reembolsos até o reembolso na etapa n fica abaixo do gás mínimo necessário:
R_n < G_{\texto{min}}
Isolando n:
G_0 \vezes r^n < G_{\texto{min}}
Resolvendo para n:
n > \frac{\log\left(\frac{G_{\text{min}}}{G_0}\right)}{\log(r)}
Assim, o número da etapa de parada é:
n = \left\lfloor \frac{\log\left(\frac{G_{\text{min}}}{G_0}\right)}{\log(r)} \right\rfloor + 1
(\lpiso x \rpiso denota a função floor, fornecendo o maior número inteiro ≤ x.)
Gás Computacional Total
Somando todo o gás computacional usado até a etapa n-1:
G_{\text{total}} = G_0 + G_0 r + G_0 r^2 + \dots + G_0 r^{n-1}
Fatorando G_0:
G_{\text{total}} = G_0 (1 + r + r^2 + \dots + r^{n-1})
Usando a fórmula da série geométrica:
1 + r + r^2 + \dots + r^{n-1} = \frac{1 – r^{n}}{1 – r}
Nós obtemos:
G_{\text{total}} = G_0 \times \frac{1 – r^{n}}{1 – r}
Substituindo nossos valores:
- G_0 = 45.000.000
- r = 0,2
- G_{\text{min}} = 21.000
Calcular n:
n = \left\lfloor \frac{\log\left(\frac{21.000}{45.000.000}\right)}{\log(0.2)} \right\rfloor + 1 = \lfloor 4,766 \rfloor + 1 = 5
Calcular gás total:
G_{\text{total}} = 45.000.000 \times \frac{1 – (0,2)^5}{1 – 0,2} = 56.232.000
Isto demonstra um aumento de aproximadamente 25% em relação ao limite inicial de gás, destacando como os reembolsos atuais distorcem significativamente a contabilização do gás em bloco.
Exemplo de contrato
Esta é a aparência desses contratos:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract Refundooor {
mapping(uint256 => uint256) private storageSlots;
/// @notice Pre‑fill `maxSlots` keys starting at `startKey`
function chargeStorage(uint256 startKey, uint256 maxSlots) external {
for (uint256 i = 0; i < maxSlots; i++) {
storageSlots(startKey + i) = startKey + i + 1;
}
}
/// @notice Clears exactly MAX_LOOPS slots unconditionally (no checks)
fallback() external {
assembly {
let base := storageSlots.slot
mstore(0x20, base)
// MAX_LOOPS * ~5,109 gas/iter ≈ 45 000 000 gas
let MAX_LOOPS := 8805
for { let i := 0 } lt(i, MAX_LOOPS) { i := add(i, 1) } {
// compute storage slot for key = i
mstore(0x0, i)
let s := keccak256(0x0, 0x40)
// unconditionally write zero
sstore(s, 0)
}
}
}
}
- Nós primeiro cobrar o contrato escrevendo para slots de armazenamento vazios.
- Em segundo lugar, chamamos o substituto do contrato, definindo 8.805 slots de armazenamento como zero.
Confira este exemplo de transação no Holesky que maximiza o número de
SSTOREoperações.
Eventualmente, o gás “contrabandeado” aumenta linearmente com o limite do gás do bloco. Com 100M de gás, um bloco pode vir com 125M de gás de trabalho real.
Alteração proposta: reembolsos de transação separados da contabilidade de gás em bloco
O EIP-7778 propõe manter os reembolsos ao nível do utilizador para incentivar a gestão eficiente do armazenamento, mas remover estes reembolsos da contabilização do gás ao nível do bloco. Isso garante que o uso do gás de bloco reflita com precisão o consumo real de recursos.
Os benefícios da implementação do EIP são:
- Previsibilidade Melhorada: o trabalho real dos blocos permanece abaixo do limite pretendido.
- Maior estabilidade da rede: Riscos de DoS reduzidos nos piores cenários relacionados ao armazenamento.
- Incentivos ao usuário preservados: os usuários mantêm a motivação para a limpeza do estado.
O EIP-7778 separa claramente os incentivos ao usuário das restrições de recursos em todo o bloco, alinhando o uso do gás do bloco mais de perto com o trabalho real executado.
Fontesethresear
