Solidity Language Tour for Engineers

What you'll learn

• Why Solidity Looks the Way It Does
• Value Types vs Reference Types
• Storage Layout: Slots, Packing, and the SSTORE Rules
• Function Visibility, Modifiers, and the Receive/Fallback Pair
• Errors and Events
• Inheritance and Interfaces
• EVM Semantics You Cannot Ignore

Key terms

EVM (Ethereum Virtual Machine)

The stack-based virtual machine that executes contract bytecode. Deterministic, replicated across every full node, and gas-metered. Solidity compiles to EVM bytecode.

Storage / Memory / Calldata

The three data locations for reference types. Storage is persistent on-chain state (expensive). Memory is per-call scratch space (cheap). Calldata is the read-only input buffer for external calls (cheapest).

SSTORE

The EVM opcode that writes a value to a storage slot. New-slot writes cost 20,000 gas; updates cost 2,900 gas; writes-to-zero refund up to 4,800. Storage cost dominates most contract gas bills.

Custom Error

A revert reason defined with the `error` keyword (Solidity 0.8.4+). Cheaper and more structured than `require` with a string, and matchable by selector in tools like Foundry.

Indexed Event Argument

An event parameter marked `indexed` becomes a topic, searchable via RPC `eth_getLogs` filters. Up to three indexed args per event. Costs more gas than unindexed but enables off-chain queries.

msg.sender vs tx.origin

`msg.sender` is the immediate caller (could be another contract). `tx.origin` is the EOA that signed the transaction. Always authorize against `msg.sender`; using `tx.origin` opens you to phishing-style proxy attacks.

Checks-Effects-Interactions

The reentrancy-safe ordering: validate inputs first, update internal state second, make external calls last. Following this pattern prevents the called contract from re-entering yours in a partially-updated state.