substrate - 如何正确升级Substrate节点上的运行时？

Question

跟随创建第一个底物链，一切正常。

然后，我想进一步走一步，在demo.rs文件上自定义我的代码，这是我正在做的事情:

用代码demo.rs完全替换here中的代码，现在有事件参与
。

使用

更新 lib.rs

Demo: demo::{Module, Call, Storage, Event<T>},  

和

impl demo::Trait for Runtime {
    type Event = Event;
}

运行./scripts/build.rs

运行./target/release/node-name --dev

然后，我看到更新的外部函数未在 Polkadot Web App上列出，或者通过按照 step 5 on tutorial上传 substrate_node_template_runtime_wasm.compact.wasm文件

因此，我必须运行以下代码来进行更新:

rm -rf ./target
cargo build --release
./target/release/node-name --dev

通过与@shawntabrizi讨论，他建议使用以下命令

./scripts/build.sh
cargo build --release
./target/release/node-name purge-chain --dev
./target/release/node-name --dev

似乎没有 purge-chain， substrate_node_template_runtime_wasm.compact.wasm和 ./target/release/node-name都不会更新。

引用 here

By upgrading the runtime, you're simply switching out the block of code that is going to be receiving extrinsics and reading storage.

但是我想更深入地了解一下，当升级运行时节点时， build.sh和 cargo build之间有什么区别？是否因为上述情况下 substrate_node_template_runtime_wasm.compact.wasm和/或 ./target/release/node-name二进制文件未更新？

Answer 1

让我们尝试解决您提出的一些不同主题:

what is the difference behind build.sh and cargo build

Substrate运行时被编译为 native 二进制文件和Wasm Blob。在Substrate v1.0中，这些编译步骤是分开的。 build.sh将您的运行时编译为Wasm，而 cargo build编译您的整个节点(如CLI，数据库等)，包括运行时的 native 版本。

It seems that without purge-chain both the substrate_node_template_runtime_wasm.compact.wasm and ./target/release/node-name are not updated.

重要的是要了解此处背景中发生的细节。当您运行节点时，具有本地链状态的数据库存储在本地。因此，如果使用 ./target/release/node-name --dev启动一个节点有50个块，请停止该节点，然后再次启动它，该节点将在您上次中断的地方继续(在块51)。

请记住，作为节点的创始配置的一部分，Runtime Wasm存储在链上，应该运行的运行时的 used to determine which version( native vs Wasm)。

如果重新编译Wasm和 native 二进制文件，然后不做任何其他操作就运行 ，则不会有任何区别。即使您的节点二进制文件是全新的并且已更新，它也使用具有旧链状态的相同 数据库。这意味着在数据库中，您还将拥有旧的Wasm，并且当节点执行此操作时，将检查要使用的版本，它将回退以使用数据库中的Wasm!

如果希望节点提取所做的最新更改，则可以执行以下两项操作之一:

触发Wasm运行时的链上升级。这将使您的数据库具有最新的运行时代码，因此您的节点将使用最新的更改。

清除链条以重新开始创世。这将删除您的Substrate区块链的任何旧状态，并最终使用最新的Wasm运行时填充链状态，这应与您的节点一致。

我的建议:

./scripts/build.sh
cargo build --release
./target/release/node-name purge-chain --dev
./target/release/node-name --dev

将执行第二种方法，清理数据库，并在每次升级运行时逻辑时从块0重新启动节点。在开发运行时时，这通常是最容易做的事情，因为在执行运行时升级时，有许多因素可能导致意外的行为。

I changed most of the code, and add Event in it.

不幸的是，您在这里没有共享任何代码，这可能有助于调试此问题。尽管需要特别注意的是，您不能对运行时的每次更新都使用运行时升级功能。

您应该将区块链视为两个可以协同工作的独立部分:

区块链存储

区块链逻辑

当您进行升级时，您基本上是将区块链逻辑从一件事换成另一件事。从技术上讲，您可以从字面上交换任何内容。但是实际上，这并不意味着它将起作用。如果您的新逻辑不了解您当前的区块链存储，那么您将打破链条。

因此，假设您对函数进行了更改，假设您拥有的存储项与以前完全不同....结果不会很好。

通常，添加更改对于运行时升级就很好。由于新功能不会影响旧功能，因此您的存储应始终能够与新的运行时一起正常工作。但是，如果您进行运行时升级时假设区块链存储发生了某些变化，那么您将需要在实际执行任何运行时逻辑之前触发这些存储项的迁移。您可以通过一次性on_initialize调用来完成此操作，该调用会将一组存储项转换为新格式，但是当您谈到迁移大量数据时，实现细节开始出现。

总之，总的来说，围绕运行时进行升级的因素太多，可能会引起问题，也许就像您所看到的那样。通常，不应使用运行时升级来进行初始开发。相反，通常应该清除链并在运行时的迭代之间从头开始。