Thanks for Vitalik’s explanation for how this work today. Contributing back.
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.
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.
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.
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?
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.
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.
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)?
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 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).
To further underscore the importance of this, some news from China:
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.
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
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
