Denial-of-service attack in smart contracts

Denial-of-service attack ( DoS ) can render smart contracts unusable for a period of time or even permanently. The main reasons include:

1. The logic of the contract has defects. For example, some public function implementations do not consider computational complexity, which may exceed the Gas limit and cause the transaction to fail.

2. In cross-contract calling scenarios, contract execution relies on the state of external contracts. Unreliable execution of external contracts may block the operation of this contract, such as funds being locked and unable to be deposited or withdrawn.

3. Human factors, such as the contract owner losing the private key, lead to the inability to update key system states.

The following analyzes the DoS attack vulnerability with specific examples.

1. Iterating through large data structures that can be modified externally

The following is a simple contract for distributing "dividends" to registered users:

The contract status includes a list of registered users and account balance mappings. Users can register and initialize through register_account().

The administrator distributes dividends to users through distribute_token(), iterating over the registered array to transfer a specified amount of tokens to each user.

The problem is that the size of registered is unlimited and can be maliciously manipulated, leading to excessive Gas consumption that exceeds the limit during traversal.

Recommended solutions:

• Limit the size of data structures to ensure that even at the maximum value, it does not exceed the Gas limit.
• Adopting the withdrawal mode, first bookkeeping, users can retrieve rewards themselves through withdraw.

2. Cross-contract state dependencies lead to blocking

Consider a "bidding" contract scenario:

• Record the current highest bidder and amount
• Users can register an account to participate in bidding.
• When the bid is higher than the current highest price, return the previous highest price and update the status.

The problem is that the refund relies on the state of external contracts. If the account of the previous highest bidder has been canceled, the refund will fail, resulting in an inability to update the highest bid, which blocks the entire auction process.

Solution: Consider that external calls may fail, and implement reasonable error handling. For example, temporarily store funds that cannot be refunded, and subsequently allow users to withdraw them separately.

3. Loss of Administrator Private Key

Some key functions ( such as pausing/restarting transactions ) are only callable by the administrator. Loss of the administrator's private key will result in these functions being unavailable, and the contract may not operate normally for an extended period.

Solution: Adopt a multi-signature mechanism to replace a single administrator, achieving decentralized governance and avoiding single points of failure.