[WIP] Withdrawals pull.

[djrtwo]

First of the withdrawal features to be specified. Feature metatracking issue here -- #2758

Fork has code-name -- Capella. I'm assuming Merge will have a B-star-name so putting a C-star-name placeholder for now. "Withdrawals" is too confusing of a placeholder name.

During the epoch transition, if a validator has 0x01 withdrawal credentials and is withdrawable, fully withdraw the validator -- i.e. create a withdrawal receipt and add it to the state, and zero out the validator balance

Some details to note:

• A commitment to withdrawal_receipts (e.g. the root) to be exposed in EL for normal EL TX to consume to move the ETH into the end account
• index (always increasing) included in WithdrawalReceipt so that a simple bitfield (of length max_successful_withdrawal_receipt_index) can be used to track consumed receipts in EL
• A 0x00 -> 0x01 change-of-credentials operation is required to trigger a withdrawal for existing 0x00 validators (new operation to come in subsequent PR)
• Partial withdrawals will use the saw withdraw function but not use entire balance (to be developed in subsequent PR)

todo:

• add a withdrawn_epoch to Validator. This will be useful for any sort of validator index reuse (e.g. safe to be reused after 50k epochs)
• don't use the just a simple SSZ list for the accumulator. With partial withdrawals this can grow at ~100MB / year. It's append only so you can send most receipts to disk but this means the WS states cant grow to cumbersome sizes.
  • main idea -- create a CommitmentContainer that just has the merkle root and right-most merkle branch that works for append-only trees (and has some merkle tree structure as a List)
  • backup idea -- use ring-buffer
    • simple
    • but puts a time limit on how long you have to claim in EL because receipts get overwritten
• Add some epoch transition sanity tests

[zilm13]

I don't know if this is the right issue for it, but we should make some estimations on:

• load on queues and BeaconChain just after withdrawal feature introduction
• regular BeaconChain and queues load if feature "Partial withdrawal" is introduced

[mkalinin]

An option with a ring-buffer plus historical_roots accumulator also worth considering, IMO

[djrtwo]

Right @mkalinin, I was also considering a double batched merkle accumulator (like historic roots). One reason I would like to try this other method first (commitmnt container) is that the claim process/logic will likely be much simpler because it will just look like a merkle tree, constantly growing. Additionally, it's not immediately clear when to do the batching, but that can be solved relatively easily.

[hwwhww]

Great work!

I haven't started to review the content yet. Just want to remind you of the CI setting earlier.

[mkalinin]

Right @mkalinin, I was also considering a double batched merkle accumulator (like historic roots). One reason I would like to try this other method first (commitmnt container) is that the claim process/logic will likely be much simpler because it will just look like a merkle tree, constantly growing. Additionally, it's not immediately clear when to do the batching, but that can be solved relatively easily.

Actually, user may utilize historical batches to build a persistent proof with the merkle tree solution:

1. Get a proof linking receipt to the withdrawal receipts tree root when the receipt is added to the tree
2. Get a proof linking withdrawal receipts tree root from (1) to the historical batch once the root of the state that contains the receipts tree root from (1) is accumulated
3. Get a proof linking the historical batch root from (2) to the beacon/state root and claim the receipt on EL side at any time

[hwwhww]

some nitpicking.

the logic looks good to me with bare-eye review atm. need to add more test cases to verify it.

[hwwhww]

Need to be added to preset files.

[hwwhww]

Suggested change

	| `WITHDRAWAL_RECEIPT_LIMIT` | `uint64(2**40)` (= 1,099,511,627,776) | withdrawal receipts|
	| `WITHDRAWAL_RECEIPT_LIMIT` | `uint64(2**40)` (= 1,099,511,627,776) | withdrawal receipts |

[hwwhww]

Suggested change

	| Name | Value | Unit | Duration |
	| - | - | :-: | :-: |
	| Name | Value | Unit |
	| - | - | :-: |

[hwwhww]

These words seem from Altair specs. I think seeing Phase 0 here could be a little confusing. In Merge specs, we've changed the wording.

[potuz]

Suggested change

	Capella is a consensus-layer upgrade containin a number of features related
	Capella is a consensus-layer upgrade containing a number of features related

[mcdee]

Regarding partial withdrawals: there has been a fair amount of discussion on how this could be achieved with minimal additional complexity on the beacon chain. For ease of reading I'll refer to the partial withdrawal of funds above 32 Ether in a validator as "skimming".

Any early discussion regarding skimming was to allow a validator to skim at the same time they proposed a block. Although simple, it has several downsides. Most importantly, it provides no assurance as to when skimming for any given validator will take place: due to the random nature of proposer duties, one validator may skim twice in a month, whereas another may have to wait half a year. Another downside is that it requires the block to be proposed: if the validator misses the block proposal for any reason (or the block is proposed but fails to make it on-chain) then the opportunity for skimming is lost. These downsides are exacerbated with higher numbers of active validators.

Given this, it seems that a more reliable method of generating withdrawals would be nice. Manual operations to carry out skimming may appear attractive, however this requires a new operation, new p2p channels, additional block space etc. so should be avoided if possible.

One option is to have a regular, controlled skim of all eligible* validators on a periodic basis. For example, if the period was 1024 epochs then at the end of each epoch in the period 1/1024 of the validators would be processed, with each eligible validator in the set having a withdrawal receipt generated and made available to the execution layer for processing.

This removes the requirement for a new operation and all of the additional complexity and weight that goes with it, and maintains a regular schedule for rewards to be skimmed. Additional load on the beacon node should be minimal due to the small number of validators processed per epoch, and if this is a concern then the period could be increased accordingly.

Having a system for partial withdrawals is important to avoid validators churning through the exit and activation queues to retrieve rewards, but adding to complexity and weight of the beacon chain any more than necessary is not desired and the proposed mechanism achieves the former whilst avoiding the latter.

*For a validator to be eligible it would need to be ongoing_active (not slashed), have a balance > MAX_EFFECTIVE_BALANCE, and have 0x01 withdrawal credentials.

[vbuterin]

Why do this, instead of just zeroing out the validator once it's withdrawn?

[potuz]

It may be useful to later reuse the validator index. (Oh just realized it's in the PR description)

[protolambda]

@djrtwo @ralexstokes To clarify the remaining TODO, you're looking for an implementation:

• of an append-only merkle structure using the CommitmentContainer interface
• similar to that of the deposit-contract merkle stack updates
• that has the same root as a normal SSZ List would have
• that does not store the actual list contents since you only just need an updateable merkle-root for withdrawal proofs?

I think that can be done, I can give it a try maybe tomorrow.

[protolambda]

See protolambda@17a7065

CommitmentContainer was not the right fit here since we need to commit to all state contents, including the merkle stack contents. Simply caching the root works fine in this case.

Mirrored the deposit contract merkle-stack approach:

• compute_withdrawal_tree_root to get the witthdrawal tree
• withdraw updates the merkle stack in the state

Extra: since we don't have to gas-golf as much: after processing all withdrawals, cache the new latest withdrawal-tree root in the BeaconState (so light-clients can proof it easily, and everyone can access it without re-computing)

Not sure if we can carry over formal verification easily, but it's the same thing.

Besides testing the merkle-updates (or formal verification) we'll need some integration tests (e.g. produce the proof for a withdrawal)

[axic]

I wonder if it would make sense making this Bytes32 preparing for the possibility of "address space extension"?

It has some downsides:

1. The receipt is now packed, given 64 + 160 + 256 bits of values.
2. The deposit mechanism is still locked in to 160-bit addresses anyway, and likely many other places on the beacon chain too.

[djrtwo]

closing in favor of the Push method #2836