Gloas alpha spec 8#9315
Conversation
|
Some required checks have failed. Could you please take a look @eserilev? 🙏 |
| // Set a non-zero gas_limit on latest_execution_payload_bid so the gas limit | ||
| // compatibility check doesn't reject all bids at genesis. | ||
| if let Ok(bid) = state.latest_execution_payload_bid_mut() { | ||
| bid.gas_limit = 30_000_000; | ||
| } |
There was a problem hiding this comment.
I wonder if this should be part of the interop spec for Gloas genesis. It seems quite important.
michaelsproul
left a comment
There was a problem hiding this comment.
Partial review, will complete shortly.
| parent_beacon_block_root, | ||
| }), | ||
| // V4 maps to V3 for SSE (slot_number is not part of the SSE spec) | ||
| // V4 maps to V3 for SSE (slot_number/target_gas_limit are not part of the SSE spec) |
There was a problem hiding this comment.
Should probably fix this at the spec level (cc @chong-he 🙏 )
michaelsproul
left a comment
There was a problem hiding this comment.
Have reviewed everything except the consensus changes now.
…ook more like the spec
… for invalid node variant
|
Some required checks have failed. Could you please take a look @eserilev? 🙏 |
…atch the spec and pass ef test
|
|
||
| if proposal_epoch < current_epoch || proposal_epoch > current_epoch.saturating_add(1u64) { | ||
| if proposal_epoch < current_epoch | ||
| || proposal_epoch > current_epoch.saturating_add(spec.min_seed_lookahead) |
There was a problem hiding this comment.
ethereum/consensus-specs#5215 also says that
is_valid_proposal_slot(state, preferences)returnsTrue, where
stateis the checkpoint state at the epochcompute_epoch_at_slot(preferences.proposal_slot) - MIN_SEED_LOOKAHEADand
the rootpreferences.dependent_root.
We use the head_state here which seems correct and given our previous discussion on not wanting to accept all preferences that force us to load old states. I think that is fine. Do you think this changes?
There was a problem hiding this comment.
We also need to update BeaconState::is_valid_proposal_slot to use min_seed_lookahead right?
There was a problem hiding this comment.
The PR also changes it in get_upcoming_proposal_slots but I don't see any direct usage of it in our codebase. This spec change is so annoying.
pawanjay176
left a comment
There was a problem hiding this comment.
I have reviewed the non fork choice changes and they look good. Mostly nits
| execution_layer | ||
| .get_proposer_gas_limit(proposer_index) | ||
| .await | ||
| .unwrap_or(parent_gas_limit), |
There was a problem hiding this comment.
Shouldn't this be the default that we have configured in lighthouse instead of the parent gas limit?
There was a problem hiding this comment.
Yeah agree, I think there's no harm in setting a higher gas limit here, because this is just the target. It also solves the problem I found which is that this isn't actually the parent_gas_limit anyway:
| "No proposer gas limit configured, falling back to parent gas limit" | ||
| ); | ||
| } | ||
| proposer_gas_limit.or(Some(pre_payload_attributes.parent_gas_limit)) |
There was a problem hiding this comment.
I couldn't find the relevant part of the spec where we fall back to the parent gas limit instead of the configured default in lighthouse
michaelsproul
left a comment
There was a problem hiding this comment.
Looks good. I think maybe we just add a TODO for the parent gas limit issue I raised, seeing as it is only used as a fallback, and even then is only used as a target gas limit (it can't break anything I don't think).
| cached_head | ||
| .snapshot | ||
| .beacon_state | ||
| .latest_execution_payload_bid()? | ||
| .gas_limit |
There was a problem hiding this comment.
I think this is wrong in the case where we build on the Full variant of the parent. The payload has not yet been applied to state in this case, so its gas limit won't be stored in state.latest_execution_payload_bid.
I think we would need to thread the proposer_head_payload_status through here, or maybe just the proposer head payload envelope, and then load the gas limit from that envelope.
|
Actually, Pawan's suggestion is even cleaner. Get rid of |
| let payload_parameters = PayloadParameters { | ||
| parent_hash: parent_block_hash, | ||
| parent_gas_limit, | ||
| parent_gas_limit: target_gas_limit.unwrap_or(DEFAULT_GAS_LIMIT), |
There was a problem hiding this comment.
Wait sorry I don't think this is right. The parent_gas_limit just reports the gas limit of whatever we are building on right?
There was a problem hiding this comment.
yeah my bad, I thought we didn't need an accurate parent gas limit but maybe we do?
There was a problem hiding this comment.
Actually I think this is basically unrelated to Gloas. AFAICT the parent_gas_limit in PayloadParameters is only used in verify_builder_bid, which isn't active post-Gloas.
Still, we could safely (and correctly) initialise here by using the parent payload envelope, which is available earlier in the call stack.
We can also fully delete parent_gas_limit from PrePayloadAttributes I think
There was a problem hiding this comment.
Ohh that makes sense. I was wondering why we are passing it in the payload attributes when the EL already knows about the parent gas limit.
Issue Addressed
https://github.com/ethereum/consensus-specs/releases/tag/v1.7.0-alpha.8