Conversation
This also introduces an `ENABLE_WITHDRAWALS` feature-flag to allow implementers test EIP-4844 without including Capella-specific state changes.
|
address #3044 |
hwwhww
left a comment
There was a problem hiding this comment.
Had a quick scan, @Inphi well done on the rebasing!
- Note that #3042 changed the consensus containers & epoch processing functions. So if we include it, you'd need to update that part.
- From pyspec's point of view, having
ENABLE_WITHDRAWALSis kinda annoying 😬 but I'd defer to client devs if they really want this flag control in spec.
specs/eip4844/beacon-chain.md
Outdated
| if ENABLE_WITHDRAWALS: # [New in EIP-4844] | ||
| for_ops(body.bls_to_execution_changes, process_bls_to_execution_change) |
There was a problem hiding this comment.
That means we have to replace @with_capella_and_later decorator in tests with @with_phases([CAPELLA]) if we treat ENABLE_WITHDRAWALS == 0 as a constant.
And if we want to have the flexibility to test ENABLE_WITHDRAWALS == 1, we need to write a new decorator to check preset before running the test.
specs/eip4844/fork.md
Outdated
| Since the `eip4844.BeaconState` format is equal to the `Capella.BeaconState` format, we only have to update `BeaconState.fork`. | ||
|
|
||
| ```python | ||
| def upgrade_to_eip4844(pre: bellatrix.BeaconState) -> BeaconState: | ||
| # TODO: if Capella gets scheduled, add sync it with Capella.BeaconState | ||
| epoch = bellatrix.get_current_epoch(pre) | ||
| def upgrade_to_eip4844(pre: Capella.BeaconState) -> BeaconState: |
There was a problem hiding this comment.
It's lowercase capella for the pyspec library.
Ditto. I don't think we should enshrine test-only flag in the spec. The decision on whether withdrawal is enabled or in the protocol for testing and testnet can be reached out of the band |
|
The goal is to align the behavior of disabling withdrawals across all clients. ENABLE_WITHDRAWALS will be removed eventually upon further testing. But right now, we're trying to avoid any withdrawal bugs or changes in the spec from influencing 4844. |
Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
|
In testnets we can avoid worrying too much about the impact of withdrawals on consensus by stubbing out these functions: Epoch processing: Block processing:
But I think we can figure this out on a per-testnet basis, by saying "target this spec commit but stub out these functions" rather than ingraining this in the spec here I think it's simpler if we don't touch anything else, for example:
|
And remove the ENABLE_WITHDRAWALS feature-flag. The Testing section in the spec has been updated to specify how withdrawals is to be disabled
|
@realbigsean Thanks for the suggestions. I've made the changes to the spec. |
Co-authored-by: Alex Stokes <r.alex.stokes@gmail.com>
|
Marked it "DO NOT MERGE" since we have to swap the no-op functions in pyspec internally + fix tests. I can work on it but I'm pretty afk this week. 🙏 |
There was a problem hiding this comment.
I managed to make withdrawal functions no-op & add basic tests, and find okay Wi-Fi somewhere 2km far from Machu Picchu. 😄
The functionalities/correctness LGTM now!
Edited: I'll defer to client devs to make the decision in testing. Although I personally found that the no-op stub is still somewhat annoying. 😅
|
I've updated the PR for #3068. Reviewers please take another look. |
terencechain
left a comment
There was a problem hiding this comment.
Great work @Inphi ! Just one question
| | `GENESIS_FORK_VERSION` | `phase0.SignedBeaconBlock` | | ||
| | `ALTAIR_FORK_VERSION` | `altair.SignedBeaconBlock` | | ||
| | `BELLATRIX_FORK_VERSION` | `bellatrix.SignedBeaconBlock` | | ||
| | `CAPELLA_FORK_VERSION` | `capella.SignedBeaconBlock` | |
There was a problem hiding this comment.
Potential merge conflict with #3089. I can fix that after this is merged
| #### `get_payload` | ||
|
|
||
| ```python | ||
| def get_blobs_and_kzg_commitments(payload_id: PayloadId) -> Tuple[Sequence[BLSFieldElement], Sequence[KZGCommitment]]: |
There was a problem hiding this comment.
get_blobs_and_kzg_commitments is still mentioned below, do we want to remove this?
There was a problem hiding this comment.
Good catch. This was a bad merge from dev. I've added it back in. Thanks.
hwwhww
left a comment
There was a problem hiding this comment.
lgtm! ![]()
I have a test vector generator branch (https://github.com/ethereum/consensus-specs/compare/pr3052-testgen) based on this PR. I'll open a PR once this one is merged.
| ``` | ||
|
|
||
| ### Disabling Withdrawals | ||
| During testing we avoid Capella-specific updates to the state transition. We do this by replacing the following functions with a no-op implementation: |
There was a problem hiding this comment.
This no-op works fine for clients?
I'm out of the loop, but I thought they would use the full functionality here (yes, complicating testing)
There was a problem hiding this comment.
We want to avoid submitted withdrawals from interfering with the testnet. By no-op'ing these functions, withdrawals won't have any effect.
|
|
||
|
|
||
| @with_capella_and_later | ||
| @with_phases([CAPELLA]) |
There was a problem hiding this comment.
This should be capella and later, no?
Ah, the no-op change will break this test... If we do this, we need to remember to go back and change these all :/
When we were rebasing here, I didn't realize we were rebasing and mutating. How much will we be blocked on 4844 if we don't do the capella no-op within 4844 spec?
There was a problem hiding this comment.
My understanding is to prevent random semi-public testnet users/validators from invoking any withdrawals?
Agreed with this complicating testing but given that we have 3-4 in-discussion changes on Capella, it makes sense that EIP-4844 devs want to disable Capella now... 😭
Btw I also added the tests to test the Capella no-op. So we must undo it altogether.
There was a problem hiding this comment.
My understanding is to prevent random semi-public testnet users/validators from invoking any withdrawals?
Yes it's exactly this.
djrtwo
left a comment
There was a problem hiding this comment.
okay, I'm fine with it, assuming that clients can no-op functions for a fork without too much issue.
approved
Also adds a "testing" specification that allows withdrawals to be disabled during testing.