-
Notifications
You must be signed in to change notification settings - Fork 14
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #14 from Credshields/main
Updated Timestamp_dependence
- Loading branch information
Showing
1 changed file
with
33 additions
and
10 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,14 +1,37 @@ | ||
# Timestamp Dependence | ||
## Vulnerability: Timestamp Dependence | ||
|
||
### Description | ||
Contracts that depend on block timestamps for critical operations are susceptible to manipulation, as miners can slightly adjust the timestamps. | ||
### Description: | ||
Smart contracts on Ethereum often rely on block.timestamp for time-sensitive functions such as auctions, lotteries, and token vesting. However, block.timestamp is not entirely immutable because it can be adjusted slightly by the miner who mines the block, within a window of approximately 15 seconds according to Ethereum protocol implementations. This creates a vulnerability where a miner could manipulate the timestamp to their advantage. For instance, in a decentralized auction, a miner who is also a bidder could alter the timestamp to prematurely end the auction when they are the highest bidder, thereby securing an unfair win. | ||
|
||
### Impact | ||
This can lead to unfair advantages in games, easier puzzle solutions, and flawed randomness, all of which an attacker can exploit. | ||
### Example: | ||
``` | ||
// SPDX-License-Identifier: MIT | ||
pragma solidity ^0.8.0; | ||
### Steps to Fix | ||
1. Avoid reliance on `block.timestamp` or `now` for crucial contract functionalities. | ||
2. Use `block.number` for time-keeping if needed, as it is harder to manipulate. | ||
contract DiceRoll { | ||
uint256 public lastBlockTime; | ||
### Example | ||
In a betting smart contract, if the outcome depends on a timestamp (like an even or odd timestamp deciding the winner), a miner could potentially manipulate the timestamp to affect the result. | ||
constructor() payable {} | ||
function rollDice() external payable { | ||
require(msg.value == 5 ether, "Must send 5 ether to play"); // Player must send 5 ether to play | ||
require(block.timestamp != lastBlockTime, "Only 1 transaction per block allowed"); // Ensures only 1 transaction per block | ||
lastBlockTime = block.timestamp; | ||
// Player wins if the last digit of the block timestamp is less than 5 | ||
if (block.timestamp % 10 < 5) { | ||
(bool sent,) = msg.sender.call{value: address(this).balance}(""); | ||
require(sent, "Failed to send Ether"); | ||
} | ||
} | ||
} | ||
``` | ||
### Impact: | ||
- Smart contracts that use block timestamps for essential operations, such as timed executions, are susceptible to manipulation. Attackers can alter timestamps to trigger functions either prematurely or with delays, disrupting the intended outcomes. This can lead to issues like rewards being issued too early or necessary updates being postponed, destabilizing the contract's operations. | ||
- By modifying block timestamps, attackers can exploit time-based mechanisms within contracts. For instance, in a lottery game, an attacker could adjust the timestamp to match specific conditions, increasing their chances of winning. Additionally, they could repeatedly execute functions in quick succession, potentially draining the contract's resources or gaining unfair advantages. | ||
- Timestamp manipulation can facilitate front-running, where attackers execute transactions at strategically advantageous times before others. This predictability, influenced by their controlled timestamps, is particularly damaging in financial contexts. Such actions can result in significant losses for other participants while providing unfair gains to the attacker. | ||
|
||
### Remediation: | ||
- To mitigate the risks of timestamp manipulation and improve the accuracy and security of smart contracts, it is recommended to use trusted external time sources or multiple time sources. This approach can help ensure more reliable timing. | ||
- If you need to use block.timestamp, consider adding a time buffer. For example, you could set a rule that an auction will only end when block.timestamp is greater than the auction end time plus an additional minute. This grace period makes it harder for miners to manipulate the end time, providing a fairer outcome for participants. |