3

I understand the concept of forkless updates, in that the code of the runtime is stored on the chain itself, and a runtime upgrade would entail updating this storage value on the chain. But looking at the polkadot node implementation on github, it is under quite active developement.

My question was, do these code changes affect the operation of the chain? Are changes to the node code irrelevant to the runtime? Can I make changes to the node code and still have it peer with other nodes running on an older version of the node but on the same runtime? Will only changes to runtime require a setCode call?

1 Answer 1

2

My question was, do these code changes affect the operation of the chain? Are changes to the node code irrelevant to the runtime?

Changes to the runtime and changes to the node are for the most part independent and thus runtime upgrades and individual nodes upgrading will not generally affect the operation of the chain.

Can I make changes to the node code and still have it peer with other nodes running on an older version of the node but on the same runtime?

In general, changes to node code can be made and nodes can be upgraded to this new code entirely independently of the client versions of other nodes on the same network.

Will only changes to runtime require a setCode call?

Changes to the runtime will only take effect when the network is upgraded using its governance procedure (which could be as simple as a sudo call) using setCode.

There are exceptions to the general rule of independence. To ensure a piece of node software works with a chain's runtime:

  • Any API entry points into the runtime (defined by impl_runtime_apis!) which the node software's client is expecting must be defined in the network's runtime.
  • Any API re-entry points back into the client (known as host functions) which the network's runtime is expecting must be defined in the node software's client.
  • Additionally, some types and data structures such as the hash format, block number and block header must be compatible.

To ensure that node software of differing versions work with each other, then in addition to the above, the network wire-format and protocols must be compatible. Nodes will generally retain only those peers which are vaguely respectful of the relationship. This is not especially well defined as different client software may have different expectations and peer-selection strategies. Roughly speaking clients should attempt to be as useful as possible to their peers while minimising the amount of information they ask for. Messages take resources to be processed and sending duplicate messages, out-of-date information or information which the sender could reasonably know is useless to the recipient are all considered bad form and may result in becoming kicked from the peerset.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.