EIP-7971 일시 저장소 가스 인하와 하드 한도 (Hard Limits for Transient Storage)
포함 제외 (DFI) · 수수료·가스 · 원문 상태 Draft · 2025-06-12 작성
일시 저장소 명령어 TLOAD와 TSTORE의 가스비를 100에서 각각 5와 12로 내리고 대신 한 거래에서 쓸 수 있는 슬롯 수를 131072개로 제한해 자원 고갈 공격을 막습니다.
왜 필요한가
EIP-1153이 도입한 일시 저장소(transient storage)는 거래가 끝나면 사라지는 임시 저장 공간인데, 디스크에 기록하거나 상태 루트를 갱신할 필요가 없는데도 일반 저장소의 웜(warm) 접근과 같은 100가스로 책정되어 있습니다. 이 가격 때문에 재진입 공격을 막는 잠금을 프로그래밍 언어 차원에서 기본으로 넣기에는 여전히 부담이 크고 임시 승인이나 콜백 메타데이터, 거래 안 프레임 간 통신 같은 정당한 용례도 위축됩니다. 그렇다고 가격만 내리면 공격자가 싼 값에 메모리를 대량으로 할당하는 서비스 거부(DoS) 공격이 가능해집니다. 그래서 이 EIP는 가격을 내리는 동시에 거래당 쓸 수 있는 슬롯 수에 하드 한도를 두어 일반 용례는 싸게 쓰고 클라이언트는 자원 소비 상한을 확실히 보장받게 합니다.
무엇이 바뀌나
지금
- TLOAD와 TSTORE 모두 웜 저장소 접근과 같은 100가스입니다
- 일시 저장소 슬롯 수에 별도 상한이 없어 6천만 가스 거래가 최대 60만 슬롯(38.4MB)을 할당할 수 있습니다
- 100가스 비용 때문에 언어 차원에서 재진입 잠금을 기본으로 넣기 어렵습니다
EIP-7971 이후
- TLOAD는 5가스, TSTORE는 기본 12가스로 내려갑니다
- 한 거래에서 쓸 수 있는 고유 슬롯이 131072개(약 8MB)로 제한되고 넘으면 거래가 중단됩니다
- 클라이언트가 일시 저장소에 쓸 메모리를 거래 시작 시점에 미리 예약할 수 있습니다
누구에게 영향이 있나
- 컨트랙트·언어 개발자: 재진입 잠금, 임시 승인, 콜백 메타데이터 같은 용례를 지금보다 훨씬 싼 가스비로 쓸 수 있습니다.
- 사용자: 일시 저장소를 쓰는 컨트랙트와 상호작용할 때 내는 가스비가 줄어듭니다.
- 클라이언트 팀: 거래 전역 카운터를 새로 구현해야 하지만 거래당 최대 메모리 사용량이 약 8MB로 고정되어 자원 소비를 예측하기 쉬워집니다.
심층 설명
가스비 변경: TLOAD 5, TSTORE 12
TLOAD(오피코드 0x5c)의 가스비를 GAS_WARM_ACCESS(100)에서 GAS_TLOAD(5)로, TSTORE(오피코드 0x5d)의 기본 가스비를 100에서 GAS_TSTORE(12)로 내립니다. 근거는 실제 자원 사용량입니다. 일시 저장소 읽기는 디스크 I/O 없이 메모리 접근만 필요하므로 5가스로, 쓰기는 메모리 할당과 revert 지원을 위한 저널링이 필요하므로 12가스로 잡았습니다. 일시 저장소는 영구 저장소보다 근본적으로 자원이 덜 드는데도(디스크 I/O 없음, 상태 루트 갱신 없음) 웜 저장소 연산과 같은 가격이라는 불일치를 바로잡는 것입니다.
거래 전역 슬롯 카운터와 한도
거래 시작 시 transient_slots_used 카운터를 0으로 초기화하고 TSTORE가 실행될 때 그 슬롯이 이 거래에서(어느 컨트랙트에서든) 처음 쓰이는 슬롯이면 카운터를 1 올립니다. 카운터가 MAX_TRANSIENT_SLOTS(131072)를 넘으면 거래는 반드시(MUST) 예외적으로 중단됩니다. 카운터는 거래 안의 모든 메시지 콜에 걸쳐 유지되고 거래가 끝나면 0으로 리셋됩니다. 슬롯의 고유성은 (contract_address, storage_key) 튜플 기준입니다. 같은 슬롯에 여러 번 써도 첫 쓰기 이후에는 보통 카운터가 늘지 않지만 revert로 슬롯이 해제된 경우는 예외입니다.
신규 슬롯 할당 비용 GAS_TSTORE_ALLOCATE
새 슬롯에 처음 쓸 때는 메모리 할당이 필요해 기존 슬롯에 다시 쓰는 것보다 비쌉니다. 그래서 첫 할당에 GAS_TSTORE_ALLOCATE(24)를 추가로 물리는 방안을 검토하고 있습니다. 다만 첫 할당인지 이후 쓰기인지 구분하는 메커니즘이 함께 필요합니다. 참조 구현에는 이 과금 방식이 포함되어 있습니다. unique_slots 집합에 없는 슬롯이면 24가스를 추가로 차감하고 집합에 넣은 뒤, 집합 크기가 131072를 넘으면 ExceptionalHalt를 일으키는 구조입니다.
수치는 벤치마크 후 확정
제안서는 수치가 아직 확정되지 않았다고 명시합니다. 일시 메모리 연산에 대한 벤치마크가 현재 개발 중이고 그 데이터를 모은 뒤 최종 숫자를 정하며, 신규 슬롯 할당을 다르게 과금할 만큼 성능 차이가 있는지도 그 데이터로 판단합니다. 또 캐시에서 읽는 웜 저장소 로드는 일시 저장소 읽기와 비슷한 성능 특성이 예상되므로, 최종 파라미터는 EIP-8038과 일관되게 맞춰야 한다고 적고 있습니다. 테스트 케이스도 아직 TBD 상태입니다.
하드 한도 선택과 배제한 대안
MAX_TRANSIENT_SLOTS 131072는 일반 애플리케이션에 충분한 슬롯을 주면서 거래당 메모리 사용을 약 8MB(131072 슬롯 × 64바이트)로 묶어 메모리 고갈(OOM) 기반 DoS를 막습니다. 하드 한도의 장점은 세 가지입니다. 현재 가스 한도의 함수로 계산하지 않아도 총 자원 소비가 보장되고 재진입 잠금처럼 슬롯 1~2개만 쓰는 일반 용례가 최악 사례 비용을 떠안지 않으며, 클라이언트가 거래 시작 시 필요한 메모리 전부를 안전하게 미리 예약할 수 있습니다. 대안으로 검토된 컨트랙트별 한도는 콜 스택 모양에 따라 자원 추론이 복잡해지고 초선형 가격은 복잡성을 더하면서 일반 용례를 계속 벌점 주며, 무제한은 거래 가스 한도나 가격이 나중에 바뀌면 메모리 DoS를 허용할 수 있어 배제했습니다.
보안 효과: 최대 할당량 79% 감소
현재 100가스 가격에서는 6천만(60M) 가스 거래가 일시 저장소 슬롯을 최대 600,000개, 38.4MB까지 할당할 수 있습니다. 이 EIP가 적용되면 상한이 131072슬롯, 약 8MB로 고정되어 최대 할당량이 79% 줄어듭니다. 하드 한도 방식이라 앞으로 가스 한도나 다른 프로토콜 파라미터가 바뀌어도 자원 소비 상한은 예측 가능하게 유지됩니다. 하위 호환성 문제는 기존 연산이 싸진다는 점 외에 알려진 것이 없습니다.
상태와 코어 개발자 콜 결정
이 EIP는 Draft 상태라 내용이 아직 바뀔 수 있습니다. 콜 기록에 따르면 08.13 ACDE #243에서 EIP 7971은 8058, 7609, 7973, 8360과 함께 포크 포함 후보(DFI)로 접수되지 않았습니다. 챔피언(제안을 책임지고 밀어붙이는 담당자)이 콜에 없어 nixo가 제안자에게 연락하고 연락이 안 되면 PR을 닫기로 했습니다.