Potential Research Area: Separate Dynamic and Static L1 Attributes Values

[tynes]

As of Ecotone, the L1 Attributes transaction includes the following information:

• baseFeeScalar
• blobBaseFeeScalar
• sequenceNumber
• l1BlockTimestamp
• l1BlockNumber  
• basefee
• blobBaseFee
• l1BlockHash
• batcherHash

Not all of this information changes every L2 block, which is the reasoning behind Diff Based L1 Attributes Transactions. Some fields are guaranteed to change every L2 block like the sequence number, some fields change every time the L1 origin updates (L1 blocknumber, L1 timestamp, etc) and some fields only change based on chain operator input (batcher hash).

For the fields that change automatically based on the L1 origin, we can call those dynamic values. For the values that only change based on chain operator input, we can call those static values.

The custom gas token spec adds a new static value which is the address of the ERC20 that represents the gas paying asset for the L2. A new design pattern is followed where the value is set in the system config and then it triggers a special deposit transaction that is able to set the address directly in the L2's L1Block predeploy. This pattern can be made more generic to work with all static values.

The next time that we need to add a static value to the L1 Attributes transaction, we should:

• Make a generic pipeline that is very similar to the way that custom gas token deposits its information into L2
• Remove all static values from the L1 attributes transaction and instead allow them to be configured "just in time" by the generic pipeline

This would allow us to easily allow for the configuration of the batch inbox for example