eip-7251: process consolidations

[prestonvanloon]

What type of PR is this?

Feature

What does this PR do? Why is it needed?

Extracted from #13903.

Which issues(s) does this PR fix?

Tracking @ #13849

Other notes for review

https://github.com/ethereum/consensus-specs/blob/v1.5.0-alpha.2/specs/electra/beacon-chain.md#new-process_pending_consolidations

https://github.com/ethereum/consensus-specs/blob/v1.5.0-alpha.2/specs/electra/beacon-chain.md#new-process_consolidation

Depends on these PRs:

• eip-7251: queue_entire_balance_and_reset_validator, queue_excess_active_balance, and switch_to_compounding_validator #13982
• eip-7251: New compute_consolidation_epoch_and_update_churn #13981

Merge those before merging this PR.

[prestonvanloon]

This is failing minimal spectests. I was skipping all spectests for consolidations as I thought they were deleted in v1.5.0-alpha.2, but I've learned that only mainnet spectests were missing for consolidations. When unskipping minimal spectests, they are failing for the following reason:

==================== Test output for //testing/spectest/minimal/electra/operations:go_default_test:
--- FAIL: TestMinimal_Electra_Operations_Consolidation (0.01s)
    --- FAIL: TestMinimal_Electra_Operations_Consolidation/basic_consolidation_in_current_consolidation_epoch (0.00s)
        assertions.go:144: helpers.go:62 Unexpected error: consolidation signature verification failed
    --- FAIL: TestMinimal_Electra_Operations_Consolidation/basic_consolidation_in_new_consolidation_epoch (0.00s)
        assertions.go:144: helpers.go:62 Unexpected error: consolidation signature verification failed
    --- FAIL: TestMinimal_Electra_Operations_Consolidation/basic_consolidation_with_compounding_credential (0.00s)
        assertions.go:144: helpers.go:62 Unexpected error: consolidation signature verification failed
    --- FAIL: TestMinimal_Electra_Operations_Consolidation/basic_consolidation_with_insufficient_preexisting_churn (0.00s)
        assertions.go:144: helpers.go:62 Unexpected error: consolidation signature verification failed
    --- FAIL: TestMinimal_Electra_Operations_Consolidation/basic_consolidation_with_preexisting_churn (0.00s)
        assertions.go:144: helpers.go:62 Unexpected error: consolidation signature verification failed
    --- FAIL: TestMinimal_Electra_Operations_Consolidation/consolidation_balance_larger_than_churn_limit (0.00s)
        assertions.go:144: helpers.go:62 Unexpected error: consolidation signature verification failed
    --- FAIL: TestMinimal_Electra_Operations_Consolidation/consolidation_balance_through_two_churn_epochs (0.00s)
        assertions.go:144: helpers.go:62 Unexpected error: consolidation signature verification failed
    --- FAIL: TestMinimal_Electra_Operations_Consolidation/consolidation_churn_limit_balance (0.00s)
        assertions.go:144: helpers.go:62 Unexpected error: consolidation signature verification failed

I'll work on fixing this, but the rest of the PR is still ready for review.

[prestonvanloon]

Fixed! Good bug catch by spectest, I was using the wrong fork version for computing the domain.

[rkapka]

This probably needs a broader design discussion and is outside of the scope of this PR, but what's the reason for returning the state here when the function doesn't make a copy of the passed in state? When I see a signature such as func F(state) state, I expect that I should only use the returned state because it will differ from the passed in state when the function returns. On the contrary, SwitchToCompoundingValidator doesn't return the state, so I expect the argument to be mutated inside the function.

It would be nice if we were consistent here.

P.S. The comment even says This method makes mutating calls to the beacon state

[prestonvanloon]

There is even an argument that this method should be a receiver on the state.

if err := st.ProcessPendingConsolidations(ctx, pendingConsolidations); err != nil {
  return fmt.Errorf("failed to process pending consolidations: %w", err)
}

I agree that this signature smells as is so I will change it as part of this PR such that it will not return the resulting state.

[prestonvanloon]

One thing to note @rkapka, all of the other state transition functions return (state.BeaconState, error) so these methods will be the exception actually. It's not a big deal, we can also refactor the other methods not to return the state since it mutates it in place.