There are a lot of tricks and nuances to using storage in Substrate.

• Supported storage types (found here)

  • StorageValue
  • StorageMap
  • StorageDoubleMap
  • HashedStorage/UnhashedStorage (This may be just an implementation detail we should briefly talk about, but not go deep into)
  • LinkedMap/EnumerableStorageMap
  • other...?

• Implications of using different storage types for efficiency

• Using Vec, implications of letting users input the value for this

• Storage API: get, put, insert, take, append, etc...

• Storing Structs (advance things)

• Storage Upgrades or Migrations, how and when it is possible

• Charging fees for users storing items

• Genesis configuration, default value, "add extra genesis"

• decl_storage macro in general

• using the Polkadot UI for a number of different storage scenarios

• more?

@thiolliere may be able to help us here with the details of some of these things if he is so kind :)

Update 3/25/19:

I think it is reasonable hypothesis that people who are looking to develop on Substrate are familiar with or have worked with Solidity in the past. People who are less technical may be able to evaluate which kinds of apps would be suitable as an Ethereum smart contract (business oriented) and those who are actual contract developers may have developed thought processes or patterns for smart contract development.

I want to have a doc which specifically targets these people who are "comfortable" with Ethereum, and states clearly the differences in thinking and development when building on substrate.

For example:

• What sorts of projects would be good for Ethereum Smart Contracts vs Substrate Runtime Module, and why?
• Substrate is inherently a fee-less system, and how that affects your development and functions you can build
• Storing only critical blockchain specific data on chain, not strings and other random stuff
• Bricking your chain with bad code
• Verify first, Write Last vs Revert
• How to write modular substrate modules versus how you might do the same with solidity
• etc...

Hello, as I've noticed original repo is frozen

I wanted to add to https://substrate.dev/en/users.html

• https://kodadot.xyz
• https://starmesh.xyz

  {
    "name": "Starmesh",
    "image": "",
    "homepage": "https://starmesh.xyz/",
    "github": "https://github.com/starmesh/",
    "pinned": false,
    "type": "chain",
  },

No need to hurry, just found there was an expectation to be fully migrated on 26/3.
I can still make PR to old one, but that would add some mess to the migration process.
I can wait, no hurry.

Given a module A which has a dependency on module B, show how you can build module C which can be swapped with B.

Teaches:

• How to use traits properly
• Required Functions and Implemented Functions
• Making a module have no direct dependency on another module
• Building two modules which satisfy the conditions
• Some live/practical example of swapping the two

The diagram at https://substrate.dev/docs/en/#usage still mentions the "SRML". That should be changed to "FRAME".

The file itself is https://github.com/substrate-developer-hub/substrate-developer-hub.github.io/blob/source/docs/assets/technical-freedom.png

We often find bits of Substrate interesting but not sure where it fits into the docs. Keeping this issue open to comment in if you find some tidbits that you think are worth sharing but not sure where. Once we have a list, we might see a logical way of combining them.

This is feedback from one of the community members. The initial requirements are:

Is there a reason that all these tutorials, like this one (https://substrate.dev/docs/en/tutorials/start-a-private-network-with-substrate) are installing and using local rustc versions and not using docker with all this built inside? (or something like that).
I'm working on multiple projects with different versions of rust and there are always some problems with rust nightly versions that are installed and that give errors while running this scripts inside.
Although this is not a problem with project itself but with rustc and the way it works, all this could be bypassed by building docker images that contain all this things inside. The flow would be much simpler especially for new users by using docker.

A few potential solutions for docker usage could be:

• Add steps for docker usage in the Install Substrate page
• Add section to start a blockchain with docker in one of the tutorils, like PoE.

• Content coming from:
  https://github.com/paritytech/substrate/tree/6ae3b6c4ddc03d4cdb10bd1d417b95d20f4c1b6e#7-key-management
• Decide where is the best place for this content to goto.
• Original request coming from @bkchr

Substrate offers few different hash algorithm, and for double_map, developer have to pick which one to use for first key and second key.

It will be good if there is a documentation on the pros and cons for each algorithm and how to decide which hasher to use.

I think this is all we have so far, which describes when to use blake2_256 but not other hashers.

/// If the first key is untrusted, a cryptographic hasher such as blake2_256 must be used.
/// Otherwise, other values of all storage items can be compromised.
///
/// If the second key is untrusted, a cryptographic hasher such as blake2_256 must be used.
/// Otherwise, other items in storage with the same first key can be compromised.
///
/// Supported hashers (ordered from least to best security):
///
/// * twox_64_concat - TwoX with 64bit + key concatenated.
/// * twox_128 - TwoX with 128bit.
/// * twox_256 - TwoX with with 256bit.
/// * blake2_128 - Blake2 with 128bit.
/// * blake2_256 - Blake2 with 256bit.

https://github.com/paritytech/substrate/blob/8cbfc10a28aafb6aec5487eebca16116f45bbf84/srml/support/procedural/src/lib.rs#L88-L92

Both the Adding a pallet to your runtime as well as the Creating an external pallet lack details on how to pull in dependecies like, e.g., the Randomness trait. We should create some documentation on how dependencies are pulled in.

A new functionality was implemented in the docs but it requires to have instructions on its own box or use an operator to handle multiples commands.

substrate-node-new substrate-node-template <author-name>
substrate-ui-new substrate

Change to:

substrate-node-new substrate-node-template <author-name>

substrate-ui-new substrate

Or:

substrate-node-new substrate-node-template <author-name> && substrate-ui-new substrate

In the older runtime recipes that I deleted in 1495d8616b40, There was a section called "Print a message" which showed how to output simple debugging logs. That is not in the new https://substrate.dev/recipes .

I recently saw @shawntabrizi recommend instead to

1. Compile wasm
2. Add println!s
3. Compile native

Is this a better approach?

Original

Sometimes we need to print debug messages while building applications. This recipe shows how to print messages for debugging your Substrate runtime code.

You need to include runtime_io crate from the Substrate core in order to use IO functions from within the runtime modules.

use support::{decl_module, dispatch::Result};
use runtime_io;
pub trait Trait: system::Trait {}
decl_module! {
  pub struct Module<T: Trait> for enum Call where origin: T::Origin {
    pub fn print_something(_origin) -> Result {
      // the following line prints a message on the node's terminal/console
      runtime_io::print(Hello World from Substrate Runtime!);
      Ok(())
    }
  }
}

When this function is executed, the message will appear on the terminal where the Substrate node is running. The following screenshot shows the printed message.