oasisprotocol / oasisprotocol/oasis-core

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

Open
#4,385 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

c:breaking/consensus c:upgrade
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.