CIP 42 - Reconcile EIP-1559 with Celo - Discussion

[trianglesphere]

Discussion on reconciling Ethereum's implementation of 1559 with Celo's. Link back to CIP

[oneeman]

The GPM portion of fees currently goes to the community fund (i.e. the governance contract's proxy address), not the reserve. So the places in the CIP which say "reserve" should be fixed.

We could consider changing it as part of the hard fork so they go to the reserve instead unless we contemplate making a change to that as part of the hard fork, but perhaps that should be a separate CIP if we did want to propose it. We would also consider the implications of the reserve having cUSD/cEUR as those are the assets that the reserve acts as a reserve for.

[asaj]

How will this be implemented? Will we deprecate the smart contract based approach in favor of the "native" solution?

[trianglesphere]

Will we deprecate the smart contract based approach in favor of the "native" solution?

We will not. Currently the smart contract sets the gas price minimum (which maps to basefee in 1559 terminology). This adjusts how fees are paid such that users only pay the specified tip (or max_priority_fee_per_gas) instead of setting the tip to be gasprice - GPM

[asaj]

@trianglesphere I'm curious why not deprecate the smart contract approach in favor of the "native" approach? Seems like it would make it easier to track upstream

[trianglesphere]

@asaj Splitting it would make it a little harder to track upstream, but our header format is already different. Using smart contracts to calculate the GPM keeps the benefit of being able to govern GPM parameters / implementation, and end users still see the same transaction format & similar gas price dynamics.

[mcortesi]

Checking the original EIP-1559 it seems they only have 2 parameters:

• Elasticity Multiplier = 2
• gas limit

Gas limit is on the block and follow regular ethereum gas limit rules that we don't follow. And elasticity multiplier is how much you can expand the gas limit for a block (2 => twice the block size).

We could investigate if it make sense to follow ethereum's model, but make elasticity multiplier a blockchain parameter. That would simplify the whole logic, and make us the same as ethereum, with the upgrade of having that parameter be configurable by governance

But we would loose the ability to configure other things

[trianglesphere]

Checking the original EIP-1559 it seems they only have 2 parameters:

There is a third parameter called BaseFeeChangeDenominator which is set to 8. It updates the basefee according to this formula

gas_used_delta = parent_gas_used - parent_gas_target
base_fee_per_gas_delta = max(parent_base_fee_per_gas * gas_used_delta // parent_gas_target // BASE_FEE_MAX_CHANGE_DENOMINATOR, 1)

[oneeman]

Yeah, BaseFeeChangeDenominator is like our adjustment speed, except it divides instead of multiplying, and that the delta in Ethereum is relative to the target size (see the // parent_gas_delta in the snippet quoted above) whereas in our contract it's relative to the maximum size.