Transaction Fee Estimations: How To Save On Gas?
Today, Upvest is excited to launch two new API endpoints — to estimate the transaction fee for Ethereum and transaction fee for Bitcoin.
Transactions executed on the blockchain usually have fees associated with them. The transaction fee provided by the sender determines how fast a given transaction gets processed, legitimated, and confirmed. Therefore, it becomes essential to know how much to pay and understand what confirmation speeds (or times) the varying fee costs are going to get you. In this post, we will describe in detail why we built an API endpoint (currently in Beta) to estimate such transaction fees and how it helps you save on total fee costs.
Transaction Fee Basics
Users and developers of products built on blockchains frequently come across the terms Transaction Fees, Gas, Gas Price, and Gas Limit. Feel free to jump ahead to the next section if you already know what this is.
For those who are new to this, let’s cover the fee basics for both blockchains. Ethereum and Bitcoin implement the Proof-of-Work algorithm in which “ Miners,” i.e., blockchain validators, make use of unique algorithms that require significant amounts of computational effort to solve a cryptographic “problem.” Finding a successful solution to this problem validates a set of transactions and includes them into a cryptographically verifiable block. Essentially, Miners race to find the “golden Nonce,” a numerical value that validates a given block. The successful Miner gets compensated for the costs of electricity and computational hardware for solving this puzzle (the “Proof-Of-Work”). This reward for mining a successful block is called block reward. It is made up of two components a static block subsidy and a dynamic transaction fee, both usually paid for in the blockchain’s native currency, i.e., Ether or Bitcoin. Block subsidy is usually provided by newly minting a fixed amount of blockchain native currency that goes directly to the Miner and the transaction fee, provided by the sender.
In the process of building blocks of validated transactions, many competing “forks” form, and exist in parallel at any given time. So, the network continuously determines the main branch on the chain of blocks or the “canonical chain”. An attacker can secretly construct a longer branch sequence and publish it as the canonical chain, by using more than 50% of the network’s computing power (51% attack). This attack becomes more expensive with an increase in the number blocks the attacker wants to overwrite. A 51% attack could affect the network at any time, so transactions are only considered to be confirmed when the blockchain has grown by a certain number of blocks, called the Confirmation Level. On achieving a Confirmation Level of N (N is variable for different blockchains), the mined transaction is considered confirmed. For confirmed transactions found in a given block, both the block subsidy and the transaction fee goes to the successful Miner (or a mining pool). The longer the canonical chain is, after the block that the transaction is in, the higher is the confidence in the transaction’s immutability.
In addition, in the case of Ethereum, the Ethereum Virtual Machine (EVM) allows for the execution of smart contract bytecode. Execution of this code could lead to a change of state of the blockchain. A change of state to Ethereum is also transmitted and recorded globally throughout the distributed network. During this entire process, it cannot be known in advance if a computation would end in a fixed amount of time or may presumably, go on forever. This is a well-known problem, aptly named the Turing halting problem. A way to confront this challenge, in Ethereum, is by introducing a cost per unit step of the computation. In general, the more the bytecode to process, the higher the transaction fee. Thus, the total transaction fee is the Gas consumed (in the computational steps) multiplied by the Gas Price.
Now, the end-users (or developers on their behalf) submitting these transactions or calling smart contract functions to make a change of state on the blockchain, need to compensate the Miners in the form of some valuable currency. In the case of Ethereum (ETH) and Bitcoin (BTC), the smallest unit of cryptocurrencies for both chains — Wei (10¹⁸- ETH) and Satoshis (10-⁸ BTC), is the currency used to cover the transaction fees. In the Bitcoin parlance, the fee for transactions is calculated in Satoshis per virtual byte (vbyte) of transaction data. This resource provides a time-series plot of the transaction fee essentials for Bitcoin. In Ethereum, things get a bit more nuanced, documented well in this guide. Here’s a summary of the fee essentials for Ethereum:
- Gas Price is the price a user is willing to pay per unit of Gas for the work done in Gwei. (1 GWei is 10–⁹ ETH)
- Gas Limit is the maximum amount of Gas you’re willing to pay for the submitted transaction to be mined.
- Transaction fee = Gas consumed (in the computational steps) x Gas Price
- If Transaction fee <= Gas Limit x Gas Price, the transaction executes and gets mined into a block, the state of the blockchain updates.
- If Transaction fee > Gas Limit x Gas Price, the transaction is reverted, the Gas consumed from executing EVM bytecode still goes to the Miner for the computations performed, but the state of Ethereum is not modified.
- As transactions can have varying payloads, varying transactions require varying amounts of Gas. Everyday transactions, such as an Ether transfer, have a fixed amount of Gas needed to be processed (i.e., 21,000).
- Block Gas Limit is the maximum Gas allowed in a block (i.e., a maximum amount of computational effort required to process all of the transactions being included within that block). Hence each block has a theoretical maximum number of transactions that it can contain.
- Etherscan.io provides a time series plot of the different essentials.
Transaction Confirmation Times & Gas Fee Spikes
A Gas Fee market results from the demand created by transaction senders and the supply for mining them, determined by the Miners. Both Ethereum and Bitcoin impose a limit on the amount of computation done per block with a Block Gas Limit. The amount of time each block approximately takes to be constructed and mined is also fixed, called the Block Time. Given that any transaction has a minimum Gas consumption and all blocks a Block Gas Limit, there is a theoretical limit on the total number of Ethereum / Bitcoin transactions mined in a day. Conclusively, both blockchains have a transaction throughput or a maximum number of transactions per second (approximately 31 transactions per second (tps) at the time of writing for Ethereum).
The proportion of supply and demand determines the “cost” of a transaction or the “cost” of Gas (Gas Price in Ethereum) at any given time. Therefore, if demand-side chooses to get their transactions included in a block sooner, then they need to pay a higher price for their transactions per unit of Gas. In the case of an increase in network activity, the demand for transactions increases; this can lead to a spike in transaction fees. Businesses that often transact on the blockchain or employ smart contracts on a day-to-day basis to automate business logic suddenly find that the transactions they were paying a specific fee for would not get mined unless they were to pay up to ten times as much as before. If the transaction senders are not aware of the fee spike, it often leads to their transactions taking much longer than expected to get mined. In certain circumstances, where the transaction fee remains high, these (relatively) low-fee pending transactions may even get dropped entirely off by the network. If end-users start seeing failed transactions, they get discouraged from executing further transactions, leading to a drop in revenue generating activity on the blockchain for these businesses and also negatively affecting marketplace liquidity.
An example — when a large number of users interact with smart contracts associated with a popular decentralized application (DApp), Miners start choosing the transactions that offer higher Gas Price and Gas Limit and other parameters they consider important for their mining strategies. In October 2017, the Cryptokitties DApp caused network congestion, which resulted in a crazy spike, where the average Gas Price went from 5 GWei before the game was released on the mainnet to a value of 50 GWei right afterward. In certain cases, the transaction fees got even higher than the perceived value of the game’s collectible itself.
To overcome such issues, a model that provides fee estimates for various blockchains should consider their network congestions. It should proportionally raise the recommended Gas Price to an optimal economical value to get the transaction mined in the required amount of time.
An Adaptive Fee API
Upvest is excited to release its Transaction Fee API endpoints that model the transaction fee spikes in real-time while making sure that they do not result in unreasonably high estimations. Fee spikes, occurring as a result of circumstances similar to the one mentioned above, are normalized by a proprietary smoothing algorithm. The model calculates the appropriate fee by utilizing data from different public sources for both Bitcoin and Ethereum. It then computes a weighted average from the collected values. The weights on each source may differ depending on its capacity to represent the network’s congestion conditions. The endpoints provide the transaction fee estimates (in blockchain native currencies) in real-time for variable transaction confirmation times (or block times):
Transaction Fee for Ethereum,
- Fastest: below 30 seconds (next block)
- Fast: below 2 minutes (<10 blocks)
- Medium: around 5 minutes (<20 blocks)
- Slow: around 30 minutes a.k.a safe-low (<120 blocks)
Transaction Fee for Bitcoin,
- Fast: around or below 15 minutes (within 1–2 blocks)
- Medium: around 30 minutes (within 3–4 blocks)
- Slow: above 1 hour but below 2 hours (>5 blocks)
The fastest prediction for Ethereum should not be used in most cases unless a transaction is to be urgently included in the next block. The Gas Price is higher than the market average for fastest, to cover for this particular case. A descriptive example for estimating fees for Ether and ERC-20 token transfers can be found here. Try out the API for Ethereum Fees here. A sample of the returned values in Gwei is here:
Calculating fees for Bitcoin transactions involves including the number of transaction inputs (UTXO) and outputs, the number of bytes they represent, and the cost-per-byte. Try out the API for Bitcoin Fees here. A sample of the returned values in Satoshis/vbyte is here:
These endpoints can easily handle thousands of requests per second. They are also adaptive (self-healing) such that the endpoints provide accurate estimates even with the degradation of one or more sources. If a data source becomes unavailable, the estimation algorithm ignores the data source by expunging it from the database. In the case of significant network spikes or if some of the sources fail, the Fees API algorithm will still provide reliable estimates. At the time of writing, there are few fee estimation endpoints with these production-ready features. So, we’re super excited to invite you to try them out (in Beta)! Here’s a time series plot depicting fee estimation data for both endpoints:
An Advanced Fee Prediction API
Upvest plans to adapt the current algorithm and use it as a source to develop a more intricate machine learning model to predict fees based on historical transaction data and pending transactions. As we develop the algorithm, we can also extend it to other protocols, provided there are public data sources and historical data availability.
Do you have unique ideas on estimating transaction fees or want to know how a fee estimation API can help your business? DM our Engineering Lead at Upvest, Paulius Uza (upheaver#5049) on Discord, and if you would like to know more, browse our documentation and start experimenting with the Upvest Fees API here!
Any other questions? Please send us a tweet, or join our Discord channel to engage with the Upvest developer community. Keep up-to-date with Upvest developments here.
Originally published at https://upvest.co.
