types: ensure that non-ephemeral types are upgradable

[dshulyak]

there are two kinds of types in the go-spacemesh:

1. ephemeral types

they are not stored on mesh, and need to remain decodable only within the context of some protocol. they will be versioned together with a sub-protocol itself.

for example hare is identified in the gossipsub with hr1, next version of the hare will have any other unique identifier, for example hr2. hr2 may use any types in the protocol, not necessarily hr1.

other ephemeral types and protocols:

• beacon
• proposals
• block certificate

2. types that are stored on mesh

such types should remain decodable by all future versions of the go-spacemesh. to make upgrade path future-proof we need to have some version as a first field, so that the rest of the payload can be decoded based on the value of the first field.

• block - layer id is a first field.
• ballot - layer id should be made a first field.
• activation - pub layer id should be made as a first field (within nipost challenge)

layer id will be used for protocol forks, when the fork is made go-spacemesh will be released with update that will decode specified objects (depending on the nature of the update) starting from layer X differently.

as an example consider ballot type.

currently votes are decoded into:

type Votes struct {
	// Base ballot.
	Base BallotID
	// Support and Against blocks that base ballot votes differently.
	Support, Against []BlockID
	// Abstain on layers until they are terminated.
	Abstain []LayerID
}

we could change this structure and add one more array with empty layers id (if it will make sense)

type Votes1100 struct {
	Base BallotID
	Support, Against []BlockID
	Abstain []LayerID 
        Empty []LayerID 
}

Starting from layer 1100 all ballots will be decoded using Votes1100.

3. special case:

• poet protocol the type itself doesn't need a version. as it can be decode either based on atx version, when we verify that challenge is included into the protocol. or based on protocol version, when object is accepted into the node.

[dshulyak]

@noamnelke @countvonzero @lrettig please review this task

[countvonzero]

for the sake of completeness, can you also explain how versioning for transactions is done? @dshulyak

[dshulyak]

for the sake of completeness, can you also explain how versioning for transactions is done?

there is a tx version as a first field.