Demystifying Web3 and Smart Contracts

Strip away the price talk and a blockchain is a replicated state machine with expensive writes, free reads, and no delete. That framing explains nearly every design constraint you will hit.

A single-threaded virtual machine whose state every node reproduces independently. Because every participant re-executes your code, computation is metered in gas and storage is the most expensive resource by a wide margin. A storage write costs thousands of times more than an arithmetic operation, which is why contract code looks so unlike ordinary application code.

Deployed bytecode is immutable and public. There is no hotfix, and adversaries read your source, simulate against forked state, and are paid directly by any mistake. The discipline this demands has two pillars.

Check, effects, interactions. Validate conditions, update your own state, and only then call anything external. Reversing the last two steps is how reentrancy drains a contract.

Never trust an external call. Any address you call may be a contract that calls you back.

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract Escrow { mapping(address => uint256) private balances; bool private locked;

error InsufficientBalance(); error TransferFailed();

modifier nonReentrant() { require(!locked, 'reentrant'); locked = true; _; locked = false; }

function withdraw(uint256 amount) external nonReentrant { if (balances[msg.sender] < amount) revert InsufficientBalance();

balances[msg.sender] -= amount; // state first

(bool ok, ) = msg.sender.call{value: amount}(''); if (!ok) revert TransferFailed(); // interaction last } } ```

• Reentrancy. Still responsible for enormous losses, usually in a function that looked too simple to matter.
• Oracle manipulation. Pricing off a single pool's spot price lets an attacker move that price with a flash loan and rob you inside one transaction. Use time-weighted averages and multiple sources.
• Access control gaps. An unprotected initialiser or a missing owner check is the most boring and most common critical finding.
• Unchecked return values. Some token implementations return false instead of reverting.
• Front-running. Your pending transaction is public. Anything profitable to reorder will be reordered.

Pack storage variables into shared slots, cache repeated reads in memory, use custom errors instead of revert strings, prefer calldata for read-only array parameters, and never loop over an unbounded array in a state-changing function. An array that grows past the block gas limit permanently bricks the function that iterates it.

Write property-based tests, run a fuzzer, fork mainnet and test against real protocol state, deploy to a testnet, then get an independent audit. Ship behind a timelock with a pause mechanism and start with a capped total value. Every large exploit was written by someone confident their code was fine.