Delegate activation rules

[echa]

The Blockwatch/TzStats indexer maintains an internal representation of the full blockchain state which is constructed from replaying block receipts (plus pulling snapshot index and rights from context). Anything else like supply, consensus and voting rolls, balance and delegation history, etc is derived from these receipts.

This approach works for all balance updates, but diverges from a node's context for the active delegate set. Ideally, all events that lead to registration, deactivation and reactivation of a delegate should be observable in receipts and there should be a consistent set of rules. This issue tracks our research towards understanding these rules and how they changed across versions.

From available documentation here and here and some reverse engineering our current set of delegate activation rules is as follows:

• Registration/Activation
  • a tz1/2/3 account sends a delegation operation and sets itself as delegate (example, example)
  • a tz1/2/3 account is defined as delegate in the genesis block, a.k.a. the 8 Foundation Bakers (example)
  • 🔥 a tz1/2/3 account sends an origination operation and sets itself as delegate on the created contract (example)
• Deactivation
  • 🔥 a registered delegate is listed in the block header field metadata.deactivated which gets populated in the last block of a cycle (example)
• Reactivation
  • an inactive delegate registers again using a delegation operation to self like above (example)
  • an inactive delegate receives a transaction operation (example)
  • an inactive delegate bakes or endorses a block (because it still has rights, example)

Problems with the approach above 🔥

1. some deactivations are missing from block.metadata.deactivated (example, example, example, example)
   • all the examples are marked inactive in the context, but they were never signalled in block metadata; a full dump of all deactivations extracted from block headers until block 552,960 (cycle 134) is availabe at this Gist
   • Note: early protocol versions until block 200,704 created many duplicate deactivations, although that's not an issue here the same code change that fixed duplicates may have broken signalling of some deactivations afterwards
2. delegate registration through origination is inconsistent: (a) sometimes such accounts become delegates immediatly (example), (b) sometimes they magically become delegates later (example), (c) sometimes they don't become delegates at all (example)

Open Questions

• How come that some originate+delegate operations register the caller as delegate and some do not?
• Before which block (if any specific block) or which release did an incoming transaction reactivate an inactive delegate? Is this still the case?