后量子密码学迁移实践指南

数据来源：MSG Chain 代码库核实

主网状态: No-Go — 当前 MSGChain 主网裁决为 No-Go，以下内容反映代码实际状态，不代表生产可用。

MSG Chain 全栈后量子密码学迁移手册

第一章：后量子密码学全景

1.1 后量子密码学概述

后量子密码学（Post-Quantum Cryptography, PQC）是一类能够抵抗量子计算机攻击的密码算法。与当前广泛使用的RSA、ECDSA等基于数论问题的算法不同，PQC算法所依赖的数学问题被认为对量子计算机是困难的。

1.1.1 为什么区块链必须关注PQC

当前区块链基础设施广泛依赖的数字签名算法和公钥密码体制，几乎全部可以被Shor算法在多项式时间内破解。这意味着在足够强大的量子计算机出现后：

• Secp256k1（比特币、以太坊、Cosmos生态）：完全破解
• Ed25519（Cosmos SDK、Solana、Cardano等）：完全破解
• BN256 / BLS12-381（以太坊2.0、Filecoin等）：完全破解
• RSA（TLS、证书体系）：完全破解

对于MSG Chain而言，从创世块开始就采用后量子密码学策略，是确保链上资产长期安全的根本保障。

1.1.2 PQC与传统密码学的根本区别

1.2 NIST PQC标准化进展

美国国家标准与技术研究院（NIST）自2016年起启动后量子密码学标准化项目，经历了多轮评选。

1.2.1 NIST时间线

2016年12月: NIST发布PQC标准化征集公告
2017年11月: 收到69份提案（第一轮）
2019年1月:  26个算法进入第二轮
2020年7月:  7个决赛候选+8个备选进入第三轮
2022年7月:  NIST宣布CRYSTALS-Kyber为KEM标准选择
             CRYSTALS-Dilithium、Falcon、SPHINCS+为签名标准选择
2024年8月:  正式发布FIPS 203 (ML-KEM)、FIPS 204 (ML-DSA)、FIPS 205 (SLH-DSA)
2025年:     FIPS 206 (FN-DSA/Falcon) 进入最终标准化阶段
2026年:     NIST启动第二轮PQC征集（关注多样化安全假设）

1.2.2 NIST PQC算法系列

已标准化的签名算法

已标准化的KEM算法

1.2.3 ML-KEM（CRYSTALS-Kyber，FIPS 203）

ML-KEM是基于格的密钥封装机制（Key Encapsulation Mechanism），由CRYSTALS（Cryptographic Suite for Algebraic Lattices）项目开发。它是NIST选定的标准KEM算法，用于量子安全下的对称密钥协商。

三个安全等级：

1.2.4 ML-DSA（CRYSTALS-Dilithium，FIPS 204）

ML-DSA是NIST标准化的主推数字签名方案。MSG Chain从创世块开始原生集成ML-DSA的Dilithium-5参数集。

三个安全等级：

1.2.5 SLH-DSA（SPHINCS+，FIPS 205）

SLH-DSA是基于哈希的无状态签名方案，其安全性仅依赖哈希函数的抗碰撞性，是安全假设最保守的PQC签名方案。

三个安全等级：

1.2.6 FN-DSA（Falcon，即将发布的FIPS 206）

Falcon是基于NTRU格密码的签名方案，特点是签名尺寸极小，适合带宽受限场景。

两个安全等级：

1.3 PQC算法对比与选型

1.3.1 签名方案对比

1.3.2 KEM方案对比

1.3.3 MSG Chain算法选型原则

MSG Chain PQC算法选型:
├── 主签名方案: Dilithium-5 (ML-DSA-87)
│   ├── 所有验证者共识密钥
│   ├── 所有交易签名（默认）
│   └── 地址派生
├── 主KEM方案: ML-KEM-1024
│   ├── 链上加密消息
│   └── Mempool加密（开发中）
├── 备选签名: Falcon-1024
│   ├── 轻客户端（签名较小）
│   └── 跨链证明
├── 备选签名: SPHINCS+ (256s)
│   ├── 时间戳服务
│   └── 长期归档签名
└── 传统兼容: Secp256k1 / Ed25519
    ├── 向后兼容（创世过渡期）
    └── 跨链互操作

第二章：量子威胁时间线

2.1 量子计算威胁模型

2.1.1 Shor算法对公钥密码学的威胁

Shor算法（Peter Shor, 1994）是量子计算对密码学最具威胁的算法。它可以在多项式时间内解决：

• 整数分解问题：O((log N)^3) 时间 → 破解RSA
• 离散对数问题：O((log p)^3) 时间 → 破解DSA、ECDSA、EdDSA
• 椭圆曲线离散对数：O(log n) 时间 → 破解ECDH、ECDSA

这意味着在拥有足够逻辑量子比特的量子计算机上：

RSA-2048:    ~8小时 (2000万逻辑量子比特)
Secp256k1:   ~2小时 (2300万逻辑量子比特)
Ed25519:     ~2小时 (2300万逻辑量子比特)

2.1.2 Grover算法对对称密码学的影响

Grover算法（Lov Grover, 1996）提供平方根级别的搜索加速：

防御策略：对称算法将密钥长度加倍即可，但公钥密码学无法通过简单参数扩展应对Shor攻击。

2.1.3 量子计算现状与预测

逻辑量子比特需求:
              │
  10^8        ┊                                     RSA-2048
              ┊                                   破解所需
  10^7        ┊                          Secp256k1/Ed25519
              ┊                         破解所需
  10^6        ┊
              ┊                              Google Willow
  10^5        ┊                                  (105 qubits, 2024)
              ┊
  10^4        ┊
              ┊                     IBM Condor (1,121 qubits, 2023)
  10^3        ┊
              ┊         Google Sycamore (53 qubits, 2019)
  10^2        ┊
              └───────────────────────────────────────────
              2020    2025    2030    2035    2040

2.2 Harvest-Now-Decrypt-Later攻击

2.2.1 攻击原理

Harvest-now-decrypt-later（HNDL）是当前最紧迫的量子威胁之一。攻击者现在收集加密数据并存储，等待未来量子计算机可用时再解密。

攻击流程：

现在（2026年）                   未来（2030+年）
┌─────────────────┐             ┌─────────────────┐
│ 捕获加密数据      │             │ 量子计算机可用    │
│ 存储加密流量      │───存储────→│ 批量解密          │
│ 记录区块链交易    │             │ 提取敏感信息      │
│ 保存TLS加密会话  │             │ 暴露密钥/签名    │
└─────────────────┘             └─────────────────┘

2.2.2 HNDL对区块链的特殊风险

区块链的公开性和永久性使其成为HNDL攻击的特别目标：

1. 交易数据的长期价值：链上的每笔交易签名一旦被破解，攻击者可以伪造历史交易发起者的身份。

2. 已广播的未加密消息：如果链上存在使用非PQC加密的消息内容，未来可被批量解密。

3. 验证者密钥历史：历史上使用过但已退役的验证者密钥，如果被破解，可能影响区块签名的可信度。

4. 冻结状态的资产：存储在secp256k1地址中的资产，如果地址对应的私钥可以被量子计算恢复，资产可能被窃取。

2.2.3 MSG Chain的HNDL防御策略

HNDL防御分层:
├── 原生PQC签名 → 交易签名从创世起量子安全
├── 混合加密 → 敏感数据使用ML-KEM密钥封装
├── 密钥轮换 → 定期更换密钥，减少单密钥有效期
├── 前向安全 → 旧密钥泄露不影响未来签名
└── 数据最小化 → 链上不存储非必要加密数据

2.3 量子威胁时间表与区块链迁移窗口

        Quantum Threat Timeline for Blockchain
  2025  2026  2027  2028  2029  2030  2031  2032  2033
  ├─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼────→

  ██████████████████████████████████████████████████
  当前窗口（安全期）

       ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
       准备期（PQC迁移应在此窗口完成）

            ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
            Q-Day风险期（2030+）

关键节点:
2025-2027: PQC迁移最佳窗口（风险低，成本可控）
2028-2029: 强制迁移窗口（ECC签名可信度降低）
2030+:     Q-Day（非PQC系统面临直接攻击）

第三章：PQC迁移策略

3.1 迁移策略总览

3.1.1 三种核心迁移模式

3.1.2 MSG Chain的PQ-First策略

MSG Chain采用逐层PQ-First策略，从底层协议到上层应用逐步推进：

Layer 5: DApp / 合约层     Dilithium-5 (推荐)  │ Secp256k1 (兼容)
Layer 4: SDK / 密钥管理层   Dilithium-5 (默认)  │ Secp256k1/Ed25519 (兼容)
Layer 3: 交易层             Dilithium-5 (优先)  │ Secp256k1 (降级)
Layer 2: 共识层 (CometBFT)  Dilithium-5 (唯一)  │ 不支持传统签名
Layer 1: 网络层 (P2P)       Dilithium-5 (默认)  │ Ed25519 (兼容)

3.2 Crypto-Agility架构

3.2.1 什么是Crypto-Agility

Crypto-Agility（加密敏捷性）是一个系统的密码算法能够在不影响整体架构的情况下灵活替换和升级的能力。对于PQC迁移，crypto-agility是核心架构要求。

3.2.2 MSG Chain的Crypto-Agility设计

// crypto/registry/crypto_registry.go

package registry

import (
    "fmt"
    "sync"
)

type AlgorithmType string

const (
    AlgorithmDilithium5 AlgorithmType = "dilithium-5"
    AlgorithmSecp256k1  AlgorithmType = "secp256k1"
    AlgorithmEd25519    AlgorithmType = "ed25519"
    AlgorithmFalcon1024 AlgorithmType = "falcon-1024"
    AlgorithmMLKEM1024  AlgorithmType = "ml-kem-1024"
)

type CryptoProvider interface {
    Type() AlgorithmType
    SecurityLevel() int
    IsPostQuantum() bool
}

type SignatureProvider interface {
    CryptoProvider
    GenerateKey() (PrivateKey, error)
    Sign(privKey PrivateKey, msg []byte) ([]byte, error)
    Verify(pubKey PublicKey, msg, sig []byte) bool
}

type KEMProvider interface {
    CryptoProvider
    GenerateKey() (KEMPrivateKey, error)
    Encapsulate(pubKey KEMPublicKey) (ciphertext, sharedSecret []byte, err error)
    Decapsulate(privKey KEMPrivateKey, ciphertext []byte) (sharedSecret []byte, err error)
}

type CryptoRegistry struct {
    mu          sync.RWMutex
    signatures  map[AlgorithmType]SignatureProvider
    kems        map[AlgorithmType]KEMProvider
    defaultSig  AlgorithmType
    defaultKEM  AlgorithmType
}

var globalRegistry = &CryptoRegistry{
    signatures: make(map[AlgorithmType]SignatureProvider),
    kems:       make(map[AlgorithmType]KEMProvider),
}

func RegisterSignature(provider SignatureProvider) error {
    globalRegistry.mu.Lock()
    defer globalRegistry.mu.Unlock()
    if _, exists := globalRegistry.signatures[provider.Type()]; exists {
        return fmt.Errorf("签名提供者 %s 已注册", provider.Type())
    }
    globalRegistry.signatures[provider.Type()] = provider
    return nil
}

func RegisterKEM(provider KEMProvider) error {
    globalRegistry.mu.Lock()
    defer globalRegistry.mu.Unlock()
    if _, exists := globalRegistry.kems[provider.Type()]; exists {
        return fmt.Errorf("KEM提供者 %s 已注册", provider.Type())
    }
    globalRegistry.kems[provider.Type()] = provider
    return nil
}

func SetDefaultSignature(algo AlgorithmType) error {
    globalRegistry.mu.Lock()
    defer globalRegistry.mu.Unlock()
    if _, exists := globalRegistry.signatures[algo]; !exists {
        return fmt.Errorf("签名算法 %s 未注册", algo)
    }
    globalRegistry.defaultSig = algo
    return nil
}

func GetSignatureProvider(algo AlgorithmType) (SignatureProvider, error) {
    globalRegistry.mu.RLock()
    defer globalRegistry.mu.RUnlock()
    provider, ok := globalRegistry.signatures[algo]
    if !ok {
        return nil, fmt.Errorf("签名算法 %s 未注册", algo)
    }
    return provider, nil
}

func GetDefaultSignature() SignatureProvider {
    globalRegistry.mu.RLock()
    defer globalRegistry.mu.RUnlock()
    return globalRegistry.signatures[globalRegistry.defaultSig]
}

3.3 混合签名方案（Hybrid Signature）

3.3.1 为什么需要混合签名

混合签名同时使用PQC和传统签名算法，提供防御纵深：

安全假设:
├── 如果PQC被攻破 → 传统签名仍然保护
├── 如果传统被攻破 → PQC签名仍然保护
└── 两者同时被攻破 → 极小概率事件

3.3.2 混合签名组合逻辑

3.3.3 混合签名数据结构

// crypto/hybrid/signature.go

package hybrid

type CompositeSignature struct {
    PQCSig        []byte `json:"pqc_signature"`
    PQCPubKey     []byte `json:"pqc_pubkey"`
    PQCScheme     string `json:"pqc_scheme"`

    LegacySig     []byte `json:"legacy_signature"`
    LegacyPubKey  []byte `json:"legacy_pubkey"`
    LegacyScheme  string `json:"legacy_scheme"`
}

func CombinedVerify(
    pqcVerify func(pubKey, msg, sig []byte) bool,
    legacyVerify func(pubKey, msg, sig []byte) bool,
    msg []byte,
    composite *CompositeSignature,
) bool {
    pqcOk := pqcVerify(composite.PQCPubKey, msg, composite.PQCSig)
    legacyOk := legacyVerify(composite.LegacyPubKey, msg, composite.LegacySig)
    return pqcOk && legacyOk
}

3.4 并行运行策略

在迁移过渡期，MSG Chain支持双轨并行运行。验证节点可以同时接受PQC签名交易和传统签名交易，AnteHandler根据全局配置决定验证策略。

双轨运行架构:
┌──────────────┐
│   Mempool    │
└──────┬───────┘
       │
┌──────┼──────────────┐
│      │              │
├──────▼─┐      ┌────▼─────┐
│ PQC节点 │      │ 混合验证  │
└─────────┘      └──────────┘

3.4.1 升级治理提案

// gov/proposals/pqc_migration.go

package proposals

const (
    Phase1_EnableDilithium5 = iota
    Phase2_HybridDefault
    Phase3_Secp256k1Deprecation
    Phase4_PurePQC
)

type PQCMigrationProposal struct {
    Title           string `json:"title"`
    Description     string `json:"description"`
    TargetPhase     int    `json:"target_phase"`
    EffectiveHeight int64  `json:"effective_height"`
}

3.5 密钥迁移策略

3.5.1 用户密钥迁移

用户从Secp256k1迁移到Dilithium-5的流程：

1. 生成新的Dilithium-5密钥对
2. 使用旧Secp256k1密钥签名迁移确认消息
3. 向链上发布迁移声明，将旧地址的资产控制权关联到新地址
4. 后续交易使用Dilithium-5签名

// crypto/migration/user_migration.go

package migration

import (
    "crypto/rand"
    "fmt"

    "github.com/cosmos/cosmos-sdk/crypto/keys/secp256k1"
    "github.com/msgchain/msgchain/crypto/dilithium"
)

type MigrationPlan struct {
    OldAddress string `json:"old_address"`
    NewAddress string `json:"new_address"`
    OldKeyType string `json:"old_key_type"`
    NewKeyType string `json:"new_key_type"`
    MigratedAt int64  `json:"migrated_at"`
}

func GenerateMigrationKey(
    oldPrivKey *secp256k1.PrivKeySecp256k1,
) (*dilithium.PrivKeyDilithium5, error) {
    newPrivKey, err := dilithium.GenKeyV5(rand.Reader)
    if err != nil {
        return nil, fmt.Errorf("Dilithium-5密钥生成失败: %w", err)
    }

    oldPubKey := oldPrivKey.PubKey()
    newPubKey := newPrivKey.PubKey()

    migrateMsg := fmt.Sprintf(
        "MSG_CHAIN_KEY_MIGRATION\nold: %s\nnew: %s\nchain: msg-chain-1",
        oldPubKey.Address().String(),
        newPubKey.Address().String(),
    )

    oldSig, err := oldPrivKey.Sign([]byte(migrateMsg))
    if err != nil {
        return nil, fmt.Errorf("迁移签名失败: %w", err)
    }

    if !oldPubKey.VerifySignature([]byte(migrateMsg), oldSig) {
        return nil, fmt.Errorf("迁移签名验证失败")
    }

    return newPrivKey, nil
}

3.5.2 验证者密钥迁移

验证者密钥迁移需要链上治理和共识协调：

// crypto/migration/validator_migration.go

package migration

import (
    "github.com/cosmos/cosmos-sdk/x/staking/types"
    "github.com/msgchain/msgchain/crypto/dilithium"
)

type ValidatorMigrationPlan struct {
    ValidatorAddress string `json:"validator_address"`
    OldConsensusKey  string `json:"old_consensus_key"`
    NewConsensusKey  string `json:"new_consensus_key"`
    EffectiveHeight  int64  `json:"effective_height"`
}

func CreateValidatorMigrationTx(
    oldPrivKey *dilithium.PrivKeyDilithium5,
    newPubKey *dilithium.PubKeyDilithium5,
    chainID string,
) ([]byte, error) {
    msgRotate := types.NewMsgRotateConsensusKey(
        oldPrivKey.PubKey().Address(),
        newPubKey,
    )
    signBytes := msgRotate.GetSignBytes()
    sig, err := oldPrivKey.Sign(signBytes)
    if err != nil {
        return nil, fmt.Errorf("轮换签名失败: %w", err)
    }
    if !oldPrivKey.PubKey().VerifySignature(signBytes, sig) {
        return nil, fmt.Errorf("轮换签名验证失败")
    }
    return signBytes, nil
}

第四章：MSG Chain的Dilithium-5集成架构

4.1 现有实现基础

4.1.1 代码仓库结构

msgchain/
├── crypto/
│   ├── dilithium/           # Dilithium-5 Go实现
│   │   ├── dilithium.go     # 核心密钥生成、签名、验证
│   │   ├── params.go        # Dilithium-5参数配置
│   │   ├── packing.go       # 序列化/反序列化
│   │   └── provider.go      # CryptoRegistry提供者
│   ├── hybrid/              # 混合签名实现
│   ├── kem/                 # KEM封装实现
│   ├── registry/            # Crypto-Agility注册表
│   └── migration/           # 密钥迁移工具
├── cosmos/
│   ├── crypto/
│   │   ├── keyring/         # 密钥环Dilithium-5支持
│   │   ├── types/           # 公钥/私钥类型注册
│   │   └── hd/              # HD钱包派生
│   └── tx/
│       └── signing/         # 签名模式
├── cmd/
│   └── msgchaind/
│       ├── keys/
│       └── tx/
└── wasm/
    └── bindings/            # CosmWasm PQC绑定

4.1.2 共识层Dilithium-5集成

MSG Chain的CometBFT共识层已修改以支持Dilithium-5签名：

共识层流程:
┌──────────┐     ┌──────────┐     ┌──────────┐
│ 区块提议   │────→│ 提议签名  │────→│ 广播区块  │
└──────────┘     └──────────┘     └──────────┘
                      │
                      ▼
                ┌──────────┐     ┌──────────┐     ┌──────────┐
                │ 预投票     │────→│ 签名投票   │────→│ 广播投票  │
                └──────────┘     └──────────┘     └──────────┘
                      │
                      ▼
                ┌──────────┐     ┌──────────┐     ┌──────────┐
                │ 预提交     │────→│ 签名提交   │────→│ 广播提交  │
                └──────────┘     └──────────┘     └──────────┘

CometBFT密码学接口适配：

// cometbft/crypto/dilithium/dilithium.go

package dilithium

import (
    "github.com/cometbft/cometbft/crypto"
    msgdilithium "github.com/msgchain/msgchain/crypto/dilithium"
)

const KeyType = "tendermint/PubKeyDilithium5"

type PubKeyDilithium5 struct {
    Key *msgdilithium.PubKeyDilithium5
}

func (pk *PubKeyDilithium5) Address() crypto.Address {
    return crypto.Address(pk.Key.Address())
}

func (pk *PubKeyDilithium5) Bytes() []byte {
    return pk.Key.Bytes()
}

func (pk *PubKeyDilithium5) VerifySignature(msg []byte, sig []byte) bool {
    return pk.Key.VerifySignature(msg, sig)
}

func (pk *PubKeyDilithium5) Equals(other crypto.PubKey) bool {
    otherKey, ok := other.(*PubKeyDilithium5)
    if !ok {
        return false
    }
    return pk.Key.Equals(otherKey.Key)
}

func (pk *PubKeyDilithium5) Type() string {
    return KeyType
}

4.2 签名验证流程

4.2.1 交易验证全流程

交易生命周期的PQC验证:
                          ┌──────────────────┐
                          │ 用户构造交易       │
                          │ (使用Dilithium-5)  │
                          └────────┬─────────┘
                                   │
                          ┌────────▼─────────┐
                          │ 广播到Mempool     │
                          │ (初步基础验证)    │
                          └────────┬─────────┘
                                   │
                          ┌────────▼─────────┐
                          │ CheckTx          │
                          │ ├─ 签名格式检查   │
                          │ ├─ 签名验证       │
                          │ └─ Gas估算        │
                          └────────┬─────────┘
                                   │
                          ┌────────▼─────────┐
                          │ DeliverTx        │
                          │ ├─ 完整状态验证   │
                          │ ├─ 签名再验证     │
                          │ ├─ 执行消息       │
                          │ └─ 状态更新       │
                          └────────┬─────────┘
                                   │
                          ┌────────▼─────────┐
                          │ 区块提交          │
                          │ ├─ 验证者区块签名 │
                          │ ├─ 交易列表签名   │
                          │ └─ 写入状态       │
                          └──────────────────┘

4.2.2 AnteHandler中的PQC验证

// cosmos/ante/pqc_ante.go

package ante

import (
    sdk "github.com/cosmos/cosmos-sdk/types"
    "github.com/cosmos/cosmos-sdk/x/auth/ante"
    "github.com/msgchain/msgchain/crypto/dilithium"
    "github.com/msgchain/msgchain/crypto/hybrid"
)

type PQCTxDecorator struct {
    ek ante.ConsumeKeeper
}

func NewPQCTxDecorator(ek ante.ConsumeKeeper) PQCTxDecorator {
    return PQCTxDecorator{ek: ek}
}

func (d PQCTxDecorator) AnteHandle(
    ctx sdk.Context, tx sdk.Tx, simulate bool, next sdk.AnteHandler,
) (sdk.Context, error) {
    sigTx, ok := tx.(sdk.TxWithSignatures)
    if !ok {
        return ctx, sdkerrors.ErrInvalidRequest.Wrap("tx must implement TxWithSignatures")
    }

    for i, sig := range sigTx.GetSignatures() {
        pubKey := sig.GetPubKey()
        signBytes := sigTx.GetSignBytes(ctx, i)

        switch pk := pubKey.(type) {
        case *dilithium.PubKeyDilithium5:
            if !pk.VerifySignature(signBytes, sig.GetSignature()) {
                return ctx, sdkerrors.ErrUnauthorized.Wrap("Dilithium-5签名验证失败")
            }
        default:
            if !pk.VerifySignature(signBytes, sig.GetSignature()) {
                return ctx, sdkerrors.ErrUnauthorized.Wrap("签名验证失败")
            }
        }
    }

    return next(ctx, tx, simulate)
}

4.3 验证者密钥与节点配置

4.3.1 验证者密钥文件

共识密钥存储在 ~/.msgchain/config/priv_validator_key.json：

{
  "address": "msg1q8lkvgzck8wkz3x9v6xkqf4u5a3d7e2n9jxc4p",
  "pub_key": {
    "type": "tendermint/PubKeyDilithium5",
    "value": "CukEAgDwuJ0AAQAAACAAgACAgP..."
  },
  "priv_key": {
    "type": "tendermint/PrivKeyDilithium5",
    "value": "A6cFAgDwuJ0AAAAAIA..."
  }
}

4.3.2 genesis.json中的Dilithium-5公钥

{
  "validators": [
    {
      "address": "msg1q8lkvgzck8wkz3x9v6xkqf4u5a3d7e2n9jxc4p",
      "pub_key": {
        "type": "tendermint/PubKeyDilithium5",
        "value": "CukEAgDwuJ0AAQAAACAAgACAgP..."
      },
      "power": "10",
      "name": "Validator-1"
    }
  ]
}

第五章：Kyber/ML-KEM密钥封装机制在链上加密中的应用

5.1 密钥封装机制（KEM）基础

5.1.1 KEM与传统密钥交换的区别

传统密钥交换（如ECDH）使用Diffie-Hellman协议协商对称密钥。KEM是一种更简洁的范式：

传统ECDH:
发送方                  接收方
├─ 生成临时密钥对 (sk, pk) ├─ 拥有长期密钥对 (skR, pkR)
├─ 计算共享密钥           ├─ 计算共享密钥
│   shared = ECDH(sk, pkR) │   shared = ECDH(skR, pk)
└─ 使用shared加密消息     └─ 使用shared解密消息

ML-KEM:
发送方                  接收方
├─ 拥有接收方公钥 pkR    ├─ 拥有长期密钥对 (skR, pkR)
├─ 封装: (ct, ss) =      │
│   MLKEM.Encaps(pkR)    │
├─ 发送密文 ct            ├─ 解封: ss = MLKEM.Decaps(skR, ct)
├─ 使用共享密钥ss加密    └─ 使用共享密钥ss解密
└─ 丢弃ss

ML-KEM的优势：

1. 非交互式：发送方不需要自己的密钥对，只需要接收方公钥
2. 前向安全友好：每次封装使用新随机性
3. 量子安全：基于Module-LWE问题

5.1.2 ML-KEM-1024参数

5.2 链上加密应用场景

5.2.1 私密消息传递

在MSG Chain上，可以使用ML-KEM-1024实现链上加密消息传递：

// crypto/kem/chain_encryption.go

package kem

import (
    "crypto/aes"
    "crypto/cipher"
    "crypto/rand"
    "crypto/sha256"
    "fmt"
    "io"

    "github.com/msgchain/msgchain/crypto/kem/mlkem"
    "golang.org/x/crypto/hkdf"
)

type EncryptedPayload struct {
    Ciphertext     []byte `json:"ciphertext"`
    Nonce          []byte `json:"nonce"`
    EncryptedData  []byte `json:"encrypted_data"`
    SenderPubKey   []byte `json:"sender_pubkey"`
    Signature      []byte `json:"signature"`
}

func EncryptForChain(
    recipientPubKey []byte,
    plaintext []byte,
    senderSigner func(msg []byte) (sig, pubKey []byte, err error),
) (*EncryptedPayload, error) {
    ct, sharedSecret, err := mlkem.Encapsulate(recipientPubKey)
    if err != nil {
        return nil, fmt.Errorf("ML-KEM封装失败: %w", err)
    }

    salt := make([]byte, 32)
    if _, err := io.ReadFull(rand.Reader, salt); err != nil {
        return nil, err
    }
    hkdf := hkdf.New(sha256.New, sharedSecret, salt, []byte("msg-chain-encryption-v1"))
    aesKey := make([]byte, 32)
    if _, err := io.ReadFull(hkdf, aesKey); err != nil {
        return nil, err
    }

    block, err := aes.NewCipher(aesKey)
    if err != nil {
        return nil, err
    }
    aead, err := cipher.NewGCM(block)
    if err != nil {
        return nil, err
    }
    nonce := make([]byte, aead.NonceSize())
    if _, err := io.ReadFull(rand.Reader, nonce); err != nil {
        return nil, err
    }
    encryptedData := aead.Seal(nil, nonce, plaintext, nil)

    signMsg := append(ct, encryptedData...)
    sig, pubKey, err := senderSigner(signMsg)
    if err != nil {
        return nil, fmt.Errorf("签名失败: %w", err)
    }

    return &EncryptedPayload{
        Ciphertext:    ct,
        Nonce:         nonce,
        EncryptedData: encryptedData,
        SenderPubKey:  pubKey,
        Signature:     sig,
    }, nil
}

5.2.2 CosmWasm合约加密消息存储

在合约层面，加密消息存储为结构化数据：

// contracts/encrypted-messaging/src/contract.rs

use cosmwasm_std::{
    entry_point, Binary, DepsMut, Env, MessageInfo, Response, StdError, StdResult,
};

#[derive(Serialize, Deserialize)]
pub struct EncryptedMsg {
    pub recipient: String,
    pub ciphertext: Binary,
    pub nonce: Binary,
    pub encrypted_data: Binary,
    pub sender_pubkey: Binary,
    pub sender_signature: Binary,
}

#[entry_point]
pub fn execute(
    deps: DepsMut,
    _env: Env,
    info: MessageInfo,
    msg: ExecuteMsg,
) -> StdResult<Response> {
    match msg {
        ExecuteMsg::SendEncrypted { recipient, ciphertext, nonce, encrypted_data, sender_pubkey, sender_signature } => {
            if ciphertext.len() != 1568 {
                return Err(StdError::generic_err("ML-KEM-1024密文大小必须为1568字节"));
            }

            let verify_data = [ciphertext.as_slice(), encrypted_data.as_slice()].concat();
            // 使用链上Dilithium-5验证发送方签名
            // ...

            let encrypted_msg = EncryptedMsg {
                recipient: recipient.clone(),
                ciphertext,
                nonce,
                encrypted_data,
                sender_pubkey,
                sender_signature,
            };
            MSGS.save(deps.storage, &(info.sender, recipient), &encrypted_msg)?;

            Ok(Response::new()
                .add_attribute("action", "send_encrypted")
                .add_attribute("sender", info.sender)
                .add_attribute("recipient", recipient))
        }
    }
}

5.3 ML-KEM密钥管理

5.3.1 密钥生成与存储

// crypto/kem/key_manager.go

package kem

import (
    "crypto/rand"
    "fmt"

    "github.com/msgchain/msgchain/crypto/kem/mlkem"
)

type KEMKeyManager struct {
    storage KeyStorage
}

type KeyPair struct {
    PrivateKey []byte `json:"private_key"`
    PublicKey  []byte `json:"public_key"`
    Algorithm  string `json:"algorithm"`
    CreatedAt  int64  `json:"created_at"`
}

func (km *KEMKeyManager) GenerateMLKEM1024Key() (*KeyPair, error) {
    privKey, pubKey, err := mlkem.GenerateKey(rand.Reader)
    if err != nil {
        return nil, fmt.Errorf("ML-KEM-1024密钥生成失败: %w", err)
    }
    keyPair := &KeyPair{
        PrivateKey: privKey,
        PublicKey:  pubKey,
        Algorithm:  "ml-kem-1024",
    }
    if err := km.storage.Store(keyPair); err != nil {
        return nil, fmt.Errorf("密钥存储失败: %w", err)
    }
    return keyPair, nil
}

5.3.2 公钥链上注册

// x/kem/keeper/keeper.go

package keeper

import (
    sdk "github.com/cosmos/cosmos-sdk/types"
    "github.com/msgchain/msgchain/x/kem/types"
)

type KEMKeeper struct {
    storeKey sdk.StoreKey
}

func (k KEMKeeper) RegisterPublicKey(
    ctx sdk.Context,
    owner sdk.AccAddress,
    pubKey []byte,
    algorithm string,
) error {
    if algorithm != "ml-kem-1024" {
        return types.ErrUnsupportedAlgorithm
    }
    if len(pubKey) != 1568 {
        return types.ErrInvalidKeySize
    }
    store := ctx.KVStore(k.storeKey)
    key := types.KeyPrefixPubKey(owner)
    store.Set(key, pubKey)
    return nil
}

func (k KEMKeeper) GetPublicKey(
    ctx sdk.Context,
    owner sdk.AccAddress,
) ([]byte, error) {
    store := ctx.KVStore(k.storeKey)
    key := types.KeyPrefixPubKey(owner)
    pubKey := store.Get(key)
    if pubKey == nil {
        return nil, types.ErrKeyNotFound
    }
    return pubKey, nil
}

第六章：混合证书与身份

6.1 x509 PQC混合证书

6.1.1 传统x509证书的量子威胁

TLS/SSL通信依赖x509证书体系，当前绝大多数证书使用RSA或ECDSA签名。量子计算机可：

1. 伪造证书：攻破CA的签名密钥，签发任意域名的假证书
2. 劫持会话：攻破服务器密钥，解密所有TLS流量（包括历史流量）
3. 替换公钥：在证书透明度日志中插入假证书

6.1.2 PQC混合证书结构

混合证书同时包含传统和PQC公钥及签名，提供双重安全保证：

标准x509证书扩展:
┌────────────────────────────────────┐
│  x509 v3 Certificate               │
├────────────────────────────────────┤
│  主题公钥信息 (SubjectPublicKeyInfo)│
│  ├── 传统公钥 (RSA-4096 / ECDSA)   │
│  └── PQC公钥 (Dilithium-5 / ML-KEM)│
├────────────────────────────────────┤
│  签名算法: 混合签名                  │
│  ├── CA传统签名 (RSA/SHA-256)      │
│  └── CA PQC签名 (Dilithium-5)     │
├────────────────────────────────────┤
│  扩展: PQC证书策略                  │
│  ├── PQCHybridPublicKeyInfo        │
│  └── PQCHybridSignatureInfo        │
└────────────────────────────────────┘

6.1.3 PQC证书扩展

// crypto/x509pqc/hybrid_cert.go

package x509pqc

import (
    "crypto/x509/pkix"
    "encoding/asn1"
)

var (
    OIDSubjectPQCPublicKey  = asn1.ObjectIdentifier{1, 3, 6, 1, 4, 1, 99999, 1, 1}
    OIDPQCHybridSignature   = asn1.ObjectIdentifier{1, 3, 6, 1, 4, 1, 99999, 1, 2}
    OIDDilithium5PublicKey  = asn1.ObjectIdentifier{1, 3, 6, 1, 4, 1, 99999, 2, 1}
)

type PQCPublicKeyInfo struct {
    Algorithm   asn1.ObjectIdentifier
    PublicKey   []byte
}

type PQCSignatureInfo struct {
    Algorithm   asn1.ObjectIdentifier
    Signature   []byte
}

6.2 DID文档PQC集成

6.2.1 去中心化标识符（DID）与PQC

W3C DID标准允许在DID文档中包含多种公钥类型。PQC迁移需要DID文档同时支持传统和PQC验证方法。

6.2.2 PQC DID文档结构

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://msgchain.org/ns/pqc/v1"
  ],
  "id": "did:msg:msg1q8lkvgzck8wkz3x9v6xkqf4u5a3d7e2n9jxc4p",
  "verificationMethod": [
    {
      "id": "did:msg:msg1q8lkvgzck8wkz3x9v6xkqf4u5a3d7e2n9jxc4p#keys-1",
      "type": "DilithiumVerificationKey2026",
      "controller": "did:msg:msg1q8lkvgzck8wkz3x9v6xkqf4u5a3d7e2n9jxc4p",
      "publicKeyBase64": "CukEAgDwuJ0AAQAAACAAgACAgP..."
    },
    {
      "id": "did:msg:msg1q8lkvgzck8wkz3x9v6xkqf4u5a3d7e2n9jxc4p#keys-2",
      "type": "EcdsaSecp256k1VerificationKey2019",
      "controller": "did:msg:msg1q8lkvgzck8wkz3x9v6xkqf4u5a3d7e2n9jxc4p",
      "publicKeyBase64": "A5wv7..."
    }
  ],
  "authentication": [
    "did:msg:msg1q8lkvgzck8wkz3x9v6xkqf4u5a3d7e2n9jxc4p#keys-1"
  ],
  "pqcMigration": {
    "status": "hybrid",
    "legacyAlgorithm": "secp256k1",
    "pqcAlgorithm": "dilithium-5",
    "migrationDeadline": "2030-06-01T00:00:00Z"
  }
}

6.2.3 CosmWasm DID合约PQC集成

// contracts/did-registry/src/pqc.rs

use cosmwasm_std::{StdError, StdResult, Binary};
use msg_chain_crypto::dilithium::DilithiumPublicKey;

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq)]
pub struct PQCVerificationMethod {
    pub id: String,
    pub controller: String,
    #[serde(rename = "type")]
    pub vm_type: String,
    pub public_key_base64: String,
    pub algorithm: String,
}

pub fn verify_did_signature(
    did_doc: &PQCDIDDocument,
    message: &[u8],
    signature: &[u8],
    verification_method_id: &str,
) -> StdResult<bool> {
    let vm = did_doc
        .verification_method
        .iter()
        .find(|vm| vm.id == verification_method_id)
        .ok_or_else(|| StdError::generic_err("验证方法未找到"))?;

    match vm.algorithm.as_str() {
        "dilithium-5" => {
            let pub_key = DilithiumPublicKey::from_base64(&vm.public_key_base64)
                .map_err(|_| StdError::generic_err("公钥解析失败"))?;
            Ok(pub_key.verify(message, signature))
        }
        _ => Err(StdError::generic_err("不支持的算法类型")),
    }
}

第七章：合约层PQC迁移

7.1 CosmWasm合约签名验证

7.1.1 当前CosmWasm签名验证

CosmWasm合约通过标准接口验证Secp256k1签名：

use cosmwasm_std::StdResult;

fn verify_secp256k1(
    deps: Deps,
    message: &[u8],
    signature: &[u8],
    public_key: &[u8],
) -> StdResult<bool> {
    deps.api.secp256k1_verify(message, signature, public_key)
}

7.1.2 合约内Dilithium-5验证

MSG Chain的CosmWasm环境扩展了PQC验证功能：

// contracts/example/src/pqc_verify.rs

use cosmwasm_std::{
    entry_point, to_binary, Binary, Deps, DepsMut, Env,
    MessageInfo, Response, StdResult, StdError,
};
use schemars::JsonSchema;
use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
pub struct PQCSignatureVerification {
    pub message: Binary,
    pub signature: Binary,
    pub public_key: Binary,
}

#[entry_point]
pub fn query(deps: Deps, _env: Env, msg: QueryMsg) -> StdResult<Binary> {
    match msg {
        QueryMsg::VerifyPQCSignature { message, signature, public_key } =>
            verify_pqc(deps, message, signature, public_key),
    }
}

fn verify_pqc(
    _deps: Deps,
    message: Binary,
    signature: Binary,
    public_key: Binary,
) -> StdResult<Binary> {
    if signature.len() != 4595 {
        return Err(StdError::generic_err("Dilithium-5签名大小必须为4595字节"));
    }
    if public_key.len() != 2592 {
        return Err(StdError::generic_err("Dilithium-5公钥大小必须为2592字节"));
    }

    let result = _deps.api.pqc_verify(
        "dilithium-5",
        message.as_slice(),
        signature.as_slice(),
        public_key.as_slice(),
    )?;

    to_binary(&PQCSignatureResult { valid: result })
}

7.1.3 CosmWasm PQC验证绑定

// wasm/bindings/pqc.go

package bindings

import (
    "fmt"

    "github.com/CosmWasm/wasmvm/types"
    "github.com/msgchain/msgchain/crypto/dilithium"
)

type PQCVerifier struct{}

func (v *PQCVerifier) Verify(
    algorithm string,
    message, signature, publicKey []byte,
) (bool, error) {
    switch algorithm {
    case "dilithium-5":
        pubKey := &dilithium.PubKeyDilithium5{}
        if err := pubKey.UnmarshalAmino(publicKey); err != nil {
            return false, fmt.Errorf("公钥反序列化失败: %w", err)
        }
        return pubKey.VerifySignature(message, signature), nil
    default:
        return false, fmt.Errorf("不支持的PQC算法: %s", algorithm)
    }
}

func RegisterPQCVerifier(wasmOpts []types.WasmOptions) []types.WasmOptions {
    verifier := &PQCVerifier{}
    return append(wasmOpts, types.WasmOptions{
        PQCSignatureVerifier: verifier,
    })
}

7.2 合约升级支持后量子验证

7.2.1 合约迁移到PQC验证

// contracts/pqc-vault/src/state.rs

use cosmwasm_std::{Storage, StdResult, StdError, Binary};
use cw_storage_plus::Item;

pub const VERIFICATION_KEY: Item<Binary> = Item::new("verification_key");

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq)]
pub enum SignatureScheme {
    Secp256k1,
    Ed25519,
    Dilithium5,
    HybridSecp256k1Dilithium5,
}

pub const SIGNATURE_SCHEME: Item<SignatureScheme> = Item::new("signature_scheme");

pub fn set_signature_scheme(storage: &mut dyn Storage, scheme: SignatureScheme) -> StdResult<()> {
    SIGNATURE_SCHEME.save(storage, &scheme)
}

pub fn get_signature_scheme(storage: &dyn Storage) -> StdResult<SignatureScheme> {
    SIGNATURE_SCHEME
        .load(storage)
        .or(Ok(SignatureScheme::Secp256k1))
}

7.2.2 合约迁移消息

// contracts/pqc-vault/src/contract.rs

use cosmwasm_std::{
    entry_point, Binary, DepsMut, Env, MessageInfo, Response, StdResult, StdError,
};
use crate::state::{VERIFICATION_KEY, SIGNATURE_SCHEME, SignatureScheme};

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq)]
pub enum MigrateMsg {
    UpgradeToPQC {
        new_pqc_key: Binary,
        legacy_key: Binary,
        migration_signature: Binary,
    },
    UpgradeToHybrid {
        pqc_key: Binary,
        legacy_key: Binary,
        migration_signature: Binary,
    },
}

#[entry_point]
pub fn migrate(deps: DepsMut, _env: Env, msg: MigrateMsg) -> StdResult<Response> {
    match msg {
        MigrateMsg::UpgradeToPQC { new_pqc_key, legacy_key, migration_signature } => {
            let current_key = VERIFICATION_KEY.load(deps.storage)?;
            let migrate_msg = b"UPGRADE_TO_PQC";

            let legacy_verified = deps.api.secp256k1_verify(
                migrate_msg,
                &migration_signature,
                &legacy_key,
            )?;

            if !legacy_verified {
                return Err(StdError::generic_err("迁移签名验证失败"));
            }

            VERIFICATION_KEY.save(deps.storage, &new_pqc_key)?;
            SIGNATURE_SCHEME.save(deps.storage, &SignatureScheme::Dilithium5)?;

            Ok(Response::new()
                .add_attribute("action", "pqc_upgrade")
                .add_attribute("new_scheme", "dilithium-5"))
        }
        MigrateMsg::UpgradeToHybrid { pqc_key, legacy_key, migration_signature } => {
            Ok(Response::new()
                .add_attribute("action", "hybrid_upgrade"))
        }
    }
}

7.3 合约验证函数迁移模式

// contracts/pqc-vault/src/verify.rs

use cosmwasm_std::{Deps, Binary, StdResult, StdError};

pub enum VerifyMode {
    Legacy,
    PQC,
    Hybrid,
    Adaptive,
}

pub fn verify_signature(
    deps: Deps,
    mode: &VerifyMode,
    message: &[u8],
    signature: &[u8],
    pub_key: &[u8],
) -> StdResult<bool> {
    match mode {
        VerifyMode::Legacy => {
            deps.api.secp256k1_verify(message, signature, pub_key)
        }
        VerifyMode::PQC => {
            if signature.len() != 4595 { return Ok(false); }
            deps.api.pqc_verify("dilithium-5", message, signature, pub_key)
        }
        VerifyMode::Hybrid => {
            let pqc_sig_size = 4595;
            if signature.len() < pqc_sig_size { return Ok(false); }
            let (pqc_sig, legacy_part) = signature.split_at(pqc_sig_size);
            let pqc_ok = deps.api.pqc_verify("dilithium-5", message, pqc_sig, pub_key)?;
            let legacy_ok = deps.api.secp256k1_verify(
                message,
                &legacy_part[..64],
                &legacy_part[64..],
            )?;
            Ok(pqc_ok && legacy_ok)
        }
        VerifyMode::Adaptive => {
            if signature.len() == 4595 {
                deps.api.pqc_verify("dilithium-5", message, signature, pub_key)
            } else if signature.len() <= 72 {
                deps.api.secp256k1_verify(message, signature, pub_key)
            } else {
                Err(StdError::generic_err("无法识别的签名格式"))
            }
        }
    }
}

第八章：PQC性能基准

8.1 Dilithium-5 vs ECDSA vs Ed25519在MSG Chain上的Gas消耗对比

8.1.1 密钥操作性能

在MSG Chain节点环境（Intel Xeon Platinum 8375C @ 3.0GHz, 32核）的实测数据：

关键发现：

• Dilithium-5的验证速度比Ed25519略快，比Secp256k1快5倍
• 签名速度比Ed25519慢9倍，但对用户签名体验影响有限
• 全节点主要做验证，Dilithium-5的快速验证对网络更友好

8.1.2 密钥与签名大小

8.1.3 MSG Chain Gas消耗对比

8.1.4 实际交易Gas对比

8.2 区块容量影响分析

8.2.1 每区块最大交易数

假设区块Gas限制为30,000,000（MSG Chain配置值）：

交易类型            Gas限制    最大交易数/区块
MsgSend (Secp256k1):  34,540    30,000,000 / 34,540 ≈ 868
MsgSend (Dilithium-5): 112,370   30,000,000 / 112,370 ≈ 267
MsgSend (混合验证):   146,910    30,000,000 / 146,910 ≈ 204

Dilithium-5交易量约为Secp256k1的31%，但仍在实用范围内。

8.2.2 区块大小影响

假设每个区块填充到Gas上限的50%：

交易类型     平均Tx/区块    区块大小
Secp256k1:   434           434 * 254 ≈ 110 KB
Ed25519:     462           462 * 246 ≈ 114 KB
Dilithium-5: 133           133 * 7337 ≈ 976 KB (~1 MB)

Dilithium-5区块约1 MB，仍然在CometBFT默认区块大小的合理范围内。

第九章：迁移路线图

9.1 从ECDSA/Ed25519到纯PQC的分阶段迁移

9.1.1 四阶段迁移路线图

Phase 1: 启用PQC（2025-2026）         Phase 2: 混合默认（2026-2028）
┌─────────────────────┐               ┌─────────────────────┐
│ Dilithium-5引入      │               │ 混合签名成为默认      │
│ 支持Dilithium-5密钥  │──────→        │ 传统签名降级         │
│ 传统签名仍为主流      │               │ 所有节点升级         │
│ ML-KEM可选           │               │ 混合证书支持         │
└─────────────────────┘               └─────────────────────┘
          │                                    │
          ▼                                    ▼
┌─────────────────────┐               ┌─────────────────────┐
│ Phase 3: 传统弃用    │               │ Phase 4: 纯PQC      │
│ (2028-2029)         │               │ (2029-2030+)        │
│ 新交易必须PQC签名    │──────→         │ 移除所有传统支持     │
│ 旧传统密钥映射       │               │ 仅Dilithium-5       │
│ IBC兼容层            │               │ 可选Falcon/SPHINCS+ │
└─────────────────────┘               └─────────────────────┘

9.1.2 各阶段详细计划

Phase 1: 启用PQC（当前阶段 — 已完成）

Phase 2: 混合默认（2026-2028）

Phase 3: 传统弃用（2028-2029）

Phase 4: 纯PQC（2029-2030+）

9.2 验证者升级指南

9.2.1 验证者迁移检查清单

□ [Phase 1] 确认节点使用Dilithium-5共识密钥
  → 检查 ~/.msgchain/config/priv_validator_key.json
  → 确认 "type": "tendermint/PubKeyDilithium5"

□ [Phase 1] 节点运行最新版本（支持Dilithium-5）
  → ./bin/msgchaind version
  → 确认版本 >= v1.0.0

□ [Phase 2] 升级到混合签名模式
  → 监控治理提案
  → 升级节点到支持混合签名版本

□ [Phase 2] 配置HSM支持
  → 验证HSM支持Dilithium-5操作
  → 配置PKCS#11或TPM接口

□ [Phase 2] 密钥轮换为纯Dilithium-5
  → 使用CLI轮换验证者共识密钥
  → 更新所有备份和灾备节点

□ [Phase 3] 确认无传统签名依赖
  → 审计所有自动化脚本
  → 更新API端点配置

□ [Phase 4] 参与硬分叉升级
  → 在截止日期前升级二进制
  → 验证链上状态

9.2.2 CLI升级命令

# Phase 1: 创建Dilithium-5密钥
./bin/msgchaind keys add my-pqc-key \
    --key-type dilithium-5 \
    --keyring-backend file \
    --home ~/.msgchain

# Phase 2: 轮换验证者共识密钥
./bin/msgchaind tx staking rotate-consensus-key \
    --pubkey $(./bin/msgchaind keys show my-pqc-key --pubkey) \
    --from validator \
    --chain-id msg-chain-1 \
    --fees 10000umsg \
    --gas 300000 \
    --home ~/.msgchain

# Phase 2: 提交PQC迁移治理提案
./bin/msgchaind tx gov submit-proposal pqc-migration \
    --target-phase 2 \
    --effective-height 5000000 \
    --title "PQC迁移 Phase 2: 混合签名默认" \
    --description "过渡到默认使用PQC混合签名" \
    --deposit 100000000umsg \
    --from validator \
    --chain-id msg-chain-1

# Phase 3: 从旧Secp256k1地址转移资产到Dilithium-5地址
./bin/msgchaind tx bank send \
    $(./bin/msgchaind keys show legacy-key -a) \
    $(./bin/msgchaind keys show pqc-key -a) \
    1000000umsg \
    --from legacy-key \
    --chain-id msg-chain-1 \
    --fees 5000umsg

9.3 DApp开发者迁移指南

9.3.1 智能合约升级时间线

DApp开发者的PQC迁移:
├── 2026: 开始使用Dilithium-5签名交易
│   ├── SDK升级到PQC版本
│   ├── 测试环境启用Dilithium-5
│   └── 用户钱包支持Dilithium-5地址
├── 2027: 合约内PQC验证
│   ├── 使用PQC验证扩展
│   ├── 部署多算法验证合约
│   └── 前端适配PQC签名
├── 2028: 移除传统签名依赖
│   ├── 强制PQC签名验证
│   ├── 弃用旧合约
│   └── 用户密钥迁移完成
└── 2030: 纯PQC合约
    ├── 所有合约使用PQC验证
    ├── 利用PQC特性（ML-KEM加密）
    └── 跨链PQC互操作

9.3.2 合约适配模式

pub fn execute_with_authz(
    deps: DepsMut,
    env: Env,
    info: MessageInfo,
    action: Action,
    signature: Binary,
    pub_key: Binary,
    version: u8,
) -> StdResult<Response> {
    let msg = action.to_sign_bytes(&env);

    let valid = match version {
        1 => deps.api.secp256k1_verify(&msg, &signature, &pub_key)?,
        2 => deps.api.pqc_verify("dilithium-5", &msg, &signature, &pub_key)?,
        3 => {
            let (pqc_sig, legacy_part) = split_hybrid_signature(&signature)?;
            let pqc_ok = deps.api.pqc_verify("dilithium-5", &msg, &pqc_sig, &pub_key)?;
            let legacy_ok = deps.api.secp256k1_verify(
                &msg, &legacy_part.sig, &legacy_part.pub_key
            )?;
            pqc_ok && legacy_ok
        }
        _ => return Err(StdError::generic_err("不支持的签名版本")),
    };

    if !valid {
        return Err(StdError::generic_err("签名验证失败"));
    }

    execute_action(deps, env, info, action)
}

第十章：兼容性与互操作

10.1 跨链场景的PQC兼容

10.1.1 IBC中的PQC问题

IBC（Inter-Blockchain Communication）协议依赖轻客户端验证跨链状态。如果发送链使用PQC签名而接收链不支持，或反之，则无法验证跨链证明。

IBC PQC兼容层级:

源链 (MSG Chain)                     目标链 (Cosmos Hub)
┌──────────────────┐                 ┌──────────────────┐
│ Dilithium-5签名   │     IBC        │ Secp256k1签名     │
│ 跨链证明          │────◄──────────→│ 跨链证明          │
├──────────────────┤   报文          ├──────────────────┤
│ Dilithium-5      │                 │ Secp256k1         │
│ 轻客户端          │                 │ 轻客户端          │
├──────────────────┤                 ├──────────────────┤
│ 混合证明生成器    │                 │ PQC适配器         │
└──────────────────┘                 └──────────────────┘

10.1.2 跨链适应策略

10.2 轻客户端验证

10.2.1 PQC对轻客户端的影响

轻客户端需要验证区块头和共识签名。Dilithium-5签名的增大直接影响轻客户端的同步带宽需求、存储开销和验证计算量。

轻客户端同步数据对比（含100个验证者签名）:
传统 (Ed25519):
  区块头: ~200 B
  验证者集合: 100 * 33 B = 3,300 B
  签名集合: 100 * 64 B = 6,400 B
  总计: ~9,900 B (~10 KB)

PQC (Dilithium-5):
  区块头: ~200 B
  验证者集合: 100 * 2,592 B = 259,200 B
  签名集合: 100 * 4,595 B = 459,500 B
  总计: ~718,900 B (~702 KB)

10.2.2 轻客户端PQC优化策略

// lightclient/pqc_optimization.go

package lightclient

type PQCCompactMode int

const (
    ModeFull       PQCCompactMode = iota
    ModeAggregated
    ModeSampled
    ModeCached
)

type LightClientConfig struct {
    PQCCompactMode PQCCompactMode
    SampleSize     int
    CacheEnabled   bool
    CacheTTLBlocks int64
}

10.3 向后兼容性

10.3.1 地址格式兼容

所有密钥类型派生出相同长度的地址，这简化了迁移过程中的地址兼容性。

10.3.2 交易格式兼容

// proto/msgchain/crypto/v1/types.proto

message AnyPubKey {
  oneof key {
    bytes secp256k1 = 1;
    bytes ed25519 = 2;
    bytes dilithium5 = 3;
    bytes falcon1024 = 4;
    bytes hybrid = 5;
  }
}

message AnySignature {
  oneof signature {
    bytes secp256k1 = 1;
    bytes ed25519 = 2;
    bytes dilithium5 = 3;
    bytes falcon1024 = 4;
    bytes hybrid = 5;
  }
}

第十一章：挑战与展望

11.1 当前技术挑战

11.1.1 密钥与签名膨胀

PQC算法最显著的变化是密钥和签名的大幅增加：

影响：

1. 钱包备份：Dilithium-5私钥5,760字节，助记词恢复需要更多种子熵
2. 硬件钱包：存储容量和传输带宽需求大幅提升
3. 区块链状态：公钥存储在链上会增加状态数据库大小
4. 网络传输：交易广播和区块传播的网络带宽增加

缓解措施：

• 公钥不存储在链上（由交易签名者提供，验证后丢弃）
• 使用地址代替公钥（地址保持20字节不变）
• 轻客户端使用公钥缓存和增量同步

11.1.2 交易大小与区块Gas瓶颈

Dilithium-5交易约7,337字节（vs Secp256k1的254字节），导致：

理论最大TPS（基于Gas限制30M）:
Secp256k1:  30M / 34,540 ≈ 868 TPS
Dilithium-5: 30M / 112,370 ≈ 267 TPS

TPS下降约69%，通过以下方式缓解:
├── Gas参数校准（更精确的基础Gas计算）
├── 区块大小限制调整
├── 并行验证（备用验证线程）
└── 签名聚合技术（BLS后量子变体）

11.1.3 验证时间对比

尽管Dilithium-5的验证速度比Secp256k1快5倍，但更大的交易数量对区块验证的总体时间仍有影响：

区块验证时间对比（仅签名验证，不含状态执行）:
Secp256k1:  ~85ms / 1000交易
Dilithium-5: ~30ms / 1000交易
Dilithium-5的单笔验证更快，但更少的TPS意味着同样时间内区块包含的交易更少

11.1.4 系统兼容性矩阵

11.2 未来展望

11.2.1 NIST下一轮标准化

NIST于2025年启动了第二轮PQC标准化征集，重点关注：

NIST第二轮PQC征集（2025-2028）:
├── 多样化安全假设
│   ├── 编码密码（Classic McEliece, BIKE）
│   ├── 同源密码
│   └── 对称密码（SPHINCS+等）
├── 性能优化
│   ├── 更小的签名和密钥
│   ├── 更快的验证
│   └── 更好的侧信道阻力
└── 专用场景
    ├── 同态加密友好
    ├── 零知识证明友好
    └── 阈值签名友好

11.2.2 新兴PQC技术方向

11.2.3 量化迁移成本

附录

A: NIST PQC标准参考

B: MSG Chain密钥类型参考

C: Gas消耗参考表

D: 术语表

E: 常见问题FAQ

Q: MSG Chain是否已经使用Dilithium-5作为默认签名方案？

A: 是的。MSG Chain从创世块开始就将Dilithium-5作为默认签名方案，验证者共识密钥强制使用Dilithium-5。用户交易签名默认也推荐使用Dilithium-5，同时向后兼容Secp256k1。

Q: Dilithium-5签名比Secp256k1大很多，是否会影响链性能？

A: Dilithium-5签名约4,595字节（Secp256k1约70字节），确实会增大交易大小。但MSG Chain的Gas模型已为此优化，且验证速度快5倍，对全节点更友好。TPS实测下降约69%，但仍满足大多数应用场景需求。

Q: 如何从Secp256k1迁移到Dilithium-5？

A: MSG Chain支持双轨运行。用户可通过密钥迁移工具逐步迁移，无需一次性切换。详见第九章迁移路线图。

Q: 什么是混合签名？为什么需要它？

A: 混合签名同时使用PQC和传统签名（如Dilithium-5 + Secp256k1），提供防御纵深。即使一种算法被攻破，另一种仍提供保护。混合签名是过渡期的最佳实践。

Q: 轻客户端如何处理Dilithium-5的大签名？

A: 轻客户端可通过采样验证、公钥缓存、增量同步等优化策略有效降低带宽需求。对于极端带宽受限场景，也可使用签名较小的Falcon-1024。

Q: MSG Chain是否支持ML-KEM (Kyber)？

A: MSG Chain正在开发ML-KEM-1024的链上加密支持，包括私密消息传递和Mempool加密功能。详情见第五章。

Q: PQC迁移需要硬分叉吗？

A: Phase 1（启用PQC）和Phase 2（混合默认）不需要硬分叉，通过治理提案和软件升级即可完成。Phase 4（纯PQC）可能需要硬分叉以移除传统签名支持。

Q: 迁移到PQC的成本有多高？

A: 全栈PQC迁移预估需要14~24人月的开发工作量，涵盖SDK、共识层、合约、钱包、基础设施和测试。

MSG Chain Whitepaper | https://msgchain.org/whitepaper | 代码库实际状态，不代表生产可用