EIP-8058 컨트랙트 중복 배포 가스 할인 (Contract Bytecode Deduplication Discount)
포함 제외 (DFI) · 수수료·가스 · 원문 상태 Draft · 2025-10-22 작성
이미 체인에 올라가 있는 컨트랙트와 똑같은 코드를 다시 배포할 때, 거래의 접근 목록(access list)에 기존 컨트랙트 주소를 넣으면 코드 저장 가스를 면제해 주는 제안입니다.
왜 필요한가
지금은 똑같은 바이트코드(bytecode, 컨트랙트의 실행 코드)를 다시 배포해도 처음 배포할 때와 같은 비용을 냅니다. 하지만 노드 소프트웨어는 실제로 코드를 한 벌만 저장하고 여러 계정이 같은 코드를 가리키게 합니다. 즉 저장 공간을 더 쓰지 않는데도 저장 비용을 또 내는 셈입니다. 코드 저장 가스를 바이트당 200에서 1,900으로 올리는 EIP-8037이 적용되면 24kB 컨트랙트 하나의 코드 저장 비용만 약 4,660만 가스가 되어 이 불공평이 훨씬 커집니다. 그렇다고 "노드 데이터베이스에 이 코드가 있는지"를 그냥 조회하면 안 됩니다. 풀 싱크 노드는 과거 코드까지 다 갖고 있고 스냅 싱크 노드는 일부만 갖고 있어서, 노드마다 조회 결과가 달라지고 가스 계산이 갈라져 합의가 깨지기 때문입니다. 이 제안은 거래에 이미 들어 있는 접근 목록만 보고 할인 여부를 정하므로 모든 노드가 같은 답을 냅니다.
무엇이 바뀌나
지금
- 같은 코드를 다시 배포해도 코드 저장 가스를 전액 냅니다
- 노드는 코드를 한 벌만 저장하는데 비용은 매번 새로 받습니다
- 접근 목록은 저장소 접근을 미리 알리는 용도로만 쓰입니다
EIP-8058 이후
- 접근 목록에 같은 코드를 가진 기존 컨트랙트 주소를 넣으면 코드 저장 가스(GAS_CODE_DEPOSIT × 길이)를 내지 않습니다
- 새 계정은 기존 코드 해시에 연결만 되고 코드는 다시 저장되지 않습니다
- 거래 형식은 그대로라서 기존 지갑과 도구가 그대로 동작합니다
누구에게 영향이 있나
- 같은 컨트랙트를 여러 번 배포하는 앱·프로젝트: 접근 목록에 주소 하나만 넣으면 중복 배포 비용이 크게 줄어듭니다. EIP-8037이 적용되면 절감 폭이 더 커집니다.
- 지갑·개발 도구 팀: 가스 추정(eth_estimateGas)에 할인 가능성을 반영하고 중복 배포를 감지해 접근 목록을 자동으로 채우는 기능을 넣을 수 있습니다.
- 클라이언트(노드) 팀: 거래 실행 전에 코드 해시 집합을 만들고 배포 완료 시 비교하는 로직을 추가해야 합니다. 상태 트리나 데이터베이스 구조 변경은 없습니다.
심층 설명
코드 해시 접근 집합 W의 구성
거래 실행이 시작되기 전, 상태가 바뀌기 전 시점의 상태를 기준으로 집합 W = { codeHash(a) | a ∈ accessList, a가 상태에 존재, a에 코드 있음 }를 만듭니다. 접근 목록의 모든 주소를 검사하며 상태에 존재하고 배포된 코드가 있는 계정의 코드 해시만 W에 들어갑니다. 빈 계정이나 코드 없는 계정은 기여하지 않습니다. EIP-2930 접근 목록 구조를 그대로 쓰며 새 필드나 프로토콜 변경이 없습니다.
컨트랙트 생성 가스 계산
컨트랙트 생성 거래나 CREATE/CREATE2가 성공해 길이 L의 바이트코드 B를 반환하면 H = keccak256(B)를 계산합니다. H ∉ W면 새 코드이므로 GAS_CODE_DEPOSIT × L을 과금하고 B를 H 아래 저장한 뒤 새 계정의 codeHash를 H에 연결합니다. H ∈ W면 과금과 저장 없이 기존 코드 해시 H에 연결만 합니다. 접근 목록 주소의 codeHash를 읽는 비용은 EIP-2929/2930의 접근 비용(접근 목록 고유 비용과 cold→warm 상태 접근 비용)에 이미 포함되어 있어, 중복 검사 자체에 추가 가스는 없습니다.
같은 블록 안의 순차 배포
거래는 순차 실행되므로, 거래 T_A가 블록 안에서 먼저 바이트코드 B를 주소 X에 배포하면(전액 과금) 같은 블록의 이후 거래 T_B가 접근 목록에 X를 넣어 할인을 받을 수 있습니다. T_B의 W는 T_A의 변경이 반영된 현재 상태에서 만들어지기 때문입니다. 원문은 이 동작이 거래 순서 제어가 필요해 악용하기 복잡하고 빌더가 이미 서명된 접근 목록을 수정할 수도 없지만, 일어날 수 있으므로 명세로 형식화한다고 적습니다.
엣지 케이스: 동시에 처음 배포되는 같은 코드
같은 블록의 두 거래가 모두 처음 보는 동일 바이트코드를 배포하고 서로의 주소를 접근 목록에 넣지 않았다면 둘 다 전액을 냅니다. 할인은 배포된 주소가 접근 목록에 들어 있을 때만 적용됩니다. 원문은 첫 배포를 거래 작성 시점에 알 수 없고 할인이 접근 목록을 통한 암묵적 opt-in이며, 이런 상황이 실제로 극히 드물고 특별 처리의 복잡성이 이득에 비해 크지 않다는 이유로 이를 수용 가능하다고 봅니다.
왜 접근 목록 방식인가
결과가 거래의 접근 목록과 현재 상태에만 의존하므로 모든 노드가 같은 가스를 계산합니다. codeHash → 계정 목록의 역방향 인덱스를 유지할 필요가 없고 EIP-2930/2929의 기존 인프라 위에 최소한의 변경으로 올라갑니다. 새 거래 구조를 만들지 않아 모르는 필드 때문에 노드가 거래를 거부하는 체인 분기 위험도 없습니다. 참고로 캔쿤 포크 시점 기준 풀 싱크 노드에는 살아 있는 계정이 가리키지 않는 바이트코드가 약 27,869개 있었는데, 어떤 계정의 codeHash도 이를 참조하지 않으므로 이 차이로 할인을 받을 수 없어 합의가 안전하게 유지됩니다.
하위 호환성과 구현 부담
예정된 네트워크 업그레이드가 필요하지만 거래 구조 변경은 없습니다. 접근 목록이 있는 기존 거래는 포크 후 자동으로 할인 대상이 되고 접근 목록이 없는 거래는 지금과 똑같이 동작합니다. eth_estimateGas 같은 RPC는 접근 목록이 있을 때 할인 가능성을 반영해야 하며(SHOULD), 지갑은 할인용 주소 추가 UI를 제공할 수 있고(MAY), 거래 빌더는 중복 배포를 자동 감지할 수 있습니다(MAY). 상태 트리 구조, 데이터베이스 스키마, 거래 파싱과 RLP 인코딩은 바뀌지 않습니다. 중복 검사는 집합 멤버십 테스트라 O(1)이고 추가 상태 조회가 없어 DoS 위험도 없습니다.
진행 상태: Draft, 헤고타 후보에서 제외
이 EIP는 Draft 상태로 내용이 아직 바뀔 수 있습니다. 08.13 ACDE #243에서는 챔피언(champion, 제안을 책임지고 밀어붙이는 담당자)이 콜에 없어 후보로 접수되지 않았습니다. 08.27 ACDE #244에서는 챔피언이 없고 SETCODEFROM이 같은 목표를 더 일반적으로 달성한다는 Ben Adams의 지적에 따라 헤고타 후보에서 빠졌습니다. 같은 문제를 푸는 다른 제안에 흡수됐다는 뜻입니다.