Skip to content
This repository was archived by the owner on Nov 15, 2023. It is now read-only.
This repository was archived by the owner on Nov 15, 2023. It is now read-only.

Name/version in runtime #241

@gavofyork

Description

@gavofyork

This should add an entry to the API that returns a Slicable struct:

struct RuntimeVersion {
	spec_name: String,  // "polkadot"
	impl_name: String,  // "parity-polkadot"
	authoring_version: u32,  // "0"
	spec_version: u32,  // "0"
	impl_version: u32,  // "0"
}

The fields have very particular meanings:

  • spec_name identifies the different Substrate runtimes. There'll be at least polkadot and demo. A different on-chain spec_name to that of the native runtime would normally result in node not attempting to sync further.
  • impl_name Is the name of the implementation of the spec. This is of little consequence for the node and serves only to differentiate code of different implementation teams. For this codebase, it will be parity-polkadot. If there were a non-Rust implementation of the Polkadot runtime (e.g. C++), then it would identify itself with an accordingly different impl_name.
  • authoring_version is the version of the authorship interface. An authoring node will not attempt to author blocks unless this is equal to its native runtime.
  • spec_version is the version of the runtime specification. A full-node will not attempt to use its native runtime in substitute for the on-chain Wasm runtime unless all of spec_name, spec_version and authoring_version are the same between Wasm and native.
  • impl_version is the version of the implementation of the specification. Nodes are free to ignore this; it serves only as an indication that the code is different; as long as the other two versions are the same then while the code may be different, it is nonetheless required to do the same thing. Non-consensus-breaking optimisations are about the only changes that could be made which would result in only the impl_version changing.

NOTE: This should not be thought of as classic Semver (major/minor/tiny). This triplet have different semantics and mis-interpretation could cause problems. In particular: bug fixes should result in an increment of spec_version and possibly authoring_version, absolutely not impl_version since they change the semantics of the runtime.

Metadata

Metadata

Assignees

Labels

J0-enhancementAn additional feature request.Z3-substantialCan be fixed by an experienced coder with a working knowledge of the codebase.

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions