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 8 IMPLICATIONS In the following, we discuss the key implications of our findings. Implication 1) ÐApp developers now have a baseline for transactions processing times in Ethereum. To the best of our knowledge, our study is the first one to empirically investigate transaction processing times in Ethereum. In particular, RQ1 includes several pieces of information that ÐApp developers can use as a yardstick. These pieces of information should also be useful for organizations that want to evaluate the suitability of the Ethereum platform as a backend for a prospective ÐApp. For instance, in observation 1, we note that three quarters of the processing times lie in the range of 33s to 2m 23s. As part of observation 2, we also show that the most commonly used prices and their respective 90th percentile processing time (Table 3). As part of observation 3, we analyze gas prices, group them into categories, and describe the ranges of these categories (Table 4). These ranges should help ÐApp developers understand what is considered cheap and what is considered expensive in terms of gas price. Finally, our statistics for processing time can be used as a baseline to assess the effectiveness of throughput-improving changes in future versions of the Ethereum platform. Implication 2) ÐApp developers can better assess the trade-off between processing time and transaction cost. In observation 4, we highlight that higher gas prices have diminishing returns in terms of processing time. Therefore ÐApp developers should carefully assess whether using higher gas prices is worthy. In particular, our findings indicate that ÐApp developers should typically avoid very expensive transactions, as there is no practical difference (as per Cliff’s Delta) in their processing time compared to expensive transactions. Implication 3) ÐApp developers can make more informed decisions regarding the choice of a prediction model for transaction processing times in Ethereum. In RQ2, we show that the Etherscan Gas Tracker is the best model for very cheap and cheap transactions. From RQ1, we know that the processing time of cheaper transactions varies considerably more compared to those of transactions in other price categories. Hence, we believe that ÐApp developers will typically benefit the most from using the Etherscan Gas Tracker model. We also show that the EthGasStation Gas Price API is best model for the remaining gas price categories. Therefore, developers who wish to maximize prediction accuracy can combine the two models into an ensemble model (e.g., similarly to our design shown in Figure 9). Nonetheless, ÐApp developers should be aware that, for a given a price category, the best median AEs that can be achieved with these two models are: 7m 7s for very cheap transactions, 1m 36s for cheap transactions, 28s for regular transactions, 14s for expensive transactions, and 12s for very expensive transactions (Table 9). In light of the aforementioned results, we conducted a post-hoc study in which we proposed an alternative model that is simple in design and inherently interpretable. We show that our model outperforms the Etherscan Gas Tracker for very cheap and cheap transactions. In addition, our model performs as accurately as the EthGasStation Gas Price API for the remaining categories. Nevertheless, ÐApp developers should be the ones making the final call, since the context in which each ÐApp operates might be different and might lead to different requirements in terms of prediction accuracy. 8.1 How about end-users? Our paper focuses on the development model where (i) the blockchain complexities (e.g., transaction parameter setup) are hidden from end-users and (ii) developers carry the burden of submitting transactions with proper parameters. In this context, setting up appropriate transaction parameters (e.g., gas price) becomes a clear Software Engineering problem. Nonetheless, we acknowledge the existence of several ÐApps that follow an alternative development model in which the blockchain complexities are exposed to end-users. In other words, end-users of these DApps have to submit transactions themselves and commonly use a wallet (e.g., Metamask) to do so. When using wallets, end-users can either accept the wallet’s suggested gas prices for different transaction processing speed categories or manually input a gas price. Hence, in this context, end-users also might find it important to achieve a good balance between transaction cost and processing time speed (e.g., in the event where a given end-user frequently uses a certain DApp). In this vein, the two implications discussed in the previous section apply to these end-users as well. Advanced end-users can even use prediction models such as the one that we propose in the post-hoc study in order to make more informed gas price choices. 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. 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 8 IMPLICATIONS In the following, we discuss the key implications of our findings. I mplication 1) ÐApp developers now have a baseline for transactions processing times in Ethereum. To the best of our knowledge, our study is the first one to empirically investigate transaction processing times in Ethereum. In particular, RQ1 includes several pieces of information that ÐApp developers can use as a yardstick. These pieces of information should also be useful for organizations that want to evaluate the suitability of the Ethereum platform as a backend for a prospective ÐApp. For instance, in observation 1, we note that three quarters of the processing times lie in the range of 33s to 2m 23s. As part of observation 2, we also show that the most commonly used prices and their respective 90th percentile processing time (Table 3). As part of observation 3, we analyze gas prices, group them into categories, and describe the ranges of these categories (Table 4). These ranges should help ÐApp developers understand what is considered cheap and what is considered expensive in terms of gas price. Finally, our statistics for processing time can be used as a baseline to assess the effectiveness of throughput-improving changes in future versions of the Ethereum platform. mplication 1) ÐApp developers now have a baseline for transactions processing times in Ethereum. ÐApp developers now have a baseline for transactions processing times in Ethereum. Implication 2) ÐApp developers can better assess the trade-off between processing time and transaction cost. In observation 4, we highlight that higher gas prices have diminishing returns in terms of processing time. Therefore ÐApp developers should carefully assess whether using higher gas prices is worthy. In particular, our findings indicate that ÐApp developers should typically avoid very expensive transactions, as there is no practical difference (as per Cliff’s Delta) in their processing time compared to expensive transactions. Implication 2) ÐApp developers can better assess the trade-off between processing time and transaction cost. ÐApp developers can better assess the trade-off between processing time and transaction cost. Implication 3) ÐApp developers can make more informed decisions regarding the choice of a prediction model for transaction processing times in Ethereum. In RQ2, we show that the Etherscan Gas Tracker is the best model for very cheap and cheap transactions. From RQ1, we know that the processing time of cheaper transactions varies considerably more compared to those of transactions in other price categories. Hence, we believe that ÐApp developers will typically benefit the most from using the Etherscan Gas Tracker model. We also show that the EthGasStation Gas Price API is best model for the remaining gas price categories. Therefore, developers who wish to maximize prediction accuracy can combine the two models into an ensemble model (e.g., similarly to our design shown in Figure 9). Nonetheless, ÐApp developers should be aware that, for a given a price category, the best median AEs that can be achieved with these two models are: 7m 7s for very cheap transactions, 1m 36s for cheap transactions, 28s for regular transactions, 14s for expensive transactions, and 12s for very expensive transactions (Table 9). Implication 3) ÐApp developers can make more informed decisions regarding the choice of a prediction model for transaction processing times in Ethereum. ÐApp developers can make more informed decisions regarding the choice of a prediction model for transaction processing times in Ethereum. In light of the aforementioned results, we conducted a post-hoc study in which we proposed an alternative model that is simple in design and inherently interpretable. We show that our model outperforms the Etherscan Gas Tracker for very cheap and cheap transactions. In addition, our model performs as accurately as the EthGasStation Gas Price API for the remaining categories. Nevertheless, ÐApp developers should be the ones making the final call, since the context in which each ÐApp operates might be different and might lead to different requirements in terms of prediction accuracy. 8.1 How about end-users? Our paper focuses on the development model where (i) the blockchain complexities (e.g., transaction parameter setup) are hidden from end-users and (ii) developers carry the burden of submitting transactions with proper parameters. In this context, setting up appropriate transaction parameters (e.g., gas price) becomes a clear Software Engineering problem. Nonetheless, we acknowledge the existence of several ÐApps that follow an alternative development model in which the blockchain complexities are exposed to end-users. In other words, end-users of these DApps have to submit transactions themselves and commonly use a wallet (e.g., Metamask) to do so. When using wallets, end-users can either accept the wallet’s suggested gas prices for different transaction processing speed categories or manually input a gas price. Hence, in this context, end-users also might find it important to achieve a good balance between transaction cost and processing time speed (e.g., in the event where a given end-user frequently uses a certain DApp). In this vein, the two implications discussed in the previous section apply to these end-users as well. Advanced end-users can even use prediction models such as the one that we propose in the post-hoc study in order to make more informed gas price choices. 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

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

How DApp Developers Can Optimize Ethereum Transaction Speed and Cost

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