Kusama Kusama parachains submit blocks for relay-chain validation under their registered rules.
· updated
Kusama parachains use chain-specific rules that Kusama's relay-chain validators execute to check proposed blocks. Collators maintain each chain's state and assemble candidate blocks with proof-of-validity data. Validators use those inputs to verify the proposed state change, while availability and approval checks support later finalization. This arrangement allows different runtimes to share security without applying identical transaction rules. A locally produced block remains provisional until the relay-chain protocol accepts and finalizes the corresponding parachain history.
Block authoring and shared validation require different information
Collators retain parachain state to build blocks; relay-chain validators check candidates using validation code and proofs. A collator collects transactions, executes the parachain runtime, and packages the proposed changes for checking. It supplies the candidate together with the data needed to reproduce its execution. Using the applicable validation program obtained through relay-chain state, validators check whether the submitted inputs produce the claimed outcome. A collator's local acceptance of its own block therefore precedes the relay chain's acceptance.
The distinction also separates liveness from validity. A parachain needs functioning collators to keep proposing blocks. Relay-chain validators provide the shared checking and consensus machinery. The protocol assigns validator groups to backing work, and those assignments can change. Parachains consequently maintain their own block-production arrangements while using a common validator system to secure accepted state transitions.
A parachain can stop advancing while the relay chain continues producing blocks.
When does a candidate become a finalized parachain block?
A candidate becomes finalized when relay-chain finality accepts a history that satisfies backing, availability, and approval requirements. Backing records initial validator attestations; availability makes the checking data recoverable, and approval adds secondary validity checks. The chain can display progress before all those conditions are complete.
Backing and availability
Assigned validators check a candidate and sign validity statements, and sufficient supporting statements establish its backing on a relay-chain fork. A backed candidate awaits availability confirmation as validators distribute erasure-coded data that can be recovered from enough surviving chunks. Once the protocol establishes availability, the candidate can advance the parachain's included head. The relay chain records compact candidate information rather than every parachain's full block body.
An unavailable candidate can time out before inclusion, even after validators have backed it.
Approval and finality
Secondary checkers recover the candidate data and repeat validation. Conflicting validity statements can escalate into a dispute involving the wider validator set. A candidate judged invalid can cause rejection of the affected branch. GRANDPA finality follows the protocol's approval and dispute constraints, so unresolved disputes can delay finalization. Validators who incorrectly attest validity face slashing under the dispute rules. Inclusion in an unfinalized branch remains an intermediate state even when its data is available.
With asynchronous backing, collators can build on permitted ancestors that have not yet reached inclusion, overlapping work across the pipeline. Its purpose is to increase productive use of validation capacity while retaining availability and approval checks.
What does a validator execute to check a candidate?
A validator executes the applicable parachain validation function, or PVF, using candidate data and the required relay-chain context. The function describes the chain's state-transition rules in WebAssembly, usually shortened to Wasm. The collator's proof-of-validity, or PoV, supplies data needed for that execution.
The PoV supplied for validation must match the hash committed by the candidate. A mismatched PoV fails the preliminary data check before the validation program runs. Other candidate checks bind execution to its claimed context and outputs.
The candidate's two parent contexts
The previous parachain state
For a runtime that uses a Merkle state proof, the previous header's state root commits to stored values. The witness supplies relevant values and Merkle paths, which authenticate those values against the root. Validators can check the proposed changes without keeping the parachain's entire database. The particular validation program determines the witness format that the chain accepts.
The relay-chain context
The relay parent is the relay-chain block whose state supplies context for the candidate, including applicable validation code and relay-side constraints. It also supports checks on incoming messages. This is a different reference from the previous parachain block. Both references matter because the candidate must extend the correct parachain state under an eligible relay-chain context.
Execution produces a new parachain head and other commitments, such as outgoing messages. Validators compare the produced outputs with the candidate's claims. Relay-side checks also constrain those outputs before acceptance. A reproducible state change must therefore match both the chain-specific program and the host protocol's requirements.
Validators distinguish an invalid candidate from an internal checking error. A node failure alone does not establish an invalid state transition.
Coretime schedules access to validation
Coretime determines when a parachain can use relay-chain validation capacity; it does not replace candidate checking. Bulk coretime allocates capacity across a defined period, while on-demand coretime supports individual block opportunities. Both schedule access to the shared validation protocol. System parachains can receive capacity through governance allocation. Registration alone does not supply an active core assignment, and a chain without scheduled capacity cannot keep advancing through relay-chain validation. Scheduling limits progress even when the candidate's execution rules are sound.
What does shared security protect on a Kusama parachain?
Kusama's relay-chain validators protect parachain history by checking state transitions against registered rules under the protocol's consensus assumptions. The program that applies to the candidate can still contain flawed application logic. A transition permitted by a defective runtime can pass validation, so consensus acceptance does not establish that every application rule is desirable or bug-free.
Suppose you use a parachain event to update a record that must remain editable until you commit it. A provisional head supplies earlier information that can change with chain selection. A finalized head provides a later acceptance point tied to relay-chain finality.
- Tie the event to a specific parachain block.
- Keep updates based on an unfinalized head reversible.
- Require that block's finalized status.
- Before committing the record, confirm that the event describes the application outcome the record needs.
Waiting trades earlier information for that stronger acceptance condition. If the event's block drops out of the unfinalized history, the editable record can be corrected before commitment.
Runtime upgrades and cross-chain execution have distinct checks
A parachain can propose replacement validation code through its authorized upgrade process. Relay-side acceptance and activation determine when the replacement becomes applicable. Validators use the version that applies to the candidate's context. A newer proposal therefore does not automatically replace the rules for an earlier candidate. Its configured upgrade authority determines who can authorize that change.
PVF pre-checking tests whether proposed validation code can be prepared within protocol resource limits. This screen concerns preparation, including compilation. Code can pass that check and still contain application defects. Candidate validation subsequently checks particular executions under the accepted program.
A parachain that supports XCM can also process cross-chain instructions under its own configured rules. Transporting the message and executing its instructions are distinct operations. A finalized source block can establish that the sender emitted a message. The receiving runtime's permissions and execution conditions govern the destination outcome.
Frequently asked questions about Kusama parachains
Can a failed transaction appear in a valid parachain block?
A valid parachain block can contain a transaction whose application call failed. In runtimes using the standard dispatch model, a valid extrinsic can execute and return a dispatch error. Validators check whether the runtime handled that failure correctly. Alongside finalized inclusion, check an execution result or event to establish whether the requested application action succeeded.
Are Kusama collators required to stake KSM under the relay chain's validator rules?
Collators do not inherit a universal KSM staking requirement from relay-chain validators. Each parachain's implementation determines its collator admission, bonding, and reward arrangements. A chain can impose its own requirements. Operating a collator and joining Kusama's relay-chain validator set are different roles, even though both contribute to processing parachain blocks.
Which limit controls a parachain candidate's proof-of-validity size?
A candidate's encoded proof-of-validity data must fit the maximum size supplied by its relay-chain validation context, expressed in bytes. Validators reject a candidate whose encoded PoV exceeds that bound before running the validation program. A value from another runtime version or relay-parent context may not describe the candidate's limit.
Why can transaction fees differ between Kusama parachains?
Each parachain can define its own transaction-fee rules in its runtime. Shared validation enforces those rules without imposing one fee formula across every connected chain. Whether fees depend on transaction size, execution work, or another supported basis follows the particular implementation. The chain's choice of payment asset is also distinct from the relay chain's security mechanism.
Is proof-of-validity data a zero-knowledge privacy proof?
PoV data is a witness for checking a parachain state transition, not an automatic zero-knowledge privacy feature. It provides inputs that validators need to reproduce execution and authenticate the relevant state. Confidentiality requires mechanisms implemented by the particular chain or application. The term alone makes no promise that transaction contents remain hidden.
Does data availability provide permanent archival storage?
Protocol data availability does not provide permanent archival storage for parachain history. Validators retain candidate data and chunks for the required checking and dispute periods, then prune them under retention rules. Long-term access to historical blocks or state depends on infrastructure that retains that information beyond the validation protocol's availability window.
How does a parachain ID differ from a core assignment?
A parachain ID identifies a registered chain, while a core assignment schedules validation capacity for a task. Having the identifier does not establish that the chain has capacity at a particular time. The identifier and assignment therefore describe different relationships: which chain the candidate belongs to, and when the relay chain can process its blocks.
Can a collator leave a valid transaction out of its candidate?
A collator can leave a valid transaction out of a proposed block, subject to the parachain's authoring rules. Candidate validation checks the proposed state transition; it does not promise immediate inclusion of every waiting transaction. Collator selection, transaction scheduling, and block limits affect inclusion. Censorship resistance also depends on the parachain's block-production arrangements.