add engine_preparePayload_debug endpoint

[garyschulte]

PR description

PR to enable debugging block proposals by re-adding an updated version of the deprecated
engine_preparePayload endpoint

be sure to use the current or a recent parent blockhash or you will DoS bonsai db

All fields in the parameter are optional, including the parameter itself

example usage:

curl --location --request POST 'http://localhost:8551' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE2NTkwNDEzMzZ9.4PDdSaG9hFOFR4Th7rEgaKKECsXfz6IPckFRcfSP13o' \
--data-raw '{
    "jsonrpc":"2.0",
    "method":"engine_preparePayload_debug",
    "params":
    [
        {
            "parentHash": "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3",
            "feeRecipient": "0x0000000000000000000000000000000000000000",
            "timestamp": "0x0",
            "prevRandao": "0x0",
            "withdrawals": []
        }
    ],
    "id":1
}'

OR, this usage will use fee recipient 0x00..00, current timestamp, current chain head, "deadbeef" prevrandao, and empty withdrawals:

curl --location --request POST 'http://localhost:8551' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE2NTkwNDEzMzZ9.4PDdSaG9hFOFR4Th7rEgaKKECsXfz6IPckFRcfSP13o' \
--data-raw '{
    "jsonrpc":"2.0",
    "method":"engine_preparePayload_debug",
    "params":
    [],
    "id":1
}'

Fixed Issue(s)

Documentation

• I thought about documentation and added the doc-change-required label to this PR if
  updates are required.

Changelog

• I thought about the changelog and included a changelog update if required.

[jflo]

Since this is a debug method, would it be simpler to use if it always built on the chainhead? It would be less timing/juggling when it is being used.

[garyschulte]

Since this is a debug method, would it be simpler to use if it always built on the chainhead? It would be less timing/juggling when it is being used.

yes, yes it would 👍 . I think we can do the same thing we do with timestamp and default it to the current head if it is otherwise not specified

[gfukushima]

Hi Gary, can this be closed since it's been merged as part of another PR?

[garyschulte]

Hi Gary, can this be closed since it's been merged as part of another PR?

this was merged in a speculative RC candidate, and isn't in main yet.

[non-fungible-nelson]

can we close or re-status this @garyschulte ?

[garyschulte]

IMO we should rebase and merge as it is useful for debugging proposals. @fab-10 was using a different mechanism to test proposals IIRC, so would be helpful to get his opinion

[fab-10]

IMO we should rebase and merge as it is useful for debugging proposals. @fab-10 was using a different mechanism to test proposals IIRC, so would be helpful to get his opinion

It make sense to have this endpoint as well, it is an easier and fast method to trigger a payload creation

[gfukushima]

Here is a tricky question, shouldn't this method be in the debug set? Another reason to move that is, the way we built the engine_exchange_capabilities mean Besu might report this method. CL is probably going to ignore it though.

[garyschulte]

DEBUG is present even if the ENGINE api is not, so I think this needs to live within engine api. Good point about the capabilities though 🤔 I will check to see if this causes problems for CLs

[fab-10]

What about a ENGINE_DEBUG set? So it is separated from ENGINE and can be enabled only if used

[garyschulte]

I filtered the debug prepare payload from the capabilities list in the same way the capabilities list filters itself 👍

[garyschulte]

just saw the ENGINE_DEBUG set suggestion. I think we could add something like that if we have more than one engine debug endpoint in the future 👍 . Rule of three applies in this case IMO

implemented suggested changes

[macfarla]

LGTM