I think the problem with fixed fees in this context is basically as stated: you’re going to have to keep “fixing” them as the underlying economics change or pricing will be completely out of whack. I wouldn’t try to engineer rigid stability in pricing. But I do think the economic forces could be modified slightly in a couple of ways to produce more favorable results for both the miners and those utilizing the EVM.
The blockchain users setting gas prices, and the miners choosing which gas offers to include in their blocks is a very efficient ruleset to manage supply and demand equilibrium. On the surface, it achieves the maximum value for including data on the blockchain while allowing for fluctuation in the price of Ether. More demand for space and processing on the EVM translates to higher prices for providing it. Space on the chain is basically always valued at what it is worth.
But there are several factors that create an inefficiency in the market forces between miners and transaction prices, because it assumes equal knowledge, visibility, and understanding of the EVM to create a
First, Ethereum has a problem from Econ 101: There’s a Diamond-Water paradox. Diamonds are basically useless (don’t tell my girlfriend), and water is essential for survival. But diamonds cost more, because they are rare. However, if water became rare, it would be infinitely more valuable than a diamond, even if there was only one diamond left on earth.
In Ethereum’s context, getting a transaction included in the next block is the diamond. Getting a transaction processed eventually, is the water, and a sustained large transaction pool makes it scarce. When the transaction pool is manageable, and there is reasonable confidence that a transaction will get processed at a lower gas price, eventually, even if it takes a while, then users will feel fine setting lower bids if they have confidence their transaction will get there eventually.
But a sustained transaction pool backlog with only gas prices above X ever getting through creates the potential for stuck transactions that may never be included in the EVM. While it is possible to overwrite a pending transaction with a higher gas price if it gets stuck, it’s not exactly the most user-friendly thing to do (or common knowledge). That “fear” of losing a transaction because of the gas price creates a soft advantage for miners that I could argue is an imbalance to finding efficient market equilibrium for gas prices. There is also a “visibility” advantage for miners that creates an imbalance: Miners can see the transaction pool and choose the best prices for inclusion into their blocks. Users can (technically) see the pool as well, but a retail user doesn’t really have the tools or know-how to do a probability analysis on the probability of their transaction processing within a given period… so, most probably take the average gas price and add a little to it.
The more users that do that from pure lack of visibility, the more gas prices will rise above a true equilibrium where both sides of the market have transparent access and usability to its economics. That dynamic methodically creates a “new normal” price floor for gas that consistently increases as people accept it. That also gradually moves Ether from something to transact immutable applications with into a pure store of value, and in my opinion, deteriorates the EVM value-proposition with each sustained increase in gas pricing (e.g. it might be worth $0.50 to pay the network to process a transaction between a taxi driver and a passenger for an $8-dollar ride from A to B to skip the 20% markup from the middleman. But if that’s going to cost $8 + $8 in gas + some time to hang out in the car while that transaction is mined, put in a block, and confirmed… then the “blockchain puts Uber out of a job and lets the taxi drivers work with the customer directly” value proposition pretty much breaks.
I think that the basic dynamics of how the gas mechanism works with the EVM is “theoretically” an almost-optimal ruleset for pricing the EVM’s finite resources over time, and it would be really good if we could assume that both users and miners have equal technical expertise, visibility into the transaction pools, and the same depth of understanding of the protocol. But I think it is more “perfect on paper” and less “perfect in practice.” Because right now, miners can programmatically determine which transactions to include ranked by highest value, while users are making their bids for transactions with limited information and usually by hand.
To improve the market dynamics without making authoritative changes and opinions to the protocol related to price, I think there’s a few things that could be done to help softly encourage better gas pricing behavior.
The obvious ones are already being worked on: increasing transaction bandwidth and decreasing storage costs (i.e. sharding, POS, state channels, plasma). Any/all of those increase the “supply” of “processing power” and “storage” on the blockchain, which makes the resource less constrained. More capacity means transactions can be included in a reasonable amount of time with a lower cost.
But, the concept of “setting your own transaction fee” is kind of a very knew paradigm for users coming to blockchains from the old world. As mentioned previous, I would theorize that the learning curve and fear associated with it is contributing to inefficiency in gas pricing for EVM resources that is nor reflective of efficient market pricing.
A non-protocol-changing path to help improve efficiency is to encourage wallets to make some improvements to their transaction functionality and support gas bidding and cost-savings as a primary feature set.
Most wallets provide a suggested value for gas prices, but they are generally very vanilla. Web3 initiated transactions usually rely on the DApp to provide both the limit and cost, often static.
For wallets:
Provide probable transaction times for a given gas amount relative the pool and recent history would help. Wallets will sometimes suggest a good gas price to get the transaction included, but for a user, it would be useful to know that 20 Gwei will most likely get it in with in 2 hours, 40 Gwei in 20 minutes, 1 Gwei might never be included, etc… so they can value the time appropriately.
Wallet providers could create a pool of transactions as a pre-pool that contributes transactions to the pool when the pool is low, or gas rates fall below a threshold, and allow transactions to be cancelled on their end if they haven’t been broadcasted yet without requiring on an overwriting transaction (and gas) to nullify a previous transaction.
Basically, increasing visibility and bidding utility for retail EVM users at the wallet and user experience level could definitely help gas prices find smoother equilibriums.
At the protocol level (time-delayed gas increases):
I think adding a time vector would even the playing field as well, and allow for more efficient market gas price negotiations.
For example, adding an additional variable that can modify the gas price relative to blocks mined passed the transaction broadcast block could help efficiency in gas pricing.
For example, a user could sign a transaction with:
(gasPrice: 10, gasGrow: [gasIncr,blockAmount,blockNum])
Which can be interpreted by the protocol as authorization to increase the gas price over time as blocks are mined. Where “gasIncr” = Gwei/gas to add, “blockAmount” = the number of blocks to add it after, and “blockNum” = the block that starts the increasing gas amount.
So, as a transaction requester, I could send a transaction saying something like “I’m willing to pay 10 Gwei for gas, but I’m willing to increase that bid by 1 Gwei for every 10 blocks that my transaction is not included passed the current block number).
As blocks are mined, that transaction becomes more valuable to a miner and more likely to be included. But if the network has a low period, the transaction will be processed to fill blocks.
This allows for a user to send a transaction through with the knowledge that it will eventually be included, without worrying about whether it will never be included and requiring an overwrite transaction. I believe this would encourage lower gas bids uniformly and make the pool smoother by more efficiently recognizing “time” as a variable in the gas market dynamic.
At the protocol level (Block Locking Transaction Validity):
Another augmentation to the transaction data similar to the above would be to allow the transaction to invalidate itself at a block height in the future.
Allow a broadcaster to sign a transaction “I want to send X to Y” but “Only if it’s done before block Number Z.
If Block Number > Z, the transaction can’t be included in a block and is expunged from the pending pool. Which effectively poisons the transaction if it takes too long.
A mining pool may choose to prioritize soon-to-expire transactions in the pool if its known that future blocks may not be filled.
At the protocol level (3rd party Gas Attachments to Transactions):
This may be on the roadmap or an EIP but allowing a 3rd party (e.g. a wallet service) to set and pay for gas on a transaction would open the door to allowing wallet providers to use their nodes on behalf of users to even the playing the field with the miners. This could open some more wallet business models and allow a wallet node to “mass negotiate” with gas prices instead of passing user-chosen prices along and inflating the price.
At the protocol level (Swim Lanes for Gas Bids):
This is basically an authoritative change to the protocol that creates an opinion on gas pricing to ensure transactions will eventually be processed without necessarily required fixed pricing.
The idea would be to require each block to contain a % of gas cost in transactions below a Gas-Price threshold to create a fast lane and slow lane.
So, for example, in order for a block to be valid, it must contain at least 20% of the block’s gas limit with transactions priced at 1 Gwei.
This would basically make the pending pool into two pools: 1.) Transactions that are bidding for inclusion as quickly as possible, 2.) Transactions that don’t care when they are added, but care that they ARE added eventually.
This is not elegant and would need more thought, because there may not be enough transactions that low, it creates more overhead in validation, etc. But the basic idea is to get to a point where ANY transaction will EVENTUALLY be included to solve the Diamond/Water problem.
At the protocol level (Network Gas Payments with Respect to Time):
Similar to allowing transactions to increase gas bids over time, the protocol itself could augment gas prices to make them more attractive to miners by adding gas to transactions as they age. This could easily be abused, but again could help prices find and stabilize toward equilibrium if a user can opt to pay a small amount to know their transaction will be included, and further know they won’t have to pay more as the protocol will account for the cost in time, over time.
At the protocol level (Using Broader “Bands” for Gas bids):
This is similar to Swim Lanes, and may sound counter-intuitive, but removing flexibility in the market making aspects of the gas/miner relationships could yield more efficient pricing.
Right now, a transaction can bid whatever it wants in Gwei for a unit of gas. So, by outbidding another transaction by 1 Gwei, it can be a make or break it decision for a transaction and spell the difference between inclusion soon, inclusion eventually, and never being included. Because gas price bids can be done in any increments, it creates a natural inflationary pressure on the constrained EVM resource, which is good for miners, but not great for transaction gas prices.
By requiring “Bands” of Gas pricing, the protocol can make the choice to “bid higher” more significant. For example, instead of being able to outbid another transaction by pricing gas at 1 more Gwei, the bands could be required to use 10 Gwei increments.
This will take all the bids between 10 Gwei and 20 Gwei (11, 12, 13, 14…etc.), and force them to choose up or down.
That choice and consolidation of transactions onto bands makes it so more transactions are priced evenly, which allows them to be picked up randomly by miners at the same price level instead of stack prioritizing Gwei bids against each other and causes inflationary pressure.
It’s kind of like if we were all in line for a sandwich shop, and the sandwich shop allow us all to bid on who got their sandwich first.
The most-hungry of us will bid high. The rest of us will see each other’s bids and try to outbid each other based on how much we’re willing to spend and how hungry we are. But since we can all see each other’s bids, it can be super attractive to add just “One more $0.01” to our bid to jump ahead of the next guy in line.
If we had to choose between $10 for a sandwich, $20 for a sandwich, and $30 for a sandwich, the choice to “bid higher” has much more meaning. Those of us fine with $10 for a sandwich but would have paid a little more to get it sooner would just queue up in line for the $10 instead of raising the price. Those of us who were SUPER hungry would just opt for $20 and shorter line/pool. And the wealthy guy trying to get his sandwich so he can get into that sketchy ICO faster will opt for the $30.
But basically, the point is, that if prices can be economically banded more together, it will remove that inflation creep on gas when the bid consideration is more painful.
At the protocol level (Randomization Rewards for Block Transactions):
Last idea, and then I’m done. But another way to get some more transactions processed and help control gas price inflation is to grant some “bonuses” for transactions included in blocks that fit some criteria relative to the block. This is an extension of the protocol helping to cover low gas prices.
Something simple would be:
If the first 30 transactions in the block can be filled with transactions at GWei price equal to their transaction number, the protocol will price them at all 40 Gwei.
Or:
The protocol will double the gas price on transactions included that have transaction hashes that end in the same value as the previous block hash.
Many ways to do it, but what this could do is make break apart the pure GAS/Mine market into a dynamic where higher gas bids increase the probability of the transaction being included sooner, but there are factors that would bring a low price in sooner, and as all of the above suggestions, would guarantee that any transaction could and will eventually make it in over time.
