区块链后量子密码迁移方向博士学习路线

配套实践入口：学习工作区（当前从第 1 周“量子威胁与签名接口”开始）

适用对象：密码学方向刚入学博士，对区块链与后量子密码感兴趣，但尚未系统学习现代密码学、分布式共识、区块链底层协议与后量子密码。

学习方法：先从后量子签名的整体结构和可运行实验入手，在遇到具体障碍时回补数学、安全定义与经典密码学；随后系统学习 Bitcoin、Ethereum 及其共识机制。

总目标：在约 18 个月内，完成从兴趣驱动的算法入门、基础回补、区块链系统学习到提出研究问题的过渡，并形成第一篇围绕“区块链密码敏捷性与后量子迁移安全”的论文初稿。

快速阅读：想立即开始学习，请进入学习工作区；想先看全局安排，请读18 个月总体路线；想按周执行，请读前 12 周执行计划；想了解选题，请读研究方向优先级与首篇论文候选切口；查找资料可直接跳到推荐资料。

目录 ​

1. 研究方向定位
2. 学习原则与总体知识结构
3. 18 个月总体路线
4. 阶段一：后量子密码学先行
5. 阶段二：数学与现代密码学按需回补
6. 阶段三：区块链系统、UTXO 与共识机制
7. 阶段四：区块链迁移安全
8. 前 12 周执行计划
9. 第一年学习与基础研究平台
10. 博士研究方向优先级
11. 研究问题北极星与首篇论文候选切口
12. 面向安全四大的研究标准
13. 每周科研安排
14. 论文阅读与研究记录模板
15. 阶段验收与年度里程碑
16. 常见误区
17. 推荐资料

一、研究方向定位 ​

区块链系统中的资产控制、交易授权、共识投票、数据承诺和零知识证明，大量依赖经典密码学机制。例如：

• Bitcoin 主要依赖哈希函数、ECDSA、Schnorr 签名和 Merkle 树；
• Bitcoin 通过未花费交易输出（Unspent Transaction Output，UTXO）表示可花费状态，并以 PoW、累计工作量和 P2P 网络处理双花与分支选择；
• Ethereum 普通账户交易依赖 ECDSA；
• Ethereum 执行层以账户、合约和 EVM 表示状态转换；
• Ethereum Beacon/PoS 共识层通过验证者、attestation、LMD-GHOST 和 Casper FFG 建立链头与最终性，其中大量消息依赖 BLS 签名及聚合；
• EIP-4844 的 blob 承诺与一致性证明使用 KZG，多层数据可用性还涉及共识规则、传播和存储；
• 部分 rollup 和隐私应用依赖基于椭圆曲线的零知识证明系统。

大规模容错量子计算机一旦具备运行 Shor 算法的能力，基于整数分解和离散对数问题的公钥密码机制将面临根本性威胁。与此同时，区块链又具有以下特殊约束：

• 历史数据长期公开且难以删除；
• 公钥、签名和账户状态可能永久保存在链上；
• 旧账户、休眠账户和遗失密钥无法统一升级；
• 全网节点难以同时更换密码算法；
• 新旧算法可能需要长期共存；
• 迁移过程可能遭受降级、回滚、重放和密钥替换攻击；
• 后量子签名通常比经典签名更大，影响区块容量、网络传播和验证成本。

二、学习原则与总体知识结构 ​

2.1 为什么采用“后量子先行” ​

本路线不再要求先学完数论、抽象代数和现代密码学，才允许接触后量子算法。对于零基础学习者，先看到算法能做什么、数据如何流动、为什么会产生大公钥或大签名，更容易建立兴趣和问题意识。

先运行并观察后量子算法
        ↓
理解算法的整体结构
        ↓
记录暂时看不懂的数学与安全概念
        ↓
定向回补当前真正需要的基础
        ↓
回到标准、证明和区块链系统中重新理解

这不是放弃基础，而是改变基础出现的时间。数学可以暂时延后，但不能长期绕过；凡是已经影响算法理解、安全判断或实验正确性的知识，都应进入“基础欠账表”，并设置补齐期限。

2.2 三条相互配合的学习线 ​

主线 A：后量子密码 ​

量子威胁与数字签名接口
   ↓
Lamport / WOTS+ / Merkle 树签名
   ↓
SLH-DSA 的整体结构
   ↓
玩具版 LWE / SIS 与多项式运算
   ↓
ML-DSA 的 KeyGen / Sign / Verify
   ↓
安全假设、实现风险与标准化状态

支撑线 B：数学与现代密码学 ​

模运算、向量矩阵、概率和哈希
   ↓
多项式商环、范数、离散分布和 NTT
   ↓
安全参数、PPT/QPT、可忽略函数和安全游戏
   ↓
EUF-CMA、归约、ROM/QROM 与组合安全
   ↓
群、椭圆曲线、ECDSA、Schnorr 和 BLS

系统线 C：区块链 ​

分布式账本、状态机复制与共识基础
   ↓
Bitcoin：UTXO、交易、脚本、P2P、Mempool、PoW
   ↓
Ethereum 执行层：账户、交易、EVM、状态与 Gas
   ↓
Ethereum 共识层：Beacon、PoS、Gasper、最终性
   ↓
密码资产清单、量子攻击面与迁移状态机

三条线最终汇合到：

密码敏捷性与混合认证
   ↓
密钥迁移、抗降级、抗重放和不可回滚
   ↓
形式化安全模型、协议原型与现实评测

2.3 对不同知识采用不同深度 ​

2.4 博士前期最终要形成的能力 ​

• 算法能力：能解释主要后量子密码学（Post-Quantum Cryptography，PQC）方案的结构、参数、性能与实现风险；
• 证明能力：能定义安全游戏、构造基本归约并识别模型或证明缺口；
• 协议能力：能区分交易执行、共识、网络传播、钱包和升级治理中的信任关系；
• 系统能力：能运行节点、解析真实数据、实现原型并测量网络、存储和验证开销；
• 研究能力：能把自然语言中的“安全”改写成带对手能力和前提条件的可验证性质。

三、18 个月总体路线 ​

第五、六阶段不再另设同名大章，而是由第九至十五章的研究平台、选题、论文标准、科研安排与里程碑共同展开。

总体时间原则 ​

• 阶段之间允许重叠，不要求完成上一阶段的全部内容才进入下一阶段；
• 前 3 个月先用 PQC 建立兴趣与整体认识，同时维护“基础欠账表”；
• 第 2—6 个月把已经影响理解的数学和安全定义逐项补齐；
• 区块链学习必须覆盖数据模型、执行、网络、共识、钱包和升级，而不只罗列密码算法；
• Bitcoin 与 Ethereum 都建立全局地图，研究原型阶段再选择其中一条深入；
• 第 8 个月后开始围绕“迁移”形成问题意识，但不预先假定候选题一定具有新颖性；
• 不要等所有基础学完才开始做实验；
• 不要在尚未理解安全模型时设计新密码原语；协议构想可以记录，但必须在基础补齐后重新审查。

四、阶段一：后量子密码学先行 ​

这一阶段的目标不是立即掌握全部证明，而是先回答三个问题：

1. 量子计算究竟破坏哪些经典密码机制？
2. 后量子签名在接口、结构和性能上与 ECDSA/Schnorr 有什么不同？
3. 为了真正理解这些算法，下一步必须补哪些数学与安全定义？

4.1 开始前的最低前置知识 ​

开始 PQC 前只需先掌握以下最低集合，控制在约一周：

• 正数和负数的模运算，知道模逆是什么；
• 向量、矩阵、内积和线性方程的基本计算；
• 多项式加法、乘法和取模的直觉；
• 均匀分布、条件概率、期望和方差；
• 比特、字节、异或、哈希和规范编码；
• 哈希函数的原像、第二原像和碰撞抗性；
• 数字签名的 KeyGen / Sign / Verify 接口；
• 安全参数和攻击复杂度的基本含义。

此时不要求学习完整数论、有限域证明或抽象代数体系，只要求能完成计算并读懂基本符号。

4.2 量子威胁基础 ​

无需先系统学习完整量子物理。优先掌握：

• 量子比特、叠加、测量和量子线路的基本直觉；
• 量子傅里叶变换为何与周期查找有关；
• Shor 算法对整数分解和离散对数的影响；
• Grover 算法对原像搜索和 PoW 搜索的影响；
• 理想哈希在量子查询模型下的原像、第二原像和碰撞复杂度差异；
• BQP 与量子多项式时间对手的基本含义；
• 量子能力出现时间与 QROM 安全模型不是同一个问题。

需要能够建立以下攻击映射：

4.3 从哈希签名建立直觉 ​

推荐顺序：

1. Lamport 一次性签名；
2. Winternitz / WOTS+；
3. Merkle 树签名；
4. LMS 与 XMSS；
5. FORS；
6. SLH-DSA 的整体结构。

重点理解：

• 为什么一次性密钥不能复用；
• Merkle 树如何用一个根认证大量一次性公钥；
• 有状态方案的计数器、备份回滚和多设备同步风险；
• 无状态哈希签名为什么避免状态复用，却产生较大签名；
• 域分离、地址结构和树层级为什么必须进入哈希输入；
• 哈希安全、参数选择与签名次数之间的关系。

建议亲自实现：

• Lamport 签名及密钥复用攻击演示；
• 简单 Merkle 树、认证路径和成员验证；
• 玩具版 WOTS；
• 调用标准库运行 SLH-DSA，并画出其数据结构图。

4.4 先调用标准算法，再打开内部结构 ​

在完整理解格密码前，可以把标准算法当作黑盒使用：

1. 生成 ML-DSA 和 SLH-DSA 密钥；
2. 对相同消息签名并验证；
3. 修改消息、签名或公钥，观察验证失败；
4. 记录公钥、私钥和签名大小；
5. 测量 KeyGen、Sign、Verify 和批量验证时间；
6. 固定库版本、参数集、测试向量和实验环境。

这一轮只需知道算法的安全定位和接口，不应根据微基准直接得出“哪个算法最适合区块链”的结论。

4.5 从玩具 LWE 进入 ML-DSA ​

学习顺序：

1. 二维格、基、范数、SVP 和 CVP 的直觉；
2. 模线性方程与小噪声；
3. LWE 与 SIS；
4. Ring-LWE 与 Module-LWE；
5. Module-SIS；
6. 多项式商环与卷积；
7. NTT 的加速作用；
8. Fiat–Shamir with aborts；
9. 拒绝采样、高低位分解和 hint；
10. ML-DSA 的 KeyGen / Sign / Verify 数据流。

实践任务：

• 实现一个小参数玩具 LWE；
• 观察噪声过小时的安全问题和过大时的正确性问题；
• 构造小参数 SIS 实例；
• 实现朴素的模 $x^n+1$多项式乘法；
• 跟踪一个标准实现中 ML-DSA 密钥生成、签名和验证的主要中间对象；
• 统计拒绝采样的重试次数，但不自行实现生产级 ML-DSA。

4.6 密钥封装机制（KEM）与其他后量子家族 ​

区块链资产授权应优先学习数字签名，但仍需建立以下地图：

• ML-KEM：KEM 语法、封装/解封装、解封装失败与 IND-CCA；
• HQC 与编码密码概览；
• Falcon，以及未来 FN-DSA 标准化方向；
• MPC-in-the-head 和多变量签名概览；
• 后量子承诺、向量承诺和零知识证明概览；
• 后量子多签、门限签名与签名聚合的研究现状。

必须区分：KEM 不是数字签名，也不是直接用于签署区块链交易的算法。

4.7 三层学习法 ​

对 ML-DSA、SLH-DSA 等算法分三轮学习：

第一轮：黑盒 ​

• 会调用；
• 会测量；
• 知道安全用途和标准状态。

第二轮：灰盒 ​

• 能沿数据流解释每个主要组件；
• 能定位哈希、采样、编码和多项式运算；
• 能解释常见实现风险。

第三轮：白盒 ​

• 能准确写安全定义；
• 能列出证明模型、困难假设和归约损失；
• 能阅读原方案论文及其 QROM/具体安全分析。

零基础阶段不要求一次完成第三轮。

4.8 阶段验收标准 ​

三个月结束时，应能：

• 解释 Shor 和 Grover 分别影响哪些链上机制；
• 实现 Lamport、Merkle 树和一个玩具 LWE；
• 解释有状态与无状态哈希签名的主要取舍；
• 调用并复现 ML-DSA、SLH-DSA 的标准参数实验；
• 沿数据流解释 ML-DSA 的 KeyGen、Sign 和 Verify；
• 说明噪声、拒绝采样、hint 和 Fiat–Shamir 的作用；
• 列出自己尚未补齐的数学与安全证明问题；
• 清楚说明“标准算法安全”不等于“区块链迁移协议安全”。

此时不要求从零实现完整 ML-DSA，也不要求独立完成 QROM 证明。

五、阶段二：数学与现代密码学按需回补 ​

本阶段与阶段一重叠进行。每遇到一个看不懂的符号、操作或安全结论，就把它记录为：

知识点 → 在哪里遇到 → 为什么影响理解 → 何时补齐 → 如何验收

5.1 基础欠账的触发式回补 ​

5.2 模运算、线性代数与概率 ​

优先掌握：

• 整数除法、同余、模加减乘和模逆；
• 扩展欧几里得算法；
• 向量、矩阵、转置、内积和线性组合；
• $\ell_1$、$\ell_2$、$\ell_\infty$范数；
• 线性方程、核空间和秩的直觉；
• 随机变量、条件概率、期望和方差；
• 均匀分布、二项分布、离散高斯和拒绝采样；
• 统计距离、尾界和失败概率。

建议实现：

• 快速模幂、扩展欧几里得和模逆；
• 小矩阵模 $q$运算；
• 常见离散分布采样与直方图；
• 不同噪声大小下玩具 LWE 的正确率实验。

5.3 代数结构与多项式环 ​

在进入 Module-LWE 和 NTT 时补齐：

• 群、环、域的定义和典型例子；
• 向量空间和模的直觉区别；
• 多项式加法、乘法和系数表示；
• 商环及模多项式约简；
• 循环卷积与负循环卷积；
• 有限域中的单位根；
• NTT 的输入、输出、正确性和复杂度。

必须能够计算并解释：

$$\mathbb{Z}_q,\qquad \mathbb{F}_q,\qquad \mathbb{Z}_q[x]/(x^n+1).$$

第一轮只要求理解“它们如何参与算法计算”；证明理想、同态和最坏情况归约可以放到第二轮。

5.4 面向签名的现代密码学顺序 ​

不必严格从一次一密顺序学完整本教材。围绕区块链授权，优先顺序调整为：

1. 哈希函数、MAC 与数字签名的区别；
2. 签名正确性和 EUF-CMA；
3. SUF-CMA、多用户和多目标安全；
4. 安全参数、PPT/QPT 对手、优势函数和可忽略函数；
5. 安全归约、归约损失与具体安全；
6. 随机预言机模型与量子随机预言机模型；
7. Fiat–Shamir 变换；
8. 规范编码、域分离和 transcript 绑定；
9. 密钥替换、rogue-key、重放和跨协议攻击；
10. 混合签名、不可分离性与组合安全；
11. 多签、聚合签名与门限签名的区别；
12. 承诺与零知识证明基础。

第二轮再系统补齐：

• 完美安全与一次一密；
• 伪随机生成器和伪随机函数；
• 对称加密、认证加密和 IND-CPA；
• 公钥加密、KEM、KEM–DEM 和 IND-CCA；
• Diffie–Hellman 与认证密钥交换。

5.5 经典公钥密码回补 ​

研究“迁移”前必须理解被迁移的旧机制：

• 有限域和椭圆曲线群；
• 离散对数、CDH 与 DDH；
• ECDSA 的签名方程、nonce 要求和公钥恢复；
• Schnorr 签名、线性结构与 Fiat–Shamir；
• BLS 签名、配对、聚合与 rogue-key 风险；
• 哈希到曲线和 proof of possession；
• 多签、聚合和门限机制的参与方与信任假设。

实践任务：

• 用小参数实现玩具版 Schnorr；
• 演示 ECDSA nonce 重复恢复私钥；
• 对一笔 Bitcoin 和一笔 Ethereum 交易计算或跟踪签名摘要；
• 对比 ECDSA、Schnorr、BLS、ML-DSA 和 SLH-DSA 的授权语义，而不只比较字节数。

5.6 安全定义与证明训练模板 ​

5.7 阶段验收标准 ​

六个月内应逐步达到：

• 能完成小参数模向量和模多项式计算；
• 能解释 $\mathbb Z_q[x]/(x^n+1)$在 ML-DSA 中的计算意义；
• 能写出 EUF-CMA 游戏、对手优势和简单归约框架；
• 能区分 PPT/QPT、ROM/QROM 和量子能力出现时间；
• 能解释 ECDSA、Schnorr、BLS 的基本结构与量子脆弱性；
• 能区分签名、多签、聚合签名和门限签名；
• 能说明算法标识、参数集、链 ID、账户/UTXO、nonce 和迁移纪元为何必须被认证；
• 能主动指出自己当前结论依赖了哪些数学或系统假设。

六、阶段三：区块链系统、UTXO 与共识机制 ​

这一阶段不再只学习“区块链用了哪些密码算法”，而是完整理解一笔交易如何形成、传播、执行、进入共同历史并获得最终性。推荐先 Bitcoin，后 Ethereum；第一遍建立全局地图，第二遍再结合迁移问题深入代码和规范。

6.1 区块链的六层分析框架 ​

以后分析任意区块链，都先回答六类问题：

必须从一开始区分：

• 数字签名解决授权，不负责全网排序；
• 共识解决冲突历史、排序与最终性，不替用户保管私钥；
• P2P 网络解决信息传播，不是全局完全同步的广播信道；
• 经济激励影响行为，但不能让违反共识规则的交易自动变成有效交易；
• 钱包和客户端决定用户能否安全使用协议，不能被视为链外无关组件。

6.2 分布式系统与共识基础 ​

6.2.1 必学概念 ​

• 状态机复制与确定性状态转换；
• crash fault 与 Byzantine fault；
• 安全性：诚实节点不接受相互冲突的确定结果；
• 活性：满足网络和诚实参与条件时，系统继续处理交易；
• 同步、部分同步和异步网络模型；
• 女巫攻击与 PoW/PoS 的抗女巫资源；
• 交易有效性、区块有效性、fork choice 和 finality 的区别；
• 概率最终性、经济最终性和 BFT 最终性；
• 网络分区、审查、重放、双花、equivocation 和长程攻击；
• 客户端实现、升级激活与社会协调。

6.2.2 共识家族地图 ​

学习 PBFT、Tendermint 或 HotStuff 的目的，是理解 quorum、视图切换和安全/活性边界；不要求在初学阶段完整证明全部协议。

6.2.3 共识分析模板 ​

阅读一个共识协议时固定记录：

1. 参与者如何加入，投票权如何计算；
2. 谁在何时提出区块；
3. 交易和投票如何传播；
4. 节点如何验证区块；
5. 出现多个有效分支时如何选择；
6. 什么条件下区块从 head 变为 safe/finalized；
7. 安全性需要多少诚实资源；
8. 活性需要什么网络假设；
9. 离线、双签、审查或分区如何处理；
10. 哪些步骤依赖数字签名、哈希、承诺或随机性。

6.2.4 PoW、PoS 与 BFT 的核心差异 ​

PoW ​

• 通过持续消耗外部算力竞争区块生产；
• 分支权重来自累计工作量；
• 攻击通常分析算力比例、网络传播和重组成本；
• 最终性通常是随确认增加而增强的概率保证；
• 量子分析除签名外还要考虑哈希搜索是否获得资源优势。

PoS ​

• 通过链内质押权益选择或加权区块生产与投票；
• 必须处理 equivocation、nothing-at-stake、长程攻击、权益退出和密钥泄露；
• slashing、弱主观检查点和 finality gadget 是常见防御组件；
• 不同 PoS 协议差异很大，不能把 Ethereum Gasper 的性质自动推广到所有 PoS 链；
• 一旦验证者签名被量子伪造，影响的不只是资产授权，还可能包括 fork choice、finality 和惩罚证据。

BFT 投票 ​

• 核心直觉是 quorum intersection：两个能够作出冲突决定的超级多数集合必须共享足够参与者；
• 安全性通常依赖 Byzantine 参与比例上界；
• 活性还依赖网络最终恢复同步、leader/view change 等机制；
• 数字签名认证“谁投了什么票”，但 quorum 和轮次规则才决定何时形成共识。

6.3 Bitcoin：从 UTXO 到 Nakamoto 共识 ​

6.3.1 一笔 Bitcoin 支付的完整生命周期 ​

钱包选择 UTXO
    ↓
构造输入、收款输出、找零输出和手续费
    ↓
按 sighash 规则生成认证消息并签名
    ↓
本地节点验证并放入自己的 Mempool
    ↓
交易经 P2P 网络传播，各节点独立验证
    ↓
矿工选择交易并构造候选区块
    ↓
矿工寻找满足目标值的 PoW
    ↓
全节点验证区块、交易和脚本
    ↓
节点选择累计工作量最高的有效分支
    ↓
后续区块增加，交易获得更多确认

后量子签名替换可能同时影响交易大小、签名摘要、Script、Mempool 策略、区块传播、钱包格式和共识升级，不能只在密码库一层分析。

6.3.2 UTXO 状态模型 ​

Bitcoin 没有协议层账户余额。每个交易输出包含：

• 以 satoshi 表示的金额；
• 规定未来花费条件的 scriptPubKey。

尚未被花费的输出称为 UTXO。普通交易输入通过 txid:vout 指向一个旧输出，这个二元组称为 outpoint。

必须理解：

• 一个 UTXO 被花费时必须整体消费，不能只减去其中一部分；
• 多余金额通常进入新的找零输出；
• 钱包余额是钱包可花费 UTXO 金额的聚合结果；
• 手续费不是普通交易中的独立字段，而是

$$\operatorname{fee} = \sum \operatorname{input\ value} - \sum \operatorname{output\ value};$$

• 每个 outpoint 在有效历史中至多被花费一次；
• UTXO 的拆分、合并、coin selection 与找零影响隐私、费用和迁移成本；
• “迁移一个钱包”最终要落实到如何发现和处理它控制的每个 UTXO；
• UTXO 锁定条件创建后不能像智能账户状态那样直接修改，通常必须花费到新输出才能升级。

最低实践：

1. 在 regtest 创建钱包并生成可花费测试币；
2. 使用 listunspent 查看 UTXO；
3. 发送一笔交易，标出输入、收款输出、找零输出和手续费；
4. 用 decoderawtransaction 解析交易；
5. 画出至少三笔交易之间的 UTXO 消费图。

6.3.3 交易、序列化与签名摘要 ​

应能够识别：

• version；
• 输入中的 txid、vout、scriptSig 和 nSequence；
• 输出金额和 scriptPubKey；
• SegWit marker、flag 和 Witness；
• nLockTime；
• txid 与 wtxid；
• 交易 weight、vbytes 与手续费率。

重点学习：

• Legacy、SegWit v0 和 Taproot 的 sighash；
• SIGHASH_ALL/NONE/SINGLE、ANYONECANPAY 和 SIGHASH_DEFAULT；
• 签名究竟承诺哪些输入、输出、金额、脚本和网络上下文；
• 绝对时间锁与相对时间锁；
• 规范序列化和解析差异为什么会成为共识风险。

6.3.4 Script、SegWit 与 Taproot ​

Bitcoin Script 是受限的栈式脚本语言。应理解：

• scriptPubKey 表达花费条件；
• Legacy 交易主要用 scriptSig 提供解锁数据；
• SegWit 主要用 Witness 提供满足条件的数据；
• 多签、哈希锁和时间锁都是不同的花费策略；
• 共识有效性与 Mempool 标准性/中继策略是不同层次。

主要输出类型：

推荐顺序：P2PK/P2PKH → P2SH → SegWit/P2WPKH/P2WSH → BIP 340 Schnorr → BIP 341 Taproot → BIP 342 Tapscript。

6.3.5 钱包与密钥生命周期 ​

必学：

• BIP 32 HD 钱包、扩展密钥和 chain code；
• hardened 与 non-hardened 派生；
• 接收链、找零链、地址复用和 coin control；
• watch-only、冷钱包和硬件签名器；
• 输出描述符和 PSBT；
• 钱包备份、恢复、重新扫描和多设备同步；
• xpub、descriptor、PSBT 或协调器在广播前泄露公钥的风险。

迁移时应追问：旧备份是否会重新启用经典密钥？硬件钱包是否认识新输出类型？descriptor、PSBT 与地址是否携带算法和版本？如何确认没有遗漏 UTXO？

6.3.6 P2P 与 Mempool ​

需要形成的核心认识：

• Mempool 是每个节点本地的未确认交易集合，不存在全网唯一 Mempool；
• 共识有效交易可能因费用或策略而不被某节点中继；
• 交易进入 Mempool 不保证最终被确认；
• RBF、CPFP、祖先/后代、交易包和 pinning 会影响确认；
• P2P 负责交易、区块和区块头传播，不决定脚本是否有效；
• 全节点、剪枝节点、轻客户端和钱包服务器具有不同信任模型。

建议用两个 regtest 节点观察：连接与断开、交易传播、不同 Mempool、冲突交易和重新连接后的状态变化。

6.3.7 区块、挖矿和 Nakamoto 共识 ​

区块头包含版本、前块哈希、Merkle root、时间、目标紧凑表示和 nonce。矿工改变 nonce、coinbase extra nonce、时间或交易集合，寻找满足目标值的双 SHA-256 哈希。

必须理解：

• coinbase 交易创建允许的区块补贴并收取手续费；
• 主网目标值通常每 2016 个区块调整一次，目标平均出块时间约为 10 分钟；
• 矿工提出和排序交易，但全节点独立执行共识规则；
• 算力多数不能直接伪造用户签名；
• “最长链”是简化表述，更准确的是累计工作量最高的有效链；
• 同高度竞争区块会产生临时分支；
• 节点切换到累计工作量更高的有效分支时发生 reorganization；
• Bitcoin 只有概率最终性，确认数降低风险但不形成绝对不可逆保证；
• 软分叉、硬分叉、矿工 signaling 和经济节点规则必须区分。

至少完成一次双节点 regtest 分叉与重组实验，并观察交易确认数和 Mempool 的变化。

6.3.8 Bitcoin 攻击与量子映射 ​

需要区分：

• 双花和低确认交易攻击；
• 高算力重组与交易审查；
• selfish mining；
• eclipse/Sybil；
• Mempool pinning；
• 钱包、seed、供应链与签名器攻击；
• 长暴露公钥与短暴露公钥攻击；
• 哈希、Merkle、PoW 和 P2P 握手的不同量子影响。

注意：P2TR 的 output key 从输出创建时公开；P2PKH/P2WPKH 的公钥通常在花费时公开，但地址复用、xpub、描述符、PSBT 或其他协议也可能提前暴露。

6.3.9 Bitcoin 阶段成果 ​

• 一张 UTXO 消费图；
• 一笔带字段标注的原始交易；
• 一张输出类型与公钥暴露表；
• 一次双节点 Mempool/传播实验；
• 一次区块头、Merkle root 和 PoW 验证；
• 一次分叉与重组实验；
• 一份《Bitcoin 数据、网络、共识与后量子攻击面清单》。

6.4 Ethereum 执行层 ​

6.4.1 节点架构 ​

Beacon Chain 最初作为 PoS 共识链启动；The Merge 将原有执行层接入其共识。The Merge 之后，不应把 Beacon Chain 理解成与 Ethereum 并列的另一条业务链，它通常对应今天所说的共识层。完整节点至少包含执行客户端和共识客户端；参与验证还需要 validator client。

6.4.2 账户、交易与状态转换 ​

必学内容：

• EOA 与合约账户；
• 账户的 nonce、balance、codeHash 和 storageRoot；
• 地址、公钥和 secp256k1 ECDSA 的关系；
• legacy、EIP-2930、EIP-1559 和 blob 交易的基本区别；
• chain ID、nonce、gas、费用、to、value 和 data；
• 交易签名、广播、交易池、打包、执行和 receipt；
• EVM 的 stack、memory、storage、calldata；
• CALL、DELEGATECALL、STATICCALL、CREATE 和 REVERT 的直觉；
• state root、transactions root 与 receipts root；
• RLP、Keccak-256、Merkle Patricia Trie 与共识层 SSZ/Merkle 化的区别；
• 预编译合约、日志、事件和执行 trace。

第一遍不要求背诵所有 opcode 和 gas 数值，只需沿着一笔交易回答：谁签名、签了什么、在哪里验证、执行了什么、状态如何改变。

6.4.3 智能账户与账户抽象 ​

学习：

• EOA 固定 ECDSA 授权与合约自定义验证的区别；
• ERC-1271 合约签名验证；
• ERC-4337 中 UserOperation、EntryPoint、bundler 与 paymaster；
• EIP-7702 delegation 的用途及其 ECDSA 授权边界；
• nonce、chain ID、EntryPoint、合约地址与签名域分离；
• 验证阶段的 Gas/DoS、重入、升级代理和恢复路径。

实践任务：

1. 使用 Anvil/Foundry 或本地执行客户端部署合约；
2. 签署并解析一笔 EIP-1559 交易；
3. 从已知交易摘要与签名恢复 ECDSA 公钥；
4. 比较 transaction、trace 和 receipt；
5. 实现一个可替换验证器的智能账户；
6. 使用 mock verifier 后，再接入真实 PQ 签名验证路径。

6.5 Ethereum PoS 与 Beacon 共识层 ​

6.5.1 Slot、epoch 与 Beacon state ​

• 当前稳定主网参数下，一个 slot 为 12 秒，是一次产生区块的机会，slot 可以为空；
• 一个 epoch 包含 32 个 slot，约为 6.4 分钟；
• slot 编号不是区块高度；
• Beacon block 保存共识对象，并包含执行层提供的 execution payload；
• Beacon state 包含验证者注册表、余额、检查点、随机性、slashing 记录和同步委员会等状态；
• 共识层主要使用 SSZ 和 hash_tree_root，不要与执行层 RLP/MPT 混淆。

具体时间和数量参数可能随升级改变；实验时固定规范 release/tag，不把易变常量当作永恒定义。

6.5.2 Validator 生命周期 ​

deposit
  → pending / activation queue
  → active
  → voluntary exit、ejection 或 slashing
  → exit queue
  → withdrawable
  → withdrawal

重点理解：

• validator signing key 与 withdrawal credentials 是不同权限；
• BLS signing key 是承担在线共识职责的热密钥；
• activation、exit 和 withdrawal 不是同一状态变化；
• churn limit 防止验证者集合瞬时大规模改变；
• 普通离线惩罚不等于 slashing；
• 阅读当前规范时需要在 Phase0 基线之上叠加后续 fork 的修改。

6.5.3 Proposer、committee、attestor 与 aggregator ​

• 每个 slot 选择 block proposer；
• 活跃验证者被分配到 committee；
• 验证者按职责产生 attestation；
• aggregator 聚合具有相同投票数据的签名并传播；
• 后续 proposer 将聚合证明收入 Beacon block；
• 聚合签名不是门限签名，每个参与验证者仍独立签署自己的消息。

一份 attestation 同时包含两类投票语义：

attestation
├── beacon_block_root：LMD-GHOST 的 head vote
├── source checkpoint：Casper FFG 的起点
└── target checkpoint：Casper FFG 的目标

6.5.4 Gasper：LMD-GHOST 与 Casper FFG ​

Ethereum PoS 共识 Gasper 由两部分组成：

LMD-GHOST：选择当前链头 ​

• 从认可的检查点附近开始；
• 根据有效余额统计各候选子树的最新投票权重；
• 每名验证者只计入 latest message；
• 递归选择较重子树得到当前 head；
• proposer boost 等机制处理及时区块与网络延迟问题；
• head 会随新消息变化，不等于最终性。

Casper FFG：证明检查点最终性 ​

• 对 epoch checkpoint 形成 source-target 投票；
• 达到超级多数权重的 link 可使目标 checkpoint justified；
• 后续满足规则的超级多数 link 可使较早 checkpoint finalized；
• 冲突最终性意味着有足够权益留下可处罚的矛盾投票证据。

必须区分：

head/latest：当前 fork choice 结果，可能短期重组
safe/justified：置信度更强，但不等于 finalized
finalized：除非发生严重共识失败，否则客户端不应回滚

6.5.5 BLS、RANDAO 与 Sync Committee ​

共识层使用 BLS12-381 签署或聚合 proposer、attestation、RANDAO 和同步委员会等消息。学习：

• BLS 公钥、签名和聚合验证；
• aggregation bits 与验证者注册表如何确定参与者；
• signing root、domain 和 fork version 如何防止跨职责与跨 fork 重放；
• RANDAO reveal 如何被混入协议随机性；
• proposer 不发布 reveal 可能造成的有限偏置；
• 当前稳定规范中的 sync committee 如何以 512 名成员、每 256 个 epoch 轮换的方式帮助轻客户端跟随近期 Beacon header；
• sync committee 不是普通 attestation committee，也不单独决定 Gasper 共识。

BLS 的紧凑聚合能力是后量子共识迁移的核心难点：简单替换为大尺寸 PQ 签名会影响 gossip 带宽、slot 关键路径、验证成本和聚合者中心化。

6.5.6 奖励、普通惩罚、Slashing 与 Inactivity Leak ​

必须区分：

1. 普通漏签或离线：损失奖励或受到普通 penalty；
2. 可证明的矛盾行为：触发 slashing 和强制退出；
3. 全网长期不能最终化：inactivity leak 逐渐削减未参与最终性的一方。

主要 slashable 行为：

• 同一 proposer 在同一 slot 签署两个不同区块；
• attester 对同一 target epoch 作出冲突投票；
• 一份 attestation 的 source-target 区间包围另一份，即 surround vote。

6.5.7 Execution Payload 与 Engine API ​

CL 运行 fork choice 并选择父块
  → CL 通过 forkchoiceUpdated 通知 EL，并可请求构造 payload
  → EL 从交易池选择并执行交易，构造 execution payload
  → CL 取得 payload，放入 Beacon block 后签名广播
  → 接收方 CL 验证共识部分
  → 接收方 EL 重新执行并验证 payload
  → committee 产生 attestation
  → 投票影响下一轮 head 与 epoch finality

理解 engine_forkchoiceUpdated、engine_getPayload 和 engine_newPayload 的语义。共识层或执行层任何一方都不能独立完成完整区块验证。

6.5.8 重组、弱主观性与安全假设 ​

应分析：

• 区块和 attestation 传播延迟；
• 空 slot、延迟发布、隐藏区块和 equivocation；
• proposer boost 与投票到达时序；
• optimistic sync 与执行验证延迟；
• 少量短期重组与 finalized 历史逆转的区别；
• 超过一定权益离线造成的 finality 停滞；
• 长程攻击和新节点的 weak-subjectivity checkpoint；
• 对网络最终同步、诚实有效余额、时钟和客户端正确性的假设。

权益阈值只能作为带前提的直觉：约三分之一权益可阻止正常最终化，过半权益可强烈影响 fork choice，约三分之二权益可推动其选择的检查点最终化；具体结论必须结合模型和协议版本。

6.5.9 Ethereum 密码组件与量子攻击面 ​

结论：迁移 EOA 的 ECDSA 并不等于 Ethereum 已实现后量子安全。账户授权、共识投票、轻客户端和数据承诺是不同迁移路径。

6.5.10 Ethereum 阶段成果 ​

1. 画出 EL、CL、validator client 与 Engine API 架构；
2. 标注一笔交易从签名到 receipt 的完整路径；
3. 读取一份 Beacon block，标注 slot、proposer、execution payload 和共识字段；
4. 解析一份 attestation 的 head/source/target；
5. 在小型分叉树上手算或实现玩具版 LMD-GHOST；
6. 模拟简化 FFG 的 justified/finalized 检查点；
7. 用 BLS 库完成独立签名与聚合实验；
8. 模拟 double vote、surround vote、离线和 finality 停滞；
9. 查询并比较 latest、safe 和 finalized；
10. 撰写《Ethereum 执行层、共识层与后量子攻击面清单》。

6.6 Bitcoin 与 Ethereum 对照 ​

6.7 第 13—32 周建议安排 ​

进度不足时优先保证 UTXO、Nakamoto 共识、Ethereum 节点架构和 Gasper 四条主线；Lightning、复杂 MEV、完整客户端源码和高级 ZK 可以后置。

6.8 阶段验收标准 ​

完成本阶段后，应能独立回答：

• 数字签名、P2P、交易执行和共识分别解决什么问题；
• UTXO、outpoint、找零和手续费如何工作；
• Script、scriptSig、Witness、txid 和 wtxid 的关系；
• 为什么 Mempool 不是全局状态；
• 为什么 Bitcoin 使用“累计工作量最高的有效链”且只有概率最终性；
• 为什么算力多数不等于能够伪造他人签名；
• Ethereum 的 EL、CL、validator client 和 Engine API 如何协作；
• slot、epoch、proposer、committee、attestation 和 checkpoint 的关系；
• 一份 attestation 如何同时服务 LMD-GHOST 与 Casper FFG；
• head、safe/justified 和 finalized 有何区别；
• 普通离线、slashing 和 inactivity leak 有何区别；
• 为什么 PoS 新节点需要 weak-subjectivity checkpoint；
• ECDSA、BLS、KZG 和哈希分别保护 Ethereum 的什么对象；
• 为什么账户 PQ 迁移不能自动解决共识层 PQ 迁移。

七、阶段四：区块链迁移安全 ​

迁移不是一次算法替换，而是一个持续多年的状态转换过程。该阶段是最可能形成博士论文创新的部分。

必须先区分两类状态模型：

• UTXO 型迁移：旧输出的花费条件通常不能原地修改，需要花费到新输出、预编码时间条件，或通过共识升级限制旧输出；
• 账户型迁移：智能账户可以更新认证状态，但必须防止旧管理员、旧签名、代理升级或恢复路径重新取得控制权。

同一个“AND/OR”“迁移纪元”或“不可回滚”概念，必须分别给出 Bitcoin 和 Ethereum 语义，不能直接套用。

7.1 混合签名 ​

设经典签名方案为 $\Sigma_C$，后量子签名方案为 $\Sigma_{PQ}$。

7.1.1 AND 模式 ​

交易同时满足：

$$\operatorname{Verify}_C(pk_C,m,\sigma_C)=1$$

和

$$\operatorname{Verify}_{PQ}(pk_{PQ},m,\sigma_{PQ})=1.$$

优点：

• 在严格 AND 验证、独立密钥、统一认证消息和正确密钥注册等条件下，只要一个组件仍满足所需不可伪造性，完整授权可继续安全；
• 适合对新算法尚未完全信任的过渡阶段。

问题：

• 公钥和签名体积明显增加；
• 用户需要管理两套密钥；
• 任意一个签名实现故障都可能导致资产不可用；
• 必须证明两份签名绑定同一消息、双方公钥、同一链、同一账户/UTXO、同一策略和同一迁移纪元；
• 必须处理 stripping、mix-and-match、密钥替换、解析歧义和组件签名跨协议复用；
• 需要处理一个签名方案被撤销或弃用后的解锁问题。

7.1.2 OR 模式 ​

经典签名或后量子签名任意一个有效即可。

优点：

• 兼容性和恢复性较好；
• 便于用户逐步切换设备和钱包。

问题：

• 一旦经典签名被量子攻击破坏，攻击者仍可通过经典分支花费；
• 必须配合明确的截止时间、迁移纪元或链上状态更新；
• 必须防止迁移后的账户重新回退到经典模式。

OR 更准确地说是一种授权策略，而不是“只要一个组件安全就整体安全”的鲁棒组合器。在经典分支关闭前，其不可伪造性通常受较弱分支限制。

7.1.3 统一认证转录 ​

组合方案不应只让两个算法分别签署一个含义不明的 m。建议至少认证：

domain || genesis-or-chain-id || contract-or-script || account-or-outpoint
|| transaction-or-action || state-nonce || migration-epoch
|| old-algorithm-and-key || new-algorithm-and-key
|| authorization-policy || expiry

必须规定唯一规范编码、算法和参数集编号、未知算法处理方式，并明确旧客户端是否可能把组合签名中的经典组件单独接受。

7.1.4 可研究问题 ​

如何构造既保证迁移期间可用性，又能在量子能力出现后不可逆关闭经典授权路径的混合签名与账户机制？

7.2 降级攻击 ​

攻击者可能诱导钱包、节点或账户继续使用旧算法，例如：

• 删除后量子能力标识；
• 修改算法版本号；
• 重放旧格式交易；
• 在算法协商中强迫双方选择经典方案；
• 回滚账户的迁移状态；
• 重新注册已被禁用的经典公钥；
• 将新旧签名分别绑定到不同消息；
• 利用跨链、跨网络或跨合约的消息格式混淆。

需要研究：

• 算法标识是否被签名覆盖；
• 版本号是否属于认证数据；
• 是否进行链 ID、账户 ID、合约地址和协议域分离；
• 迁移状态是否单调递增；
• 经典分支是否能够在某个阶段不可逆失效；
• 旧格式交易是否仍可被新节点接受；
• 节点软件升级与账户密钥升级是否存在不同步窗口。

7.3 新后量子公钥的可信绑定 ​

这是迁移中最关键的问题之一。

假设旧账户只登记了 ECDSA 公钥。用户提交交易：

将账户升级为新的 ML-DSA 公钥。

如果攻击者此时已经能够通过量子算法恢复旧 ECDSA 私钥，那么攻击者同样可以提交：

将账户升级为攻击者控制的 ML-DSA 公钥。

因此存在一个根本矛盾：

当旧密钥已经不可信时，不能仅依赖旧密钥证明新后量子公钥属于原用户。

更严格地说：如果旧经典签名已经可伪造，且失陷前没有留下仍不可伪造的承诺或独立认证因子，那么链上验证者看到的“原用户请求”和“攻击者请求”在认证能力上没有区别。挑战期只增加时间，不会自动创造新的身份依据；历史状态证明只能证明过去记录，不能单独证明当前提交者是原所有者。

因此应分别讨论：

• 已预承诺 PQ 公钥或恢复条件的账户；
• 已完成 PQ 迁移的账户；
• 未预承诺但经典密钥仍可信的账户；
• 未预承诺且经典密钥已经失陷的账户；
• 私钥已经遗失的休眠账户。

最后两类无法在没有额外信任假设时同时获得“原所有者可恢复”和“攻击者不可盗取”。这一边界可以作为形式化不可能性结果，而不只是方案设计中的困难。

可研究的方案包括：

• 提前预注册后量子公钥；
• 在量子威胁出现前提交公钥承诺；
• 延迟生效与挑战期；
• 多设备联合授权；
• 门限迁移；
• 社交恢复；
• 恢复委员会；
• 预承诺恢复脚本；
• 链上历史状态证明；
• 共识层快照；
• 紧急迁移窗口；
• 对未迁移资产进行分层冻结和申诉。

这一问题可进一步抽象为：

在对手获得量子能力前后，如何建立旧身份、旧资产与新后量子密钥之间的可证明绑定？

7.4 迁移阶段模型 ​

建议至少划分三个阶段：

阶段 A：量子能力出现前 ​

• 经典签名仍然可信；
• 用户可预注册 PQ 公钥或承诺；
• 协议开始支持混合签名；
• 需要防止假迁移和恶意注册。

阶段 B：经典与后量子机制并存 ​

• 部分账户已迁移，部分仍使用经典签名；
• 节点版本不一致；
• 攻击者可能尝试降级、重放和回滚；
• 需要兼顾安全性和可用性。

阶段 C：经典签名不再可信 ​

• 不能再仅凭经典私钥证明所有权；
• 经典授权分支需要关闭；
• 未迁移账户可能被锁定或进入特殊恢复流程；
• 共识层可能需要启动紧急策略。

形式化模型应明确：

• $T_{\mathrm{break}}$：经典签名何时实际可被伪造；
• $T_{\mathrm{detect}}$：社区何时发现或相信该能力存在；
• $T_{\mathrm{disable}}$：协议何时关闭经典授权分支；
• 单把密钥恢复延迟、并行量子预算、目标公钥数量与确认窗口；
• 对手能否控制网络；
• 对手能否延迟或阻断迁移交易；
• 对手能否腐化钱包、节点或恢复方；
• 对手能否重放旧交易；
• 用户是否提前提交过承诺。

攻击者可能长期隐藏量子能力，所以 A/B/C 是分析阶段，不一定是协议能够直接观测的状态。对 PQ 原语的安全性还需独立说明对手是 QPT、随机预言机查询是经典还是量子，以及采用 ROM 还是 QROM。

7.5 迁移安全目标 ​

建议至少定义以下条件化性质：

• 资产不可盗取性：未授权对手不能完成有效迁移或花费；
• 抗降级性：迁移后不能回退到已废弃算法；
• 密钥绑定性：新旧密钥必须绑定同一账户和同一迁移请求；
• 不可回滚性：在 common-prefix 或 finalized-checkpoint 等共识前提下，达到确认条件的迁移状态不能被旧授权恢复；
• 抗重放性：迁移交易不能跨链、跨账户或跨版本重放；
• 可恢复性：在明确的预承诺、独立恢复因子或信任方假设下，诚实用户可恢复访问；
• 活性：在最终同步、有界审查或诚实交易最终可被包含等网络假设下，诚实用户能够完成迁移；
• 算法失效容忍性：在另一条尚未失效的认证根存在时，能够再次迁移；
• 可组合性：迁移机制与多签、智能账户和共识协议组合后仍安全。

账户层协议不能单独保证抵抗任意深度重组，也不能在对手无限控制网络时保证活性。每个目标都必须列出密码假设、共识假设、网络假设和恢复信任假设。

7.6 当前工程提案与研究基线 ​

以下内容用于建立基线，不表示已经部署或已经形成社区共识。提案状态变化较快，开始实验时应再次核对并固定版本。

Bitcoin ​

• BIP 340/341/342：已部署的 Schnorr、Taproot 和 Tapscript 基线；
• BIP 360：Draft，P2MR 删除 Taproot key path，主要缓解长期公钥暴露；本身不提供 PQ 签名，也不解决短暴露攻击；
• BIP 361：Draft/Informational，讨论旧签名 sunset 与救援阶段，并依赖尚未确定的 PQ 签名提案。

Ethereum ​

• ERC-1271/4337：可在现有环境实现自定义智能账户验证，但不会自动消除既有 EOA 的 ECDSA 权限；
• EIP-7702：delegation authorization 仍由 ECDSA 授权，可作为旧密钥重新夺权或降级分析的重要基线；
• EIP-8141、EIP-8164、EIP-8197 等：围绕原生账户抽象、密钥委托或算法敏捷交易的 Draft；
• EIP-7932、EIP-8051/8052 等：辅助签名算法或 PQ 验证预编译方向的 Draft；
• Ethereum PQ/Lean 研究：共识签名、聚合、数据承诺和执行层迁移的研究路线，不应写成已经承诺的主网升级时间表。

每季度更新一次基线表，至少记录：编号、标题、状态、固定 commit/tag、威胁模型、迁移对象、安全主张、实现和已知限制。

八、前 12 周执行计划 ​

前 12 周专注于“先进入 PQC，再按需补基础”。区块链只做轻量背景阅读，系统性的 UTXO、PoW、Ethereum 执行层和 Beacon/PoS 学习从第 4 个月开始。

每周只强制保留三个成果：

1. 一个可运行且带基本测试的实验；
2. 一份 1—2 页概念笔记或一张结构图；
3. 一次约 10 分钟、不照稿的口头解释。

第 1 周：量子威胁与签名接口 ​

主线内容 ​

• Shor、Grover 和 PQC 家族全景；
• KeyGen / Sign / Verify；
• 经典签名与 PQ 签名的接口和对象大小；
• NIST PQC 标准名称和用途。

按需回补 ​

• 正负数模运算；
• 比特、字节、十六进制与哈希；
• 安全参数和“128-bit security”的直觉。

实践与成果 ​

• 建立代码仓库和实验环境；
• 调用经典签名、ML-DSA 和 SLH-DSA 完成签名与验证；
• 修改消息、签名和公钥，记录验证行为；
• 输出第一张算法接口与尺寸对照表。

第 2 周：哈希与 Merkle 树 ​

主线内容 ​

• 原像、第二原像和碰撞抗性；
• Merkle root、叶子、内部节点与认证路径；
• 域分离和唯一编码。

实践与成果 ​

• 实现 Merkle 树和成员证明；
• 对奇数叶子、空树和重复叶子规定明确行为；
• 绘制验证路径并编写错误输入测试。

第 3 周：Lamport 一次性签名 ​

主线内容 ​

• Lamport KeyGen、Sign 和 Verify；
• 一次性密钥、信息泄露与密钥复用；
• 公钥和签名为何很大。

按需回补 ​

• 概率、独立随机值和哈希安全；
• 位串与消息摘要。

实践与成果 ​

• 实现 Lamport 签名；
• 演示重复使用同一密钥后泄露更多秘密值；
• 写出“状态管理为什么是密码安全的一部分”。

第 4 周：WOTS+、LMS、XMSS 与 SLH-DSA ​

主线内容 ​

• Winternitz 权衡；
• 一次性密钥如何由 Merkle 根统一认证；
• 有状态与无状态哈希签名；
• FORS 和 SLH-DSA 的结构地图。

实践与成果 ​

• 实现玩具版 WOTS 或完成其逐步计算；
• 调用 SLH-DSA；
• 绘制从消息到最终签名的结构图；
• 完成第 4 周口头验收。

第 5 周：格、基、短向量与范数 ​

主线内容 ​

• 二维格和基；
• 不同基表示同一个格；
• 范数、SVP 和 CVP 的直觉；
• “寻找短向量”为什么可能困难。

按需回补 ​

• 向量、矩阵、内积；
• $\ell_1$、$\ell_2$、$\ell_\infty$范数。

实践与成果 ​

• 绘制二维格；
• 比较不同基；
• 完成一个小维度最近点实验。

第 6 周：LWE 与噪声 ​

主线内容 ​

• 模线性方程；
• secret、公开样本和 error；
• 噪声为何同时影响安全性和正确性；
• search-LWE 与 decision-LWE 的直觉。

按需回补 ​

• 模向量矩阵运算；
• 均匀、二项和离散高斯分布；
• 正确性失败概率。

实践与成果 ​

• 实现玩具版 LWE；
• 改变噪声参数，观察攻击难度与失败率；
• 明确玩具参数不具备真实安全性。

第 7 周：SIS 与 Module 结构 ​

主线内容 ​

• SIS 与 LWE 的区别；
• Ring-LWE、Module-LWE 和 Module-SIS；
• 为什么标准方案采用结构化矩阵和多项式模块。

按需回补 ​

• 线性组合、核空间和短向量；
• 模与向量空间的计算直觉。

实践与成果 ​

• 构造一个小参数 SIS 实例；
• 用一页图表比较 LWE、SIS、Ring 与 Module 版本。

第 8 周：多项式商环与 NTT 直觉 ​

主线内容 ​

• 多项式卷积；
• 模 $x^n+1$的负循环约简；
• NTT 为什么能加速多项式乘法；
• 数据表示和参数对实现的影响。

按需回补 ​

• 多项式加乘；
• 商环的计算含义；
• 模素数和单位根直觉。

实践与成果 ​

• 实现朴素模多项式乘法；
• 用小参数验证约简结果；
• 能解释 NTT 的输入输出，不要求严格推导。

第 9 周：ML-DSA KeyGen 与数据结构 ​

主线内容 ​

• 参数集、seed、XOF、矩阵展开和采样；
• secret/public 向量和高低位分解；
• 公钥、私钥与中间对象的编码。

实践与成果 ​

• 跟踪一个标准实现的 KeyGen；
• 记录主要对象的类型和大小；
• 画出 KeyGen 数据流。

第 10 周：ML-DSA Sign 与 Verify ​

主线内容 ​

• 承诺、challenge、response；
• 拒绝采样；
• high bits、low bits 与 hint；
• Sign 和 Verify 如何保持一致。

实践与成果 ​

• 绘制完整签名/验证流程；
• 修改签名字段观察失败；
• 若库可观测，统计拒绝重试次数；
• 不自行编写生产级实现。

第 11 周：EUF-CMA、Fiat–Shamir、ROM 与 QROM ​

主线内容 ​

• 安全参数、PPT/QPT 和可忽略函数；
• EUF-CMA 安全游戏；
• Fiat–Shamir 的作用；
• ROM 与 QROM 的区别；
• 标准算法、困难假设和安全证明之间的关系。

实践与成果 ​

• 写出 EUF-CMA 游戏；
• 画出 ML-DSA 的证明依赖图；
• 列出当前仍无法解释的证明步骤，进入基础欠账表。

第 12 周：对比实验与阶段复盘 ​

主线内容 ​

• ML-DSA、SLH-DSA 与经典签名的结构差异；
• KeyGen、Sign、Verify、尺寸和内存指标；
• 随机性、状态、侧信道和实现风险；
• 如何避免从一次微基准推导过度结论。

实践与成果 ​

• 完成可重复的算法基准脚本；
• 固定软件版本、参数、硬件和运行次数；
• 完成一份 8—12 页报告：

《从哈希签名与 LWE 到 ML-DSA：后量子签名入门实验与基础欠账清单》

建议结构：

1. 量子威胁与签名接口；
2. Lamport、WOTS、Merkle 和 SLH-DSA；
3. LWE、SIS 与 Module 结构；
4. ML-DSA 数据流；
5. EUF-CMA、ROM/QROM 和证明依赖；
6. 算法基准与实现风险；
7. 尚未补齐的数学和安全问题；
8. 第 4—6 个月基础回补计划。

12 周分级验收 ​

第 4 周 ​

• 能解释 Shor 和 Grover 分别影响哪些密码机制；
• 能实现并测试 Lamport 和 Merkle 树；
• 能解释一次性签名为什么不能复用；
• 能调用 SLH-DSA 完成完整签名流程。

第 8 周 ​

• 能用自己的语言和简单公式描述 LWE 与 SIS；
• 能解释噪声为何既提供安全性又影响正确性；
• 能计算小参数模向量和模多项式；
• 能区分 LWE、Ring-LWE、Module-LWE 和 SIS。

第 12 周 ​

• 能沿数据流解释 ML-DSA 的 KeyGen、Sign 和 Verify；
• 能说明拒绝采样、hint 和 Fiat–Shamir 的作用；
• 能写出 EUF-CMA 安全游戏；
• 能复现 ML-DSA 与 SLH-DSA 的尺寸和性能实验；
• 能列出基础欠账及补齐计划；
• 能说明标准算法安全为什么不等于区块链迁移协议安全。

九、第一年学习与基础研究平台 ​

建议搭建：

面向 Bitcoin 与 Ethereum 的后量子迁移基线平台

该平台不一定直接形成论文，但将成为后续研究的统一实验基础。不要在第一年一开始同时实现全部模块，按三个版本递增：

只有 v2 经过研究问题筛选后，才扩展为论文平台。双链、全部算法和全部策略是长期清单，不是同时完成的硬指标。

9.1 密码资产清单模块 ​

记录：

• 使用了什么密码算法；
• 公钥在何时暴露；
• 密钥控制什么资产或权限；
• 更换算法是否需要分叉；
• 是否存在休眠账户；
• 是否支持算法版本化；
• 是否支持密钥恢复；
• 是否存在聚合、多签和门限结构。

9.2 算法基准模块 ​

比较：

• secp256k1 ECDSA；
• BIP 340 Schnorr；
• BLS；
• ML-DSA；
• SLH-DSA；
• Falcon / FN-DSA；
• XMSS 或 LMS。

测量：

• 公钥大小；
• 私钥大小；
• 签名大小；
• KeyGen 时间；
• Sign 时间；
• Verify 时间；
• 批量验证；
• 内存占用；
• 不同硬件平台表现。

9.3 链上成本模块 ​

测量：

• 单笔交易增加的字节数；
• 单区块可容纳交易数；
• 区块传播延迟；
• 节点验证成本；
• Mempool 内存消耗；
• 状态或 UTXO 集合增长；
• Gas 或等价执行成本；
• 大签名触发的 DoS 风险。

9.4 迁移策略模块 ​

至少实现：

• 经典签名模式；
• PQ-only 模式；
• AND 混合模式；
• OR 混合模式；
• 带截止时间的 OR 模式；
• 预注册 PQ 公钥模式；
• 延迟激活模式；
• 恢复密钥模式；
• 不可逆升级模式。

9.5 安全分析模块 ​

分析：

• 降级攻击；
• 密钥替换；
• 重放攻击；
• 跨链重放；
• 恶意注册；
• 状态回滚；
• 经典私钥泄露；
• PQ 算法失效；
• 钱包实现漏洞；
• 大签名 DoS；
• 密钥状态复用；
• 多签中的 rogue-key 攻击。

9.6 链上状态与共识观察模块 ​

Bitcoin 至少保存和复现实验：

• UTXO 创建、消费、找零和手续费；
• 不同节点的 Mempool 差异；
• 区块头、Merkle root、目标值和累计工作量；
• 临时分支、链重组和确认数变化；
• P2PKH/P2WPKH/P2TR 的公钥暴露时间。

Ethereum 至少保存和复现实验：

• 交易、trace、receipt 和状态变化；
• EL、CL 与 Engine API 的消息路径；
• Beacon block、attestation 和 finality checkpoint；
• 玩具版 LMD-GHOST 与简化 Casper FFG；
• head、safe、justified 和 finalized 的变化；
• ECDSA、BLS、KZG 与哈希组件的权限边界。

每个实验记录客户端版本、网络配置、规范 tag、输入、输出和复现命令，避免把版本相关行为误写成永久协议规则。

十、博士研究方向优先级 ​

建议优先顺序 ​

1. 选择一种状态模型：账户或 UTXO；
2. 研究一种迁移动作及其降级/抢迁移问题；
3. 混合签名与组合安全；
4. 休眠资产、钱包和恢复；
5. 后量子多签和门限签名；
6. 共识层、轻客户端与承诺层迁移。

十一、研究问题北极星与首篇论文候选切口 ​

本节在基础学习阶段只作为“北极星”，不要求现在锁定题目。完成第 9—12 个月的文献和系统基线后，再根据导师方向、已有工作与实验结果决定主链。

宽口径研究主题可以表述为：

面向账户型区块链的抗降级、可证明安全的后量子密钥迁移协议

但首篇论文必须进一步缩小为：

一条链 × 一类状态对象 × 一次迁移 × 一个主要攻击 × 一个实现平台

例如，可验证但尚需查新的候选切口是：

旧经典密钥失陷模型下，基于预承诺的 Ethereum 智能账户不可降级 PQ 迁移。

如果最终选择 Bitcoin，则必须把研究对象改写为具体 UTXO 类型、花费路径和共识/钱包部署条件，不能直接复用账户状态机表述。

11.1 研究问题 ​

现有区块链账户通常仅依赖经典公钥。当系统开始支持后量子密码时，需要解决：

• 新后量子公钥如何与旧账户绑定？
• 旧私钥泄露后能否冒充用户完成迁移？
• 新旧签名并存时如何防止降级？
• 迁移是否能够不可逆？
• 没有及时迁移的休眠账户如何处理？
• 如何在保证安全的同时避免永久锁定诚实用户资产？

11.2 对手模型 ​

对手可以：

• 在某个时间点获得量子能力；
• 恢复部分经典私钥；
• 控制或延迟网络；
• 重放旧交易；
• 替换注册的 PQ 公钥；
• 阻止用户及时迁移；
• 控制部分恢复方或设备；
• 利用旧节点接受旧格式交易。

11.3 安全目标 ​

以下是长期问题池，不表示首篇论文必须同时解决：

• 资产不可盗取；
• 新旧密钥绑定；
• 抗降级；
• 抗回滚；
• 抗重放；
• 迁移活性；
• 用户可恢复；
• 经典分支可安全退出；
• PQ 算法失效后仍可二次迁移。

首篇论文通常选择一个主要性质和一至两个由同一机制自然得到的附带性质。

11.4 可考虑的协议组件 ​

• 双密钥绑定；
• 提前承诺；
• 延迟激活；
• 挑战窗口；
• 迁移纪元；
• 单调状态机；
• 经典分支自动失效；
• 多设备门限授权；
• 恢复委员会；
• 紧急冻结与申诉机制。

11.5 论文应包含的成果 ​

候选贡献可以包括：

1. 一个此前未被清楚表达的攻击或不可能性边界；
2. 带明确前提的迁移状态机和安全定义；
3. 一个只解决核心问题的新协议；
4. 安全证明、形式化验证或严格攻击分析；
5. 与所选链一致的原型；
6. 三到五个最接近的迁移基线；
7. 与主张直接相关的交易大小、延迟、存储、Gas/weight、吞吐量或 DoS 评测；
8. 与现有 EIP、BIP、标准和密码组合器的系统比较。

注意：该题目只是研究起点。正式立题前必须系统核查近五年的安全顶会、密码学会议、EIP、BIP 和工程实现，确认新颖性。

十二、面向安全四大的研究标准 ​

若目标是 IEEE S&P、ACM CCS、NDSS 或 USENIX Security，一篇迁移论文最好同时具有以下组成部分。

12.1 新问题或新攻击 ​

需要回答：

• 现有迁移方案忽略了什么？
• 是否存在可实际利用的降级、重放、抢迁移或锁资攻击？
• 现有安全模型是否遗漏了量子能力出现的时间因素？

12.2 明确的安全模型 ​

需要明确：

• 对手何时获得量子能力；
• 对手能否控制网络；
• 对手能否恢复旧私钥；
• 对手能否阻断迁移；
• 对手能否控制恢复参与方；
• 对手是否可以量子查询随机预言机。

12.3 新协议或新机制 ​

不能只是调用标准 PQC 库，而应在以下方面有实质贡献：

• 密钥绑定；
• 迁移状态机；
• 抗降级组合；
• 休眠账户处理；
• 紧急恢复；
• 兼容性与部署路径。

12.4 形式化分析或安全证明 ​

至少需要证明或形式化验证：

• 不可伪造；
• 不可降级；
• 不可回滚；
• 抗重放；
• 密钥绑定；
• 迁移活性。

12.5 真实原型 ​

可选择：

• Bitcoin regtest；
• Ethereum 智能账户；
• 执行客户端修改；
• 共识客户端模拟；
• 独立迁移测试框架。

12.6 现实评测 ​

至少包括：

• 交易大小；
• 区块吞吐量；
• 验证延迟；
• 网络传播；
• 存储增长；
• Gas 或脚本成本；
• 大签名 DoS；
• 钱包和节点兼容性。

12.7 部署路径 ​

必须讨论：

• 旧节点怎么办；
• 旧钱包怎么办；
• 旧账户怎么办；
• 用户拒绝迁移怎么办；
• 迁移失败怎么办；
• 新后量子算法后来被攻破怎么办；
• 是否需要软分叉、硬分叉或账户级升级。

12.8 基线比较 ​

至少比较：

• 经典签名；
• PQ-only；
• AND 混合；
• OR 混合；
• 带截止时间的 OR；
• 预注册方案；
• 恢复方案；
• 现有 EIP/BIP 或学术方案。

若主要贡献是新的签名、聚合、门限方案或安全归约，也应考虑 CRYPTO、EUROCRYPT、ASIACRYPT、PKC、TCC 和 PQCrypto 等密码学会议。

十三、每周科研安排 ​

零基础阶段不采用全年固定比例，而是随阶段变化：

“主线学习/实验”既包括阅读，也包括动手。每周优先完成一个能累积到阶段报告的研究工件，而不是同时追求所有产出类型。

每周最低成果 ​

每周最低只要求：

1. 一个主要成果：可运行实验、协议图、安全游戏、证明练习或规范注释之一；
2. 一份 1—2 页笔记，记录结论、失败、未懂概念和下周动作；
3. 一次约 10 分钟的口头复述或演示。

论文卡片、证明题和长周报按阶段需要选择，不要求零基础时期每周全部完成。连续两周无法完成时，应缩小任务而不是继续堆积欠账。

推荐周安排 ​

十四、论文阅读与研究记录模板 ​

14.1 论文阅读卡片 ​

# 论文标题

## 1. 基本信息
- 作者：
- 会议/期刊：
- 年份：
- 代码：
- 研究对象：

## 2. 研究问题
论文试图解决什么问题？为什么重要？

## 3. 系统与对手模型
- 系统参与方：
- 对手能力：
- 信任假设：
- 量子能力：

## 4. 安全目标
- 机密性：
- 完整性：
- 不可伪造性：
- 抗降级：
- 抗回滚：
- 可恢复性：

## 5. 核心方案
用自己的语言描述方案，不复制摘要。

## 6. 密码学工具
- 签名：
- 承诺：
- 零知识证明：
- 门限机制：
- 安全假设：

## 7. 安全证明
- 证明模型：
- 归约目标：
- 关键混合游戏：
- 归约损失：
- 可能缺口：

## 8. 系统实现与评测
- 平台：
- 数据集：
- 基线：
- 主要指标：
- 实验结论：

## 9. 局限性
论文没有解决什么？

## 10. 对本人研究的启发
可以扩展、修复或重新建模的点是什么？

14.2 研究问题记录模板 ​

# 研究问题名称

## 现象
观察到什么系统或安全问题？

## 现有方案
现有工作如何处理？

## 缺口
为什么现有方案不足？

## 对手能力
攻击者具备哪些能力？

## 目标性质
新方案需要满足什么？

## 初步构造
核心机制是什么？

## 证明路线
准备归约到什么假设？

## 实验路线
在哪个平台实现？测什么指标？

## 风险
可能没有创新或无法证明的地方是什么？

## 下一步
一周内可验证的最小任务是什么？

十五、阶段验收与年度里程碑 ​

15.1 三个月验收 ​

• 能解释 Shor、Grover 与主要链上密码组件的关系；
• 能实现 Lamport、Merkle 树和玩具 LWE；
• 能调用并比较 ML-DSA 与 SLH-DSA；
• 能沿数据流解释 ML-DSA 的主要步骤；
• 能写出 EUF-CMA 游戏的基本结构；
• 建立代码仓库、实验记录和基础欠账表。

15.2 六个月验收 ​

• 能完成模向量、模多项式和基本概率计算；
• 能解释群、离散对数、ECDSA、Schnorr 和 BLS；
• 能区分 PPT/QPT、ROM/QROM、多用户和组合安全；
• 能写出简单安全归约框架并说明归约损失；
• 能解析 Bitcoin UTXO 与交易，完成初步 regtest 实验。

15.3 九个月验收 ​

• 能解释 Bitcoin 的 UTXO、Script、Mempool、PoW、重组和概率最终性；
• 能解释 Ethereum 的执行层状态转换；
• 能画出 EL、CL、validator client 与 Engine API；
• 能解释 slot、epoch、attestation、LMD-GHOST 和 Casper FFG；
• 能区分普通惩罚、slashing、inactivity leak 和 weak subjectivity；
• 完成 Bitcoin 与 Ethereum 两份分层量子攻击面报告。

15.4 十二个月验收 ​

• 选择一条主链作为研究对象；
• 完成 PQC、链上状态和共识观察平台；
• 实现至少三种最相关迁移基线；
• 复现至少一种降级、抢迁移、重放或回滚轨迹；
• 明确旧密钥失陷、网络审查与共识最终性的模型边界；
• 形成 2—3 个候选研究问题和一次 go/no-go 评审。

15.5 十八个月验收 ​

• 完成系统性相关工作与提案对照；
• 确定一个范围清楚的研究问题；
• 完成协议或攻击设计；
• 完成安全证明、形式化验证或严格经验分析中的主要部分；
• 完成可复现实验与系统评测；
• 形成第一篇完整论文初稿，或一份足以支持转题判断的完整技术报告。

十六、常见误区 ​

误区零：把“后量子先行”理解成永远跳过基础 ​

先运行算法是为了建立问题意识，不是为了绕开数学和安全定义。凡是已经阻碍理解或安全判断的知识，必须进入基础欠账表并在指定阶段补齐。

误区一：把后量子密码等同于格密码 ​

区块链中还需要关注：

• 哈希签名；
• Merkle 承诺；
• STARK；
• 后量子零知识证明；
• 门限和恢复机制；
• 密码敏捷性。

误区二：认为隐藏公钥即可实现量子安全 ​

公钥哈希只能延迟公钥暴露。交易广播后，公钥仍可能暴露，因此不能替代真正的后量子签名。

误区三：一开始同时修改 Bitcoin Core 和 Ethereum 客户端 ​

学习时建议先 Bitcoin 后 Ethereum；研究原型可以优先选择 Ethereum 智能账户，因为更容易快速修改验证逻辑。

误区四：只做性能比较 ​

Benchmark 是必要基础设施，但单纯比较签名大小、Gas 和运行时间通常不足以构成高水平论文。

误区五：过度关注量子计算机出现的具体年份 ​

迁移协议应在不同量子到达时间假设下成立，而不是依赖某个具体年份。

误区六：直接自行设计新的后量子签名 ​

博士前期更适合使用标准方案，研究迁移协议、安全组合、账户机制和系统约束。

误区七：只分析算法安全，不分析迁移安全 ​

即使 ML-DSA 本身安全，迁移协议仍可能因为以下问题失败：

• 公钥绑定错误；
• 算法降级；
• 版本回滚；
• 跨链重放；
• 休眠账户被抢迁移；
• 恢复机制被滥用。

误区八：只读论文，不运行真实系统 ​

只有实际解析交易、修改钱包验证逻辑、测量签名大小和区块传播，才能发现真实约束。

误区九：只学签名，不学状态、网络和共识 ​

签名只回答“谁授权了状态变化”。UTXO 或账户模型决定状态是什么，Mempool 和 P2P 决定消息如何到达，共识决定哪段历史被接受。缺少任何一层，都无法准确分析迁移安全。

误区十：把 Beacon Chain 当作与 Ethereum 并列的另一条业务链 ​

The Merge 之后，Beacon 共识层与执行层共同组成 Ethereum。执行客户端处理交易和 EVM，共识客户端处理 fork choice、验证者和最终性，两者通过 Engine API 协作。

误区十一：把提案编号当作已经部署的路线 ​

BIP、EIP 和研究 roadmap 可能处于 Draft、Review、Final、Deployed 或停滞状态。阅读时必须记录状态、日期、commit/tag 和实际主网激活情况，不能因为编号存在就将其当作系统现状。

十七、推荐资料 ​

17.1 现代密码学 ​

• Dan Boneh and Victor Shoup, A Graduate Course in Applied Cryptography
  https://toc.cryptobook.us/

• Jonathan Katz and Yehuda Lindell, Introduction to Modern Cryptography

• Mihir Bellare and Phillip Rogaway, Introduction to Modern Cryptography 课程资料

17.2 格密码与后量子密码 ​

• Chris Peikert, Lattices in Cryptography 课程资料
  https://github.com/cpeikert/LatticesInCryptography

• NIST Post-Quantum Cryptography Project
  https://csrc.nist.gov/projects/post-quantum-cryptography

• FIPS 203: ML-KEM
  https://csrc.nist.gov/pubs/fips/203/final

• FIPS 204: ML-DSA
  https://csrc.nist.gov/pubs/fips/204/final

• FIPS 205: SLH-DSA
  https://csrc.nist.gov/pubs/fips/205/final

• SP 800-208: Stateful Hash-Based Signature Schemes
  https://csrc.nist.gov/pubs/sp/800/208/final

• NIST Additional Digital Signature Schemes
  https://csrc.nist.gov/projects/pqc-dig-sig

• Open Quantum Safe / liboqs
  https://openquantumsafe.org/liboqs/

截至 2026-09-02，ML-KEM、ML-DSA 和 SLH-DSA 已有最终 FIPS；Falcon 是未来 FN-DSA/FIPS 206 的基础，FIPS 206 尚未成为最终标准。引用时仍应再次核对当前状态。

17.3 分布式系统与共识 ​

• Bitcoin Whitepaper
  https://bitcoincore.org/bitcoin.pdf

• Introduction to Reliable and Secure Distributed Programming，Cachin、Guerraoui、Rodrigues

• Distributed Systems，Coulouris 等，或同类分布式系统入门课程

• Gasper: Combining GHOST and Casper
  https://arxiv.org/abs/2003.03052

阅读目标不是一次掌握全部分布式理论，而是能够准确使用安全性、活性、网络同步、quorum、fork choice 和 finality 等概念。

17.4 Bitcoin ​

• Bitcoin Developer Guide
  https://developer.bitcoin.org/devguide/

• Transactions 与 UTXO
  https://developer.bitcoin.org/devguide/transactions.html

• Block Chain、Mining 与 P2P Network
  https://developer.bitcoin.org/devguide/block_chain.html
  https://developer.bitcoin.org/devguide/mining.html
  https://developer.bitcoin.org/devguide/p2p_network.html

• BIP 32: Hierarchical Deterministic Wallets
  https://bips.dev/32/

• BIP 141: Segregated Witness
  https://bips.dev/141/

• BIP 340: Schnorr Signatures for secp256k1
  https://bips.dev/340/

• BIP 341: Taproot
  https://bips.dev/341/

• BIP 342: Tapscript
  https://bips.dev/342/

• BIP 360: P2MR，Draft
  https://bips.dev/360/

• BIP 361: Post Quantum Migration and Legacy Signature Sunset，Draft/Informational
  https://bips.dev/361/

• Bitcoin Core descriptors 与 Mempool policy
  https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md
  https://github.com/bitcoin/bitcoin/tree/master/doc/policy

17.5 Ethereum 执行层 ​

• Ethereum Developer Documentation
  https://ethereum.org/developers/docs/

• Accounts、Transactions 与 EVM
  https://ethereum.org/developers/docs/accounts/
  https://ethereum.org/developers/docs/transactions/
  https://ethereum.org/developers/docs/evm/

• Node Architecture
  https://ethereum.org/developers/docs/nodes-and-clients/node-architecture/

• ERC-1271 与 ERC-4337
  https://eips.ethereum.org/EIPS/eip-1271
  https://eips.ethereum.org/EIPS/eip-4337

• EIP-7702: Set EOA Account Code
  https://eips.ethereum.org/EIPS/eip-7702

• EIP-4844: Shard Blob Transactions
  https://eips.ethereum.org/EIPS/eip-4844

17.6 Ethereum 共识层与 Beacon/PoS ​

• Ethereum Proof-of-Stake
  https://ethereum.org/developers/docs/consensus-mechanisms/pos/

• Slots、Epochs、Block Proposal 与 Attestations
  https://ethereum.org/developers/docs/consensus-mechanisms/pos/block-proposal/
  https://ethereum.org/developers/docs/consensus-mechanisms/pos/attestations/

• Gasper
  https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/

• Rewards、Penalties 与 Weak Subjectivity
  https://ethereum.org/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/
  https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/

• Ethereum Consensus Specifications
  https://ethereum.github.io/consensus-specs/
  https://github.com/ethereum/consensus-specs

• Engine API
  https://github.com/ethereum/execution-apis/tree/main/src/engine

规范阅读采用“Phase0 基线 + 后续 fork 增量修改”的方式，并为实验固定 release/tag，不要只读早期 Phase0 字段后将其当作当前完整协议。

17.7 当前后量子迁移跟踪入口 ​

• Ethereum Quantum Resistance Roadmap
  https://ethereum.org/roadmap/security/quantum-resistance/

• Post-Quantum Ethereum
  https://pq.ethereum.org/

• EIP-8141: Frame Transaction，Draft
  https://eips.ethereum.org/EIPS/eip-8141

• EIP-8202: Scheme-Agile Transactions，Draft
  https://eips.ethereum.org/EIPS/eip-8202

• EIP-8164: Native Key Delegation for EOAs，Draft
  https://eips.ethereum.org/EIPS/eip-8164

• EIP-8197: Cryptographically Agile Transactions，Draft
  https://eips.ethereum.org/EIPS/eip-8197

• EIP-7932、8051、8052：辅助签名算法与 PQ 验证预编译，Draft
  https://eips.ethereum.org/EIPS/eip-7932
  https://eips.ethereum.org/EIPS/eip-8051
  https://eips.ethereum.org/EIPS/eip-8052

• EIP-8292: Post-Quantum Attestation Aggregators，Draft
  https://eips.ethereum.org/EIPS/eip-8292

这些页面属于动态资料。正式写作前重新核对提案状态、主网激活情况和规范版本。

最后建议 ​

现阶段最重要的是让兴趣带动基础，并建立一个可反复运行的螺旋：

运行一个后量子算法
   ↓
画出结构并记录不懂之处
   ↓
定向回补数学与安全定义
   ↓
回到算法重新解释
   ↓
学习真实区块链的状态、网络与共识
   ↓
建立分层量子攻击面
   ↓
提出迁移问题、实现并验证

第一周可以只完成三件事：

1. 搭好代码仓库并调用一次 ML-DSA 和 SLH-DSA；
2. 复习最基本的模运算、比特、字节和签名接口；
3. 建立基础欠账表，记录每个暂时看不懂的符号和概念。

不需要在第一周证明 EUF-CMA，也不需要立即运行 Bitcoin 或 Ethereum 节点。先建立成就感，再按阶段进入证明和系统。能够持续完成“运行—解释—补课—再解释”的循环时，学习路线就真正从资料清单转化为了科研训练。