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

Economics
,
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
28

The point of keeping block sizes finite is to decrease node centralization

A normal user is going to run a light node or use a web wallet. In the context of sharding - why would random users run a node for some random shard they don’t particularly care about?

The general incentive problem with the current gas limit is that local validation is too fast to impact orphan chance. Validation time on a pruned parity node, on a normal pc, is 40-50ms for 8M gas block. Even making it 100x faster would have a very small impact.
At ~10x it would change and miners would start putting resources into making validation and propagation faster. Being able to validate a block in 50ms rather than 500ms would make a noticeable difference in the individual orphan rate.

It’s hard to quantify, but globally probably >100x more resources went into optimizing ethash computation (including asic design) rather than making nodes and network propagation faster. That’s not a good allocation of resources.

29

A normal user is going to run a light node or use a web wallet. In the context of sharding - why would random users run a node for some random shard they don’t particularly care about?

True, but the point isn’t so much to get every user to run a full node, but to keep the cost of full nodes down to the level that a dedicated person or team and set up their own node network and copy the state of the system without too much difficulty.

Take for instance, a blockchain with, say, 21 supernodes that are so huge they cost millions of dollars to setup. Under this system, forking the chain not only requires downloading the entire state from one of these supernodes (who might be colluding to prevent such things) but also large upfront capital. This gives the supernodes much more power then even a mining pool with >>51% hashrate.

That said, I think you’re idea of increasing the gas limit by 10x is interesting. After such an increase, it would still be possible to run a node at reasonable cost, (<$10,000) but it would be out of reach of most people with everyday hardware. I don’t know of any examples of such ‘inbetweener’ blockchains systems.

The problem is, people who are not pool operators are not incentivised to run a full node, and unfortunately, mining pools are so few in numbers 21 dedicated DPoS nodes would probably even be more then all mining pools with non-negligible hashrate.

If there was some way to make it so the cost for setting up a node could be medium, (~$10,000) and that there would be a few thousand of them, you could still have forks and a much lower chance of collusion, while making the chain (at least the base layer) much more usable. You would need someone other then pool operators to be incentivised to run a full node though. Instead of right now, where running full nodes is mostly done on altruism.

It’s hard to quantify, but globally probably >100x more resources went into optimizing ethash computation (including asic design) rather than making nodes and network propagation faster. That’s not a good allocation of resources.

Agree. Although, this seems more like an argument for Proof of State then increasing the gas limit.

30

No, I’m not saying that at all. I’m saying that right now gas prices are primarily constricted by the gas limit, and not marginal uncle risk. Sure, miners set the gas limit and are not increasing it, but I don’t think this is an evil cartelization poly, I think it’s them trying to account for real social costs of additional gas usage.

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.

Oh I agree that a gas policy that’s not perfectly “vertical” is optimal (eg. one could imagine a rule where 8 million gas is available for free, but then an additional 3 million gas is available at a cost of 50 gwei per gas), and our current vertical policy is making transaction spam attacks cheaper than they need to be. Notice that my proposed policy change does improve on this, at least for very short-term attacks, and can be modified to be “flexible” against longer-term attacks as well.

The minimum fee mechanism would make this attack cheaper to execute.

I don’t see why at all.

31

but I don’t think this is an evil cartelization poly, I think it’s them trying to account for real social costs of additional gas usage.

Even if not ‘evil’, it’s still a price fixing cartel.
‘Social costs’ in this context mean valuing slower increase in required storage for full nodes and time to initially sync, over cost paid by users.
4 days ago fees from 100 average transactions were enough to buy a 1TB ssd, or 2 months of a dedicated server with 1TB ssd and 16GB ram.

It’s impossible to doubtlessly prove or disprove, but I’m certain fees that high actually reduce number of full nodes ran by avid users, also by decreasing the latter.

I don’t see why at all.

With the attack goal defined as a constant effective minimum gas fee = x, drive minBlockFee[n] to x.
Then for k = 0.5, minBlockFee[n+1] = 1.25*minBlockFee[n]. This block is left empty of spam transactions.
Now minBlockFee[n+2] falls to 0.75*blockFee[n], less if others made transactions.
Fill n+2 and n+3 blocks with spam transactions using x as gas price.
Third one has minFee > x, so leave it empty again and repeat.

Empty blocks are the difference compared to the current fee algorithm, which would require the attacker to fill every block. (unless others outprice him, but that works too)

I can see the usefulness of max gas limit in early network to prevent nearly free spam, but don’t see any reason for it to exist today, it’s a huge net negative.

Ignoring uncle rates, that’s a factor of >100 compared to the current gas limit, assuming nodes on normal pc. I run a geth node and average verification time is ~110ms. Pruned parity with no old blocks is >2x faster.
Add parallel transaction verification and it goes up to ~1000x

I guess fast/warp sync protocol would need some improvements and copy state in much bigger blocks.

32

Would it still be a cartel if the gas limit was set by hard forks and not voted on by miners? As I’ve said elsewhere, I actually think that’s a good idea to move towards long term.

It’s impossible to doubtlessly prove or disprove, but I’m certain fees that high actually reduce number of full nodes ran by avid users, also by decreasing the latter.

I agree and that’s a good point; I am definitely not advocating for anything close to bitcoin-level block size restrictionism.

Empty blocks are the difference compared to the current fee algorithm, which would require the attacker to fill every block. (unless others outprice him, but that works too)

It sounds like you’re saying, in the approach I describe, an attacker would need to on average fill blocks 50% to maintain an attack, whereas in the current system an attacker would need to fill them 100%. However, I think the solution I describe should be coupled with a max gas limit increase to 16 million, so that long run usage targets ~8 million/block as before; in this case, the cost of an attack would be the same.

33

Would it still be a cartel if the gas limit was set by hard forks and not voted on by miners?

No. It’s a cartel because major miners/pools are able to not maximize profitability per block.

Minimum fee introduces potential incentive problems here, as blocks that increase the minimum fee make child blocks less valuable. If major miners/pools can keep the 8M limit, they can enforce ~0 minimum fee by orphaning blocks that go above 50%, possibly with some stealth like ‘orphan only if younger than x seconds’.

I actually think that’s a good idea to move towards long term.

Why, to keep blocks verifiable on a pc?
I guess it could be defined by dynamically coupling it to power of one cpu via a specially designed pow function, as server ones aren’t and almost certainly aren’t going to be faster due to emphasis on stability.

In any case as long as pow is used for consensus, verifiability by pcs isn’t going to be a problem, exponential distribution of block times is enough to enforce that.

However, I think the solution I describe should be coupled with a max gas limit increase to 16 million

As a hard limit or as a recommended default?

34

In any case as long as pow is used for consensus, verifiability by pcs isn’t going to be a problem, exponential distribution of block times is enough to enforce that.

That’s dangerous; relying solely on uncle risk to restrict block times could lead to a scenario where the pools with the best connectivity and hardware can seamlessly broadcast blocks between each other, and everyone else falls behind. Even in an egalitarian scenario, it would lead to inevitable very high stale rate, selfish mining risk, etc.

35

the pools with the best connectivity and hardware can seamlessly broadcast blocks between each other, and everyone else falls behind

That’s already possible, three biggest pools control 59.5637% between them. Five biggest 82.42%. Instead what they’re doing is limiting gas to 8M.

If you’re really worried about verifiability by non-miners add a hard limit like 10M gas per 1 second since last block, while removing max gas limit. Per second rather than per block would allow even slow nodes to catch up in few seconds at most. It would also automatically relieve congestion, as blocks after a long delay would be bigger.

This would give some breathing room before other scaling solutions and make spam attack much more costly.

selfish mining risk, etc.

There’s no selfish mining risk on ethereum. The attack assumes one big attacker with the rest of the network comprised of many small miners, too many and too small to cooperate.
If the biggest pool attempts a selfish mining attack the other big ones are going to cooperate against it fast and that’s going to be it.
The biggest pool owners probably all sit on one irc channel, or telegram I guess, where they decide things like changing the gas limit.

Screenshot_2018-07-11%20Ethereum%20Top%20Miner%20Stats
Screenshot_2018-07-11%20Ethereum%20Top%20Miner%20Stats1140×400 33.1 KB

1 Like
36

If this is the goal, I’d argue that the specified model is a significant improvement on the status quo. The current way that fees are treated is kind of abysmal. This proposal pushes more in the direction of what I would think of as an efficient market with:

  1. Reduced transaction costs that allow those with high transaction valuations to be processed quicker.
  2. The ability to specific a maximum number of blocks to wait (the F_{max} value) where the user specifies both a time and price priority.
  3. Allow the gas price to more closely fluctuate about the equilibrium transaction price.

I sense a little trepidation among some of the participants on this, but can we at least agree that this is less bad than the current mechanism?

38

For clarity: “‘Social costs’ in this context mean” (as it appears) or “‘Social cost’ in this context means” (as in the object of work on “the problem of”)?

Compare, e.g., Coase 1960 (on bovine increments, inter alia) with Posner & Weyl 2018 at 50-51 (on domains proper to rule by X)

Notes for further exposition of optimal corporate reorganizations

Baliga & Maskin 2002 at 22-23;
compare “selfish capital elasticity” after Roughgarden & Tardos 2001
with griefing factor analysis; reconcile α in models s.t.
a “current commitment value” C_{V_i} is aggregate consumption of a (nontradable under what assumptions?) validation (item?) “as creditor holdings”

39

Um… the first, I think. I meant that ‘social costs’ as used hid meaning in abstraction. Node owners aren’t distinct from users, so external costs don’t actually exist (ignoring things like ‘increased demand for ssds raising ssd prices for everyone’…).

40

I was revisiting this post after the morning’s eip-1559 call, and found myself wondering:

Why did 1559 make the change where the tx bid over the base_fee is now ignored, instead of pocketed by the miner like in this draft? I’m not saying the prior was better, but it’s a change from this foundation that I didn’t see described in 1559.

41

My question might be super strange and nooby, but I still like to ask due to my curiosity about k-th auction.

Vitalik mentions the following problem.

First, a block proposer can include their own transactions in a block,
and thereby increase the clearing price, increasing their own total
revenue.

If miner has space for 5 transactions and we assume that all 5 transactions must be included, then, sure, miner will include two of his own dummy transactions priced at 0.13, causing users with(0.13, 0.19, 1.00) to pay 0.13 as well, i.e miner gained 0.13 * 3. While this is true, I don’t understand why miner even needs to submit his own dummy transactions to increase the price ? he can just only include 3 most-right transactions in the block, gaining the same revenue. Why does vitalik even mention dummy transactions by miner at all ? If there was a validation upon consensus that blocks “mostly small” are rejected, then at least I would understand it.