Solidity Language Tour for Engineers

For developers who already know a curly-brace language. Types, storage layout, function visibility, errors, events, inheritance, and the parts of the EVM model you cannot ignore.

45 min · expert · part of Solidity & Smart Contract Development

Why Solidity Looks the Way It Does

Solidity is the dominant smart-contract language for Ethereum and every EVM-compatible chain. It was created by Christian Reitwiessner at the Ethereum Foundation and first released in 2014. The syntax was deliberately made to feel like JavaScript so the (much larger) JavaScript developer pool would have something familiar to grab onto. That surface familiarity is a trap. Beneath the curly braces, Solidity is a language for a deterministic, replicated, gas-metered virtual machine — not a Node process. The constraints of that target shape every decision you'll make. Two things you'll notice right away if you're coming from a typical web stack: First, every state-modifying operation costs gas. There is no free read in the conventional sense (off-chain calls don't cost gas, but on-chain reads inside a write transaction still do). You think about storage the way an embedded developer thinks about flash memory. Second, code is deployed permanently to addresses you cannot change. There's no "redeploy and update the DNS." If you want upgradeability, you build it in explicitly via proxy patterns (covered in lesson 3). A bug in a deployed contract is a bug forever, unless the contract was designed with an explicit pause or upgrade path. This is why the Solidity engineering culture is so paranoid about correctness: the rollback costs are real and measured in tens of millions of dollars per incident. The good news: the language is small. You can fit the entire grammar in your head in a weekend. The hard parts are not syntactic — they're the EVM semantics and the security mindset, both of which come later in this module.

Also in this lesson

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.

Continue this lesson — 6 more sections in the CryptoBipto app.

Open lesson

Educational only — not financial advice.