Denial-of-Service (DoS) Attack

An attack where a transaction is crafted to consume the maximum block gas limit, preventing other transactions from being included. This can be triggered by forcing a contract into an unbounded loop or an expensive computation that runs out of gas, causing the entire transaction to revert and block progress.

• Example: A function that iterates over an array controlled by users can be DoS'd if an attacker makes the array extremely large.

A pattern where a malicious actor causes a contract call to always revert, blocking essential state-changing operations. This often occurs in multi-step processes where progress depends on every participant acting correctly.

• Classic Example: In a blind auction, if a malicious bidder's fallback function always reverts, the withdraw function for the auction contract may fail for all participants, permanently locking funds.

An attack that makes a contract prohibitively expensive to use by bloating its storage. This increases the gas cost for all future operations that read or write to that storage, potentially pricing users out.

• Mechanism: An attacker exploits a function that allows unlimited data entries (e.g., adding addresses to a whitelist). The growing size of the storage trie drives up the SLOAD and SSTORE opcode costs for all users.

A DoS risk arising from over-dependence on a single address or a small set of privileged actors. If the owner or governance key is lost, compromised, or becomes inactive, critical administrative functions (e.g., upgrading contracts, unlocking funds) are permanently disabled.

• Mitigation: Use timelocks, multi-signature wallets, or decentralized governance to distribute control and prevent a single point of failure.

Exploiting time-dependent logic or strict equality checks to block contract execution. For example, a function may only be callable at a specific future block.timestamp, which a miner can influence within a small margin, potentially preventing the call indefinitely.

• Best Practice: Use time ranges (> or <) instead of exact equality (==) and avoid relying solely on block.timestamp for critical state transitions.

A contract's function becomes unusable if it depends on an external call that can revert or run out of gas. This is a major risk in token transfers, oracle queries, and cross-chain communication.

• Defensive Pattern: Use the pull-over-push pattern for payments, allowing users to withdraw funds themselves rather than the contract pushing funds, which could fail due to external token contract behavior.

This attack forces a transaction to consume all available gas, causing it to revert. Attackers can trigger this by:

• Crafting loops that iterate over unbounded arrays controlled by users.
• Calling functions with expensive operations that scale with user input.
• A classic example is a function that sends funds via a loop (for (uint i = 0; i < contributors.length; i++) { contributors[i].transfer(share); }). If the array grows too large, the transaction hits the block gas limit and fails for everyone.

A malicious or compromised privileged address (e.g., contract owner) can permanently disable critical functions. This is achieved by:

• Setting a crucial state variable to a value that causes all subsequent operations to fail (e.g., setting a fee to an astronomically high value).
• Permanently pausing a contract via an admin function with no unpause mechanism.
• This highlights the risk of centralized control points and the need for timelocks and multi-signature schemes for sensitive operations.

An attacker exploits external calls that revert, causing the entire encompassing transaction to fail. Common patterns include:

• Reentrancy guard failures that revert on legitimate re-entry attempts.
• Interacting with a malicious contract in a payment loop; if one call reverts, the entire batch fails.
• This is particularly damaging in patterns like withdrawal arrays, where one user's revert can block withdrawals for all others.

Attackers force the contract to consume excessive, unpaid-for resources. Key methods are:

• Block Stuffing: Spamming the network with high-gas transactions to delay target transactions.
• Storage Bloat: Creating numerous storage entries to make state reads/writes prohibitively expensive for others.
• Gas Griefing: Exploiting mechanisms where one party pays for another's execution (e.g., relay functions), submitting computations that use the maximum allowed gas.

Flawed contract logic creates conditions where an operation can never succeed. The classic example is the withdrawal pattern vulnerability:

• A contract holds funds for multiple users and processes withdrawals in sequence via a loop.
• A single malicious actor can cause the transaction to always revert (e.g., by implementing a fallback function that reverts).
• This blocks all users in the queue. The mitigation is to use a pull-over-push pattern, where users withdraw their own funds individually.

Developers can defend against DoS vectors through specific design patterns:

• Cap Iterations: Use limits or pagination for loops over user-supplied data.
• Pull-over-Push: Let users withdraw funds themselves instead of contracts pushing to arrays.
• Gas Analysis: Audit functions for worst-case gas consumption.
• Circuit Breakers: Implement emergency stop functions with clear governance.
• Avoid State-Dependent External Calls: Isolate critical logic from external interactions that can revert.

A Transaction Spam Attack is a blockchain-specific DoS vector where an attacker floods the network's mempool with a high volume of low-value or zero-value transactions. The goal is to:

• Consume block space, increasing transaction fees for legitimate users.
• Overwhelm node memory and processing capacity.
• Delay or prevent the confirmation of other transactions. This exploits the cost of block production and validation.

An Economic Denial-of-Service (EDoS) attack aims to make a service financially unsustainable to operate. In Web3, this often targets smart contracts with expensive on-chain operations (like storage writes or complex computations). By repeatedly triggering these costly functions, the attacker forces the contract owner or users to pay exorbitant gas fees, eventually leading to abandonment of the service.

A Consensus-Level Attack is a DoS attack targeting the blockchain's core consensus mechanism. The most famous example is a 51% attack (or majority attack) on Proof-of-Work chains, where an entity gains control of the majority of the network's hashing power. This allows them to:

• Halt block production.
• Reverse transactions (double-spend).
• Exclude or censor other miners. This disrupts the fundamental liveness and security guarantees of the chain.

Resource Exhaustion, often called Gas Griefing, is a smart contract attack where a malicious actor designs a transaction to consume the maximum possible gas limit of a block or to push a contract's execution to its computational limits (the block gas limit). This can cause other transactions in the same block to fail due to 'out of gas' errors, effectively denying service to legitimate users within that block.