区块链【免费下载链接】polkadotPolkadot Node Implementation项目地址https://gitcode.com/gh_mirrors/po/polkadot点击查看免费下载本文聚焦 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 HostConfigurationBlockNumber并派生了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: Optionu32, /// The maximum number of validators to use for parachains, in total. None means no maximum. pub max_validators: Optionu32, /// 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_candidateHRMP 单条消息的最大尺寸与单个候选可发送的出站 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 的当前实现可以观察到指南与源码的三点差异字段顺序不同源码将max_code_size、max_head_data_size等平行链必需参数置于结构体最前部而把validation_upgrade_cooldown等放在其后configuration.rs并明确将参数分为平行链必需与非必需但可能相关两组存在指南未列出的字段如async_backing_params: AsyncBackingParams异步背书参数见 configuration.rs与max_pov_sizePoV 最大字节数说明该结构随协议迭代持续演进部分类型有出入hrmp_sender_deposit/hrmp_recipient_deposit在源码中为Balance而非u32。该配置通过#[pallet::genesis_config]参与创世配置生成configuration.rs运行时通过配置 pallet 的存储读取这些值并传递给调度、包含、批准投票等各模块使用。ParaInherentData推进平行链共识的固有数据平行链共识的推进依赖固有数据inherent data它是区块作者在构建区块时注入、由所有验证者独立验证、并作为区块内容一部分存储的数据。ParaInherentData正是传递给运行时入口点、用于推进平行链共识的那份固有数据。指南明确指出其包含4 份数据Bitfields可用性位域BackedCandidates已背书候选列表MultiDisputeStatementSet争议陈述集Header父区块头。struct ParaInherentData { bitfields: Bitfields, backed_candidates: BackedCandidates, dispute_statements: MultiDisputeStatementSet, parent_header: Header }四份数据的语义①Bitfields可用性位域定义见 availability.mdtype SignedAvailabilityBitfield SignedBitvec; struct Bitfields(Vec(SignedAvailabilityBitfield)), // bitfields sorted by validator index, ascending每个验证者针对待处理候选的可用性签署一份位域。位域中每一位对应一个可用性核心1表示该验证者认为该核心被占用、存在对应的CommittedCandidateReceipt即该平行链有进行中的区块、且验证者自己的可用性存储中保存了该平行区块 PoV 的一个分片。它是OccupiedCore::availability的转置。中继链收集各验证者的位域判断哪些候选达到了可用性确认的门槛。②BackedCandidates已背书候选定义见 backing.mdstruct BackedCandidate { candidate: CommittedCandidateReceipt, validity_votes: VecValidityAttestation, validator_indices: BitVec, } struct BackedCandidates(VecBackedCandidate); // sorted by para-id.一份CommittedCandidateReceipt包含候选描述符与执行承诺的收据见 candidate.md加上所有证明其已被背书的数据有效性投票列表Implicit/Explicit两种背书对应Seconded与Valid陈述、以及组内签署候选的验证者索引位向量只需覆盖组内验证者故更紧凑。BackedCandidates按 para-id 升序排序交由运行时进入 pending-availability待可用性确认阶段。③MultiDisputeStatementSet争议陈述集定义见 disputes.mdtype MultiDisputeStatementSet VecDisputeStatementSet; 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在真实实现中的对应类型为ParachainsInherentDataHeaderForT定义于 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 对照阅读可以最准确地把握这两个核心类型在当前代码库中的真实形态与演进方向。赞分享区块链【免费下载链接】polkadotPolkadot Node Implementation项目地址https://gitcode.com/gh_mirrors/po/polkadot点击查看免费下载相关推荐Polkadot 实现者指南核心类型定义体系全解Types OverviewPolkadot 实现者指南核心类型定义体系全解Types Overview 本文围绕 Polkadot 节点实现仓库中 roadmap/implemen区块链PyTorch Lightning CLI 常见问题全解子命令、YAML 配置、覆盖顺序与调试实战PyTorch Lightning CLI 常见问题全解子命令、YAML 配置、覆盖顺序与调试实战 导读 LightningCLI 是 PyTorch Lig区块链Polkadot 实现者指南persisted_validation_data Runtime API 与持久化验证数据详解Polkadot 实现者指南 persisted_validation_data Runtime API 与持久化验证数据详解 本篇指南聚焦 Polkadot区块链上一篇HackTricks从零到一的网络安全攻防实战指南下一篇华硕笔记本终极静音方案G-Helper风扇控制完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考