Module polkadot_sdk_docs::reference_docs

Reference documents covering in-depth topics across the Polkadot SDK. It is suggested to read these on-demand, while you are going through the guides or other content.

Polkadot SDK Reference Docs.

This is the entry point for all reference documents that enhance one’s learning experience in the Polkadot SDK.

Note that this module also contains the glossary.

What is a “reference document”?

First, see why we use rust-docs for everything and our documentation principles. We acknowledge that as much of the crucial information should be embedded in the low level rust-docs. Then, high level scenarios should be covered in crate::guides. Finally, we acknowledge that there is a category of information that is:

1. crucial to know.
2. is too high level to be in the rust-doc of any one type, trait or fn.
3. is too low level to be encompassed in a crate::guides.

We call this class of documents “reference documents”. Our goal should be to minimize the number of “reference” docs, as they incur maintenance burden.

Modules

• blockchain_state_machines
  Learn about the way Substrate and FRAME view their blockchains as state machines.
• chain_spec_genesis
  Learn about chain specification file and the genesis state of the blockchain. Chain spec and genesis build.
• cli
  Learn about Substrate’s CLI, and how it can be extended.
• consensus_swapping
  Learn about Substrate’s consensus algorithms, and how you can switch between two. Consensus Swapping
• defensive_programming
  Learn about how to write safe and defensive code in your FRAME runtime. Defensive programming is a design paradigm that enables a program to continue running despite unexpected behavior, input, or events that may arise in runtime. Usually, unforeseen circumstances may cause the program to stop or, in the Rust context, panic!. Defensive practices allow for these circumstances to be accounted for ahead of time and for them to be handled gracefully, which is in line with the intended fault-tolerant and deterministic nature of blockchains.
• development_environment_advice
  Advice for configuring your development environment for Substrate development.
• extrinsic_encoding
  Learn about how extrinsics are encoded to be transmitted to a node and stored in blocks.
• fee_less_runtime
  Learn about how to make a pallet/runtime that is fee-less and instead uses another mechanism to control usage and sybil attacks.
• frame_benchmarking_weight
  Learn about benchmarking and weight.
• frame_offchain_workers
  Learn about the offchain workers, how they function, and how to use them, as provided by the frame APIs.
• frame_origin
  Learn about Origins, a topic in FRAME that enables complex account abstractions to be built.
• frame_pallet_coupling
  Learn about the different ways through which multiple frame pallets can be combined to work together.
• frame_runtime_types
  Learn about composite enums and other runtime level types, such as “RuntimeEvent” and “RuntimeCall”.
• frame_runtime_upgrades_and_migrations
  Learn about Runtime Upgrades and best practices for writing Migrations.
• frame_system_accounts
  Learn about how frame-system handles account-ids, nonces, consumers and providers.
• frame_tokens
  Learn about the token-related logic in FRAME and how to apply it to your use case.
• glossary
  The glossary.
• light_nodes
  Learn about light nodes, how they function, and how Substrate-based chains come light-node-first out of the box.
• metadata
  Learn about metadata, the main means through which an upgradeable runtime communicates its properties to the outside world.
• runtime_vs_smart_contract
  Learn about the differences between smart contracts and a FRAME-based runtime. They are both “code stored onchain”, but how do they differ?
• signed_extensions
  Learn about the signed extensions that form a part of extrinsics. Signed extensions are, briefly, a means for different chains to extend the “basic” extrinsic format with custom data that can be checked by the runtime.
• trait_based_programming
  Learn how Substrate and FRAME use traits and associated types to make modules generic in a type-safe manner.
• wasm_memory
  Learn about all the memory limitations of the WASM runtime when it comes to memory usage.
• wasm_meta_protocol
  Learn about the WASM meta-protocol of all Substrate-based chains.