`PayloadId` returned from `payload_id_optimism` inconsistent with `op-geth`

[0xOsiris]

Describe the bug

The PayloadId returned from a FCU in Reth when a build process is started is inconsistent with the implementation in op-geth.

I think it's reasonable to have a consistent implementation across execution clients for the PayloadId.

e.g. rollup-boost relies on parity in PayloadId between the builder, and the sequencer. Making Reth not compatible as a builder.

Reth implementation:

reth/crates/optimism/payload/src/payload.rs

Line 272 in 9f9de0f

pub(crate) fn payload_id_optimism(parent: &B256, attributes: &OpPayloadAttributes) -> PayloadId {

op-geth implementation:
https://github.com/ethereum-optimism/op-geth/blob/f21b97f1d6f673b608f72e9e60d63e70bd925e85/miner/payload_building.go#L57

Steps to reproduce

Example op-geth vs reth PayloadId

    #[test]
    fn test_payload_id_parity_op_geth() {
        // INFO rollup_boost::server:received fork_choice_updated_v3 from builder and l2_client payload_id_builder="0x6ef26ca02318dcf9" payload_id_l2="0x03d2dae446d2a86a"
        let expected = PayloadId::new(FixedBytes::<8>::from_str("0x03d2dae446d2a86a").unwrap().into());
        let attrs = OptimismPayloadAttributes {
            payload_attributes: PayloadAttributes {
                timestamp: 1728933301,
                prev_randao: b256!("9158595abbdab2c90635087619aa7042bbebe47642dfab3c9bfb934f6b082765").into(),
                suggested_fee_recipient: address!("4200000000000000000000000000000000000011"),
                withdrawals: Some([].into()),
                parent_beacon_block_root: b256!("8fe0193b9bf83cb7e5a08538e494fecc23046aab9a497af3704f4afdae3250ff").into()
            },
            transactions: Some([bytes!("7ef8f8a0dc19cfa777d90980e4875d0a548a881baaa3f83f14d1bc0d3038bc329350e54194deaddeaddeaddeaddeaddeaddeaddeaddead00019442000000000000000000000000000000000000158080830f424080b8a4440a5e20000f424000000000000000000000000300000000670d6d890000000000000125000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000014bf9181db6e381d4384bbf69c48b0ee0eed23c6ca26143c6d2544f9d39997a590000000000000000000000007f83d659683caf2767fd3c720981d51f5bc365bc")].into()),
            no_tx_pool: None,
            gas_limit: Some(30000000)
        };
        
        // Reth's `PayloadId` should match op-geth's `PayloadId`. This fails
        assert_eq!(
            expected,
            payload_id_optimism(
                &b256!("3533bf30edaf9505d0810bf475cbe4e5f4b9889904b9845e83efdeab4e92eb1e"),
                &attrs
            ) // := "0x6ef26ca02318dcf9"
        );
    }

Node logs

No response

Platform(s)

Linux (x86)

What version/commit are you on?

reth-optimism-cli Version: 1.0.7-dev
Commit SHA: b2848f2fc84595fa62c3831a9bb80c7708e6b627

What database version are you on?

NA

Which chain / network are you on?

Devnet

What type of node are you running?

Archive (default)

What prune config do you use, if any?

No response

If you've built Reth from source, provide the full command you used

No response

Code of Conduct

• I agree to follow the Code of Conduct