DOCSEARCHbyAlgolia
Submit Docs

Substrate Framework

repository·master·Indexed 27 days ago

https://github.com/paritytech/substrate

A next-generation framework for blockchain innovation. This legacy version of the framework has been consolidated into the Polkadot SDK, merging Substrate, Cumulus, and Polkadot into a single codebase. It includes tools for building node templates, configuring runtime pallets via FRAME, managing chain genesis state, and utilities like subkey for account generation and signature verification.

Tokens
84.5K
Snippets
146
Records
560
Agent score
94%

What's inside Substrate

  2. Overview of the Bounties Module (pallet-bounties)

    master

    The pallet-bounties module manages bounty spending proposals, which are rewards earmarked from the Treasury for specific bodies of work or objectives.

    Key Workflow:

    1. Proposal: A proposer earmarks a Treasury amount for tasks and stakes a deposit.
    2. Approval: The Council approves the bounty and funds it.
    3. Curation: A curator is assigned to manage the bounty and assign a payout address once objectives are met. The curator provides a deposit.
    4. Completion & Payout: Once work is completed, the curator closes the bounty, triggering a delayed payout to the payout address, the curator fee, and the return of the curator deposit.

    Important Constraints:

    • Treasury Coupling: This pallet is tightly coupled with pallet-treasury.
    • Sub-bounties: If using a ChildBountyManager, a parent bounty cannot be closed if it has any active child bounties.
    • Council Intervention: The Council can unassign a curator (triggering a new election) or cancel a bounty (slashing the curator's deposit) during the active or pending payout phases.

  3. Overview of the Session Pallet

    master

    The Session pallet enables validators to manage their session keys, control session lengths, and handle session rotation. It manages the transition between validator sets and provides mechanisms for both 'normal' (rewardable) and 'exceptional' (slashable) session rotations.

    Key Concepts

    • Session: A period of time with a constant set of validators, measured in block numbers. The end of a session is determined by the ShouldEndSession trait.
    • Session Key: A collection of keys used for various signing functions required by validators.
    • Validator ID: An identifier associated with an account. In staking systems, this is typically the stash account ID.
    • Session Key Configuration: Keys are set using set_keys for use in the session after next. They are stored in NextKeys and can be set before an account is even selected as a validator.
    • Session Rotation: At the start of a block, the pallet checks ShouldEndSession. If a session ends, new validator IDs and keys are activated from storage.

  4. Overview of the Contracts Module

    master

    The Contracts module enables the runtime to deploy and execute WebAssembly (Wasm) smart contracts. It extends accounts that implement the frame_support::traits::fungible trait, allowing them to become 'smart-contract accounts'.

    Key features:

    • Code Reuse: Smart-contract code is stored once and retrieved via a code_hash, allowing multiple contract instances to share the same underlying code.
    • State Management: Contract calls can alter the storage of the contract account, instantiate new contracts, or call other contracts.
    • Lifecycle: When a smart-contract account is reaped, its associated code and storage are also deleted.

  5. Overview of the Multisig Module

    master

    The Multisig module enables multi-signature dispatch, allowing multiple signed origins (accounts) to coordinate and dispatch a call from a well-known origin. This origin is deterministically derived from the set of account IDs and a specified threshold number of accounts required for approval.

    This is particularly useful for implementing multisig wallets in environments where cryptographic threshold signatures are unavailable or not desired. If the threshold is set to one, the operation becomes stateless.

  6. Overview of the Staking Module

    master

    The Staking module manages funds placed under deposit by network maintainers (validators/authorities). It facilitates the process of locking up funds to become a rewarded maintainer, while risking those funds through 'slashing' (expropriation) if duties are not performed correctly.

    Key concepts include:

    • Staking: Locking funds to become a rewarded maintainer.
    • Validating: Running a node to produce blocks or guarantee finality.
    • Nominating: Placing staked funds behind validators to share in their rewards and punishments.
    • Stash account: The account holding the funds used for staking.
    • Controller account: The account that issues instructions for the stash funds (Note: Controller accounts are being deprecated in favor of proxy accounts).
    • Era: A period of sessions used for recalculating the validator set and paying out rewards.
    • Slash: The reduction of a staker's funds as punishment.

  8. Overview of Statement Store

    master

    The Statement Store is an off-chain data-store designed for signed statements. It is accessible via RPC and Off-Chain Workers (OCW). Nodes maintain statements that include a proof of authenticity linked to an account ID.

    Key Access Methods:

    • OCWs: Can place items in the data-store (with valid signatures) for any accounts they control.
    • RPC: Users can submit pre-signed statements.
    • On-chain Logic: Statements can be submitted via the NewStatement system event. When using this method, the statement is accompanied by the block hash and the event index, which serves as the proof of authenticity.

  9. Overview of the Society Module

    master
    The Society module is an economic game designed to incentivize users to participate in and maintain a membership society. It uses a treasury-funded reward system to encourage active participation, such as voting on new candidates and defending existing memberships. The module manages various user roles, including Bidders, Candidates, Members, and specialized roles like the Head, Defenders, and Skeptics. It also implements a punishment mechanism via 'strikes' and slashing to ensure active engagement.

  10. Overview of the Scheduler module

    master

    The scheduler module provides capabilities for scheduling dispatches to occur at a specific block number or at a specified period. Dispatches can be named for easier identification or anonymous. They can also be canceled before they are executed.

    Important Security Note on Call Filters: Scheduled calls are dispatched using the default filter for the origin: frame_system::Config::BaseCallFilter for all origins except root (which receives no filter). Even if a call was originally scheduled using a proxy or another mechanism that applied a specific filter, that original filter is not used during dispatch. The dispatch relies on the system's base call filter.

  12. Overview of the Treasury Pallet

    master
    The Treasury pallet manages a central 'pot' of funds that can be used for system expenditures. It provides a structured mechanism for stakeholders to propose, approve, or deny spending from this pot. To function, the chain must implement a method for collecting funds into the treasury, such as inflation or transaction fees.