[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-3-gaseu-ihaehagi-keonteulaekteu-biyong":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-000000000103","a0000000-0000-0000-0000-000000000052","Deep EVM #3: 가스 이해하기 — 컨트랙트 비용이 결정되는 이유","deep-evm-3-gaseu-ihaehagi-keonteulaekteu-biyong","EVM 가스 비용의 정밀한 분석: 내재 가스, EIP-2929 cold\u002Fwarm 접근, 환불 메커니즘, 검증된 최적화 패턴으로 실질적 비용 절감.","## 가스는 추상이 아니다\n\n개발자들은 종종 가스를 모호한 \"비용\" 지표로 취급합니다. 실제로 가스는 정확한 공식을 가진 정밀한 자원 회계 시스템입니다. 모든 옵코드, 모든 콜데이터 바이트, 모든 스토리지 접근에는 옐로 페이퍼와 후속 EIP에 정의된 결정론적 가스 비용이 있습니다.\n\n이 비용을 이해하면 가스 최적화가 추측에서 엔지니어링으로 변합니다.\n\n## 내재 가스: 기준선\n\n컨트랙트 코드가 단일 옵코드를 실행하기 전에 트랜잭션은 이미 가스를 소비했습니다:\n\n```\nintrinsic_gas = 21000                           \u002F\u002F 기본 트랜잭션 비용\n             + 16 * 비영_콜데이터_바이트       \u002F\u002F 비영 바이트당\n             + 4 * 영_콜데이터_바이트            \u002F\u002F 영 바이트당\n             + access_list_cost                   \u002F\u002F EIP-2930 접근 목록\n             + 32000 (컨트랙트 생성인 경우)       \u002F\u002F CREATE 트랜잭션만\n```\n\n## EIP-2929: 접근 목록 혁명\n\nEIP-2929 이전에는 SLOAD 비용이 항상 800 가스였습니다. EIP-2929는 트랜잭션별 접근 세트를 도입하여 모든 것을 변경했습니다.\n\n| 옵코드 | Cold | Warm | 절감 |\n|--------|------|------|------|\n| SLOAD | 2100 | 100 | 2000 |\n| BALANCE | 2600 | 100 | 2500 |\n| CALL | 2600 | 100 | 2500 |\n\n## SSTORE: 가장 복잡한 옵코드\n\nSSTORE 가스 비용은 세 가지 요소에 따라 달라집니다: 원래 값(트랜잭션 시작 시), 현재 값, 새 값.\n\n핵심 인사이트: **제로 슬롯을 nonzero로 설정하면 20000 가스**가 들고(새 상태 트리 리프 노드 기록), **기존 nonzero 슬롯을 수정하면 2900 가스**(warm)입니다. 이 7배 차이가 다음을 설명합니다:\n\n- 새 사용자를 위한 매핑 초기화가 비용이 높은 이유\n- 재진입 잠금에 `0` 대신 `1`을 \"미설정\" 값으로 사용하면 17100 가스를 절약하는 이유\n\n## 실제로 중요한 최적화 패턴\n\n### 1. 스토리지 읽기를 메모리에 캐시\n\n```solidity\n\u002F\u002F 좋음: 1 SLOAD\nfunction withdraw() external {\n    uint256 amount = balances[msg.sender];\n    require(amount > 0);\n    balances[msg.sender] = 0;\n}\n```\n\n### 2. 스토리지 변수 패킹\n\n여러 변수를 하나의 슬롯에 = 하나의 SLOAD.\n\n### 3. 외부 매개변수에 메모리 대신 콜데이터 사용\n\n```solidity\n\u002F\u002F 좋음: 콜데이터에서 직접 읽기\nfunction processOrders(Order[] calldata orders) external { ... }\n```\n\n### 4. 안전할 때 unchecked 산술 사용\n\n```solidity\nfor (uint256 i = 0; i \u003C length;) {\n    \u002F\u002F ... 루프 본문 ...\n    unchecked { ++i; }\n}\n```\n\n### 5. require 문자열 대신 커스텀 에러 사용\n\n```solidity\nerror InvalidAmount();\nif (amount == 0) revert InvalidAmount();\n```\n\n## 결론\n\n가스 최적화는 산술 옵코드를 미세 최적화하는 것이 아닙니다 — 스토리지 접근과 외부 호출을 최소화하는 것입니다. 가장 많은 가스를 절약하는 패턴은 아키텍처적입니다: 스토리지 패킹, 캐싱, 콜데이터 사용, 접근 목록 최적화.","\u003Ch2 id=\"\">가스는 추상이 아니다\u003C\u002Fh2>\n\u003Cp>개발자들은 종종 가스를 모호한 “비용” 지표로 취급합니다. 실제로 가스는 정확한 공식을 가진 정밀한 자원 회계 시스템입니다. 모든 옵코드, 모든 콜데이터 바이트, 모든 스토리지 접근에는 옐로 페이퍼와 후속 EIP에 정의된 결정론적 가스 비용이 있습니다.\u003C\u002Fp>\n\u003Cp>이 비용을 이해하면 가스 최적화가 추측에서 엔지니어링으로 변합니다.\u003C\u002Fp>\n\u003Ch2 id=\"\">내재 가스: 기준선\u003C\u002Fh2>\n\u003Cp>컨트랙트 코드가 단일 옵코드를 실행하기 전에 트랜잭션은 이미 가스를 소비했습니다:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>intrinsic_gas = 21000                           \u002F\u002F 기본 트랜잭션 비용\n             + 16 * 비영_콜데이터_바이트       \u002F\u002F 비영 바이트당\n             + 4 * 영_콜데이터_바이트            \u002F\u002F 영 바이트당\n             + access_list_cost                   \u002F\u002F EIP-2930 접근 목록\n             + 32000 (컨트랙트 생성인 경우)       \u002F\u002F CREATE 트랜잭션만\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"eip-2929\">EIP-2929: 접근 목록 혁명\u003C\u002Fh2>\n\u003Cp>EIP-2929 이전에는 SLOAD 비용이 항상 800 가스였습니다. EIP-2929는 트랜잭션별 접근 세트를 도입하여 모든 것을 변경했습니다.\u003C\u002Fp>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>옵코드\u003C\u002Fth>\u003Cth>Cold\u003C\u002Fth>\u003Cth>Warm\u003C\u002Fth>\u003Cth>절감\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>SLOAD\u003C\u002Ftd>\u003Ctd>2100\u003C\u002Ftd>\u003Ctd>100\u003C\u002Ftd>\u003Ctd>2000\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>BALANCE\u003C\u002Ftd>\u003Ctd>2600\u003C\u002Ftd>\u003Ctd>100\u003C\u002Ftd>\u003Ctd>2500\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>CALL\u003C\u002Ftd>\u003Ctd>2600\u003C\u002Ftd>\u003Ctd>100\u003C\u002Ftd>\u003Ctd>2500\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch2 id=\"sstore\">SSTORE: 가장 복잡한 옵코드\u003C\u002Fh2>\n\u003Cp>SSTORE 가스 비용은 세 가지 요소에 따라 달라집니다: 원래 값(트랜잭션 시작 시), 현재 값, 새 값.\u003C\u002Fp>\n\u003Cp>핵심 인사이트: \u003Cstrong>제로 슬롯을 nonzero로 설정하면 20000 가스\u003C\u002Fstrong>가 들고(새 상태 트리 리프 노드 기록), \u003Cstrong>기존 nonzero 슬롯을 수정하면 2900 가스\u003C\u002Fstrong>(warm)입니다. 이 7배 차이가 다음을 설명합니다:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>새 사용자를 위한 매핑 초기화가 비용이 높은 이유\u003C\u002Fli>\n\u003Cli>재진입 잠금에 \u003Ccode>0\u003C\u002Fcode> 대신 \u003Ccode>1\u003C\u002Fcode>을 “미설정” 값으로 사용하면 17100 가스를 절약하는 이유\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"\">실제로 중요한 최적화 패턴\u003C\u002Fh2>\n\u003Ch3>1. 스토리지 읽기를 메모리에 캐시\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F 좋음: 1 SLOAD\nfunction withdraw() external {\n    uint256 amount = balances[msg.sender];\n    require(amount > 0);\n    balances[msg.sender] = 0;\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>2. 스토리지 변수 패킹\u003C\u002Fh3>\n\u003Cp>여러 변수를 하나의 슬롯에 = 하나의 SLOAD.\u003C\u002Fp>\n\u003Ch3>3. 외부 매개변수에 메모리 대신 콜데이터 사용\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F 좋음: 콜데이터에서 직접 읽기\nfunction processOrders(Order[] calldata orders) external { ... }\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>4. 안전할 때 unchecked 산술 사용\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-solidity\">for (uint256 i = 0; i < length;) {\n    \u002F\u002F ... 루프 본문 ...\n    unchecked { ++i; }\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>5. require 문자열 대신 커스텀 에러 사용\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-solidity\">error InvalidAmount();\nif (amount == 0) revert InvalidAmount();\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"\">결론\u003C\u002Fh2>\n\u003Cp>가스 최적화는 산술 옵코드를 미세 최적화하는 것이 아닙니다 — 스토리지 접근과 외부 호출을 최소화하는 것입니다. 가장 많은 가스를 절약하는 패턴은 아키텍처적입니다: 스토리지 패킹, 캐싱, 콜데이터 사용, 접근 목록 최적화.\u003C\u002Fp>\n","ko","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:27.823847Z","EVM 가스 비용 정밀 분석: 내재 가스, EIP-2929 cold\u002Fwarm 접근, SSTORE 비용, 환불 메커니즘, 검증된 최적화 패턴.","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"]