EVM gas refund는 실행 중 남은 gas를 늘리는 쿠폰이 아니라 transaction 종료 때 refund counter를 effective gas used에서 제한적으로 차감하는 정산입니다. EIP-3529 이후 mainnet 규칙에서는 SELFDESTRUCT refund가 없어졌고 nonzero storage slot을 zero로 지울 때의 SSTORE clear refund가 4,800 gas로 줄었습니다. 최종 적용 가능한 refund는 transaction이 refund 전 사용한 gas의 1/5 이하이므로, 여러 slot을 지워 counter가 크게 쌓여도 사용량 100,000 gas라면 최대 20,000 gas만 차감됩니다. 실행 도중 out-of-gas를 막아 주지 않으며 sender는 gas limit을 환급 전 실행에 충분히 제공해야 합니다.
사용 가스와 환급 counter를 따로 셉니다
SSTORE가 실행될 때 client는 slot의 transaction 시작 original value, 현재 current value와 새 new value를 비교해 즉시 gas를 청구하고 조건에 따라 refund counter를 더하거나 뺍니다. Dirty slot을 원래 값으로 되돌리는 경우도 counter 변화가 생깁니다. 같은 opcode라도 값 전이와 cold·warm 접근 여부가 달라 단일 상수로 비용을 예측할 수 없습니다.
Refund는 transaction 실행이 끝난 뒤 적용됩니다. 안쪽 call이 5,000 gas밖에 남지 않은 상황에서 미래 clear refund를 기대해 8,000 gas 작업을 수행할 수 없습니다. Revert된 frame의 상태 변경과 관련 refund 변화도 되돌려지므로 trace의 중간 counter만으로 최종 fee를 계산하지 않습니다.
가스 환급은 실행 중 꺼내 쓰는 연료가 아니라, 모든 실행이 끝난 뒤 상한 안에서만 인정되는 정산 할인입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 사용 가스와 환급 counter를 따로 셉니다
SSTORE가 실행될 때 client는 slot의 transaction 시작 original value, 현재 current value와 새 new value를 비교해 즉시 gas를 청구하고 조건에 따라 refund counter를 더하거나 뺍니다.
- London 이후 상한은 1/5입니다
EIP-3529는 MAX_REFUND_QUOTIENT를 5로 정해 적용 refund를 gas_used // 5로 제한합니다.
- 세 가지 숫자 예제로 상한을 계산합니다
가정 1에서 refund 전 gas used가 100,000이고 eligible clear 다섯 개로 counter가 24,000이면 cap은 20,000입니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
London 이후 상한은 1/5입니다
EIP-3529는 MAX_REFUND_QUOTIENT를 5로 정해 적용 refund를 gas_used // 5로 제한합니다. 이전의 절반 상한보다 낮아져 refund를 이용해 block의 실제 연산량을 크게 늘리는 폭을 줄였습니다. SSTORE_CLEARS_SCHEDULE도 EIP-2929·2930 문맥에서 4,800 gas로 바뀌었습니다.
SELFDESTRUCT refund는 완전히 제거됐습니다. 이는 opcode의 잔액 이전·상태 효과와 별개입니다. Cancun의 EIP-6780이 code 삭제 semantics를 바꾼 사실과 London의 refund 제거를 한 변화로 섞지 않습니다. 어느 chain과 fork rules를 적용하는지 먼저 확인합니다.
| 항목 | EIP-3529 이후 값·역할 | 주의 |
|---|---|---|
| SSTORE clear refund | 4,800 gas | original nonzero 등 조건 필요 |
| SELFDESTRUCT refund | 0 | opcode 효과와 별개 |
| Refund cap | gas_used ÷ 5 | 소수점은 정수 규칙 적용 |
| Gas limit | 환급 전 실행 한도 | counter로 늘지 않음 |
| Effective gas | gas_used – 적용 refund | base·priority fee 계산 기반 |
세 가지 숫자 예제로 상한을 계산합니다
가정 1에서 refund 전 gas used가 100,000이고 eligible clear 다섯 개로 counter가 24,000이면 cap은 20,000입니다. 실제 적용 refund는 min(24,000,20,000)=20,000이고 effective gas used는 80,000입니다. 4,000은 다음 transaction으로 이월되지 않습니다.
가정 2에서 gas used 100,000, clear 두 개로 counter 9,600이면 cap보다 작아 9,600 전부가 적용되고 effective는 90,400입니다. 가정 3에서 24,000 counter를 만들었지만 이후 실행이 revert되어 관련 clears가 취소됐다면 원래 counter를 다시 계산해야 합니다. Receipt gasUsed와 client trace 정의도 확인합니다.
- 적용 fork와 chain id를 고정합니다.
- Slot별 original·current·new 값을 기록합니다.
- 실행 gas used와 refund counter를 분리합니다.
- gas_used // 5와 counter 중 작은 값을 택합니다.
- 적용 후 effective gas와 실제 fee를 계산합니다.
Storage 정리는 여전히 공짜가 아닙니다
Nonzero slot을 zero로 만들면 4,800 환급 후보가 생겨도 SSTORE 실행 비용과 처음 cold access 비용을 먼저 냅니다. Transaction 자체가 다른 작업을 적게 해 cap이 낮으면 일부 refund가 잘립니다. 오직 refund를 얻으려고 불필요한 slot을 만들고 지우는 gas token 전략은 EIP-3529가 약화한 대상입니다.
데이터 삭제 여부도 history 삭제와 다릅니다. 현재 state trie에서 slot 값이 zero가 되어도 과거 block·archive 자료에는 변경 이력이 남을 수 있습니다. 개인정보 삭제나 storage rent 정책을 gas refund 하나로 해결했다고 설명하지 않습니다.
측정은 compiler와 fork 조건을 고정합니다
Solidity optimizer는 redundant SSTORE를 없애거나 쓰기 순서를 바꿀 수 있고 reentrancy guard가 같은 transaction 안에서 값을 설정했다 원복하는 패턴도 net metering 영향을 받습니다. Source line 수가 아니라 실제 bytecode trace의 SSTORE와 access list를 봅니다.
테스트에서는 빈 slot 설정, nonzero clear, dirty slot reset, reverted subcall과 cap 초과를 각각 분리합니다. EstimateGas 응답은 특정 state와 pending block rules의 실행 추정이므로 실제 포함 block에서 상태가 바뀌면 달라질 수 있습니다. 환급을 수익이나 확정 할인으로 UI에 선반영하지 않습니다.
자주 묻는 질문
Refund가 있으면 더 낮은 gas limit으로 보내도 되나요?
안 됩니다. Refund는 실행 뒤 정산되므로 gas limit은 환급 전 전체 실행을 완료할 만큼 충분해야 합니다.
Storage slot 하나를 zero로 만들면 항상 4,800을 받나요?
Original·current·new 값과 revert 여부 등 SSTORE 조건을 충족해야 하며 최종 transaction 상한에도 걸릴 수 있습니다.
사용하지 못한 refund는 다음 거래로 넘어가나요?
아닙니다. 해당 transaction 정산에서 상한을 넘은 counter는 이월되지 않습니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
