EVM storage·memory·calldata는 비용과 수명이 어떻게 다를까

storage는 계약 계정에 영구 보존되는 256비트 key-value 영역이고 상태 변경 transaction 사이에도 남습니다. memory는 message call마다 새로 생기는 byte-addressed 작업 공간으로 호출이 끝나면 사라지며 커질수록 expansion gas가 듭니다. calldata는 외부 호출에 들어온 ABI bytes를 담는 읽기 전용 영역이라 원본을 수정할 수 없고 필요한 부분만 읽을 수 있습니다. Solidity의 참조형에서 data location은 단순 성능 표시가 아니라 alias와 copy 여부를 바꾸므로 storage 포인터를 수정하면 영구 상태가 바뀌고 storage에서 memory로 대입하면 별도 복사본이 만들어집니다.

세 영역은 수명부터 다릅니다

각 contract account의 storage는 256비트 slot에서 256비트 값으로 이어지는 영구 key-value 공간입니다. 함수가 끝나도 남고 다음 transaction이 같은 상태를 읽습니다. Solidity state variable은 packing, mapping hash와 dynamic array 규칙에 따라 slot에 배치됩니다. 다른 계약 storage를 SLOAD로 직접 읽을 수 없으며 CALL과 DELEGATECALL의 문맥에 따라 어느 계정 storage인지 정해집니다.

Memory는 각 message call에 freshly cleared 상태로 주어지고 byte 단위 주소를 갖지만 일반 word 연산은 32바이트를 사용합니다. 높은 offset을 처음 건드리면 확장 비용이 붙고 크기에 따라 선형과 제곱 항이 함께 증가합니다. Calldata는 transaction 또는 external call이 전달한 bytes이며 read-only라 CALLDATALOAD·CALLDATACOPY로 읽습니다.

데이터 위치는 같은 배열을 어디에 놓을지 정하는 표식이 아니라, 언제 사라지고 누가 수정 결과를 보게 되는지 정하는 실행 규칙입니다.

JOBCOIN 해설

VISUAL GUIDE프로토콜 실행의 기본 구조

1. 01
   세 영역은 수명부터 다릅니다

   각 contract account의 storage는 256비트 slot에서 256비트 값으로 이어지는 영구 key-value 공간입니다.

2. 02
   가변성과 복사 규칙을 표로 확인합니다

   External 함수의 dynamic parameter를 calldata로 선언하면 compiler가 처음부터 memory로 전체 decode하지 않고 접근 시 필요한 부분을 읽을 수 있습니다.

3. 03
   배열 하나가 위치에 따라 다른 작업을 만듭니다

   외부 함수가 1,000개 uint 배열을 받아 합계만 계산한다고 가정하면 calldata 순회는 원본을 그대로 읽습니다.

AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

가변성과 복사 규칙을 표로 확인합니다

External 함수의 dynamic parameter를 calldata로 선언하면 compiler가 처음부터 memory로 전체 decode하지 않고 접근 시 필요한 부분을 읽을 수 있습니다. 함수 안에서 값을 바꿔야 한다면 memory 복사가 필요합니다. Public 함수와 internal 호출에서는 compiler version과 ABI 경로가 다를 수 있으므로 생성된 IR·gas report로 확인합니다.

storage 참조끼리의 대입은 같은 상태 객체를 가리킬 수 있지만 memory로 옮기면 copy가 생깁니다. Memory 참조 대입은 같은 memory 객체를 공유할 수 있어 한 변수를 통해 원소를 바꾸면 다른 참조에서도 보입니다. 값형은 stack 값 복사가 기본이므로 배열·struct와 같은 참조형 규칙을 그대로 적용하지 않습니다.

배열 하나가 위치에 따라 다른 작업을 만듭니다

외부 함수가 1,000개 uint 배열을 받아 합계만 계산한다고 가정하면 calldata 순회는 원본을 그대로 읽습니다. 매 원소를 변경해야 해서 uint[] memory로 받으면 ABI decoder가 배열 길이와 내용을 memory에 놓고 확장 비용을 냅니다. 배열을 state variable에 저장하면 각 slot에 SSTORE가 생겨 가장 큰 지속 비용이 발생합니다.

Storage 배열을 memory 지역 변수로 복사한 뒤 수정하면 영구 배열은 바뀌지 않습니다. 반대로 storage 포인터를 잡아 원소를 수정하면 transaction 성공 시 상태 root에 반영됩니다. 리뷰에서는 함수 signature만 보지 말고 대입 양쪽 data location과 compiler가 만든 copy loop를 확인해야 합니다.

• 데이터가 다음 transaction에도 필요한지 먼저 묻습니다.
• 입력을 수정하지 않으면 calldata 사용 가능성을 확인합니다.
• Memory 최대 offset과 예상 배열 길이에 상한을 둡니다.
• Storage pointer와 memory copy를 코드 리뷰에서 표시합니다.
• Compiler 버전을 고정하고 gas snapshot을 비교합니다.

비용은 같은 transaction에서 처음 접근한 cold slot

SSTORE 비용은 slot의 original, current, new value와 refund counter에 따라 달라집니다. 같은 transaction에서 처음 접근한 cold slot과 이미 접근한 warm slot도 비용이 다릅니다. ‘storage write는 항상 20,000 gas’라는 규칙은 0에서 nonzero로 처음 설정하는 일부 경우만 설명합니다.

Memory는 한번 확장한 범위 안의 추가 접근과 새 high-water mark를 늘리는 접근이 다릅니다. Calldata도 chain의 transaction data pricing과 실행 중 copy 비용을 구분해야 합니다. Optimizer가 loop·bounds check를 바꿀 수 있으므로 추정 수치 대신 목표 compiler·EVM version의 bytecode를 측정합니다.

안전성은 길이와 alias를 검증하는 데서 시작합니다

공격자가 매우 긴 calldata 배열을 보내면 전체 복사·loop가 block gas 안에서 실패하거나 서비스 estimate를 소진시킬 수 있습니다. 길이 상한, pagination 또는 Merkle proof처럼 bounded input 설계를 사용합니다. Assembly에서 calldata offset과 length를 직접 다룰 때 overflow와 ABI 범위 검사를 생략하지 않습니다.

Upgrade 계약은 storage layout을 바꾸면 기존 slot 의미를 잃습니다. Memory 최적화가 맞더라도 영구 변수 순서와 mapping base slot은 별도 호환성 검사 대상입니다. 성능 검토와 upgrade 안전 검토를 한 숫자의 gas 절감으로 합치지 않습니다.

자주 묻는 질문