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.
  • V7 Primitives.
  • Staging Primitives.

Structs§

  • Abridged version of HostConfiguration (from the Configuration parachains host runtime module) meant to be used by a parachain or PDK such as cumulus.
  • Abridged version of HrmpChannel (from the Hrmp parachains host runtime module) meant to be used by a parachain or PDK such as cumulus.
  • A vote of approval on a candidate.
  • A vote of approval for multiple candidates.
  • Approval voting configuration parameters
  • Candidate’s acceptance limitations for asynchronous backing per relay parent.
  • 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.
  • Index of an availability chunk.
  • 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.
  • Unit type wrapper around Hash that represents a hash of preparation-related executor parameters.
  • 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.
  • Scheduler configuration parameters. All coretime/ondemand parameters are here.
  • 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§

Constants§

Traits§

  • This helper trait ensures that we can encode Statement as CompactStatement, and anything as itself.
  • Abstraction around hashing

Functions§

Type Aliases§

  • 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), or 10^18 total atomic units, to grow at 50%/year for 51 years (10^9 multiplier) for an eventual total of 10^27 units (27 significant decimal figures). We round denomination to 10^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.
  • Bit indices in the HostConfiguration.node_features that correspond to different node features.
  • 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.