이더리움 트랜지언트 스토리지: EIP-1153 TLOAD·TSTORE 원리

스마트 컨트랙트가 같은 트랜잭션의 다음 호출에 메모를 남겨야 할 때가 있어요. 그런데 그 메모를 영구 보관하면 상태 공간을 낭비합니다. 이더리움 트랜지언트 스토리지(Transient Storage)는 바로 이 짧은 수명의 작업 공간이에요. 호출마다 새로 생기는 메모리와 트랜잭션이 끝나도 남는 스토리지 사이의 개념이므로 블록체인 기초에서 꼭 구분해 둘 필요가 있습니다.

EIP-1153은 이 용도로 TLOAD와 TSTORE 명령어를 도입했어요. 재진입 잠금(Reentrancy Lock) 같은 패턴을 효율화할 수 있지만, 자동으로 지워진다고 자동으로 안전한 것은 아닙니다. 이 글은 확정된 프로토콜 사양과 현재 Solidity 공식 문서를 기준으로 작동 원리, 구현 범위와 위험을 설명해요.

이더리움 트랜지언트 스토리지란 무엇인가요?

트랜잭션을 여러 사람이 회의실을 쓰는 상황에 비유해 볼게요. **메모리(Memory)**는 참가자마다 받는 개인 메모장이라 호출이 바뀌면 새로 생깁니다. **영구 스토리지(Storage)**는 회의가 끝난 뒤에도 남는 문서 보관함이에요. 트랜지언트 스토리지는 한 컨트랙트가 회의 내내 공유하는 화이트보드에 가깝습니다. 그 컨트랙트의 여러 호출 프레임이 볼 수 있지만 트랜잭션이 끝나면 이더리움이 지워요.

EIP-1153은 트랜지언트 스토리지를 컨트랙트가 소유하는 워드 단위 키-값 공간으로 정의합니다. 실행 중에는 실패 되돌리기(Revert)를 포함해 일반 스토리지와 비슷하게 동작하지만, 모든 값은 트랜잭션 끝에 폐기돼요. 이더리움의 영구 상태에는 기록되지 않습니다.

이 수치는 확정된 EIP-1153 사양의 현재 비용입니다. 별도 초안이 미래의 다른 가격을 제안하더라도, 제안된 숫자를 지금 활성화된 네트워크 규칙처럼 사용하면 안 돼요.

트랜잭션 단위 수명은 어떻게 작동하나요?

트랜지언트 스토리지는 EVM 메모리보다 오래가고 영구 스토리지보다 짧게 유지됩니다. 네 가지 경계를 이해해야 해요.

한 트랜잭션 안의 호출 사이에서 유지돼요

컨트랙트 A가 트랜지언트 슬롯에 값을 쓰면, 같은 트랜잭션에서 A의 맥락으로 실행되는 뒤쪽 프레임이 그 값을 읽을 수 있습니다. 제어가 다른 컨트랙트를 거쳐 돌아올 때 유용해요. 일반 메모리는 메시지 호출마다 새로 생기므로 이런 컨트랙트 단위 공유 통로가 되지 못합니다.

전체 트랜잭션이 끝날 때 초기화돼요

초기화 시점은 함수 반환이 아니라 트랜잭션 종료입니다. 멀티콜(Multicall)이나 콜백 흐름에서 같은 컨트랙트를 다시 호출하면 앞에서 남긴 0이 아닌 값을 볼 수 있어요. 임시 잠금의 의도가 끝났다면 직접 해제해야 합니다. 뒤쪽 호출까지 유지하려는 설계일 때만 남겨 두세요.

실패하면 쓰기도 되돌아가요

호출 프레임이 실패하면 그 프레임과 함께 되돌아간 내부 호출에서 발생한 트랜지언트 쓰기도 롤백됩니다. 영구 스토리지의 실패 처리와 비슷해요. 성공한 바깥 프레임이 앞서 기록한 값은 계속 유지됩니다.

소유자는 실행 맥락을 따라가요

일반 CALL에서는 호출받은 컨트랙트가 접근하는 트랜지언트 스토리지를 소유합니다. DELEGATECALL에서는 영구 스토리지와 마찬가지로 코드를 빌려 실행하는 호출자의 맥락을 따라가요. 업그레이드 프록시 컨트랙트, 라이브러리와 공유 구현을 설계할 때 특히 중요합니다.

메모리·트랜지언트·영구 스토리지 비교

트랜지언트 스토리지는 단순한 '저렴한 메모리'가 아니에요. 스토리지와 비슷한 소유권과 슬롯 규칙을 가지며 함수가 반환된 뒤에도 같은 트랜잭션에서는 값이 보일 수 있습니다. 한 프레임의 계산에는 메모리를, 다음 트랜잭션도 알아야 하는 상태에는 영구 스토리지를 쓰세요. 여러 프레임이 현재 트랜잭션에서 임시 상태를 공유해야 할 때만 트랜지언트 스토리지가 맞습니다.

Solidity에서는 EIP-1153을 어떻게 쓰나요?

공식 Solidity 컨트랙트 문서는 상태 변수에 transient 키워드를 지원합니다. 이전 EVM에는 TLOAD와 TSTORE가 없으므로 Cancun 이상을 대상으로 컴파일해야 해요.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.28;
 
contract TransientGuard {
    bool transient locked;
 
    modifier nonReentrant() {
        require(!locked, "reentrant call");
        locked = true;
        _;
        locked = false;
    }
}

현재 고수준 Solidity 문법은 트랜지언트 스토리지의 값 타입(Value Type) 상태 변수만 지원해요. 배열, 매핑, 구조체 같은 참조 타입은 이 선언 문법으로 쓸 수 없습니다. 선언과 동시에 초기값을 지정할 수도 없어요. 배포 트랜잭션이 끝나면 값이 지워져 초기화 의미가 없기 때문입니다.

영구 스토리지와 트랜지언트 스토리지는 서로 독립된 주소 공간을 사용합니다. 트랜지언트 변수를 추가해도 일반 스토리지 슬롯이 밀리지 않아요. 다만 변수 이름은 구분돼야 하고 자체 레이아웃이 있습니다. 컴파일러 표준 JSON 출력의 transientStorageLayout으로 배치를 검토할 수 있어요.

대표 활용법: 재진입 잠금

재진입 잠금은 함수가 외부 호출을 하는 동안 공격자가 원래 실행이 끝나기 전에 다시 들어오는 것을 막아야 합니다. 따라서 여러 호출 프레임이 잠금 상태를 공유해야 해요. 기존 컨트랙트는 영구 SLOAD와 SSTORE를 쓰고 반환 전에 잠금을 해제했습니다.

EIP-1153은 같은 조정을 영구 상태에 쓰지 않고 트랜잭션 단위 공간에서 처리합니다. 디스크 영구 상태와 가스 환급 회계가 필요하지 않아 비용을 줄일 수 있어요. 하지만 올바른 제어 흐름은 여전히 필요합니다.

1. 민감한 동작 전에 잠금을 확인합니다.
2. 신뢰할 수 없는 외부 상호작용 전에 잠금을 설정해요.
3. 보호할 함수 본문을 실행합니다.
4. 같은 트랜잭션의 뒤쪽 호출을 허용해야 한다면 잠금을 해제해요.
5. 중첩 호출, 멀티콜, 콜백, 실패 경로와 프록시 실행 맥락을 테스트합니다.

잠금 하나가 컨트랙트 전체의 안전을 증명하지는 않아요. 설계에 따라 검사-효과-상호작용(Checks-Effects-Interactions), 풀 방식 송금, 좁은 외부 호출, 접근 제어와 공격적 테스트가 여전히 필요합니다. 수정자 하나를 완전한 방어책으로 보기 전에 스마트 컨트랙트의 기본 구조를 함께 확인하세요.

그 밖의 활용 사례

EIP는 여러 프레임 사이에서 임시 통신이 필요한 패턴을 제시합니다.

• 한 트랜잭션에서만 유효한 토큰 승인
• 트랜잭션 종료 전 잔액이 맞아야 하는 콜백 회계
• 프록시 실행 과정에서 전달하는 메타데이터
• 현재 트랜잭션에만 열리는 수수료 또는 권한
• 팩토리가 CREATE2 주소를 계산할 때 공유하는 생성자 데이터

이는 모든 임시 변수를 대체하라는 뜻이 아니라 설계 재료예요. 같은 실행 맥락이 소유한 여러 프레임이 한 트랜잭션에서 이 값을 공유해야 하는지 물어보세요. 그렇지 않다면 호출 데이터, 반환 데이터, 스택 또는 메모리가 더 단순할 수 있어요.

리스크와 한계

초기화 경계를 오해하기 쉬워요

트랜지언트 값은 외부 함수마다 지워지지 않습니다. 배치 라우터가 트랜잭션 종료 전에 같은 컨트랙트를 다시 호출하면 해제하지 않은 슬롯을 볼 수 있어요. 이는 조합성(Composability)을 깨뜨리거나 뒤쪽 동작에 의도적으로 영향을 줄 수 있습니다.

Delegatecall은 슬롯 소유자를 바꿔요

DELEGATECALL로 실행된 구현은 프록시의 트랜지언트 스토리지에 접근합니다. 서로 다른 모듈이 같은 슬롯을 고르면 충돌할 수 있어요. 고수준 컴파일러 레이아웃은 한 컴파일 계층의 우발적 충돌을 줄이지만, 어셈블리와 모듈형 프록시는 명시적인 슬롯 네임스페이스가 필요합니다.

정적 호출에서는 쓸 수 없어요

STATICCALL 안에서 TLOAD는 허용되지만 TSTORE는 트랜잭션 단위 상태를 바꾸므로 예외가 발생합니다. 임시 데이터라는 이유만으로 정적 실행과 호환되는 것은 아니에요.

컴파일러 버전이 중요해요

배포 전 Solidity 알려진 버그 목록을 확인해야 합니다. 공식 문서는 특정 via-IR 설정에서 0.8.28부터 0.8.33까지 영향을 주고 0.8.34에서 수정된 고위험 트랜지언트 스토리지 초기화 도우미 충돌을 기록하고 있어요. 현재 공식 컴파일러 버그 목록을 확인하고 버전을 고정한 뒤 빌드 설정이 영향 조건에 해당하는지 검토하세요.

저렴한 상태도 남용할 수 있어요

트랜지언트 쓰기는 노드 메모리를 소비하고 실패 시 롤백을 지원해야 합니다. EIP-1153이 메모리보다 높은 비용을 두는 이유예요. 이후의 가격 변경 제안은 별도 프로토콜 작업입니다. 무제한 할당이 안전하다거나 미래 초안의 가스 일정이 이미 적용됐다고 가정하면 안 됩니다.

개발자 체크리스트

• 대상 체인이 Cancun 이상 EVM 규칙을 지원하는지 확인
• 검토한 Solidity 컴파일러를 고정하고 알려진 버그 목록 확인
• 호출 프레임을 넘어 통신해야 할 때만 트랜지언트 상태 사용
• 값을 언제 해제할지 명확히 정의
• 같은 트랜잭션에서 컨트랙트를 두 번 호출하는 경로 테스트
• 바깥·안쪽 프레임의 실패 동작 테스트
• CALL과 DELEGATECALL의 소유권 추적
• 모듈형·프록시 어셈블리 슬롯에 네임스페이스 적용
• STATICCALL 경로가 TSTORE를 실행하지 않는지 확인
• 절감 효과를 추정하지 말고 배포 대상에서 가스 측정

자주 묻는 질문

EIP-1153은 영구 이더리움 상태를 만드나요?

아니요. 트랜지언트 값은 트랜잭션이 끝나면 폐기되며 컨트랙트의 영구 스토리지로 커밋되지 않습니다.

함수가 반환되면 트랜지언트 스토리지가 지워지나요?

아니요. 코드가 직접 덮어쓰거나 해제하지 않으면 전체 트랜잭션이 끝날 때까지 같은 소유 컨트랙트의 뒤쪽 프레임에서 볼 수 있어요.

다른 컨트랙트의 트랜지언트 슬롯을 읽을 수 있나요?

아니요. 영구 스토리지처럼 컨트랙트 단위로 소유합니다. 특히 DELEGATECALL을 포함한 호출 맥락이 활성 슬롯의 소유자를 결정해요.

정적 호출에서 TSTORE를 쓸 수 있나요?

아니요. EIP 사양에 따라 STATICCALL 안의 TSTORE는 예외를 일으킵니다. TLOAD는 허용돼요.

Solidity에서 트랜지언트 매핑이나 배열을 선언할 수 있나요?

현재 고수준 트랜지언트 상태 변수 문법으로는 안 됩니다. 공식 문서는 값 타입만 지원한다고 명시해요.

주요 공식 출처

• EIP-1153: Transient storage opcodes
• Solidity: Transient Storage
• Solidity: Storage and Transient Storage Layout
• Solidity: List of Known Bugs
• ethereum.org: Ethereum Virtual Machine

목적에 맞는 가장 짧은 수명의 상태를 고르세요

트랜지언트 스토리지는 한 트랜잭션 동안 컨트랙트가 쓰는 공유 화이트보드예요. 영구 상태를 만들지 않고 여러 호출 프레임에 임시 통로를 제공하지만, 트랜잭션 전체 수명과 실패 처리, Delegatecall 소유권을 의도적으로 설계해야 합니다. 단순히 영구 스토리지보다 저렴해서가 아니라 이 의미가 정확히 필요할 때 선택하세요.

이 글은 교육 목적이며 투자 조언이 아닙니다. 스마트 컨트랙트 상호작용은 되돌릴 수 없고 크립토 자산은 변동성이 큽니다. 올바른 네트워크에서 테스트하고, 잃어도 되는 금액만 사용하며, 최신 공식 문서를 확인하고 스스로 조사하세요(DYOR).