在基板运行时的主lib.rs
中(以及在模板节点中),有几个可以更改的版本属性-我猜测是要跟踪各种构建版本-但目前尚不清楚在我们自己的项目中使用它们。
1)它们是干什么的?在我们自己的项目中增加这些期望值是什么?
2)这些或组合中的任何一个是否旨在表示与我们的运行时的先前版本不兼容,例如,递增表示该新版本与存储,共识或其他可能预期的方面不兼容造成网络中的分叉?
pub const VERSION: RuntimeVersion = RuntimeVersion {
spec_name: create_runtime_str!("node"),
impl_name: create_runtime_str!("substrate-node"),
authoring_version: 10,
spec_version: 99,
impl_version: 104,
apis: RUNTIME_API_VERSIONS,
};
答案 0 :(得分:2)
运行时版本控制是基于Substrate的区块链的“无叉运行时升级”功能的重要组成部分。
发帖时来自core/sr-version
,
/// Runtime version.
/// 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.
#[derive(Clone, PartialEq, Eq, Encode)]
#[cfg_attr(feature = "std", derive(Debug, Serialize, Decode))]
#[cfg_attr(feature = "std", serde(rename_all = "camelCase"))]
pub struct RuntimeVersion {
/// Identifies the different Substrate runtimes. There'll be at least polkadot and node.
/// A different on-chain spec_name to that of the native runtime would normally result
/// in node not attempting to sync or author blocks.
pub spec_name: RuntimeString,
/// 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`.
pub impl_name: RuntimeString,
/// `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.
pub authoring_version: u32,
/// 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.
pub spec_version: u32,
/// 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 actual code may be different, it is nonetheless required to
/// do the same thing.
/// Non-consensus-breaking optimizations are about the only changes that could be made which
/// would result in only the `impl_version` changing.
pub impl_version: u32,
/// List of supported API "features" along with their versions.
#[cfg_attr(feature = "std", serde(serialize_with = "apis_serialize::serialize"))]
pub apis: ApisVec,
}
spec_version
用于表示关键共识逻辑是否已更改,而impl_version
用于表示不会影响网络共识的更改。例如,如果函数的行为在运行时中发生变化,则必须增加spec_version
以注意此版本的运行时不会与另一版本的运行时达成共识。而如果仅对函数进行了优化,但是结果却是相同的,则仅需impl_version
即可。
使用spec_version
,节点能够确定运行时的本地版本(实际运行该节点的本地可执行文件)是否与运行时的Wasm版本(存储在链上和网络上)匹配已经达成共识)。
如果运行时的本地spec_name
,authoring_version
和spec_version
与Wasm运行时的版本匹配,则使用本地运行时而不是Wasm运行时,因为它执行起来更快。在spec_version
不完全匹配的情况下,该节点将退回以使用运行时的Wasm版本,以确保该节点与网络的其余部分保持一致。
如果您想遵循这种代码路径,可以从core/sr-version
开始。
impl RuntimeVersion {
/// Check if this version matches other version for calling into runtime.
pub fn can_call_with(&self, other: &RuntimeVersion) -> bool {
self.spec_version == other.spec_version &&
self.spec_name == other.spec_name &&
self.authoring_version == other.authoring_version
}
...
}
然后,如果您进入core/executor/native_executor.rs
,将看到can_call_with
函数用于确定是否可以使用本机运行时。
编辑:重要的是要注意,块构建执行引擎始终默认为Wasm,而导入执行引擎则尽可能使用上述逻辑尝试使用本机。