Builder Payments and Bids Verification Improvement

Creating an Ethereum Improvement Proposal (EIP) requires a structured approach. The issue described involves improving how builder bids are verified in Ethereum, specifically addressing the complexities involved with calculating accurate fee payments to the proposer fee recipient. Let's break down the suggestion into key problems and proposed solutions, and then format them into a draft EIP.

Current Mechanisms and Their Limitations

Pre/Post Balance Checks

These checks can fail if unrelated transactions alter the balance of the proposer fee recipient’s address during the same block, particularly if the recipient is a smart contract.Payment Transaction Value Checks: If the recipient address is a contract that forwards funds (e.g., a splitter contract), the straightforward transaction value method can misrepresent the actual funds retained by the recipient.

Complexity in Verification:

Verifying payments to a smart contract as a proposer fee recipient requires understanding the contract’s internal logic, which can vary widely and include automatic transfers that obscure the true amount received.

Proposed Solution

The solution involves revising the way builder bids are recorded and verified by extending the types of data tracked within each block:

Transfers In: Total value of funds transferred to the proposer fee recipient during the block.Transfers Out: Total value of funds transferred out from the proposer fee recipient within the same block.Costs: Total transaction fees burned by transactions originating from the proposer fee recipient.

The net change in the proposer fee recipient’s balance would then be calculated as:
[ \text{Net Change} = (\text{Value} + \text{Transfers In} - \text{Transfers Out} - \text{Costs}) ]
This approach allows for a comprehensive and verifiable calculation of the net funds received by the proposer fee recipient.

EIP Draft Proposal Specification

Block Data Extensions:Transfers In: Define as the sum of all incoming transfers to the proposer fee recipient within a block.Transfers Out: Define as the sum of all outgoing transfers from the proposer fee recipient within the same block.Costs: Define as the sum of all transaction fees burned by transactions that originate from the proposer fee recipient.Bid Calculation:The builder bid value for the proposer fee recipient is calculated using the formula: [ \text{Net Change} = (\text{Value} + \text{Transfers In} - \text{Transfers Out} - \text{Costs}) ]

Rationale

This proposal introduces a more robust and transparent mechanism for verifying builder bids. By accounting for all relevant transfers and costs, the network can ensure that the payments to proposer fee recipients are accurately represented and verifiable.