idea: Add a "reserved for future use" field to all of our descriptors

[Yawning]

The design

To enable a more easy transition assuming we ever do another breaking upgrade in the future (after the upcoming one), it may be beneficial to add a reserved field to each of our node descriptors, that is checked for CBOR validity, but otherwise ignored by the consensus layer.

Tentatively my initial thoughts are along the lines of:

type MyAmazingDescriptor struct {
  // Other fields elided.

  ReservedForFutureExpansion cbor.RawMessage `json:"reserved_for_future_expansion,omitempty"`
}

Defining the "version" on a per-breaking upgrade basis, interacting with the field will work like thus:

• Add field: MAY at any time, name MUST be unique.
• Parse/Inspect field: MUST only parse fields that were added in the prior version.
• Remove field: MAY at any time prior to the first upgrade. MUST NOT remove fields that are parsed at any point during a subsequent version's validity.

Example deployment

We decide to switch committee elections to be based off entropy harvested by nodes that have an array of webcams, watching lava laps. The node descriptor needs a new field Lava *LavaInfo, to indicate that the node has the appropriate hardware.

Prior to the Lava Update, we deploy a non-consensus breaking upgrade that adds ReservedForFutureExpansion.Lava. Beyond being checked for well-formedness (from a CBOR point of view), the field is ignored.

At the Lava Update, we run fixgenesis to drop nodes that have malformed ReservedForFutureExpansion.Lava. ReservedForFutureExpansion.Lava has it's semantics fixed for the duration of the Lava Update consensus version. Nodes transition to using Node.Lava instead of ReservedForFutureExpansion.Lava in their registrations. Honoring the ReservedForFutureExpansion.Lava field can be a genesis epoch only thing as well.

The update after the Lava Update, we can drop nodes that still provide ReservedForFutureExpansion.Lava as part of fixgenesis.