Misc Versions in Node Codebase

(This post is just for QoL of developers, to memorize those all kinds of versions which are quite important sometimes, especially for upgrading and backward compatibility related topics.)

  1. ProtocolVersion

In core/src/global.rs, there’s a PROTOCOL_VERSION const which is the default “local” protocol version for this node.

So far 1,2,3 have been used in mwc.

  • 1 for [ < 3.0.0] releases. with the 1st version of TxKernel structure (see below link).
  • 2 for [3.0.0 ~ 4.1.0] releases. transaction kernels changed in v2 due to “variable size kernels”.
  • 3 for [4.2.0 ~ current] releases. transaction input changed in v3 due to “commit only” inputs upgrading.

mwc will bump the protocol version to 1000 in next HF (v6.0.0) for NIT.

So far, peers with all protocol versions can talk to each other, including 1000.

In the future, for example, when we bump the protocol version to 2000, the peers with “1,2,3” versions will be kicked out. This will be helpful to throw the burden of those very old versions, to avoid those boring backward compatibility on quite old versions.

  • 1st version of TxKernel structure: {features: 1byte, fee: 8bytes, lock_height: 8bytes, excess: 33, sig: 64}
  • v2 TxKernel structure for “variable size kernels”:
  • Kernel note: (1) kernel hash always in serialization with v1 format! (2) kernel serialization for p2p broadcasting will handle the protocol versions.
  1. HeaderVersion

This is the block header version, which is normally used for hardfork only. So far, mwc has used 1 and 2, because we only had one hardfork till now.

mwc will bump this header version to 3 in next hardfork (v6.0.0) for [NIT].

  1. Backend database version.

This is the database version which is useful to migrate the database on upgrading. Database version reused the same data as ProtocolVersion but obviously in different context.

So far, version 1,2,3 have been used.

  • 2 is used for [3.0.0 ~ 4.1.0] release, transaction kernels changed in v2 due to “variable size kernels”.
  • 3 is used for [4.2.0 ~ current], transaction input changed in v3 due to “commit only” inputs upgrading.

Note: the database migration can not jump versions. For example, migration from v2 to v3 is ok, but it’s not ok from v1 to v3. In another word, release 2.x.x can not upgrade to 4.x.x directly.


  1. Backend MMR data file version.

This is the MMR data file version which is useful to migrate the MMR data on upgrading. MMR data file version also reused the same data as ProtocolVersion but obviously in different context.

Different MMR data file can use different version.

So far, only version 1 has been used for output/rangeproof/header/sync MMRs. For kernel MMR, version 1 and 2 have been used.

  • 1 is used for [ … ~ 2.x.x] release.
  • 2 is used for [3.0.0 ~ current] release, transaction kernels changed in v2 due to “variable size kernels”.