-
Notifications
You must be signed in to change notification settings - Fork 994
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rebase EIP-4844 on Capella #3052
Conversation
This also introduces an `ENABLE_WITHDRAWALS` feature-flag to allow implementers test EIP-4844 without including Capella-specific state changes.
address #3044 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had a quick scan, @Inphi well done on the rebasing!
- Note that Withdrawals into queue in single function #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_WITHDRAWALS
is 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 <[email protected]>
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 <[email protected]>
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work @Inphi ! Just one question
@@ -140,6 +141,7 @@ Per `context = compute_fork_digest(fork_version, genesis_validators_root)`: | |||
| `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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Potential merge conflict with #3089. I can fix that after this is merged
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed in f1d4c90
specs/eip4844/validator.md
Outdated
|
||
```python | ||
def get_blobs_and_kzg_commitments(payload_id: PayloadId) -> Tuple[Sequence[BLSFieldElement], Sequence[KZGCommitment]]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
get_blobs_and_kzg_commitments
is still mentioned below, do we want to remove this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. This was a bad merge from dev. I've added it back in. Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@@ -335,3 +342,10 @@ def initialize_beacon_state_from_eth1(eth1_block_hash: Hash32, | |||
|
|||
return state | |||
``` | |||
|
|||
### 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We want to avoid submitted withdrawals from interfering with the testnet. By no-op'ing these functions, withdrawals won't have any effect.
@spec_state_test | ||
def test_success(spec, state): | ||
signed_address_change = get_signed_address_change(spec, state) | ||
yield from run_bls_to_execution_change_processing(spec, state, signed_address_change) | ||
|
||
|
||
@with_capella_and_later | ||
@with_phases([CAPELLA]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is to prevent random semi-public testnet users/validators from invoking any withdrawals?
Yes it's exactly this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.