Blockchain & Web3

A blockchain is a replicated, append-only ledger maintained by mutually distrusting parties. That definition sounds narrow, but it produces an unusual programming environment: your code is deployed publicly, cannot be patched in place, executes on every node, costs money per operation, and is under permanent attack by anyone who can profit from a bug.

For engineers, the interesting part is less the financial layer than the constraints. Immutability turns deployment into a one-way door and makes upgrade patterns a first-class design concern. Public state means there are no secrets and no obscurity. Metered execution means gas costs are part of your algorithm's complexity analysis. And an adversarial mempool means transaction ordering itself is an attack surface.

TL;DR

The Stack

Featured Topics

Foundations

Smart Contracts

Scaling & Cryptography

Applications

Common Questions

Do I need cryptocurrency knowledge to do blockchain engineering?

You need the mechanics, not the markets. Understanding public-key cryptography, hashing, transaction lifecycles, gas, and consensus is essential — they determine what your code can and cannot do. Token price movements and trading are a separate domain and largely irrelevant to writing correct contracts. This wiki covers the engineering; it does not offer investment guidance.

How is smart contract development different from normal backend work?

Four ways, all consequential. Immutability — you cannot hotfix a deployed contract, so upgradeability must be designed in advance or accepted as absent. Public state — all storage is readable, including variables marked private. Metered execution — every operation costs gas, so loops over unbounded arrays are a denial-of-service vector, not just slow. Adversarial by default — anyone can call any public function in any order, with any inputs, from another contract, in a transaction they control the position of. Testing therefore leans heavily on invariant and fuzz testing rather than happy-path unit tests.

Which chain should I build on?

For learning and for most applications, an EVM chain: Ethereum itself for maximum security and composability, or an L2 like Base, Arbitrum, or Optimism for cheap transactions with the same tooling and Solidity code. EVM skills transfer across dozens of chains, which is the strongest practical argument. Solana is the main alternative with a genuinely different architecture — a distinct accounts model, Rust programs, and parallel execution — and is worth learning if you need high throughput and low latency more than EVM ecosystem compatibility.

Where does the frontend fit?

A Web3 frontend is a normal React app with two additions: a wallet connection that lets the user sign transactions with a key your app never sees, and an RPC client for reading chain state. Reads are usually served from an indexer rather than the chain directly, because scanning event logs is far too slow for a UI. See Web3 Frontends.

Is any of this actually used in production?

Yes, and being precise is useful: stablecoin payments and settlement, tokenized assets, decentralized exchanges, on-chain identity and attestations, and NFT-based ownership records all run real volume. Equally, plenty of proposed use cases are better served by an ordinary database — if you don't need multiple mutually distrusting parties to agree on shared state without an intermediary, a blockchain adds cost and latency for nothing. The engineering skills (cryptography, distributed consensus, adversarial thinking) generalize well regardless.

Learning Path

Beginner

Understand hashing, keys, and transactions (Blockchain Fundamentals). Deploy a trivial Solidity contract to a testnet with Foundry or Hardhat.

Intermediate

Token standards (ERC-20, ERC-721), storage and gas optimization, event indexing, and a wallet-connected frontend. Write invariant tests.

Advanced

Security — reentrancy, oracle manipulation, MEV — plus L2 architecture, proxy upgrade patterns, and zero-knowledge systems.

Related Hubs