substrate-node-template | A new SRML-based Substrate node | Runtime Evironment library

In Substrate 3.0 you use the same construct_runtime! macro in tests that you use in the full runtime. You can see an example of how to test events the new way in the Substrate repository itself.

https://github.com/paritytech/substrate/blob/83942f58fc859ef5790351691e1ef665d79f0ead/frame/balances/src/tests.rs#L470-L473

Rust compilations are not deterministic, thus the exact same code for the exact same blockchain compiled on two computers will unfortunately not have the same genesis hash. (Specifically because part of the genesis of that chain is the Wasm Runtime blob, which is compiled non-deterministically with Rust).

You need to create a chainspec file to use for all other nodes. Note that you want to generate this on one computer, and pass the file to other nodes (don't re-generate it, as the genesis code will differ, as you ran into) before you then start other nodes using the correct chainspec and manually specifying boot nodes.

This is not a substrate question.

Try to use a VPN. Or use a mirror source.

@kmdreko is right. You do not want to convert the block number to an integer, but convert the integer into a block number and then do the math.

So replace:

The compile is not stuck in compilation, it is just taking a while due to the 800+ dependencies. From @gnunicorn on this github issue:

Rust isn't particular quick with the compiling at the moment and opaque to the person in front, at this step (when compiling node-template-runtime) we are actually building the project twice: once natively and once in wasm. So at some step in between it appears as if nothing happens and that can take up to half the total build time – if the other part took e.g. 10minutes then this process might take another 10min without any indicator of process (other than the CPU pumping hard).

You are doing a release build (cargo build --release) which enables optimizations. For development purposes, a regular build or just a cargo check will be substantially faster.

Some comments in the linked GitHub issue mentioned that running a cargo clean and rebuilding helped speed up compile times, so you can try that as well.

Solution: as JoshOrndorff stated in a Github issue:

[...] The problem now is because the UI needs to know the types your node uses. When you use the node template, the UI detects it, and uses the appropriate types for you. Sine you have renamed your template, the UI cannot tell that it is still basically the node template, so you need to add your own custom types. In the Apps UI, go the the developer settings, and enter:

I (thanks to Dan) solved it by execution:

Apparently this macro accepts custom syntax, as documented in https://substrate.dev/rustdocs/v2.0.0-rc5/frame_support/macro.decl_storage.html:

Basic storage can be extended as such:

#vis #name get(fn #getter) config(#field_name) build(#closure): #type = #default;

• #vis: Set the visibility of the structure. pub or nothing.
• #name: Name of the storage item, used as a prefix in storage.
• [optional] get(fn #getter): Implements the function #getter to Module.
• [optional] config(#field_name): field_name is optional if get is set. Will include the item in GenesisConfig.
• [optional] build(#closure): Closure called with storage overlays.
• #type: Storage type.
• [optional] #default: Value returned when none.

So in your Something is the name of the storage item, used as a prefix in storage.

You should be using a hash of known size, so do something like: