尧图网页设计 
区块链【免费下载链接】polkadotPolkadot Node Implementation项目地址https://gitcode.com/gh_mirrors/po/polkadot点击查看免费下载本文围绕 Polkadot 实现者指南中 Availability 类型定义系统梳理验证人validator保证候选区块candidate数据在挑战期内可用available所依赖的四个核心类型SignedAvailabilityBitfield、PoV、AvailableData与ErasureChunk。读者将掌握这些类型的数据结构、语义约束以及它们如何与仓库中的 erasure-coding 擦除编码库 和 av-store 可用性存储子系统 相互印证、构成 Polkadot 可用性协议的数据面。背景验证人如何确保数据可用在 Polkadot 中验证人validator的关键职责之一是在挑战期challenge period内保证所有用于验证候选candidate的数据始终可用。实现手段是对需要保持可用的数据进行擦除编码erasure-coding把一份完整数据切分成 n 份编码块chunk分发给全部 n 个验证人只要收集到足够数量的块任何一方都能重建完整数据从而不依赖单一验证人诚实保存全部副本。这一设计由四个相互关联的类型承载下面逐一展开。其中AvailableData是被编码的对象ErasureChunk是编码产物SignedAvailabilityBitfield是验证人上报我存了哪块的声明PoV则是贯穿其中的无状态验证证明数据。Signed Availability Bitfield验证人视角的可用性声明SignedAvailabilityBitfield是某个验证人对待处理候选pending candidates的可用性所签署的位域bitfield。它由 backing 阶段引入的通用 Signed 签名包装器 派生而来type SignedAvailabilityBitfield SignedBitvec; struct Bitfields(Vec(SignedAvailabilityBitfield)), // bitfields sorted by validator index, ascendingSignedPayload, RealPayload内部持有payload、validator_index和signature三部分签名覆盖 SCALE 编码后的(payload, signing_context)其中 SigningContextparent_hashsession_index用于防止重放攻击位域按验证人索引升序排序以便在链上处理时与验证人集合对齐。位域语义每一位对应一个可用性核心一个SignedAvailabilityBitfield代表某个特定验证人视角下的状态视图。位域中的每一位对应一个可用性核心availability core。某一位为1表示该验证人认为下列陈述对该核心同时成立该可用性核心处于被占用occupied状态存在与该核心对应的CommittedCandidateReceipt即该平行链para有一个正在推进中的区块该验证人的 Availability Store 中存有该平行链区块 PoV 的一个擦除编码块。换言之它是OccupiedCore::availability的转置链上OccupiedCore.availability中的每一位代表验证人 i 是否上报了该核心的可用性而每个验证人提交的位域则是对每个核心我是否可用的行视图。当 2/3 的位被置为1时该核心的数据即可被判定为可用。从节点侧看这些位域的流转由 bitfield-signing 子系统 生成、bitfield-distribution 子系统 分发最终汇入 relay chain 的 inclusion 流程更新OccupiedCore::availability位域。Proof-of-ValidityPoV无状态客户端验证证明PoV常被简称为 PoVProof-of-Validity是一个围绕字节的类型安全包装。当数据作为输入喂给平行链验证函数、充当候选的无状态客户端验证证明时使用struct PoV(Vecu8);文档层面的抽象是Vecu8包装仓库中的实际定义位于 node/primitives/src/lib.rs为pub struct PoV { pub block_data: BlockData }并附带hash()方法返回blake2-256哈希该哈希正是 CandidateDescriptor.pov_hash 字段的来源验证人据此核对收到的 PoV 是否与候选描述一致由于 PoV 体积可能很大受PersistedValidationData.max_pov_size约束它只在 backing/approval 阶段被需要可用性系统将其编码后分发而非逐份复制到每个验证人。AvailableData需要长期可用的数据单元AvailableData是系统希望为每个已被包含进 relay chain 的候选candidate 保持可用的数据集合由候选的 PoV 与其PersistedValidationData组成struct AvailableData { /// The Proof-of-Validation of the candidate. pov: ArcPoV, /// The persisted validation data used to check the candidate. validation_data: PersistedValidationData, }仓库中的实现与文档完全一致见 node/primitives/src/lib.rspov: std::sync::ArcPoV、validation_data: PersistedValidationData。这里有两个值得注意的设计点ArcPoV在节点进程内同一候选的 PoV 可能被多个子系统如 candidate-validation、approval-voting并发引用使用引用计数避免深拷贝降低内存开销PersistedValidationData必须持久化它包含parent_head、relay_parent_number、relay_parent_storage_root、hrmp_mqc_heads和max_pov_size等由链上状态推导的输入参数详见 candidate.md 定义。批准检查者approval checker在后续区块中复核候选时不再依赖旧的中继链状态而是直接使用随AvailableData持久化的这份数据这正是可用性一词的核心含义。文档原注未来引入 XCMP 后还需要把平行链验证产生的出站消息outgoing messages一并纳入AvailableData保持可用。Erasure Chunk擦除编码块与 Merkle 证明AvailableData在可用性流程中被擦除编码切分每个验证人分得一块。ErasureChunk描述其中一块以及该块针对 Merkle 根哈希的证明——该根哈希即为上下文中的erasure_root也即CandidateDescriptor.erasure_root字段struct ErasureChunk { /// The erasure-encoded chunk of data belonging to the candidate block. chunk: Vecu8, /// The index of this erasure-encoded chunk of data. index: u32, /// Proof for this chunks branch in the Merkle tree. proof: VecVecu8, }仓库实现node/primitives/src/lib.rs与文档略有演进index字段的类型是ValidatorIndex而非u32proof则被收紧为带长度上限的Proof(BoundedVecBoundedVecu8, 1, MERKLE_NODE_MAX_SIZE, 1, MERKLE_PROOF_MAX_DEPTH)防止恶意构建的超深证明造成内存/CPU 消耗并提供了iter()方法还原为VecVecu8视图。源码纵深擦除编码的容错阈值与 Merkle 分支构造理解了四个类型之后值得深入 erasure-coding 库 看它们是如何被编码、重建和验证的。容错模型f1 块即可重建该库的模块级注释明确了参数假设n 3f k其中0 k ≤ 3f是系统中最多故障验证人数。编码参数由验证人总数推导let needed n_validators.saturating_sub(1) / 3; Ok(needed 1)即恢复阈值recovery_threshold (n-1)/3 1 f 1只要收集到任意 f1 个块即可重建完整数据即使有 f 个验证人离线或作恶也不影响恢复。GF(2^16) 有限域与规模上限编码基于 Reed-Solomon 类算法在GF(2^16)有限域上工作因此验证人总数被限制为MAX_VALIDATORS 65536字段大小。对应地Error枚举定义了TooManyValidators、NotEnoughValidators、NotEnoughChunks、NonUniformChunks、UnevenLength块长必须为偶数才能适配 GF(2^16)等可恢复错误。核心 API 如下obtain_chunks(n_validators, data)将AvailableDataSCALE 编码后切成 n 个 shard返回VecVecu8每个验证人一块reconstruct(n_validators, chunks)接收([u8], usize)形式的块与索引校验索引越界、块长一致性与偶数性后重建并Decode回AvailableDatabranches(chunks)/branch_hash(root, proof, index)前者把每个块的哈希按索引写入 Patricia Merkle Trie 并返回根与逐块证明后者用分支节点重建 Trie、trie.get_with取出对应索引的块哈希用于验证一个ErasureChunk.proof是否匹配erasure_root。这一验证路径解释了ErasureChunk.proof为何是分支证明它不是把整棵 Merkle 树交给验证人而是只提供目标叶子到根的路径节点验证复杂度与树深相关而非与块数成正比。可用性存储与剪枝1 小时 / 25 小时规则ErasureChunk与AvailableData最终落盘在 av-store 可用性存储子系统 中。该子系统按文档中可用性存储规范实现几个关键常量与数据库前缀可以在源码中直接看到常量值含义KEEP_UNAVAILABLE_FOR1 小时已声明但从未被 backing 的 PoV/块保留时长KEEP_FINALIZED_FOR25 小时1 天 1 小时候选进入最终化区块后的保留时长覆盖争议期PRUNING_INTERVAL5 分钟后台剪枝例程的触发间隔数据库采用键值模型前缀为available、chunk、meta、unfinalized、prune_by_time其中时间戳与区块号均以大端序编码以保证字典序即时间序见 lib.rs 与 schema 文档。每个候选的元信息CandidateMeta维护一个三态状态机Unavailable→Unfinalized→Finalized源码 State 枚举并记录data_available与chunks_stored位域其状态迁移、BlockFinalized事件处理与按时间剪枝的逻辑均在 文档对应章节 有逐消息的复杂度说明。类型在可用性协议中的完整流转将上述类型串联起来即可得到一条完整的可用性数据链路Backing 阶段候选通过 backing 类型 获得足够的有效性投票后以BackedCandidate提交到 relay chain进入 pending-availability 阶段此时CandidateDescriptor中已经承诺了pov_hash与erasure_root擦除编码与分发验证人把AvailableDataPoV PersistedValidationData经 erasure-coding 编码为 n 个块配合 Merkle 分支证明经 availability-distribution 分发每个验证人在自己的 av-store 中按(chunk, candidate_hash, index)存储自己的块位域上报每个验证人基于我的 av-store 里有哪些块生成SignedAvailabilityBitfield即OccupiedCore::availability的转置通过 bitfield-distribution 汇聚核心释放判定链上在满足 2/3 位域声明后判定该核心可用、候选完成包含若超时time_out_at则走超时释放路径长期保持与剪枝av-store 依据unfinalized/finalized状态与 1 小时、25 小时的剪枝规则保证数据在挑战期内可被 availability-recovery 子系统随时按需重建——只要收集到 f1 个块即可通过reconstruct恢复完整AvailableData用于争议仲裁或批准检查。小结SignedAvailabilityBitfield、PoV、AvailableData、ErasureChunk四个类型构成了 Polkadot 可用性协议的数据面位域完成谁存了什么的链上声明AvailableData定义了要存什么擦除编码决定了怎么存才抗故障而ErasureChunk及其 Merkle 证明保证了取回的每一块都可被链上承诺的erasure_root验证。阅读时建议将本页与 candidate 类型、availability cores 运行时 API、availability store 子系统 三份文档对照阅读并可在 erasure-coding/src/lib.rs 与 node/core/av-store/src/lib.rs 中直接查看对应实现。赞分享区块链【免费下载链接】polkadotPolkadot Node Implementation项目地址https://gitcode.com/gh_mirrors/po/polkadot点击查看免费下载相关推荐Polkadot 可用性存储Availability Store子系统解析PoV 与擦除分块的数据保鲜与剪枝机制Polkadot 可用性存储Availability Store子系统解析PoV 与擦除分块的数据保鲜与剪枝机制 Availability Store 是区块链AnyCodable类型擦除的编码和解码工具库AnyCodable类型擦除的编码和解码工具库 AnyCodable 是一个使用 Swift 编写的开源项目旨在为开发者提供一种简单的方式来处理 EncodTypeScript 擦除的结构类型Erased Structural Types深度解析结构兼容、多余属性检查与编译期类型擦除TypeScript 擦除的结构类型Erased Structural Types深度解析结构兼容、多余属性检查与编译期类型擦除 本指南基于《The Co文档教程上一篇opencodex 面向 Agent 的安装与运行规则用户同意边界的实现与操作指南下一篇ARIS 机器人方向 Idea Discovery 流水线实战从宽泛方向到 simulation-first 的可证伪研究选题创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Polkadot 可用性类型详解：位域、PoV、AvailableData 与擦除编码块
区块链【免费下载链接】polkadotPolkadot Node Implementation项目地址https://gitcode.com/gh_mirrors/po/polkadot点击查看免费下载本文围绕 Polkadot 实现者指南中 Availability 类型定义系统梳理验证人validator保证候选区块candidate数据在挑战期内可用available所依赖的四个核心类型SignedAvailabilityBitfield、PoV、AvailableData与ErasureChunk。读者将掌握这些类型的数据结构、语义约束以及它们如何与仓库中的 erasure-coding 擦除编码库 和 av-store 可用性存储子系统 相互印证、构成 Polkadot 可用性协议的数据面。背景验证人如何确保数据可用在 Polkadot 中验证人validator的关键职责之一是在挑战期challenge period内保证所有用于验证候选candidate的数据始终可用。实现手段是对需要保持可用的数据进行擦除编码erasure-coding把一份完整数据切分成 n 份编码块chunk分发给全部 n 个验证人只要收集到足够数量的块任何一方都能重建完整数据从而不依赖单一验证人诚实保存全部副本。这一设计由四个相互关联的类型承载下面逐一展开。其中AvailableData是被编码的对象ErasureChunk是编码产物SignedAvailabilityBitfield是验证人上报我存了哪块的声明PoV则是贯穿其中的无状态验证证明数据。Signed Availability Bitfield验证人视角的可用性声明SignedAvailabilityBitfield是某个验证人对待处理候选pending candidates的可用性所签署的位域bitfield。它由 backing 阶段引入的通用 Signed 签名包装器 派生而来type SignedAvailabilityBitfield SignedBitvec; struct Bitfields(Vec(SignedAvailabilityBitfield)), // bitfields sorted by validator index, ascendingSignedPayload, RealPayload内部持有payload、validator_index和signature三部分签名覆盖 SCALE 编码后的(payload, signing_context)其中 SigningContextparent_hashsession_index用于防止重放攻击位域按验证人索引升序排序以便在链上处理时与验证人集合对齐。位域语义每一位对应一个可用性核心一个SignedAvailabilityBitfield代表某个特定验证人视角下的状态视图。位域中的每一位对应一个可用性核心availability core。某一位为1表示该验证人认为下列陈述对该核心同时成立该可用性核心处于被占用occupied状态存在与该核心对应的CommittedCandidateReceipt即该平行链para有一个正在推进中的区块该验证人的 Availability Store 中存有该平行链区块 PoV 的一个擦除编码块。换言之它是OccupiedCore::availability的转置链上OccupiedCore.availability中的每一位代表验证人 i 是否上报了该核心的可用性而每个验证人提交的位域则是对每个核心我是否可用的行视图。当 2/3 的位被置为1时该核心的数据即可被判定为可用。从节点侧看这些位域的流转由 bitfield-signing 子系统 生成、bitfield-distribution 子系统 分发最终汇入 relay chain 的 inclusion 流程更新OccupiedCore::availability位域。Proof-of-ValidityPoV无状态客户端验证证明PoV常被简称为 PoVProof-of-Validity是一个围绕字节的类型安全包装。当数据作为输入喂给平行链验证函数、充当候选的无状态客户端验证证明时使用struct PoV(Vecu8);文档层面的抽象是Vecu8包装仓库中的实际定义位于 node/primitives/src/lib.rs为pub struct PoV { pub block_data: BlockData }并附带hash()方法返回blake2-256哈希该哈希正是 CandidateDescriptor.pov_hash 字段的来源验证人据此核对收到的 PoV 是否与候选描述一致由于 PoV 体积可能很大受PersistedValidationData.max_pov_size约束它只在 backing/approval 阶段被需要可用性系统将其编码后分发而非逐份复制到每个验证人。AvailableData需要长期可用的数据单元AvailableData是系统希望为每个已被包含进 relay chain 的候选candidate 保持可用的数据集合由候选的 PoV 与其PersistedValidationData组成struct AvailableData { /// The Proof-of-Validation of the candidate. pov: ArcPoV, /// The persisted validation data used to check the candidate. validation_data: PersistedValidationData, }仓库中的实现与文档完全一致见 node/primitives/src/lib.rspov: std::sync::ArcPoV、validation_data: PersistedValidationData。这里有两个值得注意的设计点ArcPoV在节点进程内同一候选的 PoV 可能被多个子系统如 candidate-validation、approval-voting并发引用使用引用计数避免深拷贝降低内存开销PersistedValidationData必须持久化它包含parent_head、relay_parent_number、relay_parent_storage_root、hrmp_mqc_heads和max_pov_size等由链上状态推导的输入参数详见 candidate.md 定义。批准检查者approval checker在后续区块中复核候选时不再依赖旧的中继链状态而是直接使用随AvailableData持久化的这份数据这正是可用性一词的核心含义。文档原注未来引入 XCMP 后还需要把平行链验证产生的出站消息outgoing messages一并纳入AvailableData保持可用。Erasure Chunk擦除编码块与 Merkle 证明AvailableData在可用性流程中被擦除编码切分每个验证人分得一块。ErasureChunk描述其中一块以及该块针对 Merkle 根哈希的证明——该根哈希即为上下文中的erasure_root也即CandidateDescriptor.erasure_root字段struct ErasureChunk { /// The erasure-encoded chunk of data belonging to the candidate block. chunk: Vecu8, /// The index of this erasure-encoded chunk of data. index: u32, /// Proof for this chunks branch in the Merkle tree. proof: VecVecu8, }仓库实现node/primitives/src/lib.rs与文档略有演进index字段的类型是ValidatorIndex而非u32proof则被收紧为带长度上限的Proof(BoundedVecBoundedVecu8, 1, MERKLE_NODE_MAX_SIZE, 1, MERKLE_PROOF_MAX_DEPTH)防止恶意构建的超深证明造成内存/CPU 消耗并提供了iter()方法还原为VecVecu8视图。源码纵深擦除编码的容错阈值与 Merkle 分支构造理解了四个类型之后值得深入 erasure-coding 库 看它们是如何被编码、重建和验证的。容错模型f1 块即可重建该库的模块级注释明确了参数假设n 3f k其中0 k ≤ 3f是系统中最多故障验证人数。编码参数由验证人总数推导let needed n_validators.saturating_sub(1) / 3; Ok(needed 1)即恢复阈值recovery_threshold (n-1)/3 1 f 1只要收集到任意 f1 个块即可重建完整数据即使有 f 个验证人离线或作恶也不影响恢复。GF(2^16) 有限域与规模上限编码基于 Reed-Solomon 类算法在GF(2^16)有限域上工作因此验证人总数被限制为MAX_VALIDATORS 65536字段大小。对应地Error枚举定义了TooManyValidators、NotEnoughValidators、NotEnoughChunks、NonUniformChunks、UnevenLength块长必须为偶数才能适配 GF(2^16)等可恢复错误。核心 API 如下obtain_chunks(n_validators, data)将AvailableDataSCALE 编码后切成 n 个 shard返回VecVecu8每个验证人一块reconstruct(n_validators, chunks)接收([u8], usize)形式的块与索引校验索引越界、块长一致性与偶数性后重建并Decode回AvailableDatabranches(chunks)/branch_hash(root, proof, index)前者把每个块的哈希按索引写入 Patricia Merkle Trie 并返回根与逐块证明后者用分支节点重建 Trie、trie.get_with取出对应索引的块哈希用于验证一个ErasureChunk.proof是否匹配erasure_root。这一验证路径解释了ErasureChunk.proof为何是分支证明它不是把整棵 Merkle 树交给验证人而是只提供目标叶子到根的路径节点验证复杂度与树深相关而非与块数成正比。可用性存储与剪枝1 小时 / 25 小时规则ErasureChunk与AvailableData最终落盘在 av-store 可用性存储子系统 中。该子系统按文档中可用性存储规范实现几个关键常量与数据库前缀可以在源码中直接看到常量值含义KEEP_UNAVAILABLE_FOR1 小时已声明但从未被 backing 的 PoV/块保留时长KEEP_FINALIZED_FOR25 小时1 天 1 小时候选进入最终化区块后的保留时长覆盖争议期PRUNING_INTERVAL5 分钟后台剪枝例程的触发间隔数据库采用键值模型前缀为available、chunk、meta、unfinalized、prune_by_time其中时间戳与区块号均以大端序编码以保证字典序即时间序见 lib.rs 与 schema 文档。每个候选的元信息CandidateMeta维护一个三态状态机Unavailable→Unfinalized→Finalized源码 State 枚举并记录data_available与chunks_stored位域其状态迁移、BlockFinalized事件处理与按时间剪枝的逻辑均在 文档对应章节 有逐消息的复杂度说明。类型在可用性协议中的完整流转将上述类型串联起来即可得到一条完整的可用性数据链路Backing 阶段候选通过 backing 类型 获得足够的有效性投票后以BackedCandidate提交到 relay chain进入 pending-availability 阶段此时CandidateDescriptor中已经承诺了pov_hash与erasure_root擦除编码与分发验证人把AvailableDataPoV PersistedValidationData经 erasure-coding 编码为 n 个块配合 Merkle 分支证明经 availability-distribution 分发每个验证人在自己的 av-store 中按(chunk, candidate_hash, index)存储自己的块位域上报每个验证人基于我的 av-store 里有哪些块生成SignedAvailabilityBitfield即OccupiedCore::availability的转置通过 bitfield-distribution 汇聚核心释放判定链上在满足 2/3 位域声明后判定该核心可用、候选完成包含若超时time_out_at则走超时释放路径长期保持与剪枝av-store 依据unfinalized/finalized状态与 1 小时、25 小时的剪枝规则保证数据在挑战期内可被 availability-recovery 子系统随时按需重建——只要收集到 f1 个块即可通过reconstruct恢复完整AvailableData用于争议仲裁或批准检查。小结SignedAvailabilityBitfield、PoV、AvailableData、ErasureChunk四个类型构成了 Polkadot 可用性协议的数据面位域完成谁存了什么的链上声明AvailableData定义了要存什么擦除编码决定了怎么存才抗故障而ErasureChunk及其 Merkle 证明保证了取回的每一块都可被链上承诺的erasure_root验证。阅读时建议将本页与 candidate 类型、availability cores 运行时 API、availability store 子系统 三份文档对照阅读并可在 erasure-coding/src/lib.rs 与 node/core/av-store/src/lib.rs 中直接查看对应实现。赞分享区块链【免费下载链接】polkadotPolkadot Node Implementation项目地址https://gitcode.com/gh_mirrors/po/polkadot点击查看免费下载相关推荐Polkadot 可用性存储Availability Store子系统解析PoV 与擦除分块的数据保鲜与剪枝机制Polkadot 可用性存储Availability Store子系统解析PoV 与擦除分块的数据保鲜与剪枝机制 Availability Store 是区块链AnyCodable类型擦除的编码和解码工具库AnyCodable类型擦除的编码和解码工具库 AnyCodable 是一个使用 Swift 编写的开源项目旨在为开发者提供一种简单的方式来处理 EncodTypeScript 擦除的结构类型Erased Structural Types深度解析结构兼容、多余属性检查与编译期类型擦除TypeScript 擦除的结构类型Erased Structural Types深度解析结构兼容、多余属性检查与编译期类型擦除 本指南基于《The Co文档教程上一篇opencodex 面向 Agent 的安装与运行规则用户同意边界的实现与操作指南下一篇ARIS 机器人方向 Idea Discovery 流水线实战从宽泛方向到 simulation-first 的可证伪研究选题创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考