Ethereum users are now consuming more than 40 billion gas on a typical day. When gas prices are high, they can collectively spend more than $3.5 million per day to satisfy this demand. Wallets play a key role in determining how much users pay for gas and how quickly their transactions get mined based on the methods they use for setting default gas prices. Ideally, Ethereum wallets should be able to select a default gas price that is the minimum required price to get a confirmation within the time interval desired by the user.

There are two basic approaches to estimating default gas prices and each has their own strengths and weaknesses:

Methods that rely on the gas prices of recently mined transactions: By looking at the minimum gas price of transactions included in recent blocks, you can get an estimate both of miner gas price policies and also, indirectly, the distribution of gas prices in the pending txpool. Empiric analysis shows that, under current network conditions, taking the taking the minimum gas price accepted in ~60% of the last 200 blocks gives a very solid estimate of a gas price that will lead to a prompt confirmation. These numbers are not fixed: you can lower the required percent of blocks to get a gas price that will still likely be accepted but with a longer wait. Also, you don’t need to use a 200 block interval: shortening this interval should make the gas price selection more sensitive to changes in the state of the txpool but also could lead to periods of significant over- or underestimation of the gas price needed for a prompt confirmation. The main advantage of this general approach is that it is fairly simple to code and can be implemented in a fully decentralized way by anyone running a full node (and in fact variants of this method are now being incorporated into geth and metamask). Furthermore, it can provide default gas price estimates that adjust reasonably quickly with the state of the network and are fairly reliable overall. Methods that rely on the gas prices of recently mined and unmined transactions: A comprehensive view of the pending transaction pool, with visibility into both the gas prices that are being mined and which ones are being left behind should in theory improve the ability to define a default gas price. Whereas when looking only at mined transactions, you cannot distinguish between low gas price transactions that have been waiting for many hours in the txpool vs ones that have been waiting only for a few minutes. In fact, by having visibility into both the mined and the unmined transactions, it may be possible to fine tune gas price estimates in line with short-term fluctuations in network demand as it is possible distinguish variance in miner gas policies and user-selected gas prices from true changes in network demand. The downside of this method, however, is that it depends on the much higher overhead of monitoring the txpool. Essentially, it requires a centralized gas price oracle. Unless such an oracle was clearly providing value over variants of decentralized methods, it may not be worth the effort.

In order to assess whether it would be worth running a centralized gas price oracle, I made some changes to the core gas price estimation logic used at ethgasstation. Whereas in the past, the estimates were primarily derived from recently mined gas prices, I altered the estimates based on the following simple logic:

look at submitted transactions between 8–50 blocks in the past (about 3–10 min in the past). See if they were mined or still in the txpool. Find the gas price at which nearly all submitted transactions were mined. This would be the ‘standard price’.

Do the same to determine the safelow price with the difference the sampling of transactions was from 50–120 blocks in the past (about 10–30 minutes in the past).

If there were not enough transactions make these determinations, default back to the mined gas price method.

In order to compare the accuracy of this new estimation method , I recorded the standard and safelow gas prices as estimated by the old and the new method at each block. This allowed me to identify transactions that were submitted at the prices recommended by each of the two methods and compare their confirmation times.

Before I describe the results, I need to caveat that with the current set up at ethgasstation, which involves a single geth node, it cannot come anywhere close to recording all transactions posted to the node at the current levels of use. Therefore, it has to rely on random sampling of submitted transactions. This is ok, but decreases the potential accuracy that could be achieved if a complete picture of the txpool was obtained. Therefore, the current test compares a ‘decentralized type’ of gas price oracle (that I am not certain can be optimized much more) to centralized gas price oracle (that has what I believe to be a lot of room for optimization).

Here are are the validation results —( Note the data for this comparison was collected concurrently for each method during random intervals between Jan14-Jan24 2018 when blocks were mostly full and gas prices were higher than they are now. The ‘decentralized’ SafeLow gas price is the minimum gasprice accepted by 35% of the last 200 blocks and the ‘decentralized’ standard gas price was the minimum accepted by 60% of the last 200 blocks).

So this data clearly favored the centralized, txpool analysis method. Not only could a lower safelow gas price be selected (by 2 gwei on average), but also the confirmation time could be reduced meaningfully and the risk of really long delays was smaller.

Similar results were seen with validation of the standard gas price estimates as shown below:

Here what you see is a larger savings in the gas price (8 gwei lower on average) with no increase in confirmation time (and in fact appears to still have the lower risk of a long delay in confirmation).

These results should not come as a big surprise: a gas price oracle using the high overhead of txpool analysis can generate default gas price estimates that appear at least moderately more efficient and optimal for users than default estimates that come from a simpler method that can be done in a decentralized way.

Nevertheless, these results suggest that there is a potential need for centralized gas price oracles such as ethgasstation going forward — because users ultimately will demand and benefit from the best gas price estimates possible, and the risk of using a centralized gas price oracle is typically fairly low.

In my next post, I will describe some ways that ethgastation.info might be able to function going forward as a centralized gas price oracle in a sustainable way (and no, don’t worry, there will not be an ICO :).