We are back with the next part of All About Smart Contract Bugs & Security – A cakewalk series, explaining to you one of the top three vulnerabilities that can weaken a smart contract, Timestamp Dependence. The timestamp dependence vulnerability occurs from a flawed comprehension of timekeeping. Make sure to check out the other parts in this series to know about Flash Loans and Re-entrancy, and how these bugs affect smart contracts.
What is Time Dependence?
Table of Contents
Unfortunately, In a distributed system like the blockchain itself, the timestamp of the block can be manipulated by the miner to exploit the vulnerability. The miner can alter the timestamp by just a few seconds that best suits his profit and completely change the output of the contract.
This vulnerability exists when a smart contract uses the block timestamp as part of the conditions to perform a critical operation (e.g., sending ether) or as the source of entropy to generate random numbers. Let’s take a look at the implementation of the vulnerability:
In this particular code, we see that ‘now’ can be manipulated by hackers for their own advantage, allowing them to always win. While reviewing this particular bug, all its direct and indirect cases should be kept in mind.
How does Time Dependence Work?
Since such a bug can be easily identified while the smart contract is being audited, there haven’t been any major hacks surrounding it but surely, if you skip a third-party audit for your smart contract, attacks are bound to happen. Let’s take up a scenario of what would happen if there is a time dependency in your smart contract.
In order to gain a profit, a miner may manipulate the timestamp by a few seconds. This, in turn, enables the Ethereum network to be detached from the synchronized global clock.
For example, let’s say a smart contract utilizes the current timestamp to generate random integers in order to compute the result and award the miner.
Since the smart contract allows miners to put up a timestamp within 10 seconds of block validation, this gives a miner an opportunity to exploit the scenario, by altering the outcome of the random number generator to gain benefits. Hence, it is advised to not use timestamps in that context as they are not random.
What is the 15-Second Rule?
There is no such restriction on how much blocks can shift in time, but according to the Yellow Paper (Ethereum’s reference specification), each timestamp should be bigger than the timestamp of its parent. Thus, a good unwritten rule in computing timestamp usage is:
“ If the scale of your time-dependent event can vary by 15 seconds and maintain integrity, it is safe to use a block.timestamp.”
The two popularly known Ethereum protocol implementations Geth and Parity reject any blocks with a timestamp greater than 15 seconds in the future.
This was our take on the Timestamp Dependency bug that can cause trouble to smart contract users. Why leave any window open for the hackers to commit any notorious crimes and to ensure that there are no such windows in your smart contract, you should get a third-party audit. Connect with the team of security professionals at ImmuneBytes today to get your smart contract free of any vulnerabilities and loopholes.