First and second-price auctions and improved transaction-fee markets

Economics
,
8

if 0.02 is less or much or 1.00 is cheap or expensive depends mostly on if you live in Zug or Mumbai. So per definition a global fee structure/mechanism/auction is putting people in castes, and favourishing richer regions to have faster transactions, while poor regions have to wait, pray and hope.

The only solution I see - besides a global communism with all people with the same (basic) income - is that certain regions of the world can operate their own “regional” chains with fees that fit into the monetary possibilities of their people.

9

Not sure I agree this is better on the philosophical level. Looking forward, on a full PoS blockchain, we can let fees be the only source of income for validators (pay to play). At this point, the security of the network is dependent on these fees (more fees - more incentive to act as a validator, harder to mount an attack), so the goal is to keep validator expanses low (no PoW) but fees reasonable. With sharding, the bandwidth also depends on it, as more validators can enable more shards. Minimizing the fees does not support these goals, specifically, users willing to pay higher fees will save money at the expense of lower bandwidth, preventing low-fee transactions from being processed.

Current software already informs of reasonable prices for timely execution. To prevent excess fees, software solutions showing actual ETH/USD prices and warning against unreasonable fees are needed (and to some extent exist). At most, we can limit the maximal fee to the 80th percentile (i.e. cut the top), but I’m not sure even that is needed.

10

Disagree! The min fee concept ensures that most of the time, blocks are 50% full (or at least, less than 100% full), which ensures that paying one particular fee gives you a very high chance of getting in, and there’s no need to consider lower or higher fees.

I agree that your other approach is also an improvement; that said, I think it’s less effective because it forces people to wait longer to get the fee that they want.

I suppose theoretically, a basic income fund that pays enough to make sure everyone has enough for a few transaction fees shouldn’t be that hard…

Practically speaking though, the goal with sharding, plasma, channels, etc is to make txfees low enough that anyone can afford to participate in at least some applications on the blockchain. You could have regional plasma chains I suppose.

11

definitively not from a technical point of view. The question is how is it meant and what it means for certain people?
Theoretically, If it’s a “real” basic income - in the meaning “enough to eat, stay healthy and buy the basic goods” - then we’re talking about a very fundamental thing and revolution, not just a blockchain and it’s tx fees… theoretically.
If it’s meant as a basic TX funding, automatically distributing a couple of gas units per day to “everyone” (identity who?) in order to pay - let’s say - 5 basic tx per day for free, it looks to me like every general rent subsidy: rental prices grow exactly by that amount.

So - practically - first it would need a move from “work” to something else like “stake” which in principle needs less energy. Then - not having that costs and ROI-goals at miners side anymore - it would need some game-theory rules implemented in the protocol to enforce/motivate minters to process also a certain amount of lower fees (staking allows way smarter incentives then rude raw hash rates).
So instead of giving a basic income to pay TX it should be possible to shorten this path and implement a basic LowCost TX per day per account.
A rich/whale could simply don’t care and continue with his usual TX fees. Or he could use one LC-TX-fee per day to split up his 1000 ETH into 1000 accounts. Then after around 10 days (2^10) he could use 1000 LC-TX per day (for example to to buy low-cost goods or day-trades which wouldn’t make sense because a few normal TX fees would be cheaper and easier to handle for his new Rolex, Lambo and Cote d’Azur holiday), while the normal-Joe owning one ETH can think about using his one LC-TX each day on supermarket, or if he want to split it up into blocks of 500 to 100 Finney’s. The lower limit would be a certain ratio to whatever level a LC-TX fee is defined (“0.02, 0.03, 0.05, 0.08, 0.13, 0.19, 1.00”) and also at what currency it’s bound. You used $ in the above example which - beside different wealth levels around the globe - is another factor that can change significantly over time for certain groups of people.

Remember: I put these ideas just on the table and I’m not sure if they were already discussed or if they bring significant drawbacks on other sides. By taking 1-2 steps back and looking at the whole story I see solutions by either finding a very small and tricky path between general low-cost TX-fees and ledger-stability, or by giving different regions the chance to run their regional infrastructure at an appropriate cost level.

12

As a user, I can already do this by targeting a price that would have gotten into the last n blocks plus some. So if the lowest 50th percentile (gas price per gas in block) for the last n blocks was 50 nanoeth, I can simply pay 50 nanoeth and am just as “guaranteed” to get into the next block as I would be in your system. The difference is that in your proposal I cannot choose 49 nanoeth. The only way I would not get into the next block with such a price is if there was a sudden surge in congestion, which is the same scenario as in your proposed system.

In other words, any formula you come up with for enforcing min-price on a block such that blocks are 50% full could be implemented in each client without any consensus and allow users to still create transactions that are “lazy”.

I think what we are seeing is that people are cheap, but then they get surprised when their cheapness causes their transactions to sit pending for a long time. Making it so users cannot be cheap just takes away their ability to express their preference for “lazily mined” transactions.

13

As a user, I can already do this by targeting a price that would have gotten into the last n blocks plus some. So if the lowest 50th percentile (gas price per gas in block) for the last n blocks was 50 nanoeth, I can simply pay 50 nanoeth and am just as “guaranteed” to get into the next block as I would be in your system.

That’s really not how it works. Gas prices can adjust suddenly, there are difficulties in measuring, demand differs block by block, etc etc. First-price auctions really do put a lot of cognitive (or programming) load on users and wallets end up massively overpaying to avoid harming the user experience.

14

Lets say your proposed strategy is implemented (via consensus) and the min gas price is 10 nanoeth. Blocks are currently all 50% full, and if you pay 11 nanoeth you know that you will be over the min gas price for the next block, because the min gas price between two blocks can only change by (example numbers) 0.1 nanoeth.

In a parallel universe the proposed strategy was not implemented as part of consensus but instead the exact same logic is used by some (or perhaps all) clients to decide what gas price to recommend to users. The difference being that instead of looking to see whether the previous block was more or less than 50% full and adjusting min gas price based on that, it looks to see what gas price 50% of the gas spent in the block was at/above and compares that to its previous block gas recommendation and adjusts this block’s gas recommendation up/down by 0.1 nanoeth per block, just as the proposed strategy.

Under normal operations, when gas prices are not swinging by huge amounts between blocks, both strategies give users similar (possibly the same, but there are a few edge cases that I believe may cause the strategies to not be exactly equal) probability of getting their transaction into a block. In fact, in both cases the user is guaranteed to get into the next block unless there is a sudden increase in block contention (e.g., crowdsale start block, poorly implemented air drop, etc.).

In the case of a sudden increase in block contention, both strategies will result in the user missing the next block, despite using a gas price that should be “plenty” to get into a block. Over the next n blocks, the min_gas_price/suggested_gas_price will increase until such time as it reaches a point where it represents reality and the user can use it to get into the block.

The advantage of the latter strategy IMO is that it isn’t calcified in the consensus protocol and different clients can tune it to react faster/slower to gas price bursts, use different algorithms for calculating the 50% mark, change the block fullness target, etc.

The other advantage of the latter strategy is that it allows users to lowball gas prices and get in “next time there is a block that isn’t full”. With the min gas price strategy, if the next block isn’t full (or rather, isn’t 50% full) then the min price decreases slightly but the user with the lowball gas price will not get included. They will have to wait until the min-gas-price decreases all the way to their target, which could take a long time depending on how much they lowballed.

15

Here is a reading of the 90th percentile (ie. 10th from the bottom) of gasprice in gwei in a span of 100 blocks (5500000…5500099):

[1, 1, 2, 1, 1, 1, 1, 1, 20, 1, 1, 4, 1, 1, 1, 50, 1, 4, 1, 5,
 0, 1, 1, 1, 1, 1, 1, 1, 0, 2.2, 1, 1, 1, 0.646, 1, 1, 1, 5, 2.2, 1,
 1, 1, 1, 1, 22, 1, 0, 4, 1, 1, 1, 1, 22, 1, 1, 1, 1, 1, 0.646, 0.646,
 1.01, 1, 4, 1, 1, 1, 0.5, 1, 1.01, 4, 1, 5, 2, 1, 1, 1, 1, 6.71, 2, 1,
 1, 5, 1, 1, 1, 1, 1, 1, 5, 20, 1, 5, 1, 1, 5.6, 1, 5, 1, 2, 1]

So it definitely is volatile. And it’s volatile because block-by-block gas usage really is volatile. What I’m suggesting would turn that block-by-block price volatility into block-by-block usage volatility, reducing costs and delays for participants at fairly little cost. Also, the median gasprice paid is ~2.8x higher over that timespan, and the average is ~4.9 times higher. So plenty of people are overpaying quite significantly.

With the min gas price strategy, if the next block isn’t full (or rather, isn’t 50% full) then the min price decreases slightly but the user with the lowball gas price will not get included. They will have to wait until the min-gas-price decreases all the way to their target, which could take a long time depending on how much they lowballed.

Not if you use the version where the user can specify “I’m ok with paying whatever the mingasprice is, up to a maximum of X, plus k%”. Then users really would be able to just fire and forget, and get a guarantee that their tx gets included as cheaply as it can be, unless the price goes above what they are willing to pay.

16

Thanks for Vitalik’s explanation for how this work today. Contributing back.

txfees

A miner bribes users who value their tx less than p1 to pay exactly p1. The miner then later refunds the users with p1 - p2. So the bribed users pay area A + B + C and refunded with A + B, and the miner is happy to earn a net revenue C from them.

17

As a related aside, earlier this year I did some poking at per-block fee auction mechanisms, to address the unpredictability/volatility problems @vbuterin mentioned. My intuition was to treat each tx fee as a “max” fee, and then charge less than that when the sender is egregiously overpaying. Eg, if a block’s tx fees are:

5 5 5 5 5 5 5 5 5 5

then it makes sense to charge them each 5 (“actual” fees):

5 5 5 5 5 5 5 5 5 5 (max) ->
5 5 5 5 5 5 5 5 5 5 (actual)

But if the specified fees are:

5 5 5 5 5 5 5 5 5 100

then you’d think the fee logic could just charge the last tx 55 (or 60, or something), rather than the specified 100:

5 5 5 5 5 5 5 5 5 100 (max) ->
5 5 5 5 5 5 5 5 5 55 (actual)

This would reduce the pain of accidentally paying way over the market rate, and thus make life easier and safer for senders.

(Note we can’t charge that last tx less than 55, because then the miner is incentivized to drop the other nine txs and just keep the 100. There are lots of little pitfalls like this…)

Anyway I wrote a bunch of code and stuff but I ended up hitting a brick wall, in the form of the spoofed txs problems Vitalik mentioned: if a tx specifies a fee of 100 and we charge it <<100, the miner is incentivized to insert other txs (to herself) with very high fees. Eg:

5 5 5 5 5 5 5 5 5 100 10000 (max) ->
5 5 5 5 5 5 5 5 5 100 9855 (actual)

Incentivizing miners to spoof txs, to induce real txs to pay higher fees (bring “actual” closer to specified “max”), seemed kinda fatal for my whole idea, alas.

18

The gas prices are also volatile because a lot of miners pay their pool participants in the own blocks they mine. The average gas price is around 60 GWEI right now, but a lot of blocks have 1 GWEI lowest transactions in them. These transactions are actually miners paying their pool participants and pay 1 GWEI to themselves for this (from the account which is mining the block). This hence gives a wrong image about the actual gas price of a block. The miners don’t even send a pending txn, they simply queue their own tx’s and then mine them when they found a block.

19

The author mentions two fundamental weaknesses. However I believe that there is a third weakness (very briefly mentioned in Example 5.5. of this paper). I think it is easier to see it from an example:

Let’s assume the bids are:

0.1, 0.1, 0.1, 0.1, 1.00

The block producer (or miner) will have the incentive to add only the top bid (1.00) and ignore the rest. Therefore there will be (common) cases where block producers will maximize their profit by ignoring transactions and emptying blocks.

How is the proposed fee market system deal with this weakness?

20

In my proposed system, no transaction affects the fee paid by other transactions, so the miner has the incentive to accept all transactions that pay more than the minimum.

21

From a miner’s perspective fee is payment for an increased uncle risk, so decreasing the total received fee must lead to reduced capacity, assuming rational miners.

For this reason the minimum fee system would increase volatility of fees and reduce throughput, as fees would have to be the same as they are currently on top off minimum fee. It’s a dynamic tax creating a deadweight loss.

Fees are volatile because high fees don’t increase the gas limit, ie. ‘high’ fees are too low relative to the block reward. The moment fees attain level high enough to buy additional block space the market would stabilize and become predictable.

The simplest solution is to reduce the block reward, which has separate security considerations.

A weird one would be to allow miners to gift a portion of their rewards to future blocks, paying future miners to not orphan them.

A hybrid PoS/PoW with PoW chain for validator selection/joins/exist and PoS for block generation would also work.

Fee as a function of time and/or block height is a very good idea, although hypothetically it could incentivize intentional orphaning. The difference is that the current way of replacing transactions hides future pricing information.

22

The gas_price_floor is a function of block_reward, network_propagation_time, and network_propagation_bandwidth. However, lately we have seen gas prices rise above the floor, and that is generally what we are trying to solve for IMO: how to deal with things when prices are above the floor (the floor remains pretty stable over time).

In theory, this system could be problematic if the min_gas_price == gas_price_floor (per function above) and then a sudden spike in congestion occurs. Because the congestion spike would increase block size in this system, the gas_price_floor should increase as well, but the min_gas_price did not. This means that people who included at the min_gas_price will be excluded from the congested block, even though there is space if the miners are behaving optimally and everything is perfectly efficient.

If min_gas_price != gas_price_floor prior to congestion, then the strategy should work as described.

Perhaps we should start by figuring out whether we care about behavior when gas prices are at or around gas_price_floor? Maybe we only really care about how the system behaves under perpetual congestion (like Bitcoin)?

23

Agree. Though note that in a PoS system increased uncle risk would be near-zero up until some (high) point, after which it would slope up rapidly.

Maybe we only really care about how the system behaves under perpetual congestion (like Bitcoin)?

I personally care primarily/only about the perpetual congestion case at this point. Three reasons:

  • It’s been the state of the ethereum network consistently for the last 6 months, and I see no signs of that changing.
  • Changes due to non-linearities in PoS as mentioned above
  • The gas price floor is indeed a function of the block reward, but with PoS we’re looking to move toward block rewards being near-zero, so the floor would be expected to drop heavily. Specifically, earlier analysis showed the gas price floor at 33 gwei, but that was in the 5 ETH days, and with a worse uncle inclusion algorithm; assuming a hypothetical 0.5 ETH reward, and today’s inclusion algorithm, the floor would be closer to 2-2.5 gwei under PoW, and much less under PoS.

It’s a dynamic tax creating a deadweight loss.

The transaction fee is there to pay for the social cost of the blockchain having to process the transaction, not just the narrow cost incurred by the miner. So it’s actually a dynamic tax offsetting a deadweight loss (note that today, we already have a cap-and-trade system offsetting the deadweight loss, in the form of the gas limit; there are reasons to believe that a tax is better).

1 Like
24

To further underscore the importance of this, some news from China:

b0e924afa171d9bc006ae5ddb266a5be
b0e924afa171d9bc006ae5ddb266a5be459×798 57.6 KB

Basically, recently there has been an exchange that, for some reason, decided to use who can spam the ethereum network the most as the decision mechanism for what coins they list. This is an ad from a self-described “geek squad” offering its expert talent in getting spam transactions included at a maximally low price with high confidence. So the fact that gas pricing under a first price auction is hard is already leading to third-party specialized intermediaries trying to alleviate the problem.

Under the proposed 50% targeting regime, what would happen is that users would be able to just send transactions that pay “the minfee, plus a little bit more, up to N gwei”, and then wait until they get included (usually within one block, as the min gas price would adjust to make sure that happens), and this would give them near-optimal results without any third parties.

1 Like
25

Something to be concerned about is that miners will have an incentive to keep the price minimum artificially low, because they will only get paid the difference between the real price and the minimum price. If more than 50% of mining pools are capable of colluding with eachother then they will be capable of lowering the price minimum to near zero by only accepting a tiny fraction of transactions. If that happens, the colluding miners will profit from the higher fees as long as the few transaction fees they accept are collectively greater than half-full blocks under the “price minimum + a few gwei” fee model

26

That’s very interesting - you’re saying that even at current fees gas limit should go up, but doesn’t? If that’s the case, the only explanation is intentional market fixing by a cartel of biggest mining pools, maximizing profitability in the long run rather than per block (ie. extracting rent).
Getting rid of the gas limit increase limit altogether would fix that, allowing smaller miners to profitably include more transactions and break the fee fixing cartel in the process.

There’s no dos risk as long as nodes verify blocks in parallel (even on single core), I think parity already does it. Ie. when two blocks at the same height appear, the one that wins (locally) is the one that gets verified faster, verification of the other one stops. So even a 1B gas block would do nothing bad to the network.

If mining is already centralized to the point of price fixing, worrying that larger blocks are going to cause centralization doesn’t make much sense to me.

This would also give miners an incentive to develop faster nodes.

The transaction fee is there to pay for the social cost

Trying to price in externalities is dangerous. Constant (even if de facto, not de jure), or more generally not organically changing gas limit is a security risk - fcoin (with very suspicious timing) provided an example.
Making the network unusable requires no mining hardware, only money.
Assuming 8M gas limit, spamming enough transactions to keep the gas price at 200 gwei costs a maximum of $4.3M/day, in reality less due to transactions made by genuine users.
What would happen with adoption after a 10 day attack? Even 2000 gwei is feasible.

What would be the social cost of that?

The minimum fee mechanism would make this attack cheaper to execute.
The only defense is to increase throughput, at 10x cost becomes infeasible, at 100x prohibitively expensive.

27

If mining is already centralized to the point of price fixing, worrying that larger blocks are going to cause centralization doesn’t make much sense to me.

The point of keeping block sizes finite is to decrease node centralization, not miner centralization. Since cheap full nodes allow contentious hardforks I think it’s important that the node cost not becomes too high, as that can depower users in favor of other players in the ecosystem.

Trying to price in externalities is dangerous.

Sure, but not trying to price in externalities is also dangerous. Some things are hard to price, but costs must ultimately be paid by someone, otherwise they’re not real costs.

In a permissionless network with a limited capacity, it will always be possible to buy out the network. We should try to make the network as predictable and stable as possible under this constraint. Bad UX is a real cost people have to pay.

1 Like