Closed potuz closed 1 day ago
I would like to discuss the possibility of moving withdrawal processing to the execution payload entirely instead of a lock-fulfil mechanism where the withdrawal is deducted from the beacon chain when processing the CL block and then later is fulfilled in the EL when processing the execution payload.
Another issue to add to the agenda: with the current PTC threshold to achieve consensus at 50%, a malicious builder that wants to create a split view requires a single PTC member to equivocate in order to do so, perhaps raising the threshold to 66% is worth it to avoid this attack.
Another issue, setting the gas limit is done by the builder in the curren iteration. This needs to be set by the proposer. Perhaps the easiest way is to leave it off-procol for the builder API in the header request, and pass the gas limit in the header so that the proposer chooses the one that matches his request.
Yet another one if there's time: the current get_attesting_indices
is a hack. Perhaps we want a cleaner way of dealing with attestations.
Regarding the gas limit, I wonder if the current P2P specification needs modification. Assume the following setup: validator_a
wants a gas limit of 30M, while validator_b
wants a gas limit of 40M. The builder knows this disparity and broadcasts two individual bids, one for 40M and one for 30M. The bids need to hop through validator_a
to get to validator_b
.
If validator_a
receives the 30M bid first, it will pass the 30M bid to validator_b
and drop the 40M bid. Depending on who is proposing, either a
or b
will use the 30M bid, even though the b
prefers the 40M bid.
If validator_a
receives the 40M bid first, it will pass the 40M bid to validator_b
and drop the 30M bid. Depending on who is proposing, a
cannot propose with the 40M bid while b
can.
In the future, we might want to refer this as EIP-7732 break out
Recording: https://youtu.be/WC9XsungamU
Agenda
get_attesting_indices
invalidates the transaction signature if there are ptc members.