> For the complete documentation index, see [llms.txt](https://alham-rizvi.gitbook.io/alhamrizvi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://alham-rizvi.gitbook.io/alhamrizvi/web3pentesting/2.-blockchain-and-web-fundamentals.md). # 2. Blockchain and Web Fundamentals This is the first stage of the roadmap. Nothing here is about attacking anything yet. The entire point of this stage is to build a correct mental model of how blockchains and dapps actually work, so that every vulnerability you learn about later actually makes sense instead of being memorized. *** ### Table of Contents 1. What a Blockchain Actually Is 2. Blocks, Hashing, and Why the Chain Can't Be Tampered With 3. Consensus Mechanisms 4. Accounts, Transactions, and Gas 5. The EVM - What Actually Runs a Smart Contract 6. Nodes and RPC Endpoints 7. Web Fundamentals - How a Normal Web App Works 8. Putting It Together - What a DApp Actually Is 9. Why All of This Matters for Security 10. Recap Table *** ### 1. What a Blockchain Actually Is A blockchain is a distributed ledger. Break that phrase into its two parts, because both matter equally: * **Ledger** - a record of transactions/events, similar in concept to a bank's transaction log or an accounting book. * **Distributed** - instead of one company holding that ledger on their own server, thousands of independent computers (called nodes) each hold their own full copy of it, and they all have to agree with each other about what the ledger contains. ``` TRADITIONAL LEDGER vs DISTRIBUTED LEDGER TRADITIONAL (a bank's database) BLOCKCHAIN (distributed ledger) ================================ ================================ [ Bank's Server ] [Node A] [Node B] [Node C] | \ | / | \ | / One single copy. All hold an IDENTICAL The bank fully controls it. copy of the same ledger. You trust the bank. No single party controls it. You trust the math/protocol instead of any one entity. ``` The core promise of a blockchain is: no single party can secretly rewrite history, because everyone else's copy would disagree, and disagreements are detectable. *** ### 2. Blocks, Hashing, and Why the Chain Can't Be Tampered With #### What a block is Transactions don't get added to the ledger one at a time in isolation. They get grouped into batches called blocks. Each block typically contains: * A list of transactions * A timestamp * A reference to the previous block (this is the part that makes it a "chain") * A hash of all of the above #### What hashing actually does A hash function takes any input (no matter how large) and produces a fixed-size, seemingly random output. The same input always produces the same output, but changing the input even slightly produces a completely different output. ``` HASHING EXAMPLE Input: "Alice sends Bob 5 ETH" --> Hash: 4f2a9c... (example) Input: "Alice sends Bob 6 ETH" --> Hash: e91b03... (completely different) Change ONE character, get a COMPLETELY different hash. This is what makes tampering detectable. ``` #### Why blocks reference the previous block's hash This is the actual "chain" part of blockchain. Each block stores the hash of the block before it. ``` THE CHAIN STRUCTURE BLOCK 1 BLOCK 2 BLOCK 3 ----------------- ----------------- ----------------- transactions transactions transactions timestamp timestamp timestamp prev hash: (genesis) prev hash: HASH(1) -----> prev hash: HASH(2) this block's hash: H1 this block's hash: H2 this block's hash: H3 ^ | | |__________________________|__________________________| each block "points back" to the one before it WHAT HAPPENS IF SOMEONE TAMPERS WITH BLOCK 1: - Changing any transaction in Block 1 changes H1 (since the hash depends on the block's contents) - But Block 2 stored the OLD H1 as its "prev hash" - Now Block 2's reference no longer matches Block 1's new hash - The mismatch is instantly detectable by every node on the network - To hide the tampering, the attacker would have to also recompute H2, H3, and every block after it, on every single node's copy, faster than the honest network can keep adding new blocks This is why older blocks become exponentially harder to tamper with as more blocks get added on top of them - this is what people mean when they say a transaction has more "confirmations." ``` *** ### 3. Consensus Mechanisms If thousands of independent nodes each hold their own copy of the ledger, something has to decide whose version is "correct" when they disagree, and who gets to add the next block. That's what a consensus mechanism does. #### Proof of Work (used by early Bitcoin and pre-2022 Ethereum) Nodes (called miners) compete to solve a computationally expensive puzzle. Whoever solves it first gets to add the next block and is rewarded. The "work" is expensive on purpose - it makes attacking the network expensive too, since you'd need more computing power than the rest of the honest network combined. #### Proof of Stake (used by modern Ethereum and most newer chains) Instead of competing with computing power, nodes (called validators) lock up ("stake") a large amount of the network's own cryptocurrency as collateral. The protocol selects validators to propose and confirm blocks, and if a validator acts dishonestly, part of their staked funds can be destroyed ("slashed"). The economic incentive replaces the computational competition. ``` PROOF OF WORK vs PROOF OF STAKE PROOF OF WORK PROOF OF STAKE ========================== ========================== Compete by solving puzzles Compete by locking up funds Costs real-world electricity Costs locked-up capital Attacker needs majority compute Attacker needs majority stake power to rewrite history to rewrite history, and risks losing that stake if caught ``` You don't need to become an expert in consensus algorithms at this stage, just understand that this is the layer that decides "whose copy of the ledger is correct," and that attacks on this layer (like a 51 percent attack) are a real, if difficult, category of blockchain-level attack, separate from smart contract bugs. *** ### 4. Accounts, Transactions, and Gas #### Two types of accounts on Ethereum * **Externally Owned Accounts (EOAs)** - controlled by a private key, this is what a normal wallet is. A person owns the private key and can sign transactions with it. * **Contract Accounts** - controlled by their own code (a smart contract), not by a private key. They can only "act" when called by a transaction. #### What a transaction is A transaction is a signed instruction, sent from an account, that either transfers value, calls a contract's function, or deploys a new contract. It has to be signed with the sender's private key, which is how the network verifies it actually came from that account without needing to trust anyone. #### What gas is Every operation on Ethereum (adding numbers, writing to storage, calling another contract) costs a small amount of computational effort, measured in "gas." The sender pays for this gas in the network's native currency (ETH). This exists for two reasons: * It compensates the nodes doing the actual computation * It prevents infinite loops or spam, since every operation costs something real - a contract that ran forever would just run out of gas and stop ``` WHAT A TRANSACTION COSTS Gas price (cost per unit of gas) x Gas used (how much work was done) = Total transaction fee If you don't send enough gas to cover the operation, the transaction fails (and you still pay for the gas that WAS consumed before it ran out). ``` *** ### 5. The EVM - What Actually Runs a Smart Contract The Ethereum Virtual Machine (EVM) is the environment that actually executes smart contract code. Every node on the network runs its own copy of the EVM, and they all execute the exact same instructions in the exact same order, which is how they all end up agreeing on the resulting state. ``` HOW A CONTRACT CALL ACTUALLY EXECUTES User signs a transaction calling withdraw(100) | v Transaction is broadcast to the network | v Included in a block by a validator/miner | v EVERY node independently re-executes the transaction inside their own copy of the EVM | v Every node arrives at the same resulting state (assuming they're all honest and running the same rules) | v The new state becomes part of the agreed-upon ledger ``` Smart contracts are compiled down from Solidity into EVM bytecode, which is what actually runs. This is worth knowing because tools that analyze contracts for vulnerabilities sometimes work at the Solidity source level, and sometimes at the raw bytecode level. *** ### 6. Nodes and RPC Endpoints A node is a computer running the blockchain's software, holding a copy of the ledger and participating in the network. Most applications don't run their own node - instead they connect to one through an RPC (Remote Procedure Call) endpoint, which is basically an API that lets outside software ask a node questions ("what's this account's balance") or submit transactions. ``` HOW A DAPP TALKS TO THE BLOCKCHAIN [ DApp Frontend ] ---> [ RPC Endpoint ] ---> [ Blockchain Node ] ---> [ The Chain ] The RPC endpoint is often run by a third-party provider (rather than the dapp's own infrastructure), which is itself a piece of the attack surface worth knowing about later - misconfigured or compromised RPC endpoints are a real category of Web3 infrastructure risk. ``` *** ### 7. Web Fundamentals - How a Normal Web App Works Since a dapp is still a website underneath everything, you need the same base knowledge a traditional web pentester needs: * **Frontend** - the part running in the user's browser (HTML, CSS, JavaScript), responsible for what the user sees and interacts with. * **Backend** - a server that the frontend talks to, usually handling things like user accounts, off-chain data, and business logic that doesn't need to be on the blockchain. * **APIs** - the defined way the frontend and backend (and sometimes other services) talk to each other, usually by sending structured requests (commonly JSON over HTTP) and getting structured responses back. * **Databases** - where the backend stores information that isn't meant to live on the blockchain (user profiles, cached data, session information, and so on). ``` A NORMAL (NON-BLOCKCHAIN) WEB APP [ Browser: HTML/CSS/JS ] <--- API requests/responses ---> [ Backend Server ] | v [ Database ] This part of a dapp is basically a completely normal web application, and normal web vulnerabilities (like the OWASP Top 10: injection flaws, broken authentication, misconfigurations, and so on) still apply here in full. ``` *** ### 8. Putting It Together - What a DApp Actually Is A decentralized application (dapp) is a normal web application that also talks to a blockchain, usually through a wallet acting as the signing/authentication layer. ``` FULL DAPP ARCHITECTURE [ User's Browser ] | |------------------> [ Wallet Extension (MetaMask, etc.) ] | | v | (signs transactions with [ Frontend: React/JS ] | the user's private key) | | | (normal API calls) | v v [ Backend API / Server ] [ Ethers.js / Web3.js library ] | | v v [ Database / Cloud Infra ] [ RPC Endpoint ] ---> [ Blockchain Node ] | v [ Smart Contracts on-chain ] Notice this diagram has BOTH a traditional web app (frontend, backend, database) AND a blockchain-specific path (wallet, RPC, contracts) running side by side. A real Web3 pentest has to cover both halves. ``` *** ### 9. Why All of This Matters for Security Every concept above maps directly onto a category of real-world attack you'll study later in this roadmap: * Understanding **hashing and block linking** is what makes you able to reason about chain reorganizations and why transaction "confirmations" matter for finality. * Understanding **consensus mechanisms** is what makes 51 percent attacks and validator-level attacks make sense, rather than being an abstract buzzword. * Understanding **gas** is the entire foundation for gas-based denial-of-service attacks and gas griefing. * Understanding **the EVM and how transactions execute deterministically** is the foundation for reasoning about reentrancy, since it explains exactly when and how control can be handed to another contract mid-execution. * Understanding **RPC endpoints and nodes** is the foundation for infrastructure-level attacks that have nothing to do with smart contract code at all. * Understanding **normal web architecture** is what lets you apply traditional web pentesting knowledge (injection, broken auth, misconfigurations) to the half of a dapp that is just a regular website. Nothing here was wasted knowledge. Every later stage of the roadmap builds directly on top of this one. *** ### 10. Recap Table | Concept | One-line definition | Why it matters later | | -------------------------- | --------------------------------------------------------------------- | ----------------------------------------------------------- | | Distributed ledger | A shared record held by many independent nodes | Explains why no single party controls a blockchain | | Hashing | A one-way function that changes drastically if input changes slightly | Explains why tampering with old blocks is detectable | | Consensus mechanism | The rule nodes use to agree on the ledger's true state | Foundation for network/consensus-level attacks | | Accounts (EOA vs Contract) | Private-key-controlled vs code-controlled accounts | Explains who can actually initiate a transaction | | Gas | The fee paid for computation on the network | Foundation for DoS and gas-based attacks | | EVM | The environment that executes contract code | Foundation for understanding reentrancy and execution order | | Nodes / RPC endpoints | How outside software talks to the blockchain | Foundation for infrastructure-level attack surface | | Frontend / backend / APIs | The normal web layer underneath every dapp | Foundation for applying standard web pentesting skills | #### The one thing to remember A dapp is really two systems stitched together: a normal web application, and a blockchain. You need to understand both halves before any of the later, more exciting attack content will actually make sense. flowchart TD ``` START([STAGE 1 RECAP
Blockchain and Web Fundamentals]) --> A subgraph A[" 1. THE LEDGER LAYER "] A1[Distributed Ledger
Many nodes hold identical copies] A2[Hashing
Small input change = totally different output] A3[Blocks link via prev-hash
Tampering with old data breaks the chain] A1 --> A2 --> A3 end subgraph B[" 2. CONSENSUS LAYER "] B1[Proof of Work
Miners compete via computation] B2[Proof of Stake
Validators lock up funds as collateral] B3[Decides whose ledger copy is correct] B1 --> B3 B2 --> B3 end subgraph C[" 3. ACCOUNTS AND TRANSACTIONS "] C1[EOA - controlled by a private key] C2[Contract Account - controlled by code] C3[Transaction - signed instruction
transfer, call, or deploy] C4[Gas - fee paid per unit of computation] C1 --> C3 C2 --> C3 C3 --> C4 end subgraph D[" 4. EXECUTION LAYER - THE EVM "] D1[Every node re-executes the same tx] D2[All nodes reach identical resulting state] D3[Execution order is deterministic] D1 --> D2 --> D3 end subgraph E[" 5. INFRASTRUCTURE LAYER "] E1[Node - full copy of the chain] E2[RPC Endpoint - API into a node] E3[Most dapps use 3rd-party RPC providers] E1 --> E2 --> E3 end subgraph F[" 6. THE WEB HALF OF A DAPP "] F1[Frontend - browser UI] F2[Backend - server, off-chain logic] F3[API - structured requests/responses] F4[Database - off-chain storage] F1 --> F3 --> F2 --> F4 end subgraph G[" 7. FULL DAPP ASSEMBLY "] G1[Wallet signs transactions
with user's private key] G2[Ethers.js / Web3.js
library bridges frontend to chain] G3[Frontend + Backend + Blockchain
all working together] G1 --> G2 --> G3 end A --> B --> C --> D --> E --> F --> G G --> WHY([WHY THIS MATTERS NEXT]) WHY --> H1[Hashing and block linking
------------------------------
Explains chain reorgs and
why confirmations matter] WHY --> H2[Consensus mechanisms
------------------------------
Foundation for 51 percent
and validator-level attacks] WHY --> H3[Gas
------------------------------
Foundation for Denial of
Service and gas griefing] WHY --> H4[EVM deterministic execution
------------------------------
Foundation for understanding
REENTRANCY] WHY --> H5[RPC and nodes
------------------------------
Foundation for infrastructure
level attacks] WHY --> H6[Web architecture
------------------------------
Lets you apply normal web
pentesting skills to dapps] WHY --> H7[Full dapp assembly
------------------------------
Shows the entire attack
surface you will test] H1 --> NEXT H2 --> NEXT H3 --> NEXT H4 --> NEXT H5 --> NEXT H6 --> NEXT H7 --> NEXT NEXT([STAGE 2
Lab Setup and Tooling
Remix, MetaMask, Hardhat/Foundry]) style START fill:#1f2937,stroke:#60a5fa,color:#ffffff style WHY fill:#1f2937,stroke:#f59e0b,color:#ffffff style NEXT fill:#1f2937,stroke:#34d399,color:#ffffff ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://alham-rizvi.gitbook.io/alhamrizvi/web3pentesting/2.-blockchain-and-web-fundamentals.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.