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:

optimism/packages/contracts-bedrock/src/L1/ResourceMetering.sol

Lines 45 to 49 in d510910

	/// value.
	struct ResourceConfig {
	uint32 maxResourceLimit;
	uint8 elasticityMultiplier;
	uint8 baseFeeMaxChangeDenominator;

in the SytemConfig contract:

optimism/packages/contracts-bedrock/src/L1/SystemConfig.sol

Lines 114 to 118 in d510910

	/// @notice The configuration for the deposit fee market.
	/// Used by the OptimismPortal to meter the cost of buying L2 gas on L1.
	/// Set as internal with a getter so that the struct is returned instead of a tuple.
	ResourceMetering.ResourceConfig internal _resourceConfig;

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:

optimism/packages/contracts-bedrock/src/L1/SystemConfig.sol

Lines 439 to 444 in d510910

	/// @notice An internal setter for the resource config.
	/// Ensures that the config is sane before storing it by checking for invariants.
	/// In the future, this method may emit an event that the `op-node` picks up
	/// for when the resource config is changed.
	/// @param _config The new resource config.
	function _setResourceConfig(ResourceMetering.ResourceConfig memory _config) internal {

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 ethereum-optimism/specs#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.