The concept of Gas in decentralized computational networks is a metric used to measure the volume of computational work, as well as reading and writing information to the ledger. To understand this tangibly, one can compare the Ethereum Virtual Machine (EVM) to a very busy filing office where every employee demands a certain amount of tax stamp for every time they open a file, archive a new document, or mathematically verify invoices. If this stamp is not defined, a malicious actor could create an infinite computational loop, locking up all the network's validator computers and disrupting the entire ecosystem's service.

Transformation in Pricing Structure Since the Introduction of EIP-1559

Prior to the London upgrade on the Ethereum network, fee estimation was similar to a blind auction where users paid high amounts without precise knowledge of others' bids. The EIP-1559 standard transformed this structure, dividing the fee formula into two parts: the Base Fee, which is burned, and the Priority Fee (tip) for the validator. If in a block the Base Fee is 30 Gwei and the tip is 2 Gwei, for a standard Ether transfer transaction consuming 21,000 units of gas, the final fee is calculated as follows: 21,000 multiplied by 32 Gwei, which equals 0.000672 Ether. Each Gwei is exactly one-billionth of one unit of Ether.

Structural Comparison of Gas Models in Different Execution Environments

While Ethereum Virtual Machine-based networks such as Arbitrum and Polygon utilize an opcode-based gas system, different networks like Solana and Sui have adopted completely different architectures for managing computational load.

The most expensive operation in all Web3 computing machines is writing and updating data in permanent storage (Storage). To visualize this cost, imagine temporary memory (Memory or Calldata) as a whiteboard that is erased for quick notes during a meeting, while storage is like engraving words onto stone tablets in an eternal vault. Every permanent storage operation (SSTORE), when a memory cell is being filled for the first time, can cost up to 20,000 gas, whereas reading data from temporary memory consumes less than a hundred gas.

The Art of Variable Arrangement or Storage Packing

In Solidity, each storage memory slot is equal to 32 bytes (256 bits). When variables are defined without optimal arrangement, the compiler allocates an independent 32-byte slot for each variable. For example, if a boolean variable (bool, 1 byte), a 256-bit number (uint256, 32 bytes), and an address (address, 20 bytes) are defined scattered, three separate slots (totaling 96 bytes) will be reserved, tripling the deployment and read/write costs. However, if the address variable (20 bytes) and the boolean variable (1 byte) are placed next to each other, they fit into a single 32-byte slot, and the next variable will occupy the second slot, thereby reducing the number of slots from 3 to 2.

Using Constant and Immutable Variables

Variables that do not change after contract deployment should not be stored in storage. Defining values with the keywords constant (for fixed variables determined during coding) and immutable (for values assigned in the constructor) ensures that the value is embedded directly within the smart contract's bytecode. This simple change transforms reading the value from an expensive SLOAD operation costing at least 100 to 2100 gas into a cheap PUSH operation costing only 3 gas.

Smart contract codes are decomposed into basic instructions called bytecode or opcodes during execution. Each opcode has a fixed gas fee determined by the network protocol. Structural errors in loops are one of the main reasons for transaction reverts due to "Out of Gas" errors. If the size of an array grows over time with user registrations and a function attempts to iterate through all members of this array in a single call, the transaction execution fee will exceed the block limit, and the contract funds will be locked forever.

Caching array length in temporary memory

In standard loops, a common error is reading the array length from storage in every iteration. An analogy for this is a factory manager conducting an employee census, where for every single person counted, the manager returns to the archive office on the upper floor to re-examine the entire list. The engineering solution is to read the array length once before entering the loop and cache it in a local variable (Memory):

• Avoiding re-reading: Reading an array length from storage in a 100-iteration loop can waste up to 21,000 gas units, but by caching it in memory, the cost is reduced to a few hundred units.
• Unchecked Increment: In Solidity versions higher than 0.8.0, all mathematical operations are automatically checked to prevent overflow. A loop counter that is bounded and will never reach the integer limit is better placed within an unchecked block so that mathematical check opcodes are removed, saving approximately 30 to 80 gas units per loop iteration.

Advantage of using Calldata instead of Memory in function parameters

When a function is defined with external visibility, input parameters of type string, array, or bytes should be marked with the calldata keyword instead of memory. The Calldata space is an immutable and read-only section of the transaction data payload. Using Memory forces the compiler to copy the received transaction data into internal memory once, and this data copying imposes a significant gas cost per 32 bytes on the user.

Gas optimization is not a cost-free and flawless process; rather, in software engineering, there is always a trade-off between code readability, security, and efficiency. While excessive use of low-level assembly code (Inline Assembly or Yul) to bypass compiler standards can reduce gas by 5 to 10%, it significantly increases the likelihood of critical security bugs, reentrancy attacks, and the impossibility of easy auditing by security auditors such as OpenZeppelin or CertiK.

The role of Layer 2s in reducing costs

Cost reduction is not achieved solely through writing clean code; choosing the hosting infrastructure is also key. Optimistic Rollup solutions (such as Optimism and Arbitrum) and Zero-Knowledge Rollups (such as zkSync Era and Starknet) drastically reduce the cost of sharing data on the Ethereum mainnet by aggregating hundreds of transactions and converting them into a single compressed proof. For the end user, performing a swap on Uniswap on the Ethereum network might cost $10 to $50, whereas the same interaction on a Layer 2 with optimized code is reduced to less than a few cents.

Three key principles that every Web3 engineer and user should remember:

• Minimize storage data: Use event hashing instead of storing heavy values in permanent variables for data that does not require on-chain logic processing.
• Simulate before deployment: By utilizing simulation tools such as Foundry Gas Reports or Hardhat Gas Reporter, measure the cost of each function at the bytecode scale.
• Do not sacrifice security for gas: Optimizing contract code should not lead to the removal of input sanitization or access controls.

What is your view?

In your opinion, with the deployment of Data Availability solutions such as the Dencun upgrade and the activation of proto-danksharding, do developers still need to spend hours optimizing at the opcode level, or should the focus shift toward modular architecture? Share your experiences in reducing your contract transaction costs with us.