Solidity and web3 Fundamentals

Transitioning from traditional backend architecture to smart contract engineering requires a fundamental shift in how developers reason about memory, persistence, and execution.

In the EVM (Ethereum Virtual Machine), every operation carries measurable financial cost (gas), and state persistence cannot be handled casually. In this post, I break down the core architectural concepts essential for designing and auditing secure decentralized protocols.

---

1. The EVM Storage Model: A Massive 256-Bit Array

Smart contract storage on Ethereum can be conceptualized as an enormous indexed key-value array:

• It contains 2^256 available slots.
• Each slot holds exactly 32 bytes (256 bits).
• Writing to uninitialized storage slots is the most gas-intensive operation in the network (SSTORE and SLOAD opcodes).

Sequential Storage for Fixed-Size Types

Fixed-size state variables (uint256, address, bool) are packed and assigned sequentially starting from slot 0:

contract StorageExample {
    uint256 public count;     // Slot 0
    address public owner;     // Slot 1
    bool public isActive;     // Slot 2
}

Dynamic Arrays and Cryptographic Hashing

Dynamic arrays cannot be stored continuously in storage slots because expanding them would overwrite downstream variables. The EVM solves this via cryptographic hashing:

1. Array Length: The variable's assigned slot position (slot p) stores only the array's current length.
2. Element Locations: The starting location of the actual array data is determined dynamically: Starting Slot = keccak256}(p)
3. The element at index k resides at: Slot of Element k = keccak256(p) + k

This deterministic hashing maps elements across a virtually boundless space (2^256), preventing storage collisions across distinct contract variables.

---

2. Gas Optimization: constant, immutable, and Stack Memory

Not every value needs to pay the ongoing cost of occupying a storage slot.

constant and immutable: Embedding into Bytecode

Variables declared as constant or immutable do not occupy storage slots:

• constant: Evaluated at compile-time. The Solidity compiler replaces every reference with the raw literal value directly within the contract's runtime bytecode.
• immutable: Can be assigned dynamically during constructor execution. Upon deployment, the final value is permanently baked into runtime bytecode.
• Security & Architectural Implication: Beyond eliminating gas-heavy SLOAD operations, this immutability hardens security by preventing storage pointer manipulation attacks.

Local Variables vs. The memory Keyword

• Stack Variables: Declared inside function bodies with primitive types (uint256 temp = 10;). They live temporarily on the EVM execution stack, consume minimal gas, and disappear upon execution return.
• memory for Reference Types: Dynamically-sized types like string and bytes are byte arrays under the hood. Because they exceed the 32-byte capacity of a single stack slot, Solidity requires an explicit data location modifier:
  • memory: Allocates temporary, linearly expandable memory available exclusively for the duration of the current external call.
  • Mutating data stored in memory has zero impact on on-chain persistent storage.

---

3. Token Primitives: Interchangeability & Standards

Smart contracts use standard interfaces to represent ownership, governance, and assets.

ERC-20: Fungible (Interchangeable) Tokens

Fungibility means that individual units of an asset are mutually interchangeable and functionally identical.

• The Analogy: A $1 USD bill (or equivalent fiat banknote) holds identical purchasing power and value to any other $1 USD bill. They can be freely substituted for one another.
• Industry Standards: Tether (USDT), Dai (DAI), Chainlink (LINK), and Uniswap (UNI).
• Primary Use Cases:
  1. Governance: Weighted voting power proportional to token balances in DAOs.
  2. Synthetic Assets: Stablecoins backed by on-chain or off-chain reserves.
  3. Economic Incentives: Automated Market Maker (AMM) liquidity rewards and staking mechanisms.

ERC-721: Non-Fungible Tokens (NFTs)

ERC-721 represents unique, non-interchangeable assets where each token holds a distinct tokenId.

• The Analogy: A signed title deed to a real estate property or an original work of art.
• Token #1 does not carry the same attributes or market value as Token #2. In Uniswap v3 and v4, liquidity positions are minted as ERC-721 tokens because each position represents custom concentrated ranges (tickLower and tickUpper).

---

4. Defensive Testing in Foundry: Stateless vs. Stateful Fuzzing

Writing unit tests with static, hard-coded inputs leaves protocols blind to edge cases. DeFi security relies on Property-Based Fuzz Testing.

Stateless Fuzzing

Stateless fuzz tests run the target function hundreds of times, injecting random pseudorandom parameters on each run:

function testFuzz_Deposit(uint256 amount) public {
    // Bound the input space to realistic conditions
    vm.assume(amount > 0 && amount <= 1000 ether);

    vault.deposit(amount);
    assertEq(vault.balanceOf(address(this)), amount);
}

• Focus: Detecting unexpected integer overflows, division-by-zero errors, precision losses, or unhandled reverts in isolated calls.

Stateful Fuzzing (Invariant Testing)

Vulnerabilities rarely happen in a single call. Real exploits occur when multiple function calls mutate contract state over time in unexpected sequences (e.g., Deposit $\rightarrow$ Borrow $\rightarrow$ Flash Swap $\rightarrow$ Liquidation).

• Stateful Fuzzing preserves contract storage mutations across randomized call sequences.
• It systematically verifies whether core protocol invariants hold under extreme conditions: $$\text{Total Vault Shares} \iff \text{Underlying Backing Assets}$$ If an arbitrary sequence of 50 multi-user actions causes the contract's accounting to drift by even 1 wei due to rounding bias, Foundry reconstructs the exact call trace that broke the invariant.

---

Final Thoughts

Grasping low-level EVM storage mechanics and strict data locations is not premature optimization—it is the baseline requirement for detecting vulnerabilities before code hits production.

Understanding how storage slots are mapped, why bytecode constants save gas, and how stateful fuzzing breaks fragile assumptions separates developers who merely assemble contracts from engineers who architect robust financial systems.