Protocol Flow

The network operators responsible for producing new blocks and securing the chain through consensus. Their primary functions include:

• Transaction Validation: Checking and ordering transactions.
• Block Production: Creating new blocks to be added to the ledger.
• Consensus Participation: Running the protocol's specific algorithm (e.g., Proof-of-Stake, Proof-of-Work) to agree on the canonical state. They are typically incentivized by block rewards and transaction fees.

Token holders who participate in network security by staking their assets, often in Proof-of-Stake (PoS) systems. Their roles are distinct:

• Active Validator Stakers: Operate nodes and have their stake directly "at risk" (slashed) for misbehavior.
• Delegators: Assign their stake to a trusted validator, sharing in rewards (and risks) without running infrastructure. This mechanism aligns economic security with honest participation, as malicious acts can lead to slashing of staked funds.

The individuals or entities that initiate transactions on the network. They are the primary consumers of the blockchain's services. Key actions include:

• Submitting Transactions: Sending tokens, interacting with smart contracts, or deploying dApps.
• Paying Fees: Compensating validators for computation and storage via gas fees or transaction fees.
• Holding Assets: Managing cryptographic keys for wallets containing tokens or NFTs. User activity drives network demand and fee markets.

Participants who possess tokens conferring voting rights in a decentralized autonomous organization (DAO) or on-chain governance system. Their power includes:

• Proposal Submission & Voting: Influencing protocol upgrades, parameter changes, and treasury allocations.
• Delegating Votes: Assigning voting power to representatives or "delegates." This role separates economic interest from operational security, focusing on the direction and evolution of the protocol.

The creators who expand the protocol's utility by writing and deploying smart contracts and building decentralized applications (dApps). Their work involves:

• Smart Contract Deployment: Creating the immutable logic that runs on the blockchain (e.g., DeFi pools, NFT collections).
• Front-End & Infrastructure: Building user interfaces and indexers (like The Graph) to interact with on-chain data.
• Protocol Development: Contributing to the core client software or proposing improvements via governance.

The canonical example of a Proof-of-Work (PoW) protocol flow. The sequence is:

• A user creates and broadcasts a signed transaction to the peer-to-peer network.
• Full nodes validate the transaction against consensus rules (e.g., valid signature, no double-spend).
• Miners collect valid transactions into a candidate block and compete to solve a cryptographic puzzle.
• The winning miner broadcasts the solved block.
• Other nodes validate the block's proof-of-work and all contained transactions.
• Upon acceptance, the block is appended to the longest chain, finalizing the state transition.

A dual-layer flow separating execution from consensus, especially post-Merge. The key stages are:

1. Execution Layer: A user submits a transaction to an Execution Client (e.g., Geth). The client executes it in the EVM, computing state changes and gas usage.
2. Consensus Layer: The execution payload is passed to a Consensus Client (e.g., Prysm). Validators propose and attest to blocks in slots and epochs using Proof-of-Stake (PoS).
3. Finalization: After sufficient attestations, the block is justified and then finalized, making reversion economically prohibitive. This flow is governed by the Ethereum Yellow Paper and EIPs.

A formal on-chain process for enacting protocol changes, common in Proof-of-Stake systems.

• Submission: A governance proposal (e.g., a parameter change, software upgrade) is submitted with a deposit.
• Deposit Period: Stakeholders deposit tokens to bring the proposal to a vote.
• Voting Period: Validators and delegators vote Yes, No, NoWithVeto, or Abstain. Voting power is weighted by stake.
• Tallying & Execution: If quorum and passing thresholds (e.g., >50% Yes, <33.4% NoWithVeto) are met, the proposal passes. The changes are automatically executed by the protocol, often via a governance module.

The flow for scaling Ethereum via layer 2 rollups, which batch transactions off-chain.

• Sequencing: Users send transactions to a central Sequencer, which orders them and creates a rollup block.
• Publication: The sequencer posts a compressed batch of transactions and a new state root to Ethereum L1 as calldata.
• State Commitment: The posted state root is the official claim about the rollup's state.
• Dispute Window (Fraud Proof): A challenge period (typically 7 days) begins. Anyone can submit a fraud proof if the state transition is invalid.
• Finalization: If no fraud proof is submitted, the state is considered final on L1. This flow is defined by the specific rollup's protocol (e.g., Optimism, Arbitrum Nitro).

An attack where the unique identifier (TXID) of an unconfirmed transaction is altered before it is confirmed, potentially invalidating downstream logic. This exploits the fact that signatures are not part of the TXID calculation.

• Mechanism: An attacker modifies the signature encoding, changing the transaction's hash while keeping it valid.
• Impact: Can break protocols relying on unconfirmed TXIDs for atomic swaps or payment tracking.
• Mitigation: SegWit (Segregated Witness) fixed this in Bitcoin by removing signature data from the TXID input hash.

The practice of exploiting the public mempool to gain an unfair advantage by inserting, reordering, or censoring transactions. Maximal Extractable Value (MEV) formalizes the profit from this.

• Common Forms: Sandwich attacks on DEX trades, arbitrage between venues, and liquidations in lending protocols.
• Vector: Relies on the transparency of pending transactions in the mempool.
• Privacy Solution: Using private transaction relays or commit-reveal schemes to hide intent until execution.

An attack where a valid transaction signed for one network is maliciously or accidentally rebroadcast and executed on another network, often after a chain fork.

• Scenario: After a chain split (e.g., ETH/ETC), a transaction signed for Ethereum could be replayed on Ethereum Classic, transferring assets there unintentionally.
• Prevention: Implementing chain-specific identifiers (e.g., EIP-155 for Ethereum) in the transaction signature or using unique nonces per network.

Exploits that manipulate the assumptions a protocol makes about time, block numbers, or timestamps.

• Timestamp Manipulation: Miners/validators can slightly influence block timestamps, affecting time-locked contracts.
• Block Number Dependency: Contracts using block.number as a time proxy are vulnerable to variable block times (e.g., during congestion).
• Best Practice: Use oracles for critical time data or design with wide tolerance for block time variance.

Even without revealing identities, the public nature of blockchain data allows for chain analysis to deanonymize users by tracing the flow of funds and interactions.

• Techniques: Clustering addresses likely owned by the same entity, analyzing transaction graph patterns, and linking on-chain activity to off-chain data.
• Impact: Can reveal trading strategies, counterparties, or wallet balances.
• Countermeasures: Privacy-focused protocols (e.g., zk-SNARKs), coin mixers, and avoiding address reuse.

The security of the entire flow depends on the integrity of the consensus mechanism and the correctness of state validation.

• Long-Range Attacks: In Proof-of-Stake, an attacker could create an alternate history starting from a distant past.
• Invalid State Transitions: A buggy client or malicious validator could propose a block that violates protocol rules but is accepted by other nodes.
• Defense: Robust peer-to-peer gossip, strict fork choice rules, and diverse, audited client implementations.