Step on the Gas? A Better Approach for Recommending the Ethereum Gas Price

Ethereum employs a Proof-of-Work consensus mechanism as first introduced by Bitcoin [20]. In such a protocol, transactions are grouped into blocks and Ethereum’s block arrival time is approximately 13 seconds [11]. Ethereum allows for the creation of so-called smart contracts. These are programs which define a set of rules using a Turing-complete programming language, typically Solidity [8], that can be invoked by network participants. An Ethereum account balance is expressed in the underlying currency Ether (ETH) and directly altered via state transitions caused by transactions. The consensus rules governing transaction validity are implemented by the Ethereum Virtual Machine (EVM), a low-level stack machine which executes the compiled EVM bytecode of the smart contract. Operations performed by the EVM consume gas, a virtual unit of account used to measure the computational cost of executing a transaction. By design, each EVM instruction has a hard-coded¹¹1Note that via a hard-fork, the Ethereum Improvement Proposal 150 [3] re-aligned gas costs for instructions involving I/O-heavy operations. gas cost [26]. The total execution cost has to be paid for by the sender of a transaction.

The total execution cost for a contract consists of two components, namely the gas cost in units and gas price per unit. The gas cost is split into a fixed base cost of 21 000 gas and an execution cost dependent on the instructions executed while running the contract.

In order to avoid risks of overpaying, gas price oracles exist [1, 13, 14, 12]. These oracles aim to recommend the gas price a transaction requires in order to be included in a block within a specified time period. Commonly, the recommendation mechanism uses some rule-based approach analyzing the gas prices of previous blocks. We provide a more detailed summary on existing approaches in Section 6.

The methodology we propose requires a forecasting model to predict the gas price trajectory over a pre-defined number of time steps $s$. In particular, we are interested in predicting the minimum gas price under rational miner behavior, since this can be seen as a lower bound for setting the gas price for a given transaction. From the preliminary data exploration in Section 3, it is apparent that the per-block data is extremely noisy, which can be attenuated by averaging over a longer period of time. We therefore average the minimum gas price of all blocks in consecutive 5 minute intervals and forecast on this level of granularity, instead of using per-block data directly. A time step is then defined as a 5 minute interval. We denote the complete time series of average minimum gas prices by $y$. Furthermore, we define the aggregated time series of all features used as model input as $\mathcal{D}$, where $d_{t}\in\mathcal{D}$ denotes the feature vector for a single time step $t$. For both model training and inference, we use a sliding window model that uses a fixed-size window of historical data with $l$ time steps for prediction. The problem of forecasting a window of $s$ time steps using a window of size $l$ can then be defined as

In the remainder of this section we present our pre-processing methodology and proposed forecasting model.

We now describe our recommendation algorithm which leverages the gas prices predicted by our model. We use the 20th percentile of the predicted prices as the initial gas price, which we note $\hat{g}$. One of the main objectives of our algorithm is to scale $\hat{g}$ such that the faster the predicted gas prices are decreasing, the lower the gas price recommended by the algorithm. On the other hand, if the prices are increasing, the predicted prices should not be significantly lower than the current gas price. We incorporate this objective by finding a coefficient $0<c\leq 1$ that is multiplied with the predicted gas price $\hat{g}$. Furthermore, we want $c$ to increase or decrease exponentially with respect to the trend to achieve aggressive gas pricing if the predicted prices decrease quickly.

First, we compute the trend of the predictions $\hat{y}$ returned by our forecasting model. We fit a linear function such that $\hat{y}=aX+b$, with $X=1,2,\cdots,s$, and store the slope $a$, which captures the trend in the predicted gas prices. We then normalize $a$ to $\tilde{a}$ to lie in the range between $0$ to $1$. This is achieved by computing the maximum $A_{max}$ and minimum $A_{min}$ values of the slopes we obtain for our training data and computing $\tilde{a}$ according to Equation (6).

Then, to obtain the described exponential behavior, we exploit the fact that the exponential function in the interval $[-2,0]$ has the desired properties and hence, compute $c$ using Equation (7).

Finally, to allow the user to configure the urgency of a transaction, we define an urgency parameter $\mathcal{U}$, which we use to scale the obtained coefficient $c$ to arrive at a recommended gas price $\mathcal{G}$ given by

Up to here, we have described how we recommend a price at a given block number. However, to understand how optimal a gas price is, we need to measure the difference between the recommended and the optimal gas price.

To evaluate the efficiency of our approach, we iterate over a range of blocks, where we do the following. For each block, a new transaction using the recommended gas price is added to a set of pending transactions. Each transaction in the pending set is processed upon encountering a block with a minimum gas price lower than that specified in the transaction. We keep track of the recommended price, the inclusion price, i.e. the minimum gas price of the block where the transaction is included, and the number of blocks elapsed until inclusion. We show the detailed steps in Algorithm 1. The EvaluateRecommender function takes a start block, an end block and a recommendation function to evaluate. LastBlock is the number of the last block which we evaluate and GetMinimumPrice returns the minimum gas price for a given block.

To be able to evaluate the efficiency of our algorithm, we use the Geth gas price recommendation algorithm as the main baseline, as it is by far the most widely used Ethereum client [10].

All models are implemented in Python, using the PyToch library [24]. We train all models on a personal computer with 32GB of RAM, an $8^{th}$ generation Intel Core i7-8700 with 3.20GHz and 6 cores and a 256GB SATA hard drive. Model training and hyper parameter tuning is performed on the data between 10 November, 2019 to 20 November, 2019, where we use the first 70% of the data for training and the remaining 30% for validation. We show exemplary predictions of our model in Figure 4.

We use a sample of around five days of data — from 20 November, 2019 (block 8,965,759) to November 24, 2019 (block 8,995,344) — and evaluate the different price recommendation strategies using the procedure presented in Algorithm 1.

We first describe the parameters of each strategy in Table 3. For Geth we use a scaling ratio parameter $\mathcal{S}$ with which the recommended gas price is multiplied. The main purpose of this parameter is to ensure that giving a lower gas price does have a direct impact on the number of blocks waited. Our proposed recommendation strategy accepts a single parameter $\mathcal{U}$ representing the urgency. The urgency parameter is used to trade off gas price for waiting time: the lower the urgency, the lower the gas price and hence, the longer the waiting time. Empirically, reasonable values for these parameters are roughly between $0.7$ and $1.3$, where $0.7$ will result in cheap but long to be accepted transactions and $1.3$ will result in more expensive but faster transactions. Finally, our look-ahead model, which we use to estimate the lowest possible price takes a parameter $\mathcal{B}$ representing the maximum look-ahead as a number of blocks. We note that the look-ahead strategy is for validation purposes only as it uses information about future blocks, which would obviously not be available in practice.

We present a summary of the results for the different recommendation strategies in Table 4. We use several values for the parameters of each strategy and order its results so that the gas price decreases and the number of blocks to wait increases. We can see that using the price recommended by Geth, the waiting time is very short — on average less than 2 blocks — with an average gas price of around 4.4 Gwei. However, by just using 90% of the recommended price, the waiting time increases to an average of 15.5 blocks. Comparing these results to the minimum possible gas price, obtained from the look-ahead model, we can see that by only waiting for an average of 4.8 blocks a saving of 75% could be obtained. Although these numbers are hypothetical, they suggest the potential for significant improvement.

We now show how our model performs in comparison to the price recommended by Geth and the hypothetical minimum price. With the urgency parameter set to $1.0$, our model recommends a gas price on average twice as low as the Geth price, while waiting for an average of approximately 3.3 blocks. When decreasing the urgency parameter, we can see that the number of blocks elapsed increases fairly slowly at first but doubles between 0.8 and 0.7, showing that at this point the gas price becomes too low for the transaction to be included in a timely manner. In Figure 5, we show the effect of our urgency parameter on the average gas price paid and the average number of blocks elapsed until the transaction is included.

The overconsumption of gas can be harmful for the contract user for two main reasons: higher monetary costs and potential vulnerabilities. Gas overconsumption is examined by Chen et al. [5], who focus on gas usage optimization by introducing Gasper, a tool leveraging symbolic execution for detecting costly patterns in the bytecode of smart contracts which are not optimized by the Solidity compiler. Potential issues in the form of gas-related vulnerabilities are carefully examined by Grech et al. [15], who propose a static analysis tool, called MadMax, predominantly suitable for detecting out-of-gas exceptions which may cause contract funds being locked. Elvira et al. [2] present Gastap, a static analysis tool for inferring gas upper bounds for smart contracts and are thereby able to detect whether any out-of-gas vulnerabilities could exist. A further approach for computing gas consumption upper bounds was introduced by Marescotti et al. [19], however, the authors are yet to implement and test their algorithms in an EVM setting. For a more general summary of existing smart contract verification tools we point the reader to [16].

There have been several pieces of work focusing on imperfections in the current gas cost mechanism. Both Yang et al. [27] and Perez and Livshits [21] identify inconsistencies in the pricing of EVM instructions in the current gas cost model. The latter propose a new type of attack aimed at exploiting EVM design flaws by generating resource exhaustive contracts, which are on average significantly slower in terms of throughput than typical contracts. As a means of preventing Denial-of-Service attacks stemming from under-priced EVM instructions a modification of the current gas cost mechanism has been proposed by [6].

While several pieces of existing work examine the current gas cost mechanism, limited work exists on gas price recommendation. Pierro et al. [22] investigate potential factors that influence transaction fees in Ethereum from a technical and economic perspective, yet leave a gas price prediction model for future research.

In the following, we examine existing approaches for gas price recommendation that are used in practice.