PROTOCOL: Self-Ejection For Nodes with Potentially Compromised Keys

[pgebheim]

https://github.com/onflow/flips/blob/main/protocol/20210118-self-ejection.md

[jasamba]

@AlexHentschel any update on the status of this FLIP?

[AlexHentschel]

The Flip has been merged (-> PR https://github.com/onflow/flow/pull/324). The flip was reviewed and approved by our engineers. But to the best of my knowledge, we didn’t really engage the community to collect feedback. Overall, there wasn’t much controversy about the approach outlined. We could move ahead, but the topic isn’t resourced (or prioritized for this year).

[KshitijChaudhary666]

@vishalchangrani - do you have context on this? Can we update the status? And who's the right DRI for this?

[AlexHentschel]

@KshitijChaudhary666 happy to be the technical DRI for this Flip 324. The status is accepted, which is accurate in my opinion: we want to implement it but haven't yet.

Context:

This FLIP addresses the question of what a node operator can do in case she believes her node's operational keys (i.e. staking or networking key) has been compromised. The established process for handling this case is (1) to revoke the compromised key and (2) issue new key(s). Changing a node's keys mid-epoch will not be supported for the foreseeable future. Therefore, the only available mitigation strategy is to remove the node as an authorized protocol participant (this is essentially just 1).

Flow's technical term for revoking a node's participation privileges is ejection (from the protocol). This FLIP proposes self-ejection as a measure a node operator can take in case they believe their node's staking key has been compromised. Conceptually, self-ejection is very similar to ejecting a node as punishment for protocol violations (usually accompanied by slashing the node's stake).

current status (as of Aug 2024):

• On the one hand we have the foundational functionality to eject nodes (via the dynamic protocol state). Essentially, we can react to triggers and eject nodes in response.
• However, there is no trigger implemented yet for ejecting nodes (neither due to slashing nor self-ejection requests). So in that sense, the core functionality proposed in this flip is still outstanding:
  1. node operator can send transaction with a self-ejection request,
  2. staking smart contract provides functionality for authenticating and processing self-ejection requests
  3. contract emits a service event that serves as a trigger for the dynamic protocol state to eject the respective node.