Skip to content
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

Merged
merged 25 commits into from
Nov 17, 2022
Merged

Rebase EIP-4844 on Capella #3052

merged 25 commits into from
Nov 17, 2022

Conversation

Inphi
Copy link
Contributor

@Inphi Inphi commented Oct 20, 2022

Also adds a "testing" specification that allows withdrawals to be disabled during testing.

This also introduces an `ENABLE_WITHDRAWALS` feature-flag to allow
implementers test EIP-4844 without including Capella-specific state
changes.
@hwwhww
Copy link
Contributor

hwwhww commented Oct 20, 2022

address #3044

@Inphi Inphi changed the title Rebase Capella on EIP-4844 Rebase EIP-4844 on Capella Oct 20, 2022
@hwwhww hwwhww added the Deneb was called: eip-4844 label Oct 20, 2022
Copy link
Contributor

@hwwhww hwwhww left a 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 Show resolved Hide resolved
Comment on lines 297 to 298
if ENABLE_WITHDRAWALS: # [New in EIP-4844]
for_ops(body.bls_to_execution_changes, process_bls_to_execution_change)
Copy link
Contributor

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.

Comment on lines 67 to 70
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:
Copy link
Contributor

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.

@terencechain
Copy link
Contributor

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_WITHDRAWALS` is kinda annoying 😬  but I'd defer to client devs if they really want this flag control in spec.

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

@Inphi
Copy link
Contributor Author

Inphi commented Oct 20, 2022

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.

@realbigsean
Copy link
Contributor

In testnets we can avoid worrying too much about the impact of withdrawals on consensus by stubbing out these functions:

Epoch processing:
-process_full_withdrawals
-process_partial_withdrawals

Block processing:

  • process_withdrawals
  • for_ops(body.bls_to_execution_changes)

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:

  • Actually get the root of an empty withdrawals list
  • Keep an empty withdrawals list in payload attributes
  • Use EIP4844 + withdrawal types in all APIs

Inphi added 2 commits October 24, 2022 12:44
And remove the ENABLE_WITHDRAWALS feature-flag. The Testing section in
the spec has been updated to specify how withdrawals is to be disabled
@Inphi
Copy link
Contributor Author

Inphi commented Oct 24, 2022

@realbigsean Thanks for the suggestions. I've made the changes to the spec. ENABLE_WITHDRAWALS has been removed and I've updated the Testing section to specify how clients can disable withdrawals.

@Inphi Inphi marked this pull request as ready for review October 25, 2022 16:06
@hwwhww
Copy link
Contributor

hwwhww commented Oct 26, 2022

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. 🙏

Copy link
Contributor

@hwwhww hwwhww left a 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. 😅

@Inphi
Copy link
Contributor Author

Inphi commented Nov 10, 2022

I've updated the PR for #3068. Reviewers please take another look.

@Inphi Inphi requested review from realbigsean, terencechain, djrtwo and hwwhww and removed request for ralexstokes, realbigsean, terencechain and djrtwo November 10, 2022 19:32
Copy link
Contributor

@terencechain terencechain left a 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` |
Copy link
Contributor

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed in f1d4c90


```python
def get_blobs_and_kzg_commitments(payload_id: PayloadId) -> Tuple[Sequence[BLSFieldElement], Sequence[KZGCommitment]]:
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

@hwwhww hwwhww left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm! :shipit:

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:
Copy link
Contributor

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)

Copy link
Contributor Author

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])
Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@djrtwo djrtwo left a 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

@hwwhww hwwhww merged commit 78f0e03 into ethereum:dev Nov 17, 2022
@hwwhww hwwhww mentioned this pull request Nov 17, 2022
@Inphi Inphi deleted the inphi/eip4844-rebase branch February 20, 2024 15:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Deneb was called: eip-4844
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants