Solidity for the EVM

Anatomy of a contract

A Solidity file declares a license identifier, a pragma pinning the compiler version, then a contract with state variables, a constructor, functions, events and modifiers. Deployment stores the compiled bytecode at an address; the ABI is the JSON description used by wallets and ethers.js to encode calls.

• •public / external / internal / private control who can call.
• •view and pure functions read but never write state — free via eth_call.
• •payable functions may receive ETH with the call.

Storage, memory and calldata

Storage is the contract's permanent, expensive key-value state. Memory is a scratchpad wiped after the call. Calldata is the read-only input buffer. Writing storage costs gas per slot, so minimising writes is the main optimisation in practice.

• •mapping(address => uint256) is the standard per-user balance pattern.
• •Prefer calldata for large read-only function arguments.
• •Cache a storage value in a local variable when reading it repeatedly.

Errors and events

require and custom errors revert the whole transaction and refund unused gas — state changes are all-or-nothing. Events write cheap, indexed logs that front-ends and explorers subscribe to, since contracts cannot push data to users.

Safety patterns in SimpleStaking

The lab contract follows checks-effects-interactions: validate inputs, update balances in storage, and only then transfer value out. That ordering is what defeats reentrancy, where a malicious receiver calls back in before your bookkeeping is finished.

• •Update state before external calls or transfers.
• •Never trust block.timestamp for precise timing or randomness.
• •Fund the reward pool explicitly — a contract cannot mint ETH.