DRAFT: Position paper on resource pricing

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…

2 Likes

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.

2 Likes

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.

I can see how this could be an issue. That said, this strategy could only be successful if miners get the minFee down so low that blocks are frequently more than 100% full, encouraging higher fee premiums, so it would require many miners to collude to have an effect. If fees are only depressed slightly by a few miners pushing minFee down so blocks are on average, say, 60% full, then the effect would be relatively small. Also note that even in the current system, it’s the case that 50% of miners could collude to push the gas limit to below 8 million and try to earn more revenue from supply constriction.

That said, if this ends up bring a problem, there is a way to do a default strategy change (not even a soft fork!) after the fact to make it robust up to 50% collusion: instead of asking each miner to vote the adjustment for one block, we ask each miner to locally compute what the minFee “should be” based on eg. the last 256 blocks, and the default strategy would be to push the fee as close to that value as possible. This way if a small coalition tries pushing it up or down, as soon as they are even slightly successful the majority would start maximally pushing back in the opposite direction.

2 Likes

Those are reassuring points.

Colluding miners would have some advantages compared to today; right now, a miner who unilaterally lowers the gas limit will forfeit some gas fees, and has no impact on other miners’ behavior. Under 1559, the miner can choose a lower minFee without any loss of revenue, and as a slight bonus that will lower the maximum minFee that can be set by the next miner. They wouldn’t really need to communicate out of band.

Also a lower gas limit today means your higher price is offset by lower quantity, and it might not be obvious where you get optimal revenue. But a lower minFee with the same gas limit has no such tradeoff; as long as the miner is ok with 16M blocks, the lower the minFee the better.

Still, if most miners were fine with 16M blocks then we’d probably have them already, so a majority might keep things in line. And I do see the benefit of keeping the strategy flexible, especially at first.

2 Likes

I still think that having a “default strategy” that isn’t game-theoretically rational in the presence of >50% collusion is fragile. Miners almost certainly already collude in setting max block sizes, etc. In fact, I already think that miners right now vote for 8 million because it’s close to their revenue-maximizing point. The main problem with miner collusion in 1559 wouldn’t really be miners extracting more revenue than they already do, but rather miners breaking the minFee+epsilon fee calculation algorithm.

I’m not really comfortable about the common approach of assuming non-coordination in blockchain protocols, and then considering things like bribing separately. I think a better approach is to explicitly consider the transaction costs of collusion, and assume that participants are fully rational in deciding whether or not to collude. So miners that would not collude for, say, 51% attacks to corrupt state, might collude to fix transaction costs.

In this case, I think the transaction costs to coordinate a minFee-zeroing cartel are very low, and the payoff very big, so >50% of miners will most likely choose to collude. (Contrast this to, say, history-reverting 51% attacks. Coordination on how to revert the history is significantly harder, and payoff is negative especially with PoS slashing. This still doesn’t mean we can trust a >51% mining pool, since idiosyncratic “irrationality”, like political pressure, is dangerous when we don’t get to average the rationality of many actors)

2 Likes

I think minfee should be under consensus, this is what will be in my proposal.

Seems reasonable to me!

FWIW the reason I originally made it voluntary was to allow the mechanism to be ramped up carefully and shut down if desired without needing additional hard forks. If we decide that we want to just go full steam ahead on it, or have two separate transaction spaces, then that’s not necessary, and mandatory is indeed better.

1 Like

Thanks for the guidance. That makes a lot of sense. I’m thinking two transaction spaces for now, but it’s tricky and I’m still thinking about it.

Adding this datapoint which is one of many examples where there is a case to be made for
the resource being under priced.

Here is a transaction in which 1,000,000 DAI was wiped with a transaction fee of ~$0.09 while the stability fee was ~$770 in MKR burned. https://etherscan.io/tx/0xb8f86c232e79f3edd0040bdc35195cafb7848b5d44dbce38ac9a0f657f239907

In this transaction 99.9% of the value accrued to the Maker protocol. Could value based pricing be more equitable?

Though I’m not sure if commenting on the old papers is a good practice, but whatever:

The derivative of -log(x) is -1/x, which means that D(W) decreases and so the C(W) increases.