baseFeeScalar zero value does not translate to L1InfoTransaction on L2

[ezdac]

So I added the l1Fee to the gas calculation in the test again. And I set the blobbasefeeScalar and
basefeeScalar parameters to zero in the deploy config. (see #254 (comment) for context)

However the basefeeScalar zero value does not end up in the L1InfoTransaction that op-geth receives, and the receipts still have a non-zero value set for the L1BasefeeScalar.

I checked the SystemConfig contract, here both values are set to zero. However, e.g. one L1InfoTransaction on L2 I checked showed the following data, and the slice of data where the basefeeScalar value should be encoded is set to 1000000:

https://go.dev/play/p/8PN2lhQ-QGE

This is the same value that I could observe in the transaction receipts.

For now I don't know what's wrong here, but this is likely something that happens in the payload building in the L2 node.
Probably the SystemConfig update events are not read properly while building the payload attributes or the data is not encoded properly for the Ecotone encoding scheme.

Originally posted by @ezdac in #254 (comment)

[karlb]

I can reproduce the issue in my local devnet. Strangely enough, I got the correct results in a very similar setup in https://github.com/celo-org/celo-blockchain-planning/issues/626#issuecomment-2393409274. I'll try to find out what's going on.

[karlb]

The deprecated gasPriceOracleScalar value gets into the BaseFeeScalar field in the L1Info. That seems wrong, but at least it explains why I got zero values out before, since I had the gasPriceOracleScalar set to zero too.

[karlb]

This is a configuration issue. gasPriceOracleScalar must be zero if we want to use BaseFeeScalar and BlobBaseFeeScalar:

optimism/op-chain-ops/genesis/config.go

Lines 253 to 255 in 0d86137

	if d.GasPriceOracleScalar != 0 {
	return common.BigToHash(big.NewInt(int64(d.GasPriceOracleScalar)))
	}

Once gasPriceOracleScalar is zero, both base fee scalars get communicated correctly.