Polkadot 实现者指南：Runtime 类型深度解析 —— HostConfiguration 与 ParaInherentData 全解

• 区块链

本文聚焦 Polkadot 实现者指南（Implementers Guide）中的 Runtime 类型章节，系统讲解只在运行时内部广泛使用的两类核心类型：由治理程序修改的HostConfiguration（平行链宿主全量配置），以及驱动平行链共识推进的固有数据ParaInherentData（位域、已背书候选、争议语句集与父头）。读者将掌握每一个配置字段的语义与作用域，理解固有数据在区块导入路径上的组装与消费流程，并能对照runtime/parachains下的真实源码验证指南中的描述。

Runtime 类型在实现者指南中的定位

Polkadot 的运行时（Runtime）不仅承载中继链自身的共识逻辑，还负责调度、背书、包含与裁决所有平行链（Parachain）与平行线程（Parathread，即按需平行链）的工作。在 实现者指南 的类型章节中，有一类类型被单独归类为 "Runtime" 类型：它们在运行时内部被排他且普遍地使用（"Types used within the runtime exclusively and pervasively"），与 Node 侧（客户端子系统）使用的类型形成对照。

本关联文档共定义了两组核心类型：

• HostConfiguration：平行链宿主的内部运行时配置结构，预期仅能通过治理程序修改；
• ParaInherentData：传递给运行时入口点的固有数据（inherent data），用于推进平行链共识。

下文先围绕HostConfiguration的每一个字段展开，再剖析ParaInherentData的四个组成部分及其在区块导入过程中的流转。

HostConfiguration：平行链宿主的运行时配置

HostConfiguration是 runtime 内部关于平行链宿主（parachain host）的配置集合。指南明确写道："This is expected to be altered only by governance procedures"——即这些参数只能经由治理流程修改，普通交易或运行时逻辑无权直接改动，从而保证平行链运行环境的稳定性与可预期性。

在真实源码中，该结构定义于 runtime/parachains/src/configuration.rs，是带BlockNumber泛型参数的pub struct HostConfiguration<BlockNumber>，并派生了Clone、Encode、Decode、PartialEq、RuntimeDebug、TypeInfo及 serde 序列化/反序列化等 trait。一个值得注意的实现细节是：该结构会通过 Merkle proof 提供给平行链使用，因此只有前部字段可以被平行链依赖，调整这些字段的顺序必须伴随相应的平行链迁移（见 configuration.rs 的 NOTE 注释）。

指南给出的完整结构如下（字段在指南版本中按语义分组，与源码当前版本的顺序略有差异，本文以指南为骨架、以源码注释为佐证）：

struct HostConfiguration { /// The minimum period, in blocks, between which parachains can update their validation code. pub validation_upgrade_cooldown: BlockNumber, /// The delay, in blocks, before a validation upgrade is applied. pub validation_upgrade_delay: BlockNumber, /// How long to keep code on-chain, in blocks. This should be sufficiently long that disputes /// have concluded. pub code_retention_period: BlockNumber, /// The maximum validation code size, in bytes. pub max_code_size: u32, /// The maximum head-data size, in bytes. pub max_head_data_size: u32, /// The amount of availability cores to dedicate to parathreads (on-demand parachains). pub parathread_cores: u32, /// The number of retries that a parathread (on-demand parachain) author has to submit their block. pub parathread_retries: u32, /// How often parachain groups should be rotated across parachains. pub group_rotation_frequency: BlockNumber, /// The availability period, in blocks, for parachains. ... pub chain_availability_period: BlockNumber, /// The availability period, in blocks, for parathreads (on-demand parachains). ... pub thread_availability_period: BlockNumber, /// The amount of blocks ahead to schedule on-demand parachains. pub scheduling_lookahead: u32, /// The maximum number of validators to have per core. `None` means no maximum. pub max_validators_per_core: Option<u32>, /// The maximum number of validators to use for parachains, in total. `None` means no maximum. pub max_validators: Option<u32>, /// The amount of sessions to keep for disputes. pub dispute_period: SessionIndex, /// How long after dispute conclusion to accept statements. pub dispute_post_conclusion_acceptance_period: BlockNumber, /// The maximum number of dispute spam slots pub dispute_max_spam_slots: u32, /// The amount of consensus slots that must pass between submitting an assignment and /// submitting an approval vote before a validator is considered a no-show. Must be at least 1. pub no_show_slots: u32, /// The number of delay tranches in total. pub n_delay_tranches: u32, /// The width of the zeroth delay tranche for approval assignments. ... pub zeroth_delay_tranche_width: u32, /// The number of validators needed to approve a block. pub needed_approvals: u32, /// The number of samples to do of the RelayVRFModulo approval assignment criterion. pub relay_vrf_modulo_samples: u32, /// Total number of individual messages allowed in the parachain -> relay-chain message queue. pub max_upward_queue_count: u32, /// Total size of messages allowed in the parachain -> relay-chain message queue ... pub max_upward_queue_size: u32, /// The maximum size of an upward message that can be sent by a candidate. ... pub max_upward_message_size: u32, /// The maximum number of messages that a candidate can contain. ... pub max_upward_message_num_per_candidate: u32, /// The maximum size of a message that can be put in a downward message queue. ... pub max_downward_message_size: u32, /// The deposit that the sender should provide for opening an HRMP channel. pub hrmp_sender_deposit: u32, /// The deposit that the recipient should provide for accepting opening an HRMP channel. pub hrmp_recipient_deposit: u32, /// The maximum number of messages allowed in an HRMP channel at once. pub hrmp_channel_max_capacity: u32, /// The maximum total size of messages in bytes allowed in an HRMP channel at once. pub hrmp_channel_max_total_size: u32, /// The maximum number of inbound HRMP channels a parachain is allowed to accept. pub hrmp_max_parachain_inbound_channels: u32, /// The maximum number of inbound HRMP channels a parathread (on-demand parachain) is allowed to accept. pub hrmp_max_parathread_inbound_channels: u32, /// The maximum size of a message that could ever be put into an HRMP channel. ... pub hrmp_channel_max_message_size: u32, /// The maximum number of outbound HRMP channels a parachain is allowed to open. pub hrmp_max_parachain_outbound_channels: u32, /// The maximum number of outbound HRMP channels a parathread (on-demand parachain) is allowed to open. pub hrmp_max_parathread_outbound_channels: u32, /// The maximum number of outbound HRMP messages can be sent by a candidate. ... pub hrmp_max_message_num_per_candidate: u32, }

验证码生命周期相关字段

• validation_upgrade_cooldown：两次验证码（validation code）升级之间必须间隔的最小区块数。源码注释补充道：该值用于防止平行链用验证码升级刷屏中继链，它控制的仅仅是UpgradeRestrictionSignal被设置的区块数；若启用 PVF 预检查，该值应大于 PVF 预检查可能消耗的最大区块数（见 configuration.rs）。在指南对应的代码时代该字段名为validation_upgrade_cooldown，当前源码中存在serde(alias = "validation_upgrade_frequency")别名，说明历史上曾被命名为 frequency。
• validation_upgrade_delay：验证码升级生效前延迟的区块数。源码给出了精确的生效语义：当第一个relay_parent >= expected_at的候选被包含时升级生效；该延迟的存在是为了应对中继链回滚（reversion）——若新版本代码产生无效候选，中继链可以回退validation_upgrade_delay个区块，仍能按哈希在存储中找到旧代码（见 configuration.rs）。
• code_retention_period：链上保留验证码的区块时长。该值必须足够长，以确保所有相关争议（dispute）都已了结，否则争议仲裁可能面临验证码已被清理的窘境。

候选尺寸与消息队列上限字段

• max_code_size/max_head_data_size：验证码与 head-data 的最大字节数。在源码中这两个字段位于结构体最前部（configuration.rs），因为它们是"平行链必需的参数"，会被平行链通过 Merkle proof 依赖。
• max_upward_queue_count/max_upward_queue_size：平行链 → 中继链上行消息（Upward Message）队列的消息条数上限与总字节上限。指南特别说明：一旦队列超出总大小上限，队列中可能只允许保留单条消息，以保证系统仍有最基本的吞吐能力。
• max_upward_message_size/max_upward_message_num_per_candidate：单个上行消息的最大尺寸，以及单个候选可携带的上行消息最大条数。二者都直接约束CandidateCommitments（候选承诺）的尺寸上界——见 candidate.md。
• max_downward_message_size：下行消息队列（DMP）中单条消息的最大尺寸。指南指出，由于要求至少能接收一条 DMP 消息，其显而易见的理论下界是 PoV 大小，但实践中平行链还会把 PoV 用于其他用途，因此实际取值通常是 PoV 大小的一个分数。

HRMP 通道与抵押字段

• hrmp_sender_deposit/hrmp_recipient_deposit：打开 HRMP 通道时，发送方与接收方各自需要提供的抵押（deposit）。源码中二者的实际类型为Balance（见 configuration.rs），指南为简写为u32。
• hrmp_channel_max_capacity/hrmp_channel_max_total_size：单个 HRMP 通道同时容纳的消息条数上限与字节总大小上限。
• hrmp_max_parachain_inbound_channels/hrmp_max_parathread_inbound_channels：平行链与平行线程各自允许接受的入站 HRMP 通道数量上限。
• hrmp_max_parachain_outbound_channels/hrmp_max_parathread_outbound_channels：平行链与平行线程各自允许打开的出站 HRMP 通道数量上限。
• hrmp_channel_max_message_size/hrmp_max_message_num_per_candidate：HRMP 单条消息的最大尺寸与单个候选可发送的出站 HRMP 消息最大条数。同样约束CandidateCommitments的尺寸上界。

可用性与调度字段

• parathread_cores：分配给平行线程（按需平行链）的可用核心（availability core）数量。
• parathread_retries：平行线程作者提交区块的重试次数。
• group_rotation_frequency：平行链分组（validator group）在平行链之间轮换的频率（以区块计）。
• chain_availability_period/thread_availability_period：平行链与平行线程各自的可用性周期（区块数），即候选被包含后验证者必须完成数据可用并链上确认信号的时间窗口。两者语义相同，但因需求不同而采用不同超时；均必须至少为 1。
• scheduling_lookahead：提前调度按需平行链的区块数。
• max_validators_per_core/max_validators：每个核心上验证者的数量上限，以及参与平行链工作的验证者总数上限。None表示不设上限。

争议（Dispute）相关字段

• dispute_period：为争议保留的会话（session）数量，以SessionIndex计。
• dispute_post_conclusion_acceptance_period：争议结论达成后，仍然接受陈述（statement）的时间窗口（区块数）。
• dispute_max_spam_slots：争议垃圾消息槽（spam slots）数量上限，用于抑制针对争议机制的垃圾流量。

批准投票（Approval Voting）相关字段

• no_show_slots：从提交分配（assignment）到提交批准投票（approval vote）之间必须经过的共识槽数量，超过则验证者被视为 no-show。必须至少为 1。
• n_delay_tranches：批准分配延迟梯队（delay tranche）的总数。
• zeroth_delay_tranche_width：第零延迟梯队的宽度，即从第 0 梯队起连续若干个梯队被合并为一个宽的第 0 梯队。
• needed_approvals：批准一个区块所需的验证者数量。
• relay_vrf_modulo_samples：对 RelayVRFModulo 批准分配准则进行的抽样次数。

源码实现细节与差异

对照 runtime/parachains/src/configuration.rs 的当前实现，可以观察到指南与源码的三点差异：

1. 字段顺序不同：源码将max_code_size、max_head_data_size等"平行链必需参数"置于结构体最前部，而把validation_upgrade_cooldown等放在其后（configuration.rs），并明确将参数分为"平行链必需"与"非必需但可能相关"两组；
2. 存在指南未列出的字段：如async_backing_params: AsyncBackingParams（异步背书参数，见 configuration.rs）与max_pov_size（PoV 最大字节数），说明该结构随协议迭代持续演进；
3. 部分类型有出入：hrmp_sender_deposit/hrmp_recipient_deposit在源码中为Balance而非u32。

该配置通过#[pallet::genesis_config]参与创世配置生成（configuration.rs），运行时通过配置 pallet 的存储读取这些值，并传递给调度、包含、批准投票等各模块使用。

ParaInherentData：推进平行链共识的固有数据

平行链共识的推进依赖固有数据（inherent data）：它是区块作者在构建区块时注入、由所有验证者独立验证、并作为区块内容一部分存储的数据。ParaInherentData正是传递给运行时入口点、用于推进平行链共识的那份固有数据。

指南明确指出其包含4 份数据：

1. Bitfields：可用性位域；
2. BackedCandidates：已背书候选列表；
3. MultiDisputeStatementSet：争议陈述集；
4. Header：父区块头。

struct ParaInherentData { bitfields: Bitfields, backed_candidates: BackedCandidates, dispute_statements: MultiDisputeStatementSet, parent_header: Header }

四份数据的语义

①Bitfields（可用性位域）

定义见 availability.md：

type SignedAvailabilityBitfield = Signed<Bitvec>; struct Bitfields(Vec<(SignedAvailabilityBitfield)>), // bitfields sorted by validator index, ascending

每个验证者针对"待处理候选的可用性"签署一份位域。位域中每一位对应一个可用性核心，1表示该验证者认为：该核心被占用、存在对应的CommittedCandidateReceipt（即该平行链有进行中的区块）、且验证者自己的可用性存储中保存了该平行区块 PoV 的一个分片。它是OccupiedCore::availability的转置。中继链收集各验证者的位域，判断哪些候选达到了可用性确认的门槛。

②BackedCandidates（已背书候选）

定义见 backing.md：

struct BackedCandidate { candidate: CommittedCandidateReceipt, validity_votes: Vec<ValidityAttestation>, validator_indices: BitVec, } struct BackedCandidates(Vec<BackedCandidate>); // sorted by para-id.

一份CommittedCandidateReceipt（包含候选描述符与执行承诺的收据，见 candidate.md）加上所有证明其已被背书的数据：有效性投票列表（Implicit/Explicit两种背书，对应Seconded与Valid陈述）、以及组内签署候选的验证者索引位向量（只需覆盖组内验证者，故更紧凑）。BackedCandidates按 para-id 升序排序，交由运行时进入 pending-availability（待可用性确认）阶段。

③MultiDisputeStatementSet（争议陈述集）

定义见 disputes.md：

type MultiDisputeStatementSet = Vec<DisputeStatementSet>; struct DisputeStatementSet { candidate_hash: CandidateHash, session: SessionIndex, statements: Vec<(DisputeStatement, ValidatorIndex, ValidatorSignature)>, }

即针对零个或多个争议的陈述集集合。每条陈述是DisputeStatement枚举（Valid/Invalid，配合ValidDisputeStatementKind的Explicit、BackingSeconded、BackingValid、ApprovalChecking等种类），与候选哈希、会话索引、验证者公钥和签名组合后可复现并校验原始陈述。运行时据此更新争议状态（DisputeState，含validators_for/validators_against位域、起始区块与结论区块），并将结论写入链上。

④Header（父区块头）

即parent_header：本次固有数据处理所依据的父区块头。运行时在处理固有数据时需要它来确定调度上下文、会话信息与存储根等。

固有数据在运行时中的消费流程

ParaInherentData在真实实现中的对应类型为ParachainsInherentData<HeaderFor<T>>，定义于 node/core/parachains-inherent/src/lib.rs，由节点侧的ParachainsInherentDataProvider负责收集（从各个子系统汇总位域、背书候选与争议陈述）。

运行时侧的处理集中在 runtime/parachains/src/paras_inherent/mod.rs：

• 固有数据解码：区块导入时，create_inherent_inner从InherentData中按固有数据标识符解码出ParachainsInherentData（解码失败会记录ParachainsInherentData failed to decode警告）；
• process_inherent_data主处理：核心函数process_inherent_data接收ParachainsInherentData与上下文（ProvideInherent或Enter），依次执行：位域检查与洗白（sanitize，剔除指向非法中继父的位域）、争议检查（通过DisputesHandler::concluded_invalid收集已裁决为无效的争议）、已背书候选的校验（verify_backed_candidate与allowed_relay_parents检查，见 paras_inherent/mod.rs）、调度核心占用更新、以及调用inclusion::Pallet::process_candidates执行候选包含；
• 组装返回：处理完成后，函数重新组装一份新的ParachainsInherentData { bitfields, backed_candidates, disputes, parent_header }连同消费权重一并返回（paras_inherent/mod.rs），供上层继续使用；
• 冻结保护：若中继链处于冻结状态（检测到无效区块），处理逻辑会返回bitfields: Vec::new(), backed_candidates: Vec::new()的空数据，仅保留争议陈述与父头，不再包含任何平行链区块（paras_inherent/mod.rs），从机制上阻止无效链上继续推进平行链共识。

测试与验证

runtime/parachains/src/paras_inherent/tests.rs 中大量测试使用InherentData::new()构造固有数据、调用create_inherent/process_inherent_data路径，并定义了辅助函数inherent_data_weight计算固有数据处理消耗的权重（见 tests.rs），覆盖位域处理、候选背书、争议裁决、冻结回退等场景，是理解ParaInherentData各字段实际消费方式的直接入口。

小结

HostConfiguration与ParaInherentData构成了 Polkadot 运行时推进平行链共识的"配置面"与"数据面"：前者通过治理设定调度、消息、可用性、争议、批准投票的全部关键参数，任何改动都需走治理流程并警惕对平行链 Merkle proof 依赖字段的影响；后者在每一条中继链区块中携带位域、已背书候选、争议陈述与父头，经paras_inherent模块的检查、洗白与包含处理后，完成一轮平行链共识的推进。将指南与 runtime/parachains/src/configuration.rs 和 runtime/parachains/src/paras_inherent/mod.rs 对照阅读，可以最准确地把握这两个核心类型在当前代码库中的真实形态与演进方向。

• 区块链