Module cumulus_primitives_core::relay_chain
source · Expand description
A module that re-exports relevant relay chain definitions.
Modules
- Runtime API module declares the
trait ParachainHost
which is part of the Runtime API exposed from the Runtime to the Host. V2
primitives.V2
Primitives.- Staging Primitives.
Structs
- Abridged version of
HostConfiguration
(from theConfiguration
parachains host runtime module) meant to be used by a parachain or PDK such as cumulus. - Abridged version of
HrmpChannel
(from theHrmp
parachains host runtime module) meant to be used by a parachain or PDK such as cumulus. - A vote of approval on a candidate.
- A bitfield concerning availability of backed candidates.
- A backed (or backable, depending on context) candidate.
- Blake2-256 Hash implementation.
- Commitments made in a
CandidateReceipt
. Many of these are outputs of validation. - A unique descriptor of the candidate receipt.
- Unit type wrapper around
Hash
that represents a candidate hash. - A candidate-receipt.
- A checked set of dispute statements.
- A candidate-receipt with commitments directly included.
- The unique (during session) index of a core.
- The entire state of a dispute.
- A set of statements about a specific candidate.
- Deterministically serialized execution environment semantics
- Unit type wrapper around
Hash
that represents an execution parameter set hash. - An explicit statement on a candidate issued as part of a dispute.
- The unique (during session) index of a validator group.
- A helper data-type for tracking validator-group rotations.
- Parachain head data included in the chain.
- A type that uniquely identifies an HRMP channel. An HRMP channel is established between two paras. In text, we use the notation
(A, B)
to specify a channel between A and B. The channels are unidirectional, meaning that(A, B)
and(B, A)
refer to different channels. The convention is that we use the first item tuple for the sender and the second for the recipient. Only one channel is allowed between two participants in one direction, i.e. there cannot be 2 different channels identified by(A, B)
. A channel with the same para id in sender and recipient is invalid. That is, however, not enforced. - Unique identifier of a parachain.
- A wrapped version of
DownwardMessage
. The difference is that it has attached the block number when the message was sent. - An HRMP message seen from the perspective of a recipient.
IndexedVec
struct indexed by type specific indices.- Parachains inherent-data passed into the runtime by a block author
- Information about a core which is currently occupied.
- An HRMP message seen from the perspective of a sender.
- A claim on authoring the next block for a given parathread (on-demand parachain).
- An entry tracking a claim to ensure it does not pass the maximum number of retries.
- The validation data provides information about how to create the inputs for validation of a candidate. This information is derived from the chain state and will vary from para to para, although some fields may be the same for every para.
- A statement from the specified validator whether the given validation code passes PVF pre-checking or not anchored to the given session index.
- A metric label.
- A set of metric labels.
- Runtime metric update event.
- Information about a core which is currently occupied.
- Scraped runtime backing votes and resolved disputes.
- Information about validator sets of a session.
- Signed data with signature already verified.
- A type returned by runtime with current session index and a parent hash.
- Unit type wrapper that represents a slot.
- Simple blob to hold an extrinsic without committing to its format and ensure it is serialized correctly.
- Unchecked signed data, can be converted to
Signed
by checking the signature. - Parachain validation code.
- Unit type wrapper around
Hash
that represents the blake2-256 hash of validation code in particular. - Index of the validator is used as a lightweight replacement of the
ValidatorId
when appropriate.
Enums
- An even concerning a candidate.
- Statements that can be made about parachain candidates. These are the actual values that are signed.
- A consensus log item for polkadot validation. To be used with
POLKADOT_ENGINE_ID
. - What is occupying a specific availability core.
- The state of a particular availability core.
- A statement about a candidate, to be used within the dispute resolution process.
- The different executor parameters for changing the execution environment semantics.
- Different kinds of statements of invalidity on a candidate.
- An assumption being made about the state of an occupied core.
- Type discriminator for PVF execution timeouts
- Type discriminator for PVF preparation timeouts
- Runtime metric operations.
- A struct that the relay-chain communicates to a parachain indicating what course of action the parachain should take in the coordinated parachain validation code upgrade process.
- A possible upgrade restriction that prevents a parachain from performing an upgrade.
- Different kinds of statements of validity on a candidate.
- An either implicit or explicit attestation to the validity of a parachain candidate.
- Custom validity errors used in Polkadot while validating transactions.
Constants
- The key type ID for parachain assignment key.
- The ID of the first publicly registerable parachain.
- Maximum compressed code size we support right now. At the moment we have runtime upgrade on chain, which restricts scalability severely. If we want to have bigger values, we should fix that first.
- Maximum head data size we support right now.
- Maximum PoV size we support right now.
- Default queue size we use for the on-demand order book.
- Unique identifier for the Parachains Inherent
- The key type ID for a parachain validator key.
Traits
- This helper trait ensures that we can encode
Statement
asCompactStatement
, and anything as itself. - Abstraction around hashing
Functions
- The maximum number of validators
f
which may safely be faulty. - Verify the backing of the given candidate.
- Get a collator signature payload on a relay-parent, block-data combo.
- The supermajority threshold of validators which represents a subset guaranteed to have at least f+1 honest validators.
Type Definitions
- Alias to the opaque account ID type for this chain, actually a
AccountId32
. This is always 32 bytes. - The type for looking up accounts. We don’t expect more than 4 billion of them.
- Alias to the public key used for this chain, actually a
MultiSigner
. Like the signature, this also isn’t a fixed size when encoded, as different cryptos have different size public keys. - The public key of a keypair used by a validator for determining assignments to approve included parachain candidates.
- The full keypair used by a validator for determining assignments to approve included parachain candidates.
- An authority discovery authority identifier.
- The balance of an account. 128-bits (or 38 significant decimal figures) will allow for 10 m currency (
10^7
) at a resolution to all for one second’s worth of an annualised 50% reward be paid to a unit holder (10^11
unit denomination), or10^18
total atomic units, to grow at 50%/year for 51 years (10^9
multiplier) for an eventual total of10^27
units (27 significant decimal figures). We round denomination to10^12
(12 SDF), and leave the other redundancy at the upper end so that 32 bits may be multiplied with a balance in 128 bits without worrying about overflow. - Block type.
- Block ID.
- The block number type used by Polkadot. 32-bits will allow for 136 years of blocks assuming 1 block per second.
- The index of the candidate in the list of candidates fully included as-of the block.
- Identifier for a chain. 32-bit should be plenty.
- A set of checked dispute statements.
- Identity that collators use.
- A Parachain collator keypair.
- Signature on candidate’s block data by a collator.
- A message sent from the relay-chain down to a parachain.
- A hash of some data used by the relay chain.
- Header type.
- An instant or duration in time.
- A set of dispute statements.
- Index of a transaction in the relay chain. 32-bit should be plenty.
- The information that goes alongside a
transfer_into_parachain
operation. Entirely opaque, it will generally be used for identifying the reason for the transfer. Typically it will hold the destination account to which the transfer should be credited. If still more information is needed, then this should be a hash with the pre-image presented via an off-chain mechanism on the parachain. - A metric label value.
- A set of metric label values.
- Simple index type with which we can count sessions.
- Alias to type for a signature for a transaction on the relay chain. This allows one of several kinds of underlying crypto to be used, so isn’t a fixed size when encoded.
- A bitfield signed by a particular validator about the availability of pending candidates.
- A set of signed availability bitfields. Should be sorted by validator index, ascending.
- A signed compact statement, suitable to be sent to the chain.
- A signed bitfield with signature not yet checked.
- A set of unchecked signed availability bitfields. Should be sorted by validator index, ascending.
- A signed compact statement, with signature not yet checked.
- A message from a parachain to its Relay Chain.
- Identity that parachain validators use when signing validation messages.
- A Parachain validator keypair.
- Signature with which parachain validators sign blocks.