oasisprotocol / oasisprotocol/oasis-core
idea: Add a "reserved for future use" field to all of our descriptors
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 369
- Forks
- 151
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 6
Description
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by identifying all node descriptor types and the CBOR decoding paths they use; the issue does not name specific files or tests. Review how descriptor fields are validated and ignored by the consensus layer, then define the scope and compatibility rules before implementation. Done means the design is agreed and the required descriptors validate reserved fields without changing consensus behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- blockchain
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100