mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-06-13 17:31:05 +00:00
Rename Palette to FRAME (#4182)
* palette -> frame * PALETTE, Palette -> FRAME * Move folder pallete -> frame * Update docs/Structure.adoc Co-Authored-By: Benjamin Kampmann <ben.kampmann@googlemail.com> * Update docs/README.adoc Co-Authored-By: Benjamin Kampmann <ben.kampmann@googlemail.com> * Update README.adoc
This commit is contained in:
Shawn Tabrizi
@@ -40,22 +40,22 @@
|
||||
/primitives/rpc/ @tomusdrw
|
||||
|
||||
# GRANDPA, BABE, consensus stuff
|
||||
/palette/babe/ @andresilva @DemiMarie-parity
|
||||
/palette/grandpa/ @andresilva @DemiMarie-parity
|
||||
/frame/babe/ @andresilva @DemiMarie-parity
|
||||
/frame/grandpa/ @andresilva @DemiMarie-parity
|
||||
/client/finality-grandpa/ @andresilva @DemiMarie-parity
|
||||
/client/consensus/babe/ @andresilva @DemiMarie-parity
|
||||
/client/consensus/slots/ @andresilva @DemiMarie-parity
|
||||
|
||||
# Contracts
|
||||
/palette/contracts/ @pepyakin @thiolliere @jimpo
|
||||
/palette/contracts/src/wasm/runtime.rs @Robbepop
|
||||
/frame/contracts/ @pepyakin @thiolliere @jimpo
|
||||
/frame/contracts/src/wasm/runtime.rs @Robbepop
|
||||
|
||||
# Inflation points
|
||||
/palette/staking/src/inflation.rs @thiolliere
|
||||
/frame/staking/src/inflation.rs @thiolliere
|
||||
|
||||
# NPoS and Governance
|
||||
/palette/staking/ @kianenigma
|
||||
/palette/election/ @kianenigma
|
||||
/frame/staking/ @kianenigma
|
||||
/frame/election/ @kianenigma
|
||||
|
||||
# End to end testing of substrate node
|
||||
/bin/node/executor/ @kianenigma
|
||||
@@ -64,4 +64,4 @@
|
||||
/primitives/sr-primitives/src/weights.rs @kianenigma
|
||||
|
||||
# Support crates
|
||||
/palette/support/ @thiolliere @kianenigma
|
||||
/frame/support/ @thiolliere @kianenigma
|
||||
|
||||
@@ -24,7 +24,7 @@ Substrate is designed for use in one of three ways:
|
||||
|
||||
**1. Trivial**: By running the Substrate binary `substrate` and configuring it with a genesis block that includes the current demonstration runtime. In this case, you just build Substrate, configure a JSON file, and launch your own blockchain. This affords you the least amount of customizability, primarily allowing you to change the genesis parameters of the various included runtime modules such as balances, staking, block-period, fees, and governance.
|
||||
|
||||
**2. Modular**: By hacking together modules from the Substrate Runtime Module Library (SRML) into a new runtime and possibly altering or reconfiguring the Substrate client's block authoring logic. This affords you a very large amount of freedom over your blockchain's logic, letting you change datatypes, add or remove modules, and crucially, add your own modules. Much can be changed without touching the block authoring logic (since it is generic). If this is the case, then the existing Substrate binary can be used for block authoring and syncing. If the block authoring logic needs to be tweaked, then a new, altered block authoring binary must be built as a separate project and used by validators. This is how the Polkadot relay chain is built and should suffice for almost all circumstances in the near to mid-term.
|
||||
**2. Modular**: By hacking together pallets built with Substrate FRAME into a new runtime and possibly altering or reconfiguring the Substrate client's block authoring logic. This affords you a very large amount of freedom over your blockchain's logic, letting you change datatypes, add or remove modules, and crucially, add your own modules. Much can be changed without touching the block authoring logic (since it is generic). If this is the case, then the existing Substrate binary can be used for block authoring and syncing. If the block authoring logic needs to be tweaked, then a new, altered block authoring binary must be built as a separate project and used by validators. This is how the Polkadot relay chain is built and should suffice for almost all circumstances in the near to mid-term.
|
||||
|
||||
**3. Generic**: The entire SRML can be ignored and the entire runtime designed and implemented from scratch. If desired, this can be done in a language other than Rust, provided it can target WebAssembly. If the runtime can be made compatible with the existing client's block authoring logic, then you can simply construct a new genesis block from your Wasm blob and launch your chain with the existing Rust-based Substrate client. If not, then you'll need to alter the client's block authoring logic accordingly. This is probably a useless option for most projects right now, but provides complete flexibility allowing for a long-term, far-reaching upgrade path for the Substrate paradigm.
|
||||
|
||||
@@ -43,9 +43,9 @@ Extrinsics in Substrate are pieces of information from "the outside world" that
|
||||
|
||||
Inherents, meanwhile, are not passed on the network and are not signed. They represent data which describes the environment but which cannot call upon anything to prove it such as a signature. Rather they are assumed to be "true" simply because a sufficiently large number of validators have agreed on them being reasonable.
|
||||
|
||||
To give an example, there is the timestamp inherent, which sets the current timestamp of the block. This is not a fixed part of Substrate, but does come as part of the Substrate Runtime Module Library to be used as desired. No signature could fundamentally prove that a block were authored at a given time in quite the same way that a signature can "prove" the desire to spend some particular funds. Rather, it is the business of each validator to ensure that they believe the timestamp is set to something reasonable before they agree that the block candidate is valid.
|
||||
To give an example, there is the timestamp inherent, which sets the current timestamp of the block. This is not a fixed part of Substrate, but does come as part of FRAME to be used as desired. No signature could fundamentally prove that a block were authored at a given time in quite the same way that a signature can "prove" the desire to spend some particular funds. Rather, it is the business of each validator to ensure that they believe the timestamp is set to something reasonable before they agree that the block candidate is valid.
|
||||
|
||||
Other examples include the parachain-heads extrinsic in Polkadot and the "note-missed-proposal" extrinsic used in the Substrate Runtime Module Library to determine and punish or deactivate offline validators.
|
||||
Other examples include the parachain-heads extrinsic in Polkadot and the "note-missed-proposal" extrinsic used in FRAME to determine and punish or deactivate offline validators.
|
||||
|
||||
|
||||
=== Runtime and API
|
||||
@@ -78,7 +78,7 @@ impl_runtime_apis! {
|
||||
|
||||
=== Inherent Extrinsics
|
||||
|
||||
The Substrate Runtime Module Library includes functionality for timestamps and slashing. If used, these rely on "trusted" external information being passed in via inherent extrinsics. The Substrate reference block authoring client software will expect to be able to call into the runtime API with collated data (in the case of the reference Substrate authoring client, this is merely the current timestamp and which nodes were offline) in order to return the appropriate extrinsics ready for inclusion. If new inherent extrinsic types and data are to be used in a modified runtime, then it is this function (and its argument type) that would change.
|
||||
Substrate FRAME includes functionality for timestamps and slashing. If used, these rely on "trusted" external information being passed in via inherent extrinsics. The Substrate reference block authoring client software will expect to be able to call into the runtime API with collated data (in the case of the reference Substrate authoring client, this is merely the current timestamp and which nodes were offline) in order to return the appropriate extrinsics ready for inclusion. If new inherent extrinsic types and data are to be used in a modified runtime, then it is this function (and its argument type) that would change.
|
||||
|
||||
=== Block-authoring Logic
|
||||
|
||||
@@ -444,11 +444,13 @@ substrate-trie
|
||||
* Substrate Runtime
|
||||
[source, shell]
|
||||
sr-api, sr-io, sr-primitives, sr-sandbox, sr-std, sr-version
|
||||
* Substrate Runtime Module Library (SRML)
|
||||
* FRAME Core
|
||||
[source, shell]
|
||||
pallet-assets, pallet-balances, palette-consensus, pallet-contracts, palette-council, pallet-democracy, pallet-example,
|
||||
palette-executive, palette-metadata, pallet-session, pallet-staking, palette-support, palette-system, pallet-timestamp,
|
||||
pallet-treasury
|
||||
frame-metadata, frame-support, frame-system
|
||||
* FRAME Pallets
|
||||
[source, shell]
|
||||
pallet-assets, pallet-balances, pallet-consensus, pallet-contracts, pallet-council, pallet-democracy, pallet-example,
|
||||
frame-executive, pallet-session, pallet-staking, pallet-timestamp, pallet-treasury
|
||||
* Node
|
||||
[source, shell]
|
||||
node-cli, node-consensus, node-executor, node-network, node-primitives, node-runtime
|
||||
|
||||
@@ -11,7 +11,7 @@ Substrate is split into multiple levels with increasing opinion and decreasing f
|
||||
|
||||
* primitives
|
||||
* client
|
||||
* PALETTE (formerly `srml`)
|
||||
* FRAME (formerly `srml`)
|
||||
|
||||
Putting all these components together we have:
|
||||
|
||||
@@ -35,23 +35,23 @@ In the lowest level, Substrate defines primitives, interfaces and traits to impl
|
||||
* _found in_: `/client`
|
||||
* _crates prefix_: `substrate-`
|
||||
* _constraints_:
|
||||
** crates may not (dev-)depend on any `palette-`-crates
|
||||
** crates may not (dev-)depend on any `frame-`-crates
|
||||
|
||||
In the client you can find a set of crates to construct the outer substrate-node, implementing outer runtime interfaces, thus it depends on `runtime`. It provides the outer building blocks like transaction queue, networking layer, database backend, full* and light-client support.
|
||||
|
||||
=== PALETTE (formerly `srml`)
|
||||
=== FRAME (formerly `srml`)
|
||||
|
||||
* _found in_: `/palette`
|
||||
* _crates prefix_: `palette-` and `pallet-`
|
||||
* _found in_: `/frame`
|
||||
* _crates prefix_: `frame-` and `pallet-`
|
||||
* _constraints_:
|
||||
** all crates that go on chain must be `[no_std]`
|
||||
** must not (dev-)depend on anything in `/client`
|
||||
|
||||
PALETTE is a set of modules that implement specific transition functions and features one might want to have in their runtime.
|
||||
FRAME is a set of modules that implement specific transition functions and features one might want to have in their runtime.
|
||||
|
||||
_Pallets_ are individual modules within _Palette._ These are containers that host domain-specific logic. They have the `pallet-` prefix. For example, `pallet-staking` contains logic for staking tokens.
|
||||
_Pallets_ are individual modules within _FRAME._ These are containers that host domain-specific logic. They have the `pallet-` prefix. For example, `pallet-staking` contains logic for staking tokens.
|
||||
|
||||
There are a few crates with the `palette-` prefix. These do not contain domain-specific logic. Rather, they are the main Palette support infrastructure. These are:
|
||||
There are a few crates with the `frame-` prefix. These do not contain domain-specific logic. Rather, they are the main FRAME support infrastructure. These are:
|
||||
|
||||
- Executive
|
||||
- Metadata
|
||||
@@ -79,7 +79,7 @@ We also provide some binaries pulling from the components creating full applicat
|
||||
|
||||
* _found in_: `/bin/node`
|
||||
|
||||
The default (testing) application pulling together our recommended setup of substrate-client with a wasm-contracts-supporting palette-runtime. The node pulls it all together, constructs the (upgradable) runtime, and wires up the client around it. You can find an example client, which includes a full wasm-contracts chain in `node`. This is also what is being built and run if you do `cargo run`.
|
||||
The default (testing) application pulling together our recommended setup of substrate-client with a wasm-contracts-supporting frame-runtime. The node pulls it all together, constructs the (upgradable) runtime, and wires up the client around it. You can find an example client, which includes a full wasm-contracts chain in `node`. This is also what is being built and run if you do `cargo run`.
|
||||
|
||||
==== Node Template
|
||||
|
||||
@@ -99,7 +99,7 @@ Subkey is a client library to generate keys and sign transactions to send to a s
|
||||
....
|
||||
+---------------+ +----------------+
|
||||
| | | |
|
||||
| runtime +<------+ palette |
|
||||
| runtime +<------+ frame |
|
||||
| | | |
|
||||
+------+-----+--+ +-------------+--+
|
||||
^ ^ ^
|
||||
|
||||
Reference in New Issue
Block a user