Resolve discrepancy between on-chain and off-chain `elasticity_multiplier`values.

[geoknee]

Off chain

op-geth uses a static elasticity multiplier set in the chain config. See here and here.

This value is currently hardcoded to 6.

On chain

We also store an elasticityMultiplier inside the ResourceConfig struct:

https://github.com/ethereum-optimism/optimism/blob/d510910381d99660295f99e4eccd553df5829df6/packages/contracts-bedrock/src/L1/ResourceMetering.sol#L45-L49

in the SytemConfig contract:

https://github.com/ethereum-optimism/optimism/blob/d510910381d99660295f99e4eccd553df5829df6/packages/contracts-bedrock/src/L1/SystemConfig.sol#L114-L118

On OP Mainnet, the parameter is actually set to 10. See this etherscan link.. I believe this is a historical / out-of-date value.

Moreover, we are actually reading and validating this parameter in the superchain registry (see here), since we have specified that 10 is the standard value.

From what I can tell this parameter is not being read by the off-chain software. Here's a hint that this was once the plan: https://github.com/ethereum-optimism/optimism/blob/d510910381d99660295f99e4eccd553df5829df6/packages/contracts-bedrock/src/L1/SystemConfig.sol#L439-L444

I propose that we should either:

1. Complete that plan so that the elasticity parameter can be changed on chain and picked up off chain
2. Remove the on chain parameter in the next contracts release to prevent confusion.

[sebastianst]

If we can't do 1. in Granite or Holocene, it could be worth it doing 2. for the next contracts release to avoid confusion until we add it back?

[tynes]

The ResourceConfig is specific to the deposit tx fee market. It is not used to configure the L2 fee market. Both are separate gas markets with different basefees. Its incredibly complex to maintain an EIP1559 fee market on chain, the state space is just too large to test thoroughly and ensure quality UX (for example out of gas issues happen randomly for end users). I am a big fan of https://github.com/ethereum-optimism/specs/pull/82 which replaces the on chain EIP1559 fee market with a queue, which would remove the oog issues, make deposits cheaper and remove the risk that deposits use up more gas than the L2 gas limit if the system is configured incorrectly.

[geoknee]

Thanks @mark. I wonder if there are any documentation improvements we can make in the short term to prevent confusion on this issue? Otherwise, it looks like there isn't any action necessary after all and this ticket can be closed.