Include l1_fee in rlp encoding of Receipt

[frisitano]

Update

We would like to propose that we introduce the l1_fee in the rlp encoding of the Receipt type.

Orignal

          Should we modify this so that the `l1_fee` is optional? Having it as a `U256::ZERO` isn't really accurate. I will create an issue for this.

Originally posted by @frisitano in #93 (comment)

[greged93]

My issue with this is that a receipt should always contain a l1_fee for Scroll, we are adding the option because the RLP encoding doesn't include it which feels like a bad design. On the other hand, I can't think of another solution, so maybe this is all we can do.

[frisitano]

I agree that a superior solution would be to include the l1_fee in the rlp encoding of the receipt. Let's raise this with the rest of the protocol team to gain opinions. There may be reasons this decision was taken initially that we are not aware of.

[Thegaram]

Is it true that l1_fee is rlp-encoded as U256::ZERO in the receipt? It seems to me that it is simply not included in the RLP encoding of the receipt.

Compare with other chains:

• In geth, only a subset of receipt fields are included in the receipt RLP: status, cumulativeGasUsed, bloom, logs. Other fields are excluded: gasUsed, blobGasUsed, transactionIndex, etc.
• In op-geth, newly added fields are also excluded (including L1Fee).

There are two possible considerations:

• Light clients: Include any fields that light clients might care about, that they cannot get from other verifiable sources. l1Fee might be convenient for light clients but they can actually calculate the fee themselves using some state reads.
• Compatibility: Currently our receipts root can be decoded or reconstructed the same way as Ethereum's.

The short answer is the L1 data fee mechanism was modeled after OP's, that's why we also excluded this field. But I also don't see a strong reason to add it.

[greged93]

Is it true that l1_fee is rlp-encoded as U256::ZERO in the receipt?

I think Francesco was referring to the value we set for the receipt's l1_fee when RLP decoding. We use a default value of U256::ZERO since the encoding doesn't contain the l1_fee.

newly added fields are also excluded (including L1Fee).

I wonder why they add the deposit_nonce and deposit_receipt_version, wouldn't this also be easily fetched from the L1 for light clients?

[frisitano]

Light clients: Include any fields that light clients might care about, that they cannot get from other verifiable sources. l1Fee might be convenient for light clients but they can actually calculate the fee themselves using some state reads.

I may be mistaken but I thought there was a hardcoded constant in the client that is used when calculating the L1 fee.

The l1_fee may be valuable metadata to a light client but I suppose it is not a hard requirement. I suspect that Optimism removes the fields from the rlp encoding to ensure that they can maintain consistency with the Ethereum block header (i.e. consistent receipts root). If we decide that we should not include this value in the rlp encoding then I propose we change this to being an Option as opposed to using U256::ZERO.