[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-2-memori-model-seutaeg-seutoliji-koldeiteo":3},{"article":4,"author":54},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":7,"meta_description":16,"focus_keyword":17,"og_image":18,"canonical_url":18,"robots_meta":19,"created_at":15,"updated_at":15,"tags":20,"category_name":34,"related_articles":35},"d5000000-0000-0000-0000-000000000102","a0000000-0000-0000-0000-000000000052","Deep EVM #2: 메모리 모델 — 스택, 메모리, 스토리지, 콜데이터","deep-evm-2-memori-model-seutaeg-seutoliji-koldeiteo","EVM의 네 가지 데이터 위치 — 스택, 메모리, 스토리지, 콜데이터 — 에 대한 심층 분석: 비용, 동작, 그리고 개발자를 놀라게 하는 메모리 확장 공식.","## 데이터가 존재할 수 있는 네 가지 장소\n\nEVM은 근본적으로 다른 비용, 수명, 접근 패턴을 가진 네 가지 데이터 위치를 제공합니다. 잘못된 것을 선택하는 것이 스마트 컨트랙트의 과도한 가스 소비의 가장 흔한 원인입니다.\n\n| 위치 | 수명 | 읽기 비용 | 쓰기 비용 | 크기 |\n|------|------|-----------|-----------|------|\n| 스택 | 현재 옵코드 | 0 (DUP: 3) | 0 (PUSH: 3) | 1024 워드 |\n| 메모리 | 현재 호출 컨텍스트 | MLOAD: 3* | MSTORE: 3* | 확장 가능 |\n| 스토리지 | 영구 (블록체인) | SLOAD: 2100\u002F100 | SSTORE: 20000\u002F2900\u002F100 | 2^256 슬롯 |\n| 콜데이터 | 현재 호출 컨텍스트 | CALLDATALOAD: 3 | 읽기 전용 | 트랜잭션 입력 |\n\n*메모리 비용은 연산당 3 가스 + 이차 확장 비용.\n\n## 스택: 빠르지만 작다\n\n스택은 EVM의 작업 메모리입니다. 모든 산술, 비교, 논리 연산은 스택에서 읽고 씁니다. 최대 1024개 요소를 보유하며, 각각 32바이트 폭입니다.\n\n실제로는 DUP과 SWAP 옵코드가 16개 요소 깊이까지만 도달하므로 16개 이상의 스택 슬롯을 사용하는 경우는 드뭅니다. Solidity 컴파일러는 자동으로 스택 레이아웃을 관리하지만, Yul과 Huff에서는 수동으로 관리해야 합니다.\n\n스택 접근은 본질적으로 무료입니다(PUSH\u002FDUP\u002FSWAP 연산에 3 가스). 이것이 스택을 중간 계산, 루프 카운터, 임시 값에 이상적인 위치로 만듭니다.\n\n## 메모리: 저렴하지만 일시적\n\n메모리는 바이트 주소 지정 가능한 배열로, 비어 있는 상태에서 시작하여 필요에 따라 확장됩니다. 현재 호출 컨텍스트 기간 동안만 유지됩니다.\n\n### 프리 메모리 포인터\n\nSolidity는 메모리의 처음 128바이트를 특수 목적으로 예약합니다:\n\n| 오프셋 | 목적 |\n|--------|------|\n| 0x00-0x3f | 스크래치 공간 (해싱에 사용) |\n| 0x40-0x5f | 프리 메모리 포인터 |\n| 0x60-0x7f | 제로 슬롯 |\n| 0x80+ | 자유 메모리 (할당 시작) |\n\n### 메모리 확장 비용\n\n메모리 비용은 MLOAD\u002FMSTORE당 3 가스만이 아닙니다 — 현재 최고 수위 표시를 넘어 메모리에 접근할 때 이차 확장 비용이 부과됩니다.\n\n공식 (옐로 페이퍼에서):\n\n```\nmemory_cost = (memory_size_words^2 \u002F 512) + (3 * memory_size_words)\n```\n\n| 사용된 메모리 | 비용 |\n|---------------|------|\n| 32 바이트 (1 워드) | 3 가스 |\n| 1 KB (32 워드) | 98 가스 |\n| 10 KB (320 워드) | 1160 가스 |\n| 100 KB (3200 워드) | 29600 가스 |\n| 1 MB (32000 워드) | 2,001,000 가스 |\n\n## 스토리지: 영구적이지만 비용이 높다\n\n스토리지는 EVM의 영구 키-값 저장소입니다. 각 컨트랙트에는 2^256개의 32바이트 슬롯을 가진 격리된 스토리지 공간이 있습니다.\n\n### 스토리지 패킹\n\nSolidity는 가능할 때 여러 작은 변수를 단일 32바이트 슬롯에 패킹합니다:\n\n```solidity\n\u002F\u002F 나쁨: 3 스토리지 슬롯 = 3 x SLOAD = 6300 가스 (cold)\ncontract Unpacked {\n    uint256 a;  \u002F\u002F 슬롯 0\n    uint256 b;  \u002F\u002F 슬롯 1\n    uint256 c;  \u002F\u002F 슬롯 2\n}\n\n\u002F\u002F 좋음: 1 스토리지 슬롯 = 1 x SLOAD = 2100 가스 (cold)\ncontract Packed {\n    uint64 a;   \u002F\u002F 슬롯 0, 바이트 0-7\n    uint64 b;   \u002F\u002F 슬롯 0, 바이트 8-15\n    uint64 c;   \u002F\u002F 슬롯 0, 바이트 16-23\n}\n```\n\n## 콜데이터: 읽기 전용이고 저렴\n\n콜데이터는 트랜잭션이나 호출과 함께 전송되는 입력 데이터입니다. 읽기 전용이며 접근 비용이 저렴합니다(CALLDATALOAD에 3 가스).\n\n## 일시적 스토리지 (EIP-1153)\n\nEIP-1153(칸쿤 업그레이드, 2024년 3월)은 **TSTORE**와 **TLOAD**를 도입했습니다. 일반 스토리지와 유사하지만 트랜잭션 종료 시 자동으로 지워집니다.\n\n- TLOAD와 TSTORE 모두 100 가스 비용\n- 재진입 잠금에 이상적 — SSTORE의 20000 가스 비용 없이\n- 트랜잭션 내 교차 컨트랙트 통신에 적합\n\n## 실용적 최적화: 올바른 위치 선택\n\n1. **스택에 넣을 수 있나?** 스택을 사용. 한계 비용 제로.\n2. **16개 이상의 값이 필요한가?** 메모리 사용.\n3. **읽기 전용 입력 데이터인가?** 콜데이터 사용. 32바이트 읽기당 3 가스.\n4. **트랜잭션 간에 지속되어야 하는가?** 스토리지 사용. 새 항목에 20000+ 가스 예산.\n5. **호출 프레임 간에 지속되지만 트랜잭션 간에는 안 되는가?** 일시적 스토리지 사용. 100 가스.\n\n## 결론\n\nEVM의 메모리 모델은 겉보기에 단순합니다 — 명확한 트레이드오프를 가진 네 가지 위치. 그러나 비용 차이는 엄청납니다: 스택 ADD는 3 가스인 반면 SSTORE는 20000 가스입니다. 이 비용을 직감적 수준에서 이해하는 것이 가스 효율적 컨트랙트와 가스 낭비 컨트랙트를 구분짓습니다.","\u003Ch2 id=\"\">데이터가 존재할 수 있는 네 가지 장소\u003C\u002Fh2>\n\u003Cp>EVM은 근본적으로 다른 비용, 수명, 접근 패턴을 가진 네 가지 데이터 위치를 제공합니다. 잘못된 것을 선택하는 것이 스마트 컨트랙트의 과도한 가스 소비의 가장 흔한 원인입니다.\u003C\u002Fp>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>위치\u003C\u002Fth>\u003Cth>수명\u003C\u002Fth>\u003Cth>읽기 비용\u003C\u002Fth>\u003Cth>쓰기 비용\u003C\u002Fth>\u003Cth>크기\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>스택\u003C\u002Ftd>\u003Ctd>현재 옵코드\u003C\u002Ftd>\u003Ctd>0 (DUP: 3)\u003C\u002Ftd>\u003Ctd>0 (PUSH: 3)\u003C\u002Ftd>\u003Ctd>1024 워드\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>메모리\u003C\u002Ftd>\u003Ctd>현재 호출 컨텍스트\u003C\u002Ftd>\u003Ctd>MLOAD: 3*\u003C\u002Ftd>\u003Ctd>MSTORE: 3*\u003C\u002Ftd>\u003Ctd>확장 가능\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>스토리지\u003C\u002Ftd>\u003Ctd>영구 (블록체인)\u003C\u002Ftd>\u003Ctd>SLOAD: 2100\u002F100\u003C\u002Ftd>\u003Ctd>SSTORE: 20000\u002F2900\u002F100\u003C\u002Ftd>\u003Ctd>2^256 슬롯\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>콜데이터\u003C\u002Ftd>\u003Ctd>현재 호출 컨텍스트\u003C\u002Ftd>\u003Ctd>CALLDATALOAD: 3\u003C\u002Ftd>\u003Ctd>읽기 전용\u003C\u002Ftd>\u003Ctd>트랜잭션 입력\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>*메모리 비용은 연산당 3 가스 + 이차 확장 비용.\u003C\u002Fp>\n\u003Ch2 id=\"\">스택: 빠르지만 작다\u003C\u002Fh2>\n\u003Cp>스택은 EVM의 작업 메모리입니다. 모든 산술, 비교, 논리 연산은 스택에서 읽고 씁니다. 최대 1024개 요소를 보유하며, 각각 32바이트 폭입니다.\u003C\u002Fp>\n\u003Cp>실제로는 DUP과 SWAP 옵코드가 16개 요소 깊이까지만 도달하므로 16개 이상의 스택 슬롯을 사용하는 경우는 드뭅니다. Solidity 컴파일러는 자동으로 스택 레이아웃을 관리하지만, Yul과 Huff에서는 수동으로 관리해야 합니다.\u003C\u002Fp>\n\u003Cp>스택 접근은 본질적으로 무료입니다(PUSH\u002FDUP\u002FSWAP 연산에 3 가스). 이것이 스택을 중간 계산, 루프 카운터, 임시 값에 이상적인 위치로 만듭니다.\u003C\u002Fp>\n\u003Ch2 id=\"\">메모리: 저렴하지만 일시적\u003C\u002Fh2>\n\u003Cp>메모리는 바이트 주소 지정 가능한 배열로, 비어 있는 상태에서 시작하여 필요에 따라 확장됩니다. 현재 호출 컨텍스트 기간 동안만 유지됩니다.\u003C\u002Fp>\n\u003Ch3>프리 메모리 포인터\u003C\u002Fh3>\n\u003Cp>Solidity는 메모리의 처음 128바이트를 특수 목적으로 예약합니다:\u003C\u002Fp>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>오프셋\u003C\u002Fth>\u003Cth>목적\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>0x00-0x3f\u003C\u002Ftd>\u003Ctd>스크래치 공간 (해싱에 사용)\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>0x40-0x5f\u003C\u002Ftd>\u003Ctd>프리 메모리 포인터\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>0x60-0x7f\u003C\u002Ftd>\u003Ctd>제로 슬롯\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>0x80+\u003C\u002Ftd>\u003Ctd>자유 메모리 (할당 시작)\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch3>메모리 확장 비용\u003C\u002Fh3>\n\u003Cp>메모리 비용은 MLOAD\u002FMSTORE당 3 가스만이 아닙니다 — 현재 최고 수위 표시를 넘어 메모리에 접근할 때 이차 확장 비용이 부과됩니다.\u003C\u002Fp>\n\u003Cp>공식 (옐로 페이퍼에서):\u003C\u002Fp>\n\u003Cpre>\u003Ccode>memory_cost = (memory_size_words^2 \u002F 512) + (3 * memory_size_words)\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>사용된 메모리\u003C\u002Fth>\u003Cth>비용\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>32 바이트 (1 워드)\u003C\u002Ftd>\u003Ctd>3 가스\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>1 KB (32 워드)\u003C\u002Ftd>\u003Ctd>98 가스\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>10 KB (320 워드)\u003C\u002Ftd>\u003Ctd>1160 가스\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>100 KB (3200 워드)\u003C\u002Ftd>\u003Ctd>29600 가스\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>1 MB (32000 워드)\u003C\u002Ftd>\u003Ctd>2,001,000 가스\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch2 id=\"\">스토리지: 영구적이지만 비용이 높다\u003C\u002Fh2>\n\u003Cp>스토리지는 EVM의 영구 키-값 저장소입니다. 각 컨트랙트에는 2^256개의 32바이트 슬롯을 가진 격리된 스토리지 공간이 있습니다.\u003C\u002Fp>\n\u003Ch3>스토리지 패킹\u003C\u002Fh3>\n\u003Cp>Solidity는 가능할 때 여러 작은 변수를 단일 32바이트 슬롯에 패킹합니다:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F 나쁨: 3 스토리지 슬롯 = 3 x SLOAD = 6300 가스 (cold)\ncontract Unpacked {\n    uint256 a;  \u002F\u002F 슬롯 0\n    uint256 b;  \u002F\u002F 슬롯 1\n    uint256 c;  \u002F\u002F 슬롯 2\n}\n\n\u002F\u002F 좋음: 1 스토리지 슬롯 = 1 x SLOAD = 2100 가스 (cold)\ncontract Packed {\n    uint64 a;   \u002F\u002F 슬롯 0, 바이트 0-7\n    uint64 b;   \u002F\u002F 슬롯 0, 바이트 8-15\n    uint64 c;   \u002F\u002F 슬롯 0, 바이트 16-23\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"\">콜데이터: 읽기 전용이고 저렴\u003C\u002Fh2>\n\u003Cp>콜데이터는 트랜잭션이나 호출과 함께 전송되는 입력 데이터입니다. 읽기 전용이며 접근 비용이 저렴합니다(CALLDATALOAD에 3 가스).\u003C\u002Fp>\n\u003Ch2 id=\"eip-1153\">일시적 스토리지 (EIP-1153)\u003C\u002Fh2>\n\u003Cp>EIP-1153(칸쿤 업그레이드, 2024년 3월)은 \u003Cstrong>TSTORE\u003C\u002Fstrong>와 \u003Cstrong>TLOAD\u003C\u002Fstrong>를 도입했습니다. 일반 스토리지와 유사하지만 트랜잭션 종료 시 자동으로 지워집니다.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>TLOAD와 TSTORE 모두 100 가스 비용\u003C\u002Fli>\n\u003Cli>재진입 잠금에 이상적 — SSTORE의 20000 가스 비용 없이\u003C\u002Fli>\n\u003Cli>트랜잭션 내 교차 컨트랙트 통신에 적합\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"\">실용적 최적화: 올바른 위치 선택\u003C\u002Fh2>\n\u003Col>\n\u003Cli>\u003Cstrong>스택에 넣을 수 있나?\u003C\u002Fstrong> 스택을 사용. 한계 비용 제로.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>16개 이상의 값이 필요한가?\u003C\u002Fstrong> 메모리 사용.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>읽기 전용 입력 데이터인가?\u003C\u002Fstrong> 콜데이터 사용. 32바이트 읽기당 3 가스.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>트랜잭션 간에 지속되어야 하는가?\u003C\u002Fstrong> 스토리지 사용. 새 항목에 20000+ 가스 예산.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>호출 프레임 간에 지속되지만 트랜잭션 간에는 안 되는가?\u003C\u002Fstrong> 일시적 스토리지 사용. 100 가스.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2 id=\"\">결론\u003C\u002Fh2>\n\u003Cp>EVM의 메모리 모델은 겉보기에 단순합니다 — 명확한 트레이드오프를 가진 네 가지 위치. 그러나 비용 차이는 엄청납니다: 스택 ADD는 3 가스인 반면 SSTORE는 20000 가스입니다. 이 비용을 직감적 수준에서 이해하는 것이 가스 효율적 컨트랙트와 가스 낭비 컨트랙트를 구분짓습니다.\u003C\u002Fp>\n","ko","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:27.819258Z","EVM 메모리 모델 심층 분석: 스택, 메모리, 스토리지, 콜데이터, 일시적 스토리지, 메모리 확장 비용 공식.","EVM 메모리 모델",null,"index, follow",[21,26,30],{"id":22,"name":23,"slug":24,"created_at":25},"c0000000-0000-0000-0000-000000000016","EVM","evm","2026-03-28T10:44:21.513630Z",{"id":27,"name":28,"slug":29,"created_at":25},"c0000000-0000-0000-0000-000000000020","Gas Optimization","gas-optimization",{"id":31,"name":32,"slug":33,"created_at":25},"c0000000-0000-0000-0000-000000000014","Solidity","solidity","블록체인",[36,42,48],{"id":37,"title":38,"slug":39,"excerpt":40,"locale":12,"category_name":34,"published_at":41},"d0000000-0000-0000-0000-000000000605","Ethereum 상호운용성 레이어: 55개 이상의 L2가 하나의 체인이 되는 방법","ethereum-sangho-unyongseong-layer-55-l2-hana-chain","Ethereum에는 55개 이상의 Layer 2 롤업이 있어 유동성과 사용자 경험이 파편화되어 있습니다. Ethereum 상호운용성 레이어 — 크로스 롤업 메시징, 공유 시퀀서, 베이스드 롤업을 결합하여 — 하나의 조합 가능한 네트워크로 통합하는 것을 목표로 합니다.","2026-03-28T10:44:44.895917Z",{"id":43,"title":44,"slug":45,"excerpt":46,"locale":12,"category_name":34,"published_at":47},"d0000000-0000-0000-0000-000000000604","롤업을 넘어선 ZK 증명: Ethereum에서의 검증 가능한 AI 추론","rolleob-eul-neomeo-zk-jeungmyeong-ethereum-geomjeung-ai-churon","영지식 증명은 더 이상 단순한 스케일링 도구가 아닙니다. 2026년, zkML은 온체인에서 검증 가능한 AI 추론을 가능하게 하고, ZK 코프로세서는 무거운 연산을 오프체인으로 이동시키며 온체인에서 검증하고, SP1과 Jolt 같은 새로운 증명 시스템이 이를 실용적으로 만들고 있습니다.","2026-03-28T10:44:44.890168Z",{"id":49,"title":50,"slug":51,"excerpt":52,"locale":12,"category_name":34,"published_at":53},"d0000000-0000-0000-0000-000000000581","EIP-7702 실전 가이드: Pectra 이후 스마트 계정 플로우 구축","eip-7702-siljeon-gaideu-pectra-ihu-seumateu-gyejeong-peulro-guchuk","EIP-7702는 모든 Ethereum EOA가 단일 트랜잭션 내에서 스마트 컨트랙트로 임시 동작할 수 있게 합니다. 새로운 계정 추상화 프리미티브를 사용한 배치 트랜잭션, 가스 후원, 소셜 리커버리 구현 방법을 소개합니다.","2026-03-28T10:44:43.377765Z",{"id":13,"name":55,"slug":56,"bio":57,"photo_url":18,"linkedin":18,"role":58,"created_at":59,"updated_at":59},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]