EIP-8037

EIP-8037은 “상태 생성 Gas 비용 인상”이라는 제목의 제안된 Ethereum 코어 프로토콜 변경 사항으로, 온체인 상태 생성에 드는 가스 비용을 인상 및 표준화하는 동시에 해당 비용을 일반 실행 비용과 분리하여 계산합니다. 2025년 10월 1일 Maria Silva, Carlos Perez, Jochem Brouwer, Ansgar Dietrichs, Łukasz Rozmej, Anders Elowsson, Francesco D’Amato, Dragan Rakita, Paweł Bylica, Spencer Taylor-Brown, Gary Rong에 의해 작성되었으며, block 가스 한도가 상승함에 따라 상태 성장을 제한하는 동시에 더 높은 트랜잭션 처리량과 더 큰 규모의 컨트랙트 배포를 허용하는 것을 목표로 합니다. 2026년 10월 24일 기준, EIP 저장소에는 해당 제안의 상태가 2026년 11월 1일을 마감일로 하는 “Last Call(최종 호출)” 단계로 기재되어 있으며, 공식 사양에는 동료 검토(peer-review)가 진행 중이라고 명시되어 있습니다.^[1]​^[2]​^[3]​

동기 (Motivation)

Ethereum은 영구적인 상태를 추가하는 작업에 비용을 부과하지만, EIP-8037은 기존 비용 체계가 일관되지 않다고 설명합니다. 이 제안은 새로운 바이트당 약 200 gas가 드는 컨트랙트 배포와 새로운 바이트당 약 313 gas가 드는 스토리지 슬롯 생성을 비교합니다. 또한 클라이언트가 중복 코드를 저장하지 않음에도 불구하고, 이미 데이터베이스에 존재하는 바이트코드를 배포하는 비용이 새로운 바이트코드를 배포하는 비용과 동일할 수 있다는 점을 지적합니다. 이 제안은 이러한 작업의 가격을 추가되는 상태의 양에 따라 책정하는 것을 목표로 합니다.^[1][2]

이 제안은 Ethereum 상태 데이터베이스의 예상 성장치를 근거로 삼고 있습니다. 보고에 따르면 2026년 1월 Geth node의 상태 데이터베이스는 약 390 GiB였습니다. 가스 한도가 3,000만에서 6,000만으로 증가한 후, 일일 평균 신규 상태 증가량은 약 105 MiB에서 326 MiB로, 즉 연간 약 116 GiB로 증가한 것으로 보고되었습니다. 제안서는 이러한 변화를 비선형적이며 사용자 행동의 일시적인 변화와 관련이 있을 수 있다고 규정합니다. 증가 후의 비율을 2억 가스 한도에 대입하여 추산하면 연간 상태 성장량은 약 387 GiB에 달하며, 이 추산에 따르면 약 390 GiB에서 시작한 상태 데이터베이스는 1년 이내에 650 GiB를 초과하게 됩니다.^[1][4]

설계 및 가스 회계 (Design and Gas Accounting)

EIP-8037은 새로운 상태에 대한 비용을 계산하는 데 사용되는 상태 바이트당 비용(CPSB)을 도입합니다. 사양서에는 CPSB가 바이트당 1,530 gas로 기재되어 있으며, 이는 기준 block gas 한도 1억 5,000만 가스에서 연간 평균 상태 성장량 120 GiB를 목표로 조정된 수치입니다. 상태 크기 매개변수는 스토리지 세트에 64바이트, 새 계정에 120바이트, 권한 부여 베이스(authorization base)에 23바이트를 할당합니다. 또한 호출당 최대 16개의 시스템 스토리지 작업을 설정하고, 최대 총 트랜잭션 가스 한도를 4,294,967,295(2³²−1)로 설정합니다.^[1][2]

제안의 설계는 개발 과정에서 변경되었습니다. 초기 초안에서는 연간 100 GiB의 상태 성장을 목표로 하는 양자화된 공식을 사용하여 block 가스 한도에서 CPSB를 동적으로 계산했습니다. 2026년 5월 4일에 병합된 수정안은 해당 체계를 9,600만 가스 기준 한도에서 연간 100 GiB 목표를 기반으로 한 1,174의 고정 CPSB로 대체했습니다. 현재 EIP 사양은 생성된 상태의 양에 따라 비용을 할당하는 일반적인 접근 방식은 유지하면서도, 다른 CPSB 값과 보정치를 명시하고 있습니다.^[5][6][1]

사양에서 제안된 일정에 따르면, CREATE 및 CREATE2는 새 계정과 배포된 코드의 각 바이트에 대해 상태 가스를 부과하며, 코드 해싱 비용을 포함한 실행 가스 비용도 발생시킵니다. CALL 및 SELFDESTRUCT는 새 계정을 생성할 때 상태 가스를 발생시키며, SSTORE는 새 스토리지 슬롯에 대해 상태 가스를 부과합니다. EIP-7702 계정 위임 또한 상태 생성과 실행 비용을 분리합니다. 빈 계정을 생성하고 권한 부여 베이스를 기록하는 것은 상태 가스로 가격이 책정되는 반면, 관련 실행 작업은 실행 가스로 남습니다. 여러 액세스 및 계정 쓰기 비용은 EIP-8038에 의해 정의되거나 업데이트되는데, 해당 값은 제안서에서 아직 확정되지 않았습니다.^[1][4]

핵심적인 회계 변경 사항은 **실행 가스(execution-gas)**와 **상태 가스(state-gas)**를 별개의 차원으로 추적하는 것입니다. 사용자는 두 가지 모두에 대해 비용을 지불하지만, EIP-7825에 의해 도입된 트랜잭션 가스 한도는 실행 가스에 적용되며, 상태 가스는 트랜잭션의 가스 허용량(gas allowance)에 의해 별도로 제한됩니다. 블록 레벨에서 클라이언트는 각 리소스의 누적 사용량을 추적합니다. 블록의 gas_used는 두 합계 중 더 큰 값이 되며, 이 병목 차원이 블록이 가득 찼는지 여부와 다음 블록의 기본 수수료(base fee)가 어떻게 조정될지를 결정합니다. EIP-7623에 따른 콜데이터(calldata) 가스 하한선은 실행 가스에 적용되므로 상태 가스로는 이를 충족할 수 없습니다.^[1][2]

이 제안은 트랜잭션 내에서 이러한 분리를 지원하기 위해 상태 가스 저장소(state-gas reservoir)를 사용합니다. 상태 생성 비용은 남은 실행 가스를 소비하기 전에 저장소에서 먼저 차감되며, 일반적인 작업 비용은 실행 가스를 사용합니다. 제안서는 별도의 측정을 통해 일반적인 트랜잭션 가스 캡이 단일 공유 한도와 같은 방식으로 대규모 배포를 제약하는 것을 방지할 수 있다고 주장합니다. 또한 트레이드오프도 인정합니다. 블록 빌더는 두 가지 리소스 차원의 균형을 맞춰야 하므로, 잠재적으로 더 정교한 빌더에게 유리하게 작용하여 중앙 집중화 압력을 높일 수 있습니다. 한 차원이 소진될 때까지 블록을 채우는 것과 같은 더 단순한 전략도 많은 용도에서 실용적이라고 설명됩니다.^[1][4]

호환성 및 보안 고려 사항 (Compatibility and Security Considerations)

EIP-8037은 일부 작업 후에 [GAS](https://iq.wiki/wiki/gas) 옵코드가 [gas](https://iq.wiki/wiki/gas)_left의 증가를 보고할 수 있다고 경고합니다. 따라서 연속적인 GAS 읽기 값을 빼서 작업량을 추정하는 컨트랙트는 음수 차이를 계산할 수 있으며, 이로 인해 체크된 산술 연산(checked arithmetic)이 되돌려지거나(revert) 체크되지 않은 산술 연산이 랩핑(wrap)될 수 있습니다. 사양서는 동일한 트랜잭션 내에서 0에서 설정되었다가 다시 지워지는 스토리지 슬롯에 대해 논의합니다. 이 경우 상태 가스 리필이 gas_left로 가스를 반환할 수 있습니다. 호출 프레임이 병합될 때 상태 가스를 반환하면 호출 경계를 넘어 효과가 확장될 수 있습니다.^[1][4]

이 제안은 또한 ERC-4337 트랜잭션 번들에 대한 위험을 식별합니다. GAS는 gas_left를 노출하지만 상태 가스 저장소는 노출하지 않기 때문에, 번들러와 EntryPoint 구현체는 gasleft() 차이만으로는 모든 상태 가스 비용을 신뢰성 있게 할당할 수 없습니다. 번들 내의 사용자 작업은 트랜잭션 저장소를 공유하므로, 한 작업의 상태 가스 환불이 다른 작업의 비용을 보조할 수 있으며 이는 어느 작업의 측정된 가스 차이에도 나타나지 않을 수 있습니다. 제안서는 번들러와 EntryPoint 구현체가 상태 가스 비용과 환불을 명시적으로 계산해야 한다고 명시합니다.^[1][4]

제안 상태 및 보안 (Proposal Status and Security)

2026년 10월 24일 기준, EIP 저장소는 EIP-8037을 2026년 11월 1일 마감인 “Last Call” 상태로 분류했습니다. 공식 사양에는 해당 EIP가 동료 검토 과정에 있다고 명시되어 있습니다.^[1][2]

2026년 10월 13일, 보안 업체 ChainSecurity는 EIP-8037 및 EIP-8038과 관련된 우려 사항에 대한 분석을 발표했습니다. 이 업체는 남은 gas를 사용하여 실제 작업 실패와 가스 부족으로 인한 실패(재시도 가능)를 구분하는 컨트랙트에서 발생하는 가스 부족 그리핑(insufficient-gas griefing) 위험을 경고했습니다. 제안된 규칙 하에서는 실패한 외부 호출이 이전 규칙보다 더 많은 가스를 호출자에게 반환할 수 있으며, 이는 기존 체크 결과의 변화를 초래할 수 있습니다. ChainSecurity는 영향을 받는 애플리케이션이 실패한 작업을 최종적인 것으로 처리하거나, 사용자의 청구권을 삭제하거나, 재시도를 방해할 수 있다고 밝혔으며, 번들 트랜잭션과 지급(payout)을 관련 사례로 꼽았습니다. 이 업체는 라이브 컨트랙트에서 해당 패턴의 사례 13개를 발견했다고 보고했으며, 공개 발표 전 영향을 받는 팀들과 비밀리에 협력 중이라고 밝혔습니다.^[7]

테스트 및 배포 (Testing and Deployment)

EIP-8037은 계획된 Glamsterdam 업그레이드에 포함되었습니다. 2026년 10월 6일, Glamsterdam은 증가된 gas 한도와 함께 Sepolia testnet에서 활성화되었습니다. 이 업그레이드는 또한 EIP-8038을 EIP-8037과 그룹화했으며, block 제안자와 block 빌더의 분리를 프로토콜로 가져오는 'Enshrined Proposer-Builder Separation' 및 클라이언트가 일부 작업을 병렬로 수행할 수 있도록 블록이 액세스할 데이터를 식별하는 'Block-level Access Lists'와 같은 계획된 변경 사항을 포함했습니다.^[7]

Ethereum 개발자들은 Glamsterdam의 Hoodi testnet 활성화를 2026년 10월 26일 17:42:48 UTC로 예정했으나, ChainSecurity의 조사 결과 발표 이후 10월 22일에 이를 취소했습니다. 이 취소로 인해 계획되었던 Amsterdam 실행 레이어 및 Gloas 합의 레이어 업그레이드 활성화도 제거되었으며, Hoodi의 gas 한도를 2억으로 인상하려던 제안도 철회되었습니다. 이 변경은 테스트넷에 이미 기록된 블록이 아니라 향후의 Hoodi 구성에 영향을 미쳤으며, Sepolia 활성화는 영향을 받지 않았습니다. 10월 24일 현재 Hoodi 또는 mainnet에 대한 대체 날짜는 정해지지 않았습니다. 개발자들은 2026년 12월 1일, 8일, 9일을 가능한 mainnet 날짜로 논의했으나 확정된 바는 없습니다. 이번 취소는 EIP-8037 및 EIP-8038이 이미 메인넷에 배포된 컨트랙트와 어떻게 상호작용할지에 대한 추가 조사를 허용하기 위한 것이며, 메인넷은 변경 없이 계속 운영되었습니다.^[7][8]

별도의 실행 테스트 프레임워크(execution-test-framework) 계획은 EIP-8037의 가스 모델 테스트를 위한 준비 작업을 설명합니다. 여기에는 가스 비용 계산을 통해 블록 가스 한도 컨텍스트를 전달하고, 상태 가스 모델에 맞게 벤치마크를 조정하며, 하드코딩된 가스 한도가 이전 비용에 맞춰진 정적 테스트를 수정하는 작업이 포함됩니다. 이 계획은 테스트 및 지속적 통합(CI) 변경과 함께 3,000만, 6,000만, 1억 2,000만 블록 가스 한도에서의 테스트를 제안하고 있습니다. 이는 구현 계획이며 이러한 모든 변경 사항이 실제로 적용되었다는 증거는 아닙니다.^[9]

EIP-8037은 또한 활성 상태인 Stateless Consensus 프로토콜 변경 프로젝트로 등재되어 있습니다. 해당 사양은 저작권 및 관련 권리를 포기하는 CC0 하에 공개되었습니다.^[3][1][10]