In protocol CL triggerable consolidation

[mkalinin]

Originated from and incorporates discussions around the following PR:

• In-protocol consolidation - target liable #10

The key difference to the original proposal is allowing consolidation only when withdrawal credentials of the source and the target have the same Execution layer withdrawal address. This allows to avoid dependency on EL and process consolidation on the Consensus layer.

Although, this change restricts consolidation space it significantly simplify the mechanics and can become an acceptable middle ground between the protocol and engineering complexity and consolidation capabilities.

Full change set:

• New Consolidation beacon chain operation:
  • Valid if:
    • Source and target are active and not yet exited
    • Source and target have either ETH1_ or COMPOUNDING_ credential prefix
    • Source and target have the same withdrawal address
    • The operation is signed by both the source and the target
  • Yields creation of PendingConsolidation that is appended to the pending_consolidations queue, PendingConsolidation keeps an epoch during which it was created
• On epoch processing:
  • Apply pending consolidations when they are finalized:
  • Move active balance to the target, leave excess balance to be withdrawn
• On proposer and attester slashing:
  • Resolve every validator index to the final consolidated_to index in both proposer and attester slashing processing, then apply slashing to consolidated validators
  • Finalizing consolidation and resolving to consolidated_to allows to slash target even in the case when a conflicting vote has been submitted by the source, more on this below:

Finalizing consolidation changes the above to the following:

1. val n -> m consolidation initiated on A, B has not observed such consolidation
2. consider B finalized: A has to finalize a conflicting checkpoint to finish val m -> n consolidation, finalizing A is already slashable on B
3. consider A finalized: A becomes canonical, val n on B and val m on A vote on conflicting checkpoints and val m can be slashed on A because slashing processing resolves n -> m

[fradamt]

Suggested change

	if source_validator.exit_epoch > current_epoch:
	source_validator.exit_epoch = current_epoch
	source_validator.exit_epoch = min(source_validator.exit_epoch, compute_activation_exit_epoch(current_epoch))

[mkalinin]

compute_activation_exit_epoch logic is already incorporated in process_consolidation:

https://github.com/michaelneuder/consensus-specs/pull/12/files#diff-1cdf2318cbed64bdc20bd25631130be090a72ca7ff4f05bbc74c0c63a634e0f1R2080

[dapplion]

Overall the approach looks solid! Aggregating the source and targets keys for the same Consolidation message is a neat trick

This allows to avoid dependency on EL and process consolidation on the Consensus layer.

I want to note that the trade-off is not free. Now you need a way to propagate the Consolidation message to the proposer, so we need a new gossip topic with poor DoS properties + beacon API routes. Doable, but definitely something to consider.

[fradamt]

I want to note that the trade-off is not free. Now you need a way to propagate the Consolidation message to the proposer, so we need a new gossip topic with poor DoS properties + beacon API routes. Doable, but definitely something to consider.

Given that consolidation is mainly useful for pools, and not something you need to be doing all the time anyway, we could perhaps consider not having a gossip topic, and just having each pool rely on its own proposers to get the messages on chain

[dapplion]

I want to note that the trade-off is not free. Now you need a way to propagate the Consolidation message to the proposer, so we need a new gossip topic with poor DoS properties + beacon API routes. Doable, but definitely something to consider.

Given that consolidation is mainly useful for pools, and not something you need to be doing all the time anyway, we could perhaps consider not having a gossip topic, and just having each pool rely on its own proposers to get the messages on chain

That could fly maybe, with 900k vals 1 index proposes every 125 days, 32 indexes every 3.9 days. We would be putting some min expected consolidation size, or forcing smaller player to coordinate off-protocol with bigger ones

[mkalinin]

Closing in favour of #14