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

Name/version in runtime #241

Closed
gavofyork opened this issue Jun 24, 2018 · 3 comments
Closed

Name/version in runtime #241

gavofyork opened this issue Jun 24, 2018 · 3 comments
Assignees
Labels
J0-enhancement An additional feature request. Z3-substantial Can be fixed by an experienced coder with a working knowledge of the codebase.

Comments

@gavofyork
Copy link
Member

gavofyork commented Jun 24, 2018

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.

@gavofyork gavofyork added this to the PoC-2 (Co-finalisation) milestone Jun 24, 2018
@gavofyork gavofyork added J0-enhancement An additional feature request. M4-core Z3-substantial Can be fixed by an experienced coder with a working knowledge of the codebase. labels Jun 24, 2018
@arkpar arkpar self-assigned this Jun 24, 2018
@arkpar arkpar mentioned this issue Jun 27, 2018
@arkpar
Copy link
Member

arkpar commented Jun 27, 2018

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.

This condition should not include authoring_version. Otherwise it is pointless to have authoring_version at all.

@gavofyork
Copy link
Member Author

gavofyork commented Jun 28, 2018

No - the original text was correct.

Authorship is a weaker requirement than runtime-substitution. So whereas authorship only requires authoring_version to be identical, swapping out wasm for the native version must fulfil the stronger condition of both authoring_version, spec_version and spec_name to all be identical.

@gavofyork
Copy link
Member Author

Actually, there is one addendum: authorship should require authoring_version and spec_name to be identical. But not spec_version.

JoshOrndorff added a commit to moonbeam-foundation/substrate that referenced this issue Apr 21, 2021
* remove relay block entropy from author filter

* bump spec version

* Fix array length

* cargo fmt
liuchengxu added a commit to chainx-org/substrate that referenced this issue Aug 23, 2021
* Need to resolve finalized paritytech#30

* Fixes unfinalized issue after 30 blocks

* Avoid invoke pcx_move

* Draft

* Split out

* Rebuild wasm

* Init session validators

* Quick fix for unfinalized issue

* Mul first
liuchengxu pushed a commit to chainx-org/substrate that referenced this issue Aug 23, 2021
Signed-off-by: koushiro <koushiro.cqx@gmail.com>
liuchengxu pushed a commit to autonomys/substrate that referenced this issue Jun 3, 2022
helin6 pushed a commit to boolnetwork/substrate that referenced this issue Jul 25, 2023
…h#242)

* implement session handling for unsubscribe in subxt-client

Signed-off-by: Gregory Hill <gregorydhill@outlook.com>

* update jsonrpsee to `v0.2.0-alpha.2`

Closes paritytech#241

* use new jsonrpsee request message types in subxt client

Signed-off-by: Gregory Hill <gregorydhill@outlook.com>

Co-authored-by: Niklas Adolfsson <niklasadolfsson1@gmail.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
J0-enhancement An additional feature request. Z3-substantial Can be fixed by an experienced coder with a working knowledge of the codebase.
Projects
None yet
Development

No branches or pull requests

2 participants