상태 가스 리프라이싱(EIP-8037·8038)은 상태 성장 문제를 해결하는가?

프로토콜 설계 · 참여 7명 · 인용 11건 · 2026-10-23 ~ 2026-10-25

Geth의 lightclients는 EIP-8037·8038이 가스 리밋을 올릴 수 있게 해줄 뿐 끝없이 성장하는 상태(state)라는 근본 문제를 풀지 못하며 배포된 컨트랙트를 깨는 것은 최후 수단이어야 한다고 공개 리트로를 올렸고 EF의 dankrad는 상태를 더 정확하게 가격 매기는 것 자체가 개선이라고 반박했다. 상태 만료(state expiry)와 프로세스 개편을 요구하는 개발자들이 lightclients 쪽에 보탰다.

배경

EIP-8037과 EIP-8038은 상태 접근·생성에 드는 가스 비용을 다시 매기는(리프라이싱) 제안으로 Glamsterdam 포크 대상으로 스케줄됐다. 가스 리밋을 올리려면 상태 접근 비용이 노드의 실제 자원 소모를 반영해야 한다는 문제의식에서 나왔다. 2020년 EIP-2929는 같은 DoS 우려로 SLOAD·CALL 비용을 약 3배 올렸고 EIP-2930은 그로 인해 깨질 수 있는 컨트랙트를 위해 선택적 접근 목록(access list)으로 우회로를 제공했다. lightclients는 이번 EIP들이 그때처럼 가스 리밋을 올리는 효과만 있을 뿐 상태 성장 자체를 묶지 못한다고 본다. 대안으로 거론되는 상태 만료(state expiry)와 EIP-8304(trustless log index)는 성장하는 상태를 다른 각도에서 다루려 한다.

왜 중요한가

이 논쟁의 결론이 배포된 컨트랙트를 깨뜨리는 가스 스케줄 변경을 어디까지 허용할지, 그리고 상태 만료 로드맵에 다시 힘을 실을지를 가른다. Glamsterdam의 8037·8038 메인넷 영향 분석 결과와 연기 여부를 지켜봐야 한다.

쟁점

• 리프라이싱(repricing)이 상태 성장을 '묶는' 것인가, 가스 리밋 인상만 가능하게 하는 것인가
• 더 정확한 상태 가격 책정은 그 자체로 성장 문제의 개선인가
• 완전한 상태 만료의 UX 비용을 감수할 것인가, 상태가 10배 커지는 쪽을 견딜 것인가

반대 — 상태 성장을 풀지 못하는 미봉책이다

ً, Danno Ferrin, donnoh.gwei 💗, Kushal Babel, perper, chain native

• EIP-8037·8038은 끝없이 성장하는 상태라는 근본 문제를 풀지 않고 가스 리밋을 올릴 수 있게 해줄 뿐이다
• 메인넷 컨트랙트에 미치는 영향 분석을 6개월 전에 했어야 했고 배포된 코드를 깨는 것은 최후 수단이어야 한다
• 프로토콜 내 완전한 상태 만료 대신 콜드 상태 접근 비용을 훨씬 높게 매기고 클라이언트의 DB 최적화에 맡기는 편이 현실적이다
• 상호작용을 스스로 이해하지 못하는 변경이라면 아무도 안전함을 입증하지 못했다는 중대한 경고 신호다(donnoh)

찬성 — 더 정확한 가격 책정은 개선이다

Dankrad Feist

• 상태의 더 정확한 가격 책정을 가능하게 하는데, 이는 상태 가스가 작동하는 방식을 바꾸지 않고는 거의 불가능한 일이다
• 상태가 덜 자라도록 튜닝할 수 있다는 의미에서 개선이지만 성장을 어떤 식으로든 묶어두지는 못한다는 점은 인정한다
• 완전한 상태 만료에 필요한 업그레이드의 UX 영향을 감수하느니 상태가 10배 커지는 쪽을 견디는 게 더 쉽다

← Debates