Module substrate::substrate_diagram

In this module, we explore substrate at a more depth. First, let’s establish substrate being divided into a client and runtime.

graph TB subgraph Substrate direction LR subgraph Client end subgraph Runtime end end

The client and the runtime of course need to communicate. This is done through two concepts:

1. Host functions: a way for the (Wasm) runtime to talk to the client. All host functions are defined in sp-io. For example, sp-io::storage are the set of host functions that allow the runtime to read and write data to the on-chain state.
2. Runtime APIs: a way for the client to talk to the Wasm runtime. Runtime APIs are defined using macros and utilities in sp-api. For example, sp-api::Core is the most basic runtime API that any blockchain must implement in order to be able to (re) execute blocks.

graph TB subgraph Substrate direction LR subgraph Client end subgraph Runtime end Client --runtime-api--> Runtime Runtime --host-functions--> Client end

Finally, let’s expand the diagram a bit further and look at the internals of each component:

graph TB subgraph Substrate direction LR subgraph Client Database Networking Consensus end subgraph Runtime subgraph FRAME direction LR Governance Currency Staking Identity end end Client --runtime-api--> Runtime Runtime --host-functions--> Client end

As noted the runtime contains all of the application specific logic of the blockchain. This is usually written with FRAME. The client, on the other hand, contains reusable and generic components that are not specific to one single blockchain, such as networking, database, and the consensus engine.