DRAFT: Position paper on resource pricing

I like the simplicity of a marketplace like that, though it does open up lots of market manipulation vectors / black swan events if you parameterize it badly. You could pretty easily have gas bubbles that cripple the network, and it seems like there would be feedback between gas price in such a scenario and ETH/USD exchange rate (since gas price impacts network usability; I see it as similar to oil price and the stock market, but gas in ETH is a much more fundamental resource than even oil in industrialized economies).

The social cost curve @vitalik has in the paper would probably be argued by a lot of for example Bitcoiners to not be steep enough; at some point large blocks could definitely become catastrophic in PoW, if e.g. censorship results in a network partition.

Most of my comment specifically relies on the difference between UTXO storage and computation. Storage seems to require rent, computation does not. Computation is a cost paid once by un-checkpointed validating nodes and peers on the network at the time of the transaction, where storage is persistent and must be kept in a fast-access medium for security. It is an ongoing cost for every actor on the network, so I don’t think the same mechanisms can be used.

Also, just to clarify, I’m far from convinced GasToken is a net positive. I think GasToken is an important experiment, and something like GasToken could be a net positive. But there is a lot of modeling to be done before I’d personally be convinced of the optimality of any mechanism (even defining what that means is highly nontrivial).

My ideal market for both storage and computation would definitely include limited guaranteed issuance and restrictions on redemption that would enforce the lack of a network-killing capacity spike, and would also attempt to enforce a large percentage of capacity available on the spot market to reduce the profitability of cornering the market. Limited issuance into the future should allow for enough liquidity to extract useful pricing information and allow for large players to hedge risk while not overselling capacity.

This is all somewhat separate from the “rent” issue though, and whether to have cash-backed extra-protocol futures or computation-backed in-protocol futures is an open question. I think most would prefer the former for simplicity; curious to hear what people more versed in commodity markets than me think about that.

The second-price auction is a nice, simple mechanism for allocating a fixed set of space. It preserves the same ranking of transaction priority ranking as the current system, is simple from a user decision perspective, and reduces average txn fees vis-a-vis a pay your max offer system.

It is not incentive compatible with the current block miner takes all fees in block model, but it easy to imagine modifying other aspects of fee payment to accommodate auctions. For example, you could allocate x% of txn fees to the block miner and (100-x)% to future (or alternatively preceding) block miners. In this case, the miner must shoulder a portion of fees himself in order to increase the fees paid by others. The second price auction should become incentive compatible for a sufficiently low x. Would want to do some research to establish an appropriate choice of x, but I’m guessing 50% would work.

That doesn’t work; any scheme where anything less 100% of marginal changes to txfees go to block proposers is vulnerable to side channel payment attacks, as users can bribe miners to include their transactions and give miners 100% of the fees.

1 Like

I understand what you mean by side channel attacks, but I think that the situation is not so simple and that there are at least two Nash equilibria here. Let’s work with a kth price auction, where the k highest fee offers get into the block and everyone pays the kth highest fee offer.

Suppose that the kth transaction fee under the kth price auction is y and thus that the miner receives y/2.

I could obtain get into the block by paying a fee y and a side payment ε, where ε is some small positive number.
Alternatively, I could go by the socially preferred route and get into the block by paying a fee y+ε.
The miner would accept either offer.

Thing get more interesting if I try to issue a side payment in lieu of a portion of the fee.
Suppose I pay a fee y-ε and a side payment ε, so that I am spending the exact same amount as the kth txn, but trying to exploit a side channel. Lowering the official fee reduces the auction price from y to y-ε. This price applies to the preceding (k-1) txns subject to the auction. If the miner accepts this txn he will lose (k)ε/2 via the official channel and gain ε via the side channel. Thus, the miner would not accept the side channel payment if k>2 and all other users are working with the auction. The implication here is that complying with the auction is a Nash equilibrium. Unfortunately it is not unique.

Suppose that all users offer an official fee of 0 and that the kth side channel payment is y/2. In this case, a user can only obtain entry into the block by offering a side channel payment greater than y/2. Offering a fee will not affect the auction price. So working entirely via the side channel is also a Nash equilibrium. If users are able to collude to work exclusively via a side channel, then they can temporarily reduce fees. Very quickly, however, this would lead to increased txn volumes until the fee reaches something near to and potentially higher than the previous level.

There are lots of additional things to consider here. If the miner can append fees to existing txns rather than create de novo txns where he pays a full fee, this would cause problems. But maybe the takeaway is that the use of auctions deserves a more thorough treatment in the paper.

On further consideration, I think that auctions are likely to be an improvement even under the scenario where 100% of marginal mining rewards go to the miner. Maybe we should set that idea of spreading the fee over multiple blocks aside. Regardless of whether that would work or not, it is probably unnecessary and the side channel issues add a lot of complexity.

What you are saying in the paper is that it is not incentive compatible to force the miner to auction off all gas available up to the gas limit. Instead, the miner will auction of whatever quantity of gas maximizes his revenue under the constraint that he must sell all gas use in the block at one uniform gas price. I think that’s fine. I believe that this type of auction (miner chooses how much gas to sell) would be a dramatic improvement over the current arrangement.

Essentially what this achieves is movement from a regime of perfect price discrimination by miners to one where mining operates under the law of one price.

Going from price discrimination to the law of one price has the following consequences:

  1. The miner gets much less revenue from txn fees and thus is harmed.
  2. High value users (rapid txns) will pay a dramatically lower average gas price.
  3. Low value users (slow txns) may pay a slightly higher gas price and some activity could be priced out of the market.

In general, it is not possible to say whether the combination of three consequences is socially beneficial or socially harmful. There is a benefit from restricting the miner’s ability to extract rents from users. There is a loss when users are priced out of the market. You need to weigh these two sides and in order to do this one needs to look at the demand and cost structure, which vary across contexts. For gas pricing, I think we are in a situation where restricting miner’s rent extraction yields a large net social benefit.

I peeked quickly at a recent block 6165683. For this block, using an auction to set a uniform gas price would lead to a gas price of 3.011 Gwei for all txns and would not price any txns out of the market, so there would be no dead weight loss. Instead it is just a pure transfer harming miners and benefitting users. Miner fee revenue would drop to about 10% of the current level, with the 90% being returned to high value users. Would need to automate analysis of many blocks to determine how representative this is. I expect there would turn out to be some activity that is price out of the market in some blocks, but that this would be of minimal consequence.

The key consequences would be a huge drop in user costs and a very small % decrease in miner fees (since miner rewards mostly come from the block subsidy).

In short, I think that an auction like this (where each individual miner can choose how much gas to auction off up to the gas limit) is a very promising approach to gas pricing.

Useful link providing background slides on price discrimination:

1 Like

Use of a little grammar English checker wouldn’t hurt. I’ll make a pull request.

p. 15, first full para. (2nd para.) + fn. 3: I use ethgasstation’s safe low and am happy to wait for the safe low time, unless of course the fee will be too high to be worth it, as was the case with a dock.io LinkedIn import transaction during an anonymous contract DOS attack a few months back.

“(to provide a slight incentive for the block producer to include the transaction)” p. 16, what’s the point of doing that “If being included in the blockchain simply requires paying some minFee, (which would be burned, rather than given to the miner, to prevent side-dealing between transaction senders and miners allowing free transactions)”.

W is number of bytes in block. I assume D is a utility with a value from of decentralization or demand.


D stops increasing with large block size. A benefit per additional node (marginal benefit) is decreasing with larger blocks, so marginal total social cost is increasing, if R(W) and A(W) were constant.

Pages 5 and 6 are equally confusing, especially since the 2nd derivatives of the plots are all zero. It’s like the plots are supposed to be marginal (per unit) instead of “cost” which throws the discussion out of whack with the 1974 paper. I would remove the word “marginal” from the paper, do all the math in terms of cost per unit (byte), and make sure everything is expressed as a cost such as “centralization” instead of “decentralization” and “utility loss” instead of “benefit” or “utility”.

I’m not sure the price and quantity controls of the 1974 paper are the same thing as fees (taxes) and cap-and-trade.

(p3) An equilibrium is established where users attach fees to their transactions which go to the validator that includes the transaction in a block, and validators select the transactions paying the highest fee per unit weight.

The equilibrium is not that simple. If we assume the weight of transactions to be known beforehand (like in Bitcoin), the equilibrium would be the validator including the set of transactions paying the highest total fees such that the total weight of accepted transactions is at most the weight limit.
That’s the knapsack problem.
Assume a weigh limit W=10 and transactions (under the form (f,w) (fee,weight)):

t_1 has the highest fee per unit, but for miners it’s better to include t_2 and t_3 which will pay 10 instead of 8 by including only t_1.

Just taking the TX with the highest fee per weigh is a greedy algorithm which may produce acceptable results but not optimal ones. I wonder if miners just use the greedy algorithm or effectively run a knapsack to optimize their fees.

Now for chains like Ethereum where the fee per weight (gasprice) is known but the weight is not known before trying execution (not all gas need to be consumed), the optimization seems harder. In particular because the amount of gas consumed by a transaction can depends of the execution of other transactions.

Most transactions in practice have small gas limits relative to the block gas limit, so it’s ok to treat them as being infinitely divisible. IMO we should just use this simplification; if we don’t then the problem becomes far too intractable…

1 Like

In section 9 you describe a scheme for preventing a double waking attack using a MinInterval. I think there are design patterns which will want to have contracts that put themselves to sleep in the same transaction that they wake up. This is something that should be encouraged as much as possible - These patterns will require very little storage in the network, and will halve the number of transactions to interact with them because they do not require a separate hibernate call. There is also a different scheme which would use an EpochLength instead of a MinInterval which would allow these design patterns.

At the end of every epoch of EpochLength blocks, a merkle tree and bloom filter of all the awoken contracts would be published. Those could be used, along with the merkle tree / bloom filters of the blocks in the current epoch to prove that the contract has not been awoken since it was last put to sleep. This would result in faster proofs with the bloom filters, and allow design patterns without storage costs.

Yeah, you can certainly do that and it would be slightly more efficient.

In fact, objects in UTXO architectures technically never need to be awake.

Is there any room in this analysis for the case where a history of state transitions can be compressed to reduce costs? I can imagine a lot of things where the private benefit decreases over time for transaction senders, to the point where they are really no longer relevant. If a transaction history is summarized then the cost to all other full nodes is decreased with respect to storage, which seems to be the most costly of the types of cost.

In storage price section, you described the solution of charging timely rent fees. Do users need to pay expensive timely storage fees due to price fluctuation? Is there a more predictable way to know the cost?

Say, users can occupy storage proportional to the amount of ether they hold in their accounts. If I have 100 ether and total supply is 1000, I would be able to occupy 10% of the storage without any rent fees. If my balance reduces the occupied storage can be poked by other users.

Incredible research as always! I read this paper and found it very interesting, but unfortunately, I guess I have a selfish user attack for it. The high-level idea is that because your proposed update rule is multiplicative if some exchange refrains from broadcasting its transactions for some time and then releases all of them in a single large batch, this oscillating behavior will push the price down even though the average transaction volume stays the same as in the equilibrium. In this straightforward simulation for the first 1000 blocks, everyone is acting honestly, and the network is at equilibrium, however, in the second 1000 blocks, only ten agents with 10% of the total transaction volume can halve the price.

I propose to replace the suggested update formula by the additive Almgren–Chriss framework in game theory, which guarantees that the optimal execution of transaction strategy is actually to spread transactions across different blocks which in turn helps to avoid network congestion. Also, a much simpler solution in terms of Kolmogorov complexity as @vbuterin mentioned in his paper, is to use a sliding median which is more stable and predictable than the first price auction and also much more robust to selfish miner attack for the second price auction.

One thing I haven’t really seen discussed is whether minFee could be set by validator up/downvoting, the way the gas limit is set right now, instead of being a number automatically adjusted with an algorithm. This should be able to entirely replace voting on the gas limit, and an unlimited or extremely large fixed gas limit only for stopping DoS attacks could be used.

Consider a case where the gas limit doesn’t exist, and instead validators vote on minFee. According to the position paper, this should be basically the same if perfect information about social costs etc exist. Of course that’s not the case in real life, but I don’t see the problem of dynamically adjusting “taxes” instead of “caps” on gas. It’s certainly not the case that social costs suddenly increase dramatically as blocks become larger than the gas limit.

One problem with solely using taxes rather than caps might be that sudden spikes in usage could make one block way bigger than surrounding ones. I don’t think this is actually such a big problem; one block randomly being 10 times bigger might cause some temporarily out-of-whack block times but shouldn’t be a disaster.

It’s only a problem if blocks are regularly too big to process, but that’s unlikely since the taxes can increase quite quickly. Nothing forces taxes to be “politically” fixed the way gas limits are right now; a simple behavior of “if I think that blocks are too big, upvote minFee, otherwise downvote” will quickly arrive at an appropriate minFee. An additional incentive to behave this way might be to redistribute “captured” fees to miners, letting them use minFee as a channel to fix gas prices like a cartel, leading to gas prices that a monopoly on transaction processing would charge. This isn’t as bad as it sounds since Ethereum still competes with other blockchains; VISA doesn’t really have much monopoly power to charge arbitrary transaction fees. Cartel behavior is already possible through purposefully voting down the gas limit.

The advantage of having voted-on minFee is that gas prices become a lot less volatile even compared to Vitalik’s proposed minFee mechanism, let alone vanilla Ethereum. And if minFee is redistributed to miners, gas cartels — which almost certainly will exist in any pricing system — no longer lead to degenerate behavior that break the minFee+epsilon fee strategy.

I think the difference between VISA and a mining cartel is that the survival of VISA as a company is the priority for its people, but miners always have the option to switch into other blockchains easily, and might not be that much enthusiastic about the long-term effect on Ethereum itself but the immediate profit they make from mining it.

1 Like

This is a good point (and a very good reason why hash-power-based governance is even worse — a lot worse — than coin-voting plutocracy), but in a proof-of-stake system stakers wouldn’t be able to ruin Ethereum then switch to other blockchains. Their investment in Ethereum would be destroyed, and a rational miner cartel would never raise fees above the revenue-maximizing point.

I think the problem with having validators vote on minFee is that they have little incentive to raise it, since they don’t receive any of it.

This may be less of an issue with a very high cap, but with the 16M cap in EIP1559, the validators do best by lowering minFee whenever they can, but never increasing it. Then demand for gas will more often exceed the 16M max limit, and miners will get more revenue as people raise their premiums to outbid each other.

So it seems to me that, rather than 1559’s approach of letting miners choose how much to change minFee (up to a maximum change), the protocol should actually enforce a specific new minFee.

1 Like

I actually didn’t read EIP1559 before writing my earlier reply, but the danger of miners voting down minFee to zero is indeed why I think distributing the base fees to miners, heavily smoothed across time, is best. One easy implementation is to add the base fees to a pool, and permit miners to withdraw 0.1% of the pool every block as part of the block reward.

This does allow miners to collude to extract more fees, but miners can already do so by voting down the block limit. Price-fixing and supply-fixing cartels are effectively equivalent, with the only difference being that the former at least gives users a stable gas price. Expecting miners to follow 1559 and adjust the minFee to target a block size is exactly the kind of unenforceable, incentive-incompatible price fixing that leads to black markets and ignoring the protocol.

You can force the miners to do that, if it’s one of the consensus rules. Then a block just isn’t valid unless minFee has been adjusted correctly. 1559 already has a similar rule that disallows too large of a change to minFee, so this would just tighten that criteria.

Then the miners have no discretion, other than what premium they’re willing to accept, and you don’t have to worry about incentivizing them; you can go ahead and burn minFee and avoid the collusion problem.