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. Authors:
(1) MICHAEL PACHECO, Software Analysis and Intelligence Lab (SAIL) at Queen’s University, Canada;
(2) GUSTAVO A. OLIVA, Software Analysis and Intelligence Lab (SAIL) at Queen’s University, Canada;
(3) GOPI KRISHNAN RAJBAHADUR, Centre for Software Excellence at Huawei, Canada;
(4) AHMED E. HASSAN, Software Analysis and Intelligence Lab (SAIL) at Queen’s University, Canada. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. [28] https://etherscan.io/tx/0xb9d4eb05900e1f455b13bc671d4e6d36576cbe047251714860096b8141ce2611 Table of Links Abstract and 1 Introduction Abstract and 1 Introduction 2 Background and 2.1 Blockchain 2 Background and 2.1 Blockchain 2.2 Transactions 2.2 Transactions 3 Motivating Example 3 Motivating Example 4 Computing Transaction Processing Times 4 Computing Transaction Processing Times 5 Data Collection and 5.1 Data Sources 5 Data Collection and 5.1 Data Sources 5.2 Approach 5.2 Approach 6 Results 6.1 RQ1: How long does it take to process a transaction in Ethereum? 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? 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 7 Can a simpler model be derived? A post-hoc study 8 Implications 8 Implications 8.1 How about end-users? 8.1 How about end-users? 9 Related Work 9 Related Work 10 Threats to Validity 10 Threats to Validity 11 Conclusion, Disclaimer, and References 11 Conclusion, Disclaimer, and References A. COMPUTING TRANSACTION PROCESSING TIMES A. COMPUTING TRANSACTION PROCESSING TIMES A. COMPUTING TRANSACTION PROCESSING TIMES A.1 Pending timestamp A.1 Pending timestamp A.2 Processed timestamp A.2 Processed timestamp B. RQ1: GAS PRICE DISTRIBUTION FOR EACH GAS PRICE CATEGORY B. RQ1: GAS PRICE DISTRIBUTION FOR EACH GAS PRICE CATEGORY B. RQ1: GAS PRICE DISTRIBUTION FOR EACH GAS PRICE CATEGORY B.1 Sensitivity Analysis on Block Lookback B.1 Sensitivity Analysis on Block Lookback C. RQ2: SUMMARY OF ACCURACY STATISTICS FOR THE PREDICTION MODELS C. RQ2: SUMMARY OF ACCURACY STATISTICS FOR THE PREDICTION MODELS C. RQ2: SUMMARY OF ACCURACY STATISTICS FOR THE PREDICTION MODELS D. POST-HOC STUDY: SUMMARY OF ACCURACY STATISTICS FOR THE PREDICTION MODELS D. POST-HOC STUDY: 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. block timestamp 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. A.2.1 Evaluating the accuracy of the blockchain-recorded block timestamps. 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]. 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. 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. 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). A.2.2 Obtaining a more accurate block timestamp 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. Authors: (1) MICHAEL PACHECO, Software Analysis and Intelligence Lab (SAIL) at Queen’s University, Canada; (2) GUSTAVO A. OLIVA, Software Analysis and Intelligence Lab (SAIL) at Queen’s University, Canada; (3) GOPI KRISHNAN RAJBAHADUR, Centre for Software Excellence at Huawei, Canada; (4) AHMED E. HASSAN, Software Analysis and Intelligence Lab (SAIL) at Queen’s University, Canada. Authors: Authors: (1) MICHAEL PACHECO, Software Analysis and Intelligence Lab (SAIL) at Queen’s University, Canada; (2) GUSTAVO A. OLIVA, Software Analysis and Intelligence Lab (SAIL) at Queen’s University, Canada; (3) GOPI KRISHNAN RAJBAHADUR, Centre for Software Excellence at Huawei, Canada; (4) AHMED E. HASSAN, Software Analysis and Intelligence Lab (SAIL) at Queen’s University, Canada. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. available on arxiv available on arxiv [28] https://etherscan.io/tx/0xb9d4eb05900e1f455b13bc671d4e6d36576cbe047251714860096b8141ce2611

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Ethereum

dashboard

Why Blockchain Timestamps are Inaccurate Sometimes

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A Novel Pipeline for Classifying and Repairing Smart Contracts at Scale

Can Blockchains Overcome the Scalability Trilemma?

"DApps!" A New Buzzword, or Here to Stay for Good?

DeFi Due Diligence? Not that hard

DevOps Tooling for Web 3.0: Building, Deploying, and Scaling Decentralized Applications

A Novel Pipeline for Classifying and Repairing Smart Contracts at Scale

Can Blockchains Overcome the Scalability Trilemma?

"DApps!" A New Buzzword, or Here to Stay for Good?

DeFi Due Diligence? Not that hard

DevOps Tooling for Web 3.0: Building, Deploying, and Scaling Decentralized Applications

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps