Skip to content

Commit

Permalink
vale
Browse files Browse the repository at this point in the history
  • Loading branch information
@CrackTheCode016
CrackTheCode016 committed Sep 10, 2024
1 parent 868bd8d commit 53a5ed6
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions develop/parachain-devs/parachain-maintenance/runtime-upgrades.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ Because the runtime is part of the blockchain state, network maintainers can lev

In the FRAME system for runtime development, the system library defines [the `set_code` call](https://paritytech.github.io/substrate/master/frame_system/pallet/enum.Call.html#variant.set_code) that is used to update the definition of the runtime.

When updating a runtime, there is a differentiation in _adding_ functionality to the runtime versus _updating_ existing functionality. In many cases, updating existing functionality, such as how a pallet stores state, would require a storage migration.
When updating a runtime, there is a differentiation in _adding_ functionality to the runtime versus _updating_ existing functionality. In many cases, updating existing functionality, such as how a pallet stores state, would require a storage migration.

## Runtime versioning

Expand All @@ -33,8 +33,8 @@ The parameters in the struct provide the following information:
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `spec_name` | The identifier for the different Substrate runtimes. |
| `impl_name` | 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. |
| `authoring_version` | 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` | 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 the Wasm and native binaries. Updates to the `spec_version` can be automated as a CI process, as is done for the [Polkadot network](https://gitlab.parity.io/parity/mirrors/polkadot/-/blob/master/scripts/ci/gitlab/check_extrinsics_ordering.sh). This paramenter is typically incremented when there's an update to the `transaction_version`. |
| `authoring_version` | The version of the authorship interface. An authoring node won't attempt to author blocks unless this is equal to its native runtime. |
| `spec_version` | The version of the runtime specification. A full node won't 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 the Wasm and native binaries. Updates to the `spec_version` can be automated as a CI process, as is done for the [Polkadot network](https://gitlab.parity.io/parity/mirrors/polkadot/-/blob/master/scripts/ci/gitlab/check_extrinsics_ordering.sh). This parameter is typically incremented when there's an update to the `transaction_version`. |
| `impl_version` | The version of the implementation of the specification. Nodes can ignore this. It is only used to indicate that the code is different. As long as the `authoring_version` and the `spec_version` are the same, the code itself might have changed, but the native and Wasm binaries do the same thing. In general, only non-logic-breaking optimizations would result in a change of the `impl_version`. |
| `transaction_version` | The version of the interface for handling transactions. This parameter can be useful to synchronize firmware updates for hardware wallets or other signing devices to verify that runtime transactions are valid. The parameter allows hardware wallets to know which transactions they can safely sign. This number must be bumped if there is a change in the index of the pallets in the `construct_runtime!` macro or if there are any changes to dispatchable functions, such as the number of parameters or parameter types. If this number is updated, then the `spec_version` must also be updated. |
| `apis` | A list of supported [runtime APIs](https://paritytech.github.io/substrate/master/sp_api/macro.impl_runtime_apis.html) along with their versions. |
Expand Down

0 comments on commit 53a5ed6

Please sign in to comment.