EVM 의 스토리지 구조에 따른 array vs. mapping

이건 EVM(Ethereum Virtual Machine)의 스토리지 구조의 근본적인 이해와 관련된 주제로,
왜 Solidity에서 배열보다 mapping이 많이 사용되는지에 대한 배경이기도 합니다.

⸻

✅ 먼저 요약부터

접근 구조	특징	어떤 자료구조가 유리한가?
✅ 랜덤 접근 기반 (EVM)	연속된 메모리 주소가 없음, 해시로 위치 계산	✅ mapping
✅ 연속 메모리 기반 (CPU, 일반 컴퓨터)	배열은 캐시 친화적, 빠른 순회	✅ array (배열)

⸻

📦 1. EVM의 Storage 구조: 왜 랜덤 접근인가?

EVM에서의 storage는 “key-value 형태의 거대한 해시 테이블”로 이해할 수 있어요.

uint256 public foo; // 저장됨: slot 0
mapping(address => uint256) balances; // 저장됨: slot keccak256(encodePacked(address, slot))

🎯 중요한 사실:
• EVM은 연속된 물리적 메모리를 사용하지 않아요.
• 대신, storage는 2^256 개의 슬롯을 가진 가상 공간이며,
• 접근은 keccak256(slot) 계산을 통해 이뤄져요.

➕ 예시: mapping(address => uint)

slot = keccak256(abi.encodePacked(key, mappingSlot))

✔️ 이 말은, 각 키가 전혀 다른 위치에 저장되며, 해시 기반으로 빠르게 접근할 수 있다는 뜻입니다.

⸻

💡 왜 EVM에서는 mapping이 유리할까?

✅ 이유 1. 슬롯이 연속되지 않음
• 배열의 arr[i]처럼 slot = base + i로 계산할 수 없는 경우가 많음

✅ 이유 2. 해시 접근이 기본 설계
• mapping은 해시 기반으로 바로 슬롯을 찾아가기 때문에 속도는 빠르고, 구조가 심플

✅ 이유 3. gas 효율성
• 배열은 크기를 늘리거나 반복할 때 storage 반복이 필요
• mapping은 특정 키만 저장 → 불필요한 루프 없이 직접 접근 가능

⸻

🔁 반대로: 왜 일반 컴퓨터에서는 배열이 유리할까?

✅ CPU의 메모리 접근은 연속 메모리 기반
• 배열은 메모리에 연속으로 배치됨
• CPU 캐시, branch prediction, SIMD 등과 결합되어 폭발적인 순회 속도 제공

예:

int arr[100];
for (int i = 0; i < 100; i++) {
  arr[i] += 1; // 매우 빠름 (CPU 캐시 프렌들리)
}

🔄 반면 해시 테이블 (HashMap 등)은:
• 포인터와 해시 충돌을 고려해야 해서
• 순회 성능은 느릴 수 있음

⸻

📌 비교 요약

구조	일반 컴퓨터 (CPU/메모리)	EVM (블록체인 가상 머신)
메모리 구조	연속된 물리적 메모리	2^256개의 해시 슬롯
배열 성능	✅ 빠름 (cache-friendly)	❌ 느림 (slot 순회 필요)
mapping 성능	❌ 해시 계산 필요	✅ 빠름 (keccak 기반 접근)
순회	배열이 유리	mapping은 순회 불가 (keys 저장 필요)

⸻

🎯 결론

✅ EVM에서 mapping이 배열보다 더 유리한 이유는 다음과 같습니다:
1. EVM의 스토리지는 연속 메모리 접근이 불가능함
2. keccak256(slot) 기반 랜덤 슬롯 계산이 기본 설계
3. mapping은 필요한 데이터에만 직접 접근 가능
4. 배열은 순회와 크기 증가 시 gas 소모가 크고, 확장성 낮음

⸻