가스 비용 모델

Every operation on the Ethereum Virtual Machine (EVM) costs gas. Gas is a unit that measures the computational work required to execute a transaction.

Gas exists to:

• Pay validators for the resources they spend
• Prevent infinite loops and denial-of-service attacks
• Price scarce on-chain resources fairly

The total fee you pay equals gasUsed * gasPrice, denominated in wei.

Three numbers matter for every transaction:

• gasUsed — how much computation actually happened
• gasPrice (or maxFeePerGas under EIP-1559) — how much you pay per unit
• gasLimit — the maximum gas you allow before the transaction reverts

If execution exceeds the gas limit, the transaction reverts with an out of gas error, but you still pay for the gas consumed.

Each EVM opcode has a fixed gas cost defined in the Ethereum protocol. Cheap arithmetic costs very little, while storage and external calls cost a lot.

• ADD, SUB — 3 gas
• MUL — 5 gas
• SLOAD (read storage) — 2100 gas cold, 100 warm
• SSTORE (write storage) — up to 22100 gas

Storage dominates the cost of most contracts.

Persistent storage is the single most expensive resource on the EVM. Writing a storage slot from zero to non-zero costs 20000 gas; updating a non-zero slot costs 5000 gas.

Reading is cheaper than writing but still significant. This is why the golden rule of gas optimization is: touch storage as rarely as possible.

The EVM has three data locations, each with a different cost profile:

• storage — persistent, most expensive
• memory — temporary per-call, cheap but grows quadratically
• calldata — read-only input data, cheapest for function arguments

Using calldata instead of memory for external function parameters avoids an unnecessary copy.

Before any code runs, every transaction pays a base cost called intrinsic gas:

• 21000 gas for a base transaction
• 16 gas per non-zero calldata byte
• 4 gas per zero calldata byte

This means even an empty transfer costs 21000 gas, and larger calldata payloads make transactions more expensive before execution even begins.

Since EIP-2929, the first access to an account or storage slot in a transaction is cold and expensive; subsequent accesses are warm and cheap.

• Cold SLOAD: 2100 gas
• Warm SLOAD: 100 gas
• Cold account access: 2600 gas

Caching a storage value in a local variable converts repeated cold reads into a single read plus cheap memory access.

The EVM grants a partial gas refund when you clear storage, setting a non-zero slot back to zero (via SSTORE or SELFDESTRUCT historically).

Refunds are capped at one fifth of the transaction gas used (EIP-3529). Patterns like deleting array elements or zeroing balances can recover some gas, but you should never rely on refunds as a primary optimization.

EIP-1559 split the gas price into two parts:

• base fee — burned, adjusts automatically per block based on demand
• priority fee (tip) — paid to the validator

Users set maxFeePerGas and maxPriorityFeePerGas. The effective price never exceeds the max, and unused amounts are refunded. This makes fees more predictable.

Contracts have two distinct gas profiles:

• Deployment gas — paid once, proportional to bytecode size (200 gas per byte stored)
• Runtime gas — paid on every call to the deployed contract

Sometimes you trade a larger, more expensive deployment for cheaper runtime, or vice versa. Optimize for the dimension that matters most to your use case.

Effective gas optimization follows a hierarchy:

• Avoid storage writes (biggest wins)
• Minimize cold accesses by caching
• Use calldata over memory
• Reduce calldata size
• Micro-optimize opcodes last

Always measure before and after. Premature micro-optimization often hurts readability for negligible gain.

You now understand the EVM gas cost model:

• Fees equal gasUsed * gasPrice, bounded by a gas limit
• Storage writes dominate cost; arithmetic is cheap
• Cold accesses cost more than warm ones
• Intrinsic gas (21000 + calldata bytes) is paid before execution
• EIP-1559 splits fees into a burned base fee and a validator tip

Next we apply this knowledge to optimize contract storage layout.