As stated in the document, proposal is to increase block’s targetDensity from 0.5 to 0.8. This implies that network will use 80% of max block size as the block’s target size.
Rationale behind this, is to maximize transaction throughput. Contrary to Ethereum where max block size is set to limit negative externalities like storage and compute costs imposed on every node; within Celo max block size is set as the maximum block size network can sustains without risking deviating from the 5s block average.
If we then attempt to maximize throughput; using only half that size to implement EIP-1559 is a big limitation. The proposals suggest a new number that suggest a different tradeoff, in which we still apply EIP-1559 dynamics but we use more of the potential block size.
The tradeoff comes with a risk, which is described in the document. On which validators could collude to lower gas fees and maximize their profit by accruing more of the gas fees for themselves. We believe that is is not big risk for two reasons.
Potential profit is low at the current state of the network
Performing the attacks leaves a trace of empty (or almost empty) blocks within a sequence of full blocks. Thus, you can observer validators doing such an attack, and that would impact their reputation and even make them susceptible of a governance slash.
It would be cool to have a more lay description of how EIP-1559 is being applied to CELO and what is happening here with the choices of this parameter being 0 vs 0.5 vs 0.8 vs 1. Are there any such blogs?
Gas Price Minimum (baseFee) is computed and stored in a smart contract. So changing update formula and parameter it’s just a contract call.
Currently we don’t have fields max_priority_fee_per_gas and max_fee_per_gas (we plan to add them in the next hardfork). Instead, we have gasPrice that must be bigger that gas price minimum (gpm); we then split total fee in base = gpm * gasUsed and tip = (gasPrice - gpm) * gasUsed. Code here
The tip goes to the validator, and the base goes to the community fund (Governance Contract)
When adding the new tx fields, mechanism will be similar, only that we use the fields to compute base and tip
GasPriceMinimum update happens here and follows the specified formula:
Or Neeman, made some very good notes on the paper, that are very helpful:
A target density of 0.5) has the nice property that the base fee adjustment function is symmetric. This means that a full block and an empty block in succession roughly balance each other out in terms of their effect on the base fee (at least with Ethereum’s adjustment speed of 1/8).
Note that they don’t actually balance each other out, with empty blocks always having a stronger effect that full blocks. For example, with Celo’s current parameters, a full block would increase by 25% and an empty one decrease by 25%, so you go x → 1.25x → 0.75(1.25x), and 0.75*1.25 = 0.9375 < 1.
This effect gets bigger the bigger the adjustments are (i.e. the higher the adjustment speed). Here are examples of the effect of a full block and an empty block in succession (the order doesn’t matter):
With ethereum’s current parameters: x -> 0.875(1.125x) = 0.984x
If ethereum’s adjustment speed were 1/2 instead of 1/8: x → 0.5(1.5x) = 0.75x
If it were 3/4 instead of 1/8: 0.25(1.75x) = 0.4375x, and you would need 2.5 full blocks to counteract one empty block!
In fact, the paper (in section 8.6.4) mentions Vitalik having (in personal correspondence) suggested an exponential adjustment function that would make the base fee dependent on the total gas used to date (and the height), independent of the how the gas used was distributed among the blocks, but both Ethereum and Celo use a linear adjustment function.
If we set the target density higher, empty blocks result in a bigger adjustment than full blocks. For example, if we set the target density to 0.8, the difference (in percentages) is 4x. This means that a cartel of 20% of miners could manipulate the base fee downwards by mining empty blocks.
Of course, a cartel carrying out such an attack would not be collecting fees from those blocks while doing so, since they’re mining empty blocks. So in practice you’d need a bigger cartel, part of which is driving down the GPM and part of which is mining to collect fees (or, equivalently, all the miners could produce artificially low but not empty blocks, with each one contributing to driving the GPM down and collecting some fees as well). If the base fee is high enough, the gain due to it being manipulated downwards could outweigh the opportunity cost of not mining full blocks. But, of course, cartel members would have an incentive to defect.
Here is some Python code to calculate the block ratio and cartel size g iven GPM parameters:
import math
def cartel(density, speed):
up = 1 + speed * (1 - density)
down = 1 - speed * density
full_blocks = -math.log(down) / math.log(up)
cartel = 100 / (1 + full_blocks)
print("One empty block balanced by {} full blocks".format(full_blocks))
print("Cartel size: {}".format(cartel))
And here is a plot showing, for Celo, how the necessary cartel size varies depending on the adjustment speed and the target density. This is for a cartel trying to drive the GPM downwards (if it were driving upwards the results would be flipped, with it being easier at lower target densities and higher adjustment speeds making it harder, but as mentioned below Roughgarden points out there is no incentive for miners to do this). We can see that the biggest driver of cartel size is the target density, but that adjustment speed also has an effect. If we had as our goal for the cartel size to be at least 33%, we can’t really go beyond a target density of 0.6. But, as mentioned above, for it to be profitable, the cartel would also need to include some validators proposing full blocks (otherwise nobody in the cartel gets any fees). What would determine the profitability in the end is how high an unmanipulated GPM would be at that level of demand, as with a higher “natural” GPM value there is more profit per transaction to be made by manipulating the GPM down to the floor.
The fact that increasing by x% and then decreasing by x% results in an overall decrease (and the effect is more pronounced the bigger x is)
Having a target density higher than 0.5 means that the maximum % increase is smaller than the maximum % decrease (and the effect is more pronounced the higher the target density is)
A possible response to the first effect is to use the exponential adjustment function suggested by Vitalik instead of the linear one used currently by both Celo and Ethereum
A possible response to the second effect is to make the adjustment function asymmetric (for example, with a target density of 0.8, upward adjustment of speed * (d - 0.8) (if d ≥ 0.8) and downward adjustment of speed * (0.8 - d) / 4, or perhaps having it be symmetric up to a point and then flat, i.e. speed * min(0.8 - d, 0.2), though on the face of it that feels bad. This way a full block and an empty block would more or less cancel out.
But Roughgarden points out that, if you do this, a cartel could reduce the system’s throughput at equilibrium. With the example above, for example, a 20% cartel, if mining empty blocks, would be balanced by another 20% of validators mining full blocks and the other 60% mining 0.8 blocks, and the base fee would stay put. The resulting average density would be 0.68 rather than the 0.8 target. The cartel is effectively reducing throughput.
Of course, on Celo validators can already reduce throughput to some degree by not proposing blocks when it’s their turn, causing a round change.
Another way to think of the overall picture is as follows. With a target density of 0.5, empty and full blocks balance each other both in gas usage and (approximately) in their effect on the base fee. With other target densities, they will necessarily fail to balance each out either in terms of gas usage (meaning a cartel can manipulate the throughput at equilibrium) or in terms of the effect on the base fee (meaning a cartel can manipulate the base fee).
@mariano, many thanks for laying this out. I’ve still have to fully grasp how fees all work, but this helps a lot - and the links provided too.
I guess my interpretation is that by moving to 0.8 there is a higher equilibrium throughput but less responsiveness to increased network activity. I suppose this trade off is inherent because this is effectively a P controller and not a PI type controller with an integral term?
My other remark is that the whole system throughput doesn’t seem very elastic to increased gas prices. Basically the system can push from 80% up to 100%, which doesn’t seem like much of a throughput improvement. The system basically just has a way to prioritise transactions but not a way to mechanically increase throughput… Is that right?
Can’t really speak to the P/PI controller metaphor, sorry. But yes, 0.8 implies a higher throughput on equilibrium, at the expense of slower speed to respond to increased demand burst.
With 0.5 it meant you could duplicate the used space to accommodate for an increase on demand. It also mean that gas prices would increase far more quickly. A full block implies increasing baseFee by 1.25 vs 1.1 with 0.8 target density.
1 minute of full blocks implies:
0.5 => 14.5 times the original baseFee
0.8 => 3 times the original baseFee
5 minute of full blocks implies:
0.5 => 652,530 times the original baseFee
0.8 => 304 times the original baseFee
That means that with 0.5 burst are shorter in time. Since, first we have more space to process extra demand, and prices go up really quickly which implies that tx price become expensive very quickly, leaving less tx senders willing to pay that price.
On the other hand, 0.8 implies burst last longer. But still, 2 minutes of burst already implies 10x the price, so that’s expensive enough to rule out almost all tx sender imo.
Are there any tools/interfaces that show historical block density data? It would be good to review this and evaluate how this proposal does (or does not!) ultimately impact block density should it pass.
