Proposer compares fees between local and builder blocks #11557
Conversation
|
To get a better feel for this, perhaps we can add logging / metrics for how the local vs. builder fees compare in practice to our dev nodes? This way we can evaluate the actual fraction we should use |
| @@ -145,6 +146,8 @@ func (e *ExecutionPayload) MarshalJSON() ([]byte, error) { | |||
| timeStamp := hexutil.Uint64(e.Timestamp) | |||
| recipient := common.BytesToAddress(e.FeeRecipient) | |||
| logsBloom := hexutil.Bytes(e.LogsBloom) | |||
| fee := new(big.Int).SetBytes(bytesutil.ReverseByteOrder(e.Fees)) | |||
There was a problem hiding this comment.
So basically this will be a new JSON field of execution payloads that we receive via the engine API, right? This is gonna be hard unless we add the ability to skip fields for SSZ generation...
There was a problem hiding this comment.
Yeah. Or we don't use consensus protobuf object for engine API marshal/unmarshal. It's not clear to me why that's a must
There was a problem hiding this comment.
We shouldn't need to, only once we are preparing to put it inside a beacon block. The naming is weird though...perhaps we could have pb.ExecutionPayload which is used in consensus and ExecutionPayloadEngineResponse types
There was a problem hiding this comment.
The naming is weird though
Geth uses ExecutionData which I like
There was a problem hiding this comment.
Great to see this feature being worked on! To help co-ordinate amongst teams could you comment on the execution API issue/pull request on how to best format this new data field. The current suggestion from @mkalinin is to create a new engine_getPayloadV2 method.
This is an experimental PR with some unknowns, which we'll document in the todos. This PR enables proposer to compare and choose between 1.) builder block fees and 2.) local block fees. The proposer will choose the higher fee between
local_block_feesandbuilder_block_fees * N / 100whereNis a CLI flag but defaulted to100Todos
feestoExecutionPayloadwill not work!!ExecutionPayloadis a consensus object. We can not modify that because it's part of the ssz spec. We need to decouple consensus protobuf with local JSON communication objects