AFAIK, we decided to use a sum of priority fees to calculate value of locally built block. If so, I would explicitly add this statement to the field definition. Or do it in another way, say something abstract in the field definition and specify particular calculation algorithm in the Specification part.

did we decide to go this route? I lost the thread over a number of long-running conversations across the various issues...

My notes from CL call #97 were that sum of fees (over balance diff) was the preferred approach, but there were a few voices for giving the EL flexibility to implement it however it wants.

For context, some ideas mentioned on why the EL might want to diverge from simply summing fees were to include coinbase payments in the block value (in case MEV searchers sent transactions to the mempool) or to add an artificial boost to local block value over the builder's blocks.

I think the probability of searchers sending their transaction to the mempool is negligible, thus sum of the fees looks like the best approach to evaluate locally built block value as it's not affected by inbound and outbound transactions to and from the fee recipient address.

I actually like the idea of flexibility, we may specify that blockValue computation is implementation dependent.

I think in some cases searchers will fall back to the mempool, and even play PGAs if the situation calls for it -- esp. with long-tail types of MEV just getting a transaction on-chain via the public mempool can be preferable to using a builder

that being said, I think we are fine to settle on a "good enough" solution here

the thing w/ this computation being client-specific is that you could get to a setting where one client team has spent more time optimizing this and that leads to better returns and we have a a centralization vector around that one client -- so I think better to standardize one approach

I think in some cases searchers will fall back to the mempool, and even play PGAs if the situation calls for it -- esp. with long-tail types of MEV just getting a transaction on-chain via the public mempool can be preferable to using a builder

I guess this transaction will be quickly bundled in one of the builders blocks, if this transaction breaches sanctions there are non-censoring builders that can still include it into a block. Using public mempool in this case makes sense only if local builders can recognise this type of MEV, i.e. account for coinbase transfers, or if a searcher don't want to communicate with builders directly. So, if we want to optimise for this case then I do agree that we need more fancy logic for computing block value which accounts for transactions spending fee recipient's balance that can be supplied by a local mempool.

I think specification of exact algorithm if we have it unified or not (there can be a couple of preferred approaches) should be out of the scope of the Engine API spec. If we see an EL client with some very popular algo becoming a centralised force then we should consider this algo to be spread across all other clients. Though, I believe we don't have a lot of different approaches to compute this thing

I added this to the spec as a compromise, does that work?

"4. Client software MAY use the sum of the block's priority fees to determine blockValue."

yeah this works for me

I think we can let client teams decide how to implement this and there is enough alignment across them that if something weird happens after deployment we can lobby to tweak one way or another

yeah this should have probably been there in the first place