Balancing Transaction Speed and Fees in Decentralized Apps | HackerNoon

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

3 MOTIVATING EXAMPLE

Assume that a DApp development organization (e.g., a company) wants to improve the end-user experience of their DApps. More concretely, assume that the organization wants to provide the following quality of service (QoS): 90% of all their submitted transactions should be processed within 5 minutes. Such a quality of service would be somewhat easily achievable if the organization’s budget were infinite. Clearly, that is not the case for any real-world DApp development organization. Hence, let us assume that such an organization wishes to provide the aforementioned QoS while simultaneously ensuring that the gas prices chosen for those transactions are as low as possible (i.e., minimize expenses). We refer to this balance as the time-expense balance.

Using an estimation service in practice. Meeting the organization’s goal requires an accurate processing time estimation service. If a perfect estimation service existed, the company would be able to always achieve their desired time-expense balance. Let us show how this would work in practice. Assume that a developer named Charlie is responsible for programming the transaction submissions of a given DApp. Right before submitting any transaction, Charlie can request a lookup table to the estimation service at timestamp t, which would contain the processing time predictions for each possible value of gas price, based upon recently processed transactions in previous blocks before t. Table 1 shows an example of a hypothetical lookup table requested from an estimation service at timestamp t. For simplicity, we assume that the prices returned by the estimation service go from 1 to 60 GWEI in increments of 1. Because the purpose of the lookup table is to help Charlie choose a gas price for his transaction, we also assume that the estimated time of a transaction with a gas price 𝑥𝑖 is always higher than the estimated time of another transaction with price 𝑥𝑖+1, for the same timestamp t. Finally we discretize prices into gas price categories to give a more practical, straightforward interpretation to the prices. We consider that [1,12] is very cheap, [13,24] is cheap, [25,36] is regular, [37,48] is expensive and [49,60] is very expensive. This allows Charlie to choose between prices to assign his transaction based on how quickly he wants it to be processed at that given time.

Evaluating the time-expense balance. If a perfect estimation service existed, Charlie would achieve the desired time-expense balance by always picking the smallest price whose estimated processing time is shorter than or equal to 5 minutes. In Table 1, this value would be 6 GWEI. However, no such perfect estimation service exists in practice. In fact, devising an accurate estimation service is a major research challenge. Hence, let us assume that Charlie currently uses an estimation service 𝑆 that is not perfect and that underestimates and overestimates with the same likelihood. Additionally, let us assume that Charlie has a fixed monthly budget for transaction fees. Transaction fees depend on both gas usage and gas price of transactions. In the interest of simplification, let us assume that the transactions that Charlie submits always burn the same amount of gas units, such that the budget can be specified in terms of gas price only. Let us assume Charlie’s budget is exactly 15,000 GWEI. Finally, to determine how good the estimation service 𝑆 is (i.e., how good the time-expense balance it provides is), Charlie computes the harmonic mean between the following two variables: (i) the percentage of submitted transactions that were processed within 5 minutes and (ii) how much of the budget is still left (as a percentage). The rationale behind using the harmonic mean is analogous to that of measuring the balance between precision and recall through the F1-measure (harmonic mean between precision and recall, which are both rates).

Now that the context has been specified, let us simulate how Charlie would use 𝑆 for a month. Since 𝑆 is not perfect, Charlie does not trust it very much and thus always picks the third smallest price that satisfies the processing time criterion (in Table 1, this would be 8 GWEI). For each transaction that Charlie submitted during the month, Charlie recorded both the predicted and the actual processing times. After submitting all transactions during that month, Charlie computed

the absolute errors of the predictions (i.e., the absolute value of predicted minus actual). Figure 2 [4] summarizes the results that Charlie obtained.

As the figure indicates, the median error per category decreases from left to right. Also, the difference in the median absolute error between very cheap and cheap is larger than that between cheap and regular. In fact, as we shall see in RQ2, state-of-the-practice estimation services exhibit these two characteristics. With estimation service S, 7.8% of the transactions were processed within 5 minutes and 47.8% of the budget was still free. These results yield a time-expense balance of 13.4%.

Now, let us assume that we could go back in time and make the estimation service fifty percent more accurate (i.e., absolute errors cut in half). We refer to this improved estimation service as 𝑆 + . What would be the difference in the time-expense balance be? With the new improved estimation service, 46.6% of the transactions would have been processed within 5 minutes and 27.1% of the budget would have been left unused. The time-expense balance in this case would have been 34.2% (2.55 times better than before). The results are summarized in Table 2.

Take-away. With this motivating example, we show how a practitioner can use a processing time estimation service in practice. Most importantly, we also show that improvements in the accuracy of the estimations given by these services lead to a better time-expense balance, ultimately benefiting the end-users of DApps.

We also clarify that, while the need to reduce transaction processing times is likely higher for mission-critical DApp, any DApp that issues a reasonable amount of daily transactions would

benefit from a better time-expense balance. Assume, for instance, that a given DApp does not have a strong QoS requirement. For example, assume that the QoS in question is having 90% of the transactions processed within 30 minutes. Additionally, assume that developers commonly spend an average of 4 GWEI per transaction to achieve this QoS. If developers can achieve this same QoS while spending an average of 2 GWEI instead, the costs to run the DApp would be reduced by half, making it more cost-effective. The key challenge for DApp developers is thus spending as little as possible to achieve the desired QoS (i.e., optimizing the time-expense balance). To address this challenge, accurate processing time estimation services are needed.

In this paper, we aim to determine how long transactions normally take to be processed in Ethereum (RQ1) and how accurate the current existing services are (RQ2).

4 COMPUTING TRANSACTION PROCESSING TIMES

In this paper, we define the processing time of a transaction 𝑡 as the time elapsed from when a 𝑡 enters the pending state until 𝑡 enters the processed state (Figure 1). To compute the processing time of a transaction 𝑡, we thus need to determine two timestamps: the timestamp at which 𝑡 enters the pending state (henceforth pending timestamp) and the timestamp at which 𝑡 enters the processed state (henceforth processed timestamp). The processing time is then calculated by simply taking the delta between these two timestamps.

We compute transaction processing times by mining the pending timestamp and the processed timestamp from the Etherscan website. In particular, we highlight that the transaction timestamp, as recorded in the blockchain, is an imprecise representation of the processed timestamp and we thus refrain from using it. A detailed explanation of how we obtained the two aforementioned timestamps is described in Appendix A. All processing times reported in this paper are given in minutes.

[4] The results shown in Figure 2 were produced using synthetic data. The script used for generating these data is available as part of our supplementary material.