Why Blockchain Timestamps are Inaccurate Sometimes

Table of Links

Abstract and 1 Introduction

2 Background and 2.1 Blockchain

2.2 Transactions

3 Motivating Example

4 Computing Transaction Processing Times

5 Data Collection and 5.1 Data Sources

5.2 Approach

6 Results

6.1 RQ1: How long does it take to process a transaction in Ethereum?

6.2 RQ2: How accurate are the estimates for transaction processing time provided by Etherscan and EthGasStation?

7 Can a simpler model be derived? A post-hoc study

8 Implications

8.1 How about end-users?

9 Related Work

10 Threats to Validity

11 Conclusion, Disclaimer, and References

A. COMPUTING TRANSACTION PROCESSING TIMES

A.1 Pending timestamp

A.2 Processed timestamp

B. RQ1: GAS PRICE DISTRIBUTION FOR EACH GAS PRICE CATEGORY

B.1 Sensitivity Analysis on Block Lookback

C. RQ2: SUMMARY OF ACCURACY STATISTICS FOR THE PREDICTION MODELS

D. POST-HOC STUDY: SUMMARY OF ACCURACY STATISTICS FOR THE PREDICTION MODELS

A.2 Processed timestamp

The block timestamp is recorded in the blockchain and indicates the timestamp at which a given block has been appended to the blockchain. The processed timestamp of all transactions inside a mined block b correspond to the block timestamp of b. However, the block timestamp is potentially inaccurate by construction. Due to the peer-to-peer architecture of the blockchain network, there is no global clock. Miners not only have to rely on their own clock, but might also have their own algorithm to decide upon the exact time for the block timestamp. This timestamp is accepted as long as the timestamp of the mined block is greater than the timestamp of the parent block and no longer than 2 hours into the future [44]. Therefore, block timestamps can drift considerably from miner to miner.

In Section A.2.1, we empirically evaluate the accuracy of the blockchain-recorded block timestamps. We conclude that these timestamps are inaccurate. In Section A.2.2, we describe our approach for retrieving more accurate block timestamps.

A.2.1 Evaluating the accuracy of the blockchain-recorded block timestamps. We investigated the block timestamps of the mined blocks that ended up housing the transactions that we submitted as part of the experiment described in Section A.1.2. More specifically, we calculated the delta between the block timestamp and submitted timestamp for our 200 submitted transactions and analyzed the distribution of deltas.

Result. The block timestamp is inaccurate, as such a timestamp happened to be lower than or equal to the transaction submission timestamp in 7.5% of the cases. The results that we obtained are shown in Figure 19. As the red dashed line indicates, 7.5% of our submitted transaction had either a negative or a zero lag between their submission time and the blockchain-recorded block timestamp. For instance, in one of our submitted transactions, the submitted timestamp recorded by our program was 2019-11-11 20:55:58 UTC. In turn, the block timestamp associated with the transaction was 2019-11-11 20:55:56 UTC[28].

This provides empirical evidence that the block timestamp, as recorded in the blockchain, is indeed inaccurate. As another reference, the red blue dashed line indicates that 20% of our submitted transactions were processed in no more than 7 seconds. Given that blocks are appended 15s in average, we believe that it is unlikely that 20% of our transactions would be processed in no more than 7 seconds. Therefore, we conclude that the block timestamp is an inappropriate proxy for the processed timestamp.

A.2.2 Obtaining a more accurate block timestamp. To obtain a more accurate value for the processed timestamp, we use another piece of information provided by Etherscan. More specifically, Etherscan triggers an update on its front page when it discovers that a new block has been appended to the blockchain. Each new block is shown at the top of a live, real-time list of newly appended blocks (Figure 20).

Therefore, instead of relying on the clocks of several different miners, we monitor Etherscan’s front page and record the timestamp at which a new block appears at the top of the live list. We use this timestamp as the processed timestamp. By employing such an approach, our only source of bias is now Etherscan’s method for updating this live list. Since Etherscan aims to provide a real-time dashboard, we believe that the lag between the addition of a new block and Etherscan’s corresponding page update is minimal and somewhat constant across blocks.

[28] https://etherscan.io/tx/0xb9d4eb05900e1f455b13bc671d4e6d36576cbe047251714860096b8141ce2611