【免费下载链接】quip-validatorA rust implementation of the Quip Protocol forked from Substrate项目地址https://gitcode.com/gh_mirrors/qu/quip-validator点击查看免费下载阅读导读本文围绕 quip-validator 仓库中的去重方案文档 docs/hybrid-crypto-dedup-plan.md 展开剖析该方案要解决的双份实现漂移风险、sp-io 无法进入浏览器 WASM 的约束以及通过 SDK fork 侧新增 sp-freecrypto-core实现字节级收敛的三阶段落地路径。读完本文你将掌握H3sr25519 ML-DSA-44两套实现必须保持字节一致的根本原因、quip-crypto-primitives中哪些模块是 sp-free 的、classical/sr25519.rs如何用schnorrkelblake2替换sp_core以及如何用 golden-vector parity gate 从机制上杜绝再次漂移。注意文档标注了当前状态——交易签名与共识已切换到 H2/H4pqhybridsign的composite_delta本文聚焦的 H3 去重设计属于遗留 H1/H3 后续跟进阅读时请结合仓库实际代码状态理解。1. 问题背景为什么存在“必须一致”的两份实现1.1 两条代码路径、同一个签名套件在 quip-validator 的混合密码学架构中同一个 H3 签名套件sr25519 ML-DSA-44被实现了两次位置角色定位quip-transaction-crypto-core本仓库 crates/transaction-crypto-coreno_std、依赖极少的字节级实现用于构建浏览器签名器 WASMquip-crypto-primitivesSDK forkpolkadot-sdk/quip/primitives/crypto经QuipNetwork/polkadot-sdkv0.2git 依赖拉取运行时runtime基于其构建的权威混合签名方案两者的字节必须逐字节一致runtime 验证的正是浏览器签出的内容。一旦任意一处发生漂移例如改了 HKDF 派生串、换了个签名上下文所有已签名的 extrinsic 都会在链上静默验签失败——这是最危险的失败模式不是报错而是全部失效。1.2 为什么不能简单复用一份直觉上最简单方案是让transaction-crypto-core直接依赖quip-crypto-primitives但文档明确指出此路不通quip-crypto-primitives依赖sp-core、sp-application-crypto和sp-iosp-io依赖 runtime host functions无法在独立浏览器 WASM 中链接没有宿主环境提供 host function浏览器签名器 bundle 必须保持小体积-Oz优化约 400 KB引入 sp 栈会显著膨胀。因此只能通过在 SDK fork 侧抽出 sp-free 核心来同时满足“单一实现”与“浏览器可用”两个约束。2. 当前重复内容清单必须保持同步的部分文档给出了一个精确的“重复内容对照表”逐项列出了两个 crate 中需要严格锁步的实现关注点transaction-crypto-corequip-crypto-primitives消息框架v ‖ label ‖ len(ctx) ‖ ctx ‖ msgprepare_messagelib.rs:417 附近当前已重构为pqhybridsign内建框架domain.rs::prepare_messageHKDF 种子拆分hybrid-sig/classical/pqderive_component_seedslib.rs:268 附近seed.rsLabelhybrid-sr25519-mldsa44-v1\0、版本0x01H3_LABEL/H3_VERSIONlib.rs:40-41suite/sr25519_mldsa44.rssuite/mod.rs::DEFAULT_HYBRID_SIGNATURE_VERSION长度 32/64/64、1312/2560/2420常量lib.rs:28-34classical/sr25519.rs、pq/mldsa44.rs确定性 sr25519Blake2Rngctxbsubstratesr25519_sign_deterministicBlake2Rnglib.rs:428,500 附近classical/sr25519.rs相同的Blake2RngML-DSA-44 签名/验签ml_dsa_*lib.rs:466-486 附近pq/mldsa44.rs组装 / 签名 / 验签流程keypair_from_seed/sign_h3_deterministic/verify_h3fixed.rs泛型引擎这些内容过去由手工在两处维护这正是文档标题所指的“fragile脆弱”来源。2.1 不重复的部分留在transaction-crypto-coreSDK crate没有以下能力它没有bip39依赖、没有账户模型因此这些 quip 特有逻辑天然只存在于transaction-crypto-core无需去重Account-id 派生ACCOUNT_ID_DOMAIN bquip-account-v1account_id_from_public_byteslib.rs:54,119。实现为Blake2bVar(32)对domain ‖ public做变长 Blake2b 哈希lib.rs:156-166SCALE 信封HybridTxSignatureByteslib.rs:77{ public: [u8; HYBRID_PUBLIC_LEN], signature: [u8; HYBRID_SIGNATURE_LEN] }实现了Encode/Decode/DecodeWithMemTracking并提供encode_envelope/decode_envelopelib.rs:105-153BIP39 / secret-URI → seedmaster_seed_from_secret_uri、master_seed_from_mnemonic、decode_seed_hexlib.rs:149,176,201。其中master_seed_from_mnemonic使用Mnemonic::parse_in_normalizedsubstrate_bip39::seed_from_entropyPBKDF2-HMAC-SHA512、盐mnemonic ‖ password、2048 轮取 64 字节输出的前 32 字节作为 master seedlib.rs:218-240。仓库佐证SDK 侧sp_*用法被严格限定在两处——substrate/*SubstratePair/Public/Signature包装器保持 sp 绑定是预期行为以及classical/sr25519.rs唯一一处使用sp_core::sr25519::Pair的from_seed/verify与sp_core::hashing::blake2_256。其余模块domain、seed、fixed、pq/mldsa44、suite、error已完全 sp-free仅依赖schnorrkel/fips204/blake2/hkdf/sha2/rand_core/subtle/zeroize。3. 核心约束与关键使能发现3.1 约束再确认去重的核心约束始终是SDK 的quip-crypto-primitives因依赖sp-io无法进入独立浏览器 WASM而浏览器签名器必须保持小体积。所以不能“直接依赖”只能“抽离共享核心”。3.2 关键使能发现sp 绑定可以被替换文档给出了一个决定性发现classical/sr25519.rs的sp_core用法可以用直接的schnorrkelblake2调用替换而且transaction-crypto-core在生产中已经证明了这些替换产生完全相同的字节当前两套实现在线上互操作sp_core调用等价纯 Rust 调用sr25519::Pair::from_seed_slice(seed)MiniSecretKey::from_bytes(seed).expand_to_keypair(Ed25519)sr25519::Pair::verify(...)PublicKey::verify_simple(bsubstrate, ...)sp_core::hashing::blake2_256(x)Blake2bVar::new(32) … finalize这意味着整个纯密码学栈可以整体迁移进一个 sp-free crate且不会改变任何线上字节。仓库佐证当前 crates/transaction-crypto-core/src/lib.rs 已在用pqhybridsign::composite_deltaSrFn512H4并直接用Blake2bVar实现 account-id 派生lib.rs:156-166、用blake2与substrate-bip39实现种子派生证明“无 sp_core 的纯依赖集”在本仓库路径上是可行的。其Cargo.toml仅依赖pqhybridsign、bip39、blake2、codec、substrate-bip39、zeroize见 crates/transaction-crypto-core/Cargo.toml。4. 目标架构一个 sp-free 核心 薄包装文档给出的目标架构如下关键点已结合仓库实际路径标注polkadot-sdk/quip/primitives/ ├── crypto-core/ # 新建quip-crypto-primitives-coreno_std、sp-FREE │ └── src/{domain,seed,fixed,error,pq/*,suite/*,classical/*}.rs │ deps: schnorrkel, ed25519-zebra, fips204, blake2, hkdf, sha2, │ rand_core, subtle, zeroize按需 codec/scale-info └── crypto/ # quip-crypto-primitives公开 API 不变 └── src/substrate/*.rs # sp 绑定包装器re-export crypto-core deps: quip-crypto-primitives-core sp-core/sp-io/sp-application-crypto quip-validator/crates/transaction-crypto-core/ # 收缩 依赖 quip-crypto-primitives-coresp-free使用 H3 套件 仅保留account-idquip-account-v1、HybridTxSignatureBytes 信封、 BIP39/secret-URI seed 辅助函数、薄签名/验签包装。架构要点依赖方向保持正确SDK 是quip-validator的上游quip-validator通过现有的QuipNetwork/polkadot-sdkv0.2git 依赖消费新 crate公开 API 不变crypto/层通过pub use重导出核心现有消费者如Sr25519MlDsa44、HybridSignatureScheme、domain、seed、suite 常量、HybridSignatureError无需改动transaction-crypto-core收缩为“quip 特有逻辑 薄包装”。仓库佐证该架构方向在仓库当前版本中已有呼应——根 Cargo.toml 的[workspace.dependencies]同时声明了quip-crypto-primitivesCargo.toml:129与quip-crypto-primitives-coreCargo.toml:130两个 git 依赖均指向QuipNetwork/polkadot-sdk同一 revCargo.lock 中也同时存在quip-crypto-primitives与quip-crypto-primitives-core两个 package。而 crates/transaction-crypto/src/lib.rs 使用quip_crypto_primitives::substrate::sr25519_fndsa512定义HybridPublic/HybridPairH4transaction-crypto-core则通过pqhybridsign::composite_delta::SrFn512走同一实现——两者通过同一库保持字节一致crates/transaction-crypto/src/lib.rs:246-269 的测试runtime_signature_scale_matches_core_envelope直接断言 runtime 信封与 core 信封 SCALE 编码相等。5. 三阶段落地步骤5.1 Phase 1 —— SDK forkpolkadot-sdk分支v0.2创建quip/primitives/crypto-corecratequip-crypto-primitives-coreno_std使用上述 sp-free 依赖集将domain.rs、seed.rs、fixed.rs、error.rs、pq/、suite/、classical/移入保持模块布局与公开 API重写classical/sr25519.rs去除sp_corefrom_seedschnorrkel::MiniSecretKey::from_bytes(seed).expand_to_keypair(ExpansionMode::Ed25519)verifyschnorrkel::PublicKey::verify_simple(bsubstrate, …)blake2_256_seed_counter改用Blake2bVar确认新 crate 通过 workspace lints 与no_std构建在quip-crypto-primitivescrypto/中依赖crypto-core删除被迁移的模块保留substrate/*并pub use核心内容以保持现有公开 API 不变运行 SDK crate 既有 suite 测试suite/sr25519_mldsa44.rs测试模块——迁移后的代码必须原样通过合入v0.2分支。5.2 Phase 2 ——quip-validator将quip-crypto-primitives-core加入 workspace Cargo.tomlgit QuipNetwork/polkadot-sdk, branch v0.2, default-features false与现有quip-crypto-primitives条目保持一致重写 crates/transaction-crypto-core/src/lib.rs删除重复的常量与逻辑长度常量、HKDF 字符串、H3_LABEL/H3_VERSION、SUBSTRATE_SIGNING_CONTEXT、prepare_message、derive_component_seeds、keypair_from_seed、sr25519_*、ml_dsa_*、sign_h3_deterministic、verify_h3、Blake2Rng、各*_from_bytes校验器保留并在共享套件上重建HYBRID_PUBLIC_LEN/HYBRID_SIGNATURE_LEN/HYBRID_SECRET_LEN← 套件的HYBRID_PK_LEN/HYBRID_SIG_LEN/HYBRID_SK_LENpublic_key_from_seed、sign_payload_from_seed、sign_payload_from_secret、HybridTxSignatureBytes::verify→ 变为Sr25519MlDsa44::{from_seed_slice, sign_deterministic, public, verify}的薄包装固定ctx b、nonce baccount_id_from_public_bytes/ACCOUNT_ID_DOMAIN—— 不变quip 特有HybridTxSignatureBytes信封 —— 不变SCALE、quip-tx 特有master_seed_from_*/decode_seed_hex—— 不变BIP39在边界处将套件的HybridSignatureError映射为HybridTxCryptoError保持公开错误类型不变精简 crates/transaction-crypto-core/Cargo.toml删除已被共享 crate 提供的依赖fips204、schnorrkel、hkdf、sha2、rand_core若不再被直接引用可移除按需保留bip39、substrate-bip39、blake2account-id、codec、zeroize保持 crateno_stddefault [std]确保 WASM cratetransaction-crypto-wasm仍能构建。5.3 Phase 3 —— Parity gate无论阶段顺序都必须做添加一个入库的 golden-vector fixture与测试断言两个实现永远一致向量seed → public_key以及若干个固定 seed/message 的(seed, msg) → signature包含一个 BIP39 派生的 seed从quip-crypto-primitivesSr25519MlDsa44生成断言transaction-crypto-core能复现且 runtime verifier 接受它们放置于crates/transaction-crypto-core/tests/沿用现有quantum-validationfixture 模式在删除代码之前捕获当前重构前签名器输出作为基线向量使 Phase 2 能以今天的字节为基准被验证。仓库佐证Phase 3 描述的“golden-vector parity gate”模式在仓库中已有成熟的实现样例crates/transaction-crypto-core/tests/golden_parity.rs 读取 golden_vectors.txt断言seed → public与(seed, msg) → signature envelope与 H4 golden 字节完全一致其中transaction_core_matches_pqhybridsign_h4直接对比composite_delta直调与sign_payload_from_seed信封golden_parity.rs:98-131向量文件包含seed_01/07/09/11、bip39、bip39_pw的 public 及三类 messagemsg_quip/msg_empty/msg_fixture的信封golden_vectors.txt生成器为 crates/transaction-crypto-core/examples/generate_golden_vectors.rs从固定 seed 与 BIP39 短语bottom drive obey lake curtain smoke basket hold race lonely fit walk打印name_seed/name_public/name_msg_envelope跨语言层面quantum-validation的 crates/quantum-validation/tests/python_parity.rs 展示了同一“fixture 驱动跨实现一致性”的测试组织方式Rust 测试消费 JSON fixture部分用例与 Python 参考实现对比。6. 验证清单Verification checklist文档给出了重构完成后的完整验证门禁原文逐项列出cargo build -p quip-crypto-primitives-core --no-default-featuressp-free、no_std构建通过SDKquip-crypto-primitives测试全绿公开 API 不变现有消费者无需改动cargo test -p quip-transaction-crypto-core全绿含新增 parity fixturesmake wasm-signer构建成功bundle 体积不显著超过 ~400 KB端到端浏览器签出的 extrinsic 仍能在 runtime 验签通过appsdev signer以QUIP_DEV_SIGNER1运行。仓库佐证wasm-signertarget 定义于 Makefile使用wasm-pack 0.12.1以--target web --release构建 crates/transaction-crypto-wasm并经-Oz --strip-debug优化见 crates/transaction-crypto-wasm/Cargo.toml 的[package.metadata.wasm-pack.profile.release]随后打印产物字节数——这正是文档所述“~400 KB”体积门禁的执行点。QUIP_DEV_SIGNER1的端到端路径由 docs/polkadotjs/wasm-signing-plan.md 的 Phase 4 描述system.remark→balances.transferKeepAlive→ 反向转账 → mnemonic 导入账户 → 超长 payload 触发 Blake2-256 签名。7. 风险与缓解措施风险缓解措施奇偶性关键、安全敏感代码golden vectors 在重构之前捕获步骤 12重构是纯移动 依赖替换不是逻辑变更跨仓库 / 分支协调Phase 1 已合入v0.2Phase 2 通过标准QuipNetwork/polkadot-sdkv0.2git 依赖消费quip-crypto-primitives-core——与其它 SDK crate 同源同分支开发期曾用临时 feature-branch pin现已切回v0.2classical/sr25519.rs的 sp-swap 改变字节替换目标已是被证明的等价实现core 今天就在用parity fixtures 立即捕获任何偏差意外拉入sp-*导致 WASM 膨胀新 crate 完全没有sp-*依赖对 WASM crate 增加cargo tree检查8. 范围外事项Out of scope文档明确本次去重不涉及ed25519_mldsa44套件共识密钥——随其余代码一起迁入crypto-core但transaction-crypto-core无消费者改动重命名公开 H3 API 或信封线格式任何对quip-account-v1派生或 SCALE 信封布局的修改。仓库佐证“不改quip-account-v1”是仓库中的硬约束ACCOUNT_ID_DOMAIN被account_id_domain_is_pinned测试钉死crates/transaction-crypto-core/src/lib.rs:344-347且 crates/transaction-crypto/src/lib.rs 的模块级安全注释明确警告任何截断/投影公钥输入的做法都会静默削弱 account-id 碰撞抵抗crates/transaction-crypto/src/lib.rs:16-34并再次以account_id_domain_is_pinned测试crates/transaction-crypto/src/lib.rs:338-347锁定。9. 附文档中记录的当前状态与既有约束9.1 当前状态H2/H4 chain-wipe relaunch文档开头的引用块明确记录当前交易签名与共识已改用pqhybridsign的 H4sr25519 FN-DSA-512与 H2ed25519 FN-DSA-512。quip-transaction-crypto-core直接调用库的composite_delta实现SDK 提供 Substrate 包装器。本文主体所述的 H3 去重设计记录的是早期设计仅对遗留 H1/H3 后续跟进有参考价值。9.2 AGPL 与预发布 FIPS-206 约束pqhybridsign采用AGPL-3.0-or-later许可其固定的 FN-DSA-512 实现是pre-final-FIPS-206的任何依赖或线格式变更都是共识破坏性变更对 H2/H4 启动而言这意味着链清空后的全新 genesis、runtime 与 transaction version 变更、以及重新生成的向量——而不是对既有链状态的原地迁移。仓库佐证runtime 版本注释印证了“线格式变更必须 bump 版本”的既有纪律runtime/src/lib.rs 记录签名线格式从MultiSignature切换到混合信封时spec_versionbump 到 101 且transaction_version升至 2后续每次调用编码变更都伴随显式的版本注释文档 docs/h2-h4-integration-plan.md 亦记载 H2/H4 的 FN-DSA 线格式可能随上游变动需把pqhybridsigngit rev 固定并视任何 bump 为共识破坏docs/h2-h4-integration-plan.md “Risks / notes”一节。10. 延伸本次去重与仓库其它方案的关系本文所述的“单一 sp-free 密码学核心”思路与仓库中的其它工程方案共享同一架构理念可相互印证docs/h2-h4-integration-plan.mdH2/H4 集成方案同样依托 fork 的quip-crypto-primitives-coresp-free 引擎quip-crypto-primitivesSubstrate 胶水层两层结构且 H2/H4 的 golden-vector parity 断言与本文 Phase 3 完全同构docs/pyo3-bindings-plan.mdPython 绑定transaction-crypto-py经transaction-crypto-core传递性消费quip-crypto-primitives-core无需新增 SDK 依赖条目——与本文“sp-free 核心可同时服务于 WASM/Python/浏览器”的结论一致docs/polkadotjs/wasm-signing-plan.md浏览器签名器js/quip-signer在signRaw中执行 Substrate 的 256 字节blake2_256规则js/quip-signer/src/index.ts:209-224WASM 侧只负责对收到的确切字节签名——这份“签名器与 runtime 必须字节一致”的契约正是本文去重要守住的目标。总结docs/hybrid-crypto-dedup-plan.md描述的去重方案本质上是一次**“用架构收敛替代人工维护奇偶性”的工程改造在 SDK fork 侧抽出no_std、sp-free 的quip-crypto-primitives-core让transaction-crypto-core浏览器 WASM/Python与quip-crypto-primitivesruntime共享同一份字节级实现**再用 golden-vector parity gate 从机制上杜绝未来漂移。虽然当前交易签名已切换到 H2/H4本文记录的 H3 收敛路径及其“纯移动 依赖替换、不做逻辑变更”“先捕获基线向量再删代码”“sp-free 依赖集约束”等工程纪律对理解 quip-validator 混合密码学栈的演进与维护方式仍有直接的参考价值。赞分享【免费下载链接】quip-validatorA rust implementation of the Quip Protocol forked from Substrate项目地址https://gitcode.com/gh_mirrors/qu/quip-validator点击查看免费下载相关推荐gsd-core 项目根解析统一改造findProjectRoot 从 CJS/SDK 双实现收敛为单一 Project-Root Resolution 模块gsd core 项目根解析统一改造findProjectRoot 从 CJS/SDK 双实现收敛为单一 Project Root Resolution 模块Ouroboros ooo auto 深度解析从一句话目标到 A 级 Seed 的确定性收敛引擎Ouroboros ooo auto 深度解析从一句话目标到 A 级 Seed 的确定性收敛引擎 ooo auto 是 Ouroboros 项目中的端到端自动AI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具Valhalla Thor 路径算法深度解析从 A* 到双向搜索与动态代价的工程实现Valhalla Thor 路径算法深度解析从 A 到双向搜索与动态代价的工程实现 导读 本文聚焦 Valhalla开源 OpenStreetMap 路由引后端上一篇Ant Design Vue 4.x 版本演进全解从 4.0 设计体系重构到 4.2 系列迭代下一篇终极免费Flash反编译工具JPEXS FFDec完全指南轻松提取SWF资源与代码创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考