Skip to content

Latest commit

 

History

History
117 lines (77 loc) · 5.64 KB

cgp-0039.md

File metadata and controls

117 lines (77 loc) · 5.64 KB
cgp title date-created author discussions-to status date-executed governance-proposal-id
39
Increase Block Target Density
2021-09-06
Mariano Cortesi (@mcortesi), Or Neeman (@oneeman)
EXECUTED
39

Overview

Proposes an increase of block's target density (from 0.5 to 0.8) to increase transaction throughput & block space usage.

Status

Celo blockchain launched with its own implemenation of EIP-1559 to regulate gas fees.

It uses two parameters:

  • target density: Defines the % of max block size to be used as target for creating blocks. Blocks bigger than it will increase baseFee, while smaller than it will decrease it.
  • adjustment speed: regulates how fast the baseFee increase or decrease

Which are used to compute baseFee with the following formula:

baseFee = oldBaseFee * (1 + (adjustmentSpeed * (blockDensity - targetDensity))) + 1

Current values are:

  • target density: 0.5
  • adjustment speed: 0.5

Proposed change is:

  • target density: 0.8

With current values:

  • baseFee increases by 25% on full blocks, and decreases by 25% on empty blocks.
  • network target block is 50% of the max block size.

It's important to remember than on periods of high demands, a continuous stream of full blocks implies an exponential growth of the baseFee until it reaches an supply-demand equilibrium on which demand for block space at such fee matches the expected target block size. The exponential growth component of the model makes the burst short lived as it rapidly becomes very expensive to transact on the network.

This CGP proposes modifying target density to 0.8 in order to maximize transaction throughput. The effect of such a change is:

  • baseFee increases by 10% on full blocks, and decreases by 40% on empty blocks. Thus, breaks symmetry on the base fee formula. See Risks section to understand the implicancies
  • network target block is 80% of the max block size.

An alternative approach to maximize transaction throughput is to increase the max block size. Though, this is not recommended on Celo, as the network has to maintain a 5 seconds per block average. max block size can only be as large as the maximum size the network can handle before loosing the expected block time. This is the case for the current value, and increasing it further is then dangerous. For this reason, using a 50% target density can be interpreted as to set 50% of network's max speed as target.

Proposed value of 80% implies going at 80% of max speed which makes more sense in terms of resource utilization.

Proposed Changes

  1. Set GasPriceMinimum's targetDensity parameter
- Destination: GasPriceMinimum, setTargetDensity
- Data:
    _targetDensity = 800000000000000000000000 (0.8 * 10^24)
- Value: 0 (NA)

Verification

TODO

Risks

Breaking base fee formula symmetry implies that base fee decreases faster than it increases. With proposed value, it requires aproximately 5 full blocks to cancel out an empty block.

To compute number of blocks requided to cancel an empty block, we need to resolve the following equation:

 effectOfEmptyBlock * effectOfFullBlock ^ x = 1
 
 => x = - log(effectOfEmptyBlock) / log(effectOfFullBlock)

Which states that we apply an empty block and then x full blocks and all that combined must have a net effect of 1 (cancel each out). So x is the number of full blocks I need to cancel an empty block. It should be noted that even with 0.5 target density, x > 1 (with 50% adjusment speed, an empty block followed by a full block is 0.75 * 1.25 = 0,9375 != 1)

A Valdator's cartel can use the fact that an empty block has a bigger effect than a full block to drive the baseFee down, thus increasing the gas tip that goes to validators. The higher the target density; the smaller the required size of the cartel is

We can compute the size using:

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))

Some sample data points

  • targetDensity = 0.5, speed=0.5 -> cartelSize = 43% of total validators
  • targetDensity = 0.6, speed=0.5 -> cartelSize = 33.8% of total validators
  • targetDensity = 0.8, speed=0.5 -> cartelSize = 15.7% of total validators

The computed cartel size is enough to lower the baseFee but not to profit from it. To do so, it needs a bigger cartel, so one part of the cartel generates empty blocks while the others reaps the benefits of it with full blocks.

A target density of 80%, implies a cartel size of only 15% of validators. This implies a risk to the network, still we believe the actual risk is mitigated by two factors:

  • The profit from the attack is minimal. Currently base fee is at gas price floor ( can't be driven any lower) and transaction fees are minimal in comparison to validator rewards.
  • Performing the attack (generating artificially empty blocks) is observable in the open; and validators can be slashed by a governance proposal.

In summary, potential benefit is low, and it puts validator's reputation at risk and with that all the validators rewards and a potential slash.

For that, we recommend going forward with this new value, as the benefits surpass the risk. If this should change, we can always modify then parameter once more.

Useful Links