EIP-8116 영수증의 누적 가스 필드 교체 (Replace cumulative receipt fields)
Hegota 포함 검토 (CFI) · EVM·실행 · 원문 상태 Draft · 2025-12-30 작성
블록에 저장되는 영수증의 가스 필드를 블록 시작부터 더한 누적 합(cumulativeGasUsed)에서 그 트랜잭션이 쓴 양(gasUsed)으로 바꿉니다. RPC 응답의 로그 번호(logIndex)도 블록 기준에서 영수증 기준으로 바꿉니다.
왜 필요한가
이더리움은 트랜잭션을 처리할 때마다 결과를 적은 영수증(receipt)을 남깁니다. 지금 영수증에는 그 트랜잭션이 쓴 가스가 아니라, 블록 첫 트랜잭션부터 여기까지 쓴 가스를 모두 더한 값(cumulativeGasUsed)이 적힙니다. 그래서 트랜잭션 하나가 쓴 가스를 확인하려면 바로 앞 영수증도 받아서 두 값을 빼야 합니다. 노드를 믿지 않고 직접 검증하려는 RPC 클라이언트에게는 번거로운 일입니다. 또 영수증 내용이 앞 트랜잭션 결과에 묶여 있어서 서로 전혀 다른 상태를 건드리는 트랜잭션끼리도 영수증은 순서대로만 만들 수 있습니다. 병렬 처리에 걸림돌이 됩니다. JSON-RPC로 받는 로그 번호(logIndex)도 같은 문제를 안고 있습니다. 영수증 안의 번호가 아니라 블록 전체의 번호라서 앞 트랜잭션 정보 없이는 정할 수 없습니다.
무엇이 바뀌나
지금
- 영수증에 블록 시작부터 그 트랜잭션까지 쓴 가스의 누적 합(cumulativeGasUsed)이 적힙니다
- 트랜잭션 하나의 가스 사용량을 검증하려면 앞 영수증도 받아 뺄셈해야 합니다
- 영수증 내용이 앞 트랜잭션에 묶여 있어 서로 무관한 트랜잭션도 따로 처리하기 어렵습니다
- RPC의 logIndex 가 블록 전체 기준 번호입니다
EIP-8116 이후
- 영수증에 그 트랜잭션이 쓴 가스(gasUsed)만 적힙니다
- 영수증 하나와 머클 증명만으로 가스 사용량을 검증합니다
- 영수증이 앞 트랜잭션과 무관해져 병렬 처리의 걸림돌이 사라집니다
- logIndex 가 영수증 안의 번호가 됩니다
누구에게 영향이 있나
- 지갑·앱 개발자: 검증된 gasUsed 나 cumulativeGasUsed 값을 쓰는 앱, 블록 단위 logIndex 로 로그 순서를 정하는 앱은 새 의미에 맞춰 고쳐야 합니다.
- RPC 클라이언트·라이트 클라이언트: 영수증 하나만으로 트랜잭션의 가스 사용량을 검증할 수 있어 앞 영수증을 추가로 받을 필요가 없어집니다.
- 클라이언트 팀: 영수증 생성 로직과 JSON-RPC 응답의 logIndex 계산을 바꿔야 합니다. 콜에서는 기술 부채 청소 성격으로 분류했습니다.
- 일반 사용자: 직접 조작할 것은 없습니다. 쓰는 지갑·앱이 새 데이터 형식에 맞춰 업데이트되면 됩니다.
심층 설명
영수증에 트랜잭션별 가스 사용량을 적습니다
이 EIP가 활성화된 뒤 만들어지는 모든 영수증은 cumulativeGasUsed 대신 해당 트랜잭션의 gasUsed 를 기록합니다. cumulativeGasUsed 는 블록 안에서 앞선 트랜잭션들이 쓴 가스를 모두 더한 누적값이고 gasUsed 는 그 트랜잭션 하나가 쓴 값입니다. 원문 명세는 이 한 문장으로 끝나며 영수증의 다른 필드나 인코딩 방식 변경은 적혀 있지 않습니다. 콜 기록에 따르면 이 변경으로 영수증 두 개를 받아 차이를 계산하지 않아도 머클 증명 하나로 트랜잭션의 가스 사용량을 검증할 수 있게 됩니다.
JSON-RPC의 logIndex 가 영수증 기준 번호가 됩니다
JSON-RPC 응답의 logs 안에 있는 logIndex 필드는 지금까지 블록 전체에서 몇 번째 로그인지를 나타냈습니다. 이 EIP 이후에는 그 영수증 안에서 몇 번째 로그인지를 나타냅니다. 원문은 이 부분이 온체인 데이터가 아니라 RPC 만 바뀌는 변경이라고 명시합니다. 즉 블록에 저장되는 로그 자체는 그대로이고 노드가 응답에 붙이는 번호만 바뀝니다. 원문 Motivation 은 블록 단위로 증가하는 logIndex 가 cumulativeGasUsed 와 같은 단점이 있다고 지적하며 이 변경은 그 지적에 대한 답입니다.
누적 필드가 낳는 두 가지 문제
원문은 cumulativeGasUsed 의 단점을 두 가지로 정리합니다. 첫째는 비효율적인 검증입니다. 개별 트랜잭션의 gasUsed 를 검증하려는 RPC 클라이언트는 연속된 영수증들의 cumulativeGasUsed 를 가져와 계산해야 합니다. 둘째는 제한된 병렬성입니다. 서로 겹치지 않는 상태만 건드리는 트랜잭션이라도 영수증 내용이 앞 영수증에 의존하는 상태 기반(stateful) 값이라 독립적으로 만들 수 없습니다. 원문은 logIndex 도 영수증별 번호가 아니라 블록 단위로 증가하는 번호라서 같은 단점이 있다고 덧붙입니다.
온체인 데이터를 실제 쓰이는 RPC 데이터에 맞춥니다
원문 Rationale 은 이 EIP를 온체인 데이터와 클라이언트 애플리케이션이 실제로 소비하는 RPC 데이터를 맞춰 가는 한 걸음이라고 설명합니다. 구체적으로는 영수증의 상태 기반 구성 요소인 cumulativeGasUsed 와 logIndex 를 트랜잭션별 값으로 바꾸는 일입니다. Motivation 에 따르면 RPC 클라이언트가 원하는 값은 트랜잭션별 gasUsed 인데 체인에는 누적값만 있어서 이 값을 직접 검증하려면 연속된 영수증을 모아 계산해야 했습니다. 체인에 처음부터 트랜잭션별 값을 두면 그 간극이 사라집니다.
하위 호환성: 앱이 적응해야 하는 두 지점
첫째, 검증된 gasUsed 나 cumulativeGasUsed 값을 쓰는 애플리케이션은 새 온체인 의미에 맞춰 바꿔야 합니다. 둘째, 블록 단위 logIndex 에 의존하는 애플리케이션도 손봐야 합니다. logIndex 가 영수증별 번호가 되기 때문입니다. 원문은 예전처럼 블록 안 로그의 상대 순서를 알고 싶으면 transactionIndex * 4 + logIndex 로 추정하라고 제안합니다. 원문은 이렇게 하면 순서가 이전과 같게 보장되지만 절대 번호 값은 예전보다 커질 수 있다고 적습니다. 이 식은 정확한 복원이 아니라 추정이라는 점을 원문도 estimating 이라는 말로 분명히 합니다.
상태: Draft, Hegota 포크 검토 대상 중 최하위
이 EIP는 2025-12-30에 만들어진 Draft 상태 제안이라 명세가 아직 바뀔 수 있습니다. Security Considerations 절도 None 으로만 적혀 있어 뒤에 채워질 수 있습니다. 코어 개발자 콜에서는 07.30 ACDE #242 에서 Hegota 포크 후보로 접수(PFI)했습니다. 영수증 두 개를 받아 차이를 계산하지 않아도 머클 증명으로 검증할 수 있게 된다는 점이 근거였습니다. 10.08 ACDE #247 에서는 Hegota 검토 대상(CFI)에 올리되 우선순위를 맨 아래에 뒀습니다. 기술 부채 청소 성격이라 급하지 않다는 평가였습니다. 포크 포함이 확정된 것은 아닙니다.