Zhuang's Diary

DeepSeek-R1的实施步骤

DeepSeek-R1本身就是开源的，HuggingFace Open R1 项目 ， 李飞飞团队s1项目 ， simpleRL-reason 在部分复现DeepSeek R1，还有 TinyZero 项目在复现DeepSeek R1-Zero，又是为何？
根据 DeepSeek-R1 的技术报告，分3个步骤完成这个项目：

• 第1步：用 DeepSeek-R1 蒸馏高质量语料库，来复制R1-Distill模型。
• 第2步：复制 DeepSeek (V3) 用来构建R1-Zero的纯强化学习（RL）pipeline。这可能涉及为数学、推理和代码整理新的大规模数据集。
• 第3步：通过多阶段训练，从基础模型过渡到RL版本。

结合DeepSeek的官方技术报告来看，也就是说，Open R1项目首先要实现的，是用R1数据蒸馏小模型，看看效果是不是像DeepSeek说的那么好：

DeepSeek-R1的实施效果

DeepSeek开源了6个用R1蒸馏的小模型，其中蒸馏版Qwen-1.5甚至能在部分任务上超过GPT-4o。

接下来，就是按照DeepSeek所说，不用SFT，单纯依靠RL调教出R1-Zero，在R1-Zero的基础上复刻出性能逼近o1的R1模型。

其中R1技术报告讲到，DeepSeek-R1训练过程中引入了一个多阶段训练流程，具体包括以下4个阶段：

1. 冷启动
   用数千个长思维链（CoT）样本对基础模型进行监督微调（SFT），为模型提供初始的推理能力。
2. 面向推理的强化学习
   在第一个SFT阶段的基础之上，用和训练R1-Zero相同的大规模强化学习方法，进一步提升模型的推理能力，特别是应对编程、数学、科学和逻辑推理任务的能力。
3. 拒绝采样的监督微调
   再次使用监督微调（SFT），提升模型的非推理能力，如事实知识、对话能力等。
4. 针对所有场景的强化学习
   这次强化学习的重点是让模型行为与人类偏好保持一致，提升模型的可用性和安全性。

Open R1做了什么？

目前，在open-r1 GitHub仓库中，已经可以看到这几个文件：

• GRPO（Grouped Relative Policy Optimization）实现，grpo.py: trains a model with GRPO on a given dataset.
  在 Open R1 发布后，GRPO已整合至TRL最新版本（v0.14，Jan 30, 2025）。该整合方案支持使用单个或多个奖励函数模型进行模型训练。GRPO 实现方案深度集成了 DeepSpeed ZeRO 1/2/3 分布式训练框架以实现多 GPU 扩展，并采用 vLLM 加速生成过程——这正是在线训练方法的主要性能瓶颈。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

from datasets import load_dataset
from trl import GRPOConfig, GRPOTrainer

dataset = load_dataset("trl-lib/tldr", split="train")

# Dummy reward: rewards completions that are close to 20 characters
def reward_len(completions, **kwargs):
    return [-abs(20 - len(completion)) for completion in completions]

training_args = GRPOConfig(output_dir="Qwen2-0.5B-GRPO", logging_steps=10)
trainer = GRPOTrainer(
    model="Qwen/Qwen2-0.5B-Instruct",
    reward_funcs=reward_len,
    args=training_args,
    train_dataset=dataset,
)
trainer.train()
# (Feb 2nd)仍存在显存占用过高的问题，我们正在通过性能剖析进行优化改进。

• 合成数据生成器，generate.py: generates synthetic data from a model using Distilabel.
  R1 技术报告中最引人注目的发现之一是：主模型可用于生成合成推理轨迹，而基于该数据集微调的较小模型可获得与主模型相近的性能提升。因此Open R1自然希望复现该合成推理数据集，使社区能够在其他模型上进行微调实验。
  面对 R1 这类超大模型，核心挑战在于高效扩展生成规模。Open R1花费一周时间尝试了多种配置方案：该模型可部署在 2 个 8xH100 节点（16 块 H100 GPU）上，我们最初基于此配置使用 vLLM 作为推理服务器。但很快发现该方案存在性能瓶颈：由于 GPU 的 KV 缓存快速耗尽，吞吐量未达最优且仅支持 8 路并行请求。当缓存耗尽时，占用大量缓存资源的请求会被抢占；若配置为PreemptionMode.RECOMPUTE模式，这些请求将在显存释放后重新调度。为此我们切换至 4x8xH100 节点配置（共 32 块 H100 GPU）。该方案为 32 路并行请求提供了充足的显存余量，基本避免了因 100% 缓存占用导致的请求重新调度问题。初始阶段我们采用批量请求查询 vLLM 服务器，但很快发现批次中的长尾样本会导致GPU利用率波动——新批次需等待前一批次最后一个样本完成后才能开始处理。将批量推理切换为流式处理后，GPU利用率显著稳定。

该优化仅需修改vLLM服务器的请求发送代码。批量推理代码如下：

1
2
3
4
5
6
7
8

# send requests in batches of 500
for batch in batch_generator(dataset, bs=500):
    active_tasks = []
    for row in batch:
        task = asyncio.create_task(send_requests(row))
        active_tasks.add(task)
    if active_tasks:
        await asyncio.gather(*active_tasks)

流式请求的新版代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

active_tasks = []
for row in dataset:
    # keep the total active requests under 500
    while len(active_tasks) >= 500:
        done, active_tasks = await asyncio.wait(
            active_tasks,
            return_when=asyncio.FIRST_COMPLETED
        )

    task = asyncio.create_task(send_requests(row))
    active_tasks.add(task)

# wait for all remaining tasks to complete
if active_tasks:
    await asyncio.gather(*active_tasks)
    # Open R1当前的生成速率已趋于稳定，但对于长查询被抢占时是否采用CPU 缓存策略仍需进一步探索。

• 实施监督微调训练代码，sft.py: performs a simple SFT of a model on a dataset.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# Train via command line
accelerate launch --config_file=recipes/accelerate_configs/zero3.yaml src/open_r1/sft.py \
    --model_name_or_path Qwen/Qwen2.5-1.5B-Instruct \
    --dataset_name HuggingFaceH4/Bespoke-Stratos-17k \
    --learning_rate 2.0e-5 \
    --num_train_epochs 1 \
    --packing \
    --max_seq_length 4096 \
    --per_device_train_batch_size 2 \
    --gradient_accumulation_steps 8 \
    --gradient_checkpointing \
    --bf16 \
    --output_dir data/Qwen2.5-1.5B-Open-R1-Distill

# Train via YAML config
accelerate launch --config_file recipes/accelerate_configs/zero3.yaml src/openr1/sft.py \
    recipes/Qwen/Qwen2.5-1.5B-Instruct/sft/config_demo.yaml

• 训练和评估代码，evaluate.py: evaluates a model on the R1 benchmarks.

数据集

社区在多个与R1相关的数据集项目上非常活跃，以下是一些亮点：

• bespokelabs/Bespoke-Stratos-17k：这是对 Berkeley Sky-T1 数据管线的复制，使用 DeepSeek-R1 创建一个包含问题、推理轨迹和答案的数据集。随后，这些数据被用于通过类似于 R1 论文中的蒸馏方法，微调 7B 和 32B 的 Qwen 模型。
• open-thoughts/OpenThoughts-114k：一个“开放的合成推理数据集，包含 114k 个高质量样本，涵盖数学、科学、代码和谜题”。这是 Open Thoughts 项目的一部分。
• cognitivecomputations/dolphin-r1：一个包含 80 万样本的数据集，样本来自 DeepSeek-R1、Gemini flash 以及来自 DolphinChat 的 20 万样本，目的是帮助训练 R1 风格的模型。
• ServiceNow-AI/R1-Distill-SFT：目前有 17,000 个样本，这是 ServiceNow 语言模型实验室为支持 Open-R1 工作而创建的数据集。
• NovaSky-AI/Sky-T1_data_17k：用于训练 Sky-T1-32B-Preview 的 17k 训练数据。最终数据包含来自 APPs 和 TACO 的 5k 编码数据，以及来自 NuminaMATH 数据集的 AIME、MATH 和 Olympiads 子集的 10k 数学数据。此外，我们还维护了来自 STILL-2 的 1k 科学和拼图数据。使用该数据集训练的模型成本不到 450 美元。
• Magpie-Align/Magpie-Reasoning-V2-250K-CoT-Deepseek-R1-Llama-70B：这个数据集扩展了 Magpie 和方法，通过生成没有起始提示的指令数据来包括推理过程。指令由 Llama 3.1 70B Instruct 和 Llama 3.3 70B Instruct 生成，响应则由 DeepSeek-R1-Distill-Llama-70B 生成。

总结

1. SFT后，进步显著，怎么做到的？
   一是微调用的训练数据起到了一定作用；二是强制让模型延长思考时间（test time scaling），具体做法叫做（Budget Forcing）预算强制，也就是强制限制模型使用最大或最小 tokens 进行推理，以此控制模型的思考长度。
   为了尽可能延长模型的思考，他们将模型的思考放在标签内，当结束后，以 final answer 给出答案，同时，当 LLM 即将停止思考时，会强制输出 Wait 来迫使模型继续思考，通过这样的方式，模型会进入反思，并可能会发现自己的错误。
   推理时插入的“Wait”，也许会像当初的 Step by Step 一样，成为一个魔法 token。“这或许就是古人‘三思而后行’的哲学吧！”
2. R1 训练的步骤总结：
   1）精心选择若干条（如 8000 条）高质量的数据，
   2）通过让 Gemini/DeepSeek V3 补充完善思维链COT之后作为数据集，
   3）以开源的大模型（如 Qwen2.5-32B，Llama 3.1）为基座微调出结果(如 R1)。
   4）最后，在模型输出时，用（Budget Forcing）预算强制方法强行拉长模型的思考时长和输出 token，结果发现其在特定测试集上进步显著。

一、关于DeepSeek公司及其大模型

1.1 公司概况

DeepSeek 2023年7月成立于杭州，是幻方量化旗下的子公司，全称是杭州深度求索人工智能基础技术研究有限公司。”成立时间才一年多”、”最近推出的V3已经能和OpenAI的4o媲美”、”训练成本不到600W美元”、”API定价仅是国内其他头部厂商几十分之一”、”APP已经在中美APP store登上免费应用榜首”；

以上是最近关于DeepSeek的一些新闻热点信息，下面我们从官网看下：
DeepSeek近半年相继推出了3个主要的大模型版本，分别是DeepSeek V2.5、DeepSeek V3、DeepSeek-R1（无一例外的都是用了MOE架构）。在这之前还推出了DeepSeek-VL、DeepSeek Coder、DeepSeek Math。

1.2 模型能力

DeepSeek模型已经对标国内Qwen、海外Llama、GPT 4o，从公布的榜单评测上看：DeepSeek-V3 在开源模型中位列榜首，与世界上最先进的闭源模型不分伯仲。

1.3训推成本

推理成本(API报价)：百万Token输入价格能达到1元。

训练成本：从技术报告中看DeepSeek用的是H800的GPU做的训练，而且只有2千张左右的H800，整个V3的正式训练成本不超过600W美元。

1、预训练阶段，每万亿的Token 训练V3使用 2048 个H800GPU集群，只需要 180K 个H800 GPU小时，大概 3.7 天(180000/2048/24)
2、整个预训练总耗时 2664K GPU小时（不到2个月），加上 上下文扩展和后训练，总耗时大概2788KGPU耗时。
3、按照 H800 每小时2美元租赁，总的训练成本不超过600W美元

这么低的推理和训练成本不由引出以下的问题：

• 模型采用了什么样的网络架构？
• 训练的精度、框架和并行策略是怎样的？
• 模型的部署和优化方案是怎样的？
• 在硬件层的计算和通信上做了什么优化？

二、DeepSeek训推核心技术

2.1 DeepSeek-V3模型网络架构

1) DeepSeekV3 整体预训练用了14.8万亿的高质量Token，2) 并且在后期做了SFT和RL，模型参数量达到 671B，但是每个Token仅激活37B参数。为了做到高效的推理和训练，3) DeepSeekV3自研了MLA注意力机制和无辅助损失负载均衡策略的MoE架构。

从技术报告中看出，是经典的Transformer架构，比较亮眼的就是前馈网络使用的DeepSeekMoE架构、Attention机制使用MLA架构，其实这两个在DeepSeekV2模型已经被验证使用过。
与DeepSeek-V2相比，V3额外引入了一种无辅助损失的负载均衡策略，用于DeepSeekMoE，以减轻因需要保证Expert负载均衡而导致的性能下降。

2.1.1 DeepSeekMoE

第一个将MoE架构引入Transformer网络的就是GShard架构了，与传统大模型架构相比，MoE架构在数据流转过程中集成了一个专家网络层。
可以看出传统的MoE基本两部分组成：Gating门控网络、稀疏MoE层；

• 稀疏 MoE 层: 这些层代替了传统 Transformer 模型中的前馈网络 (FFN) 层。MoE 层包含若干“专家”(例如 8 个)，每个专家本身是一个独立的神经网络。在实际应用中，这些专家通常是前馈网络 (FFN)，但它们也可以是更复杂的网络结构，甚至可以是 MoE 层本身，从而形成层级式的 MoE 结构。
• 门控网络或路由: 这个部分用于决定哪些Token被发送到哪个专家。Token的路由方式是 MoE 使用中的一个关键点，因为路由器由学习的参数组成，并且与网络的其他部分一同进行预训练。

和传统的MoE架构相比，DeepSeekMoE使用更细粒度的专家，并将一些专家隔离为共享专家，减少专家间的知识冗余。


门控网络路由策略：TopK表示第t个Token和所有路由专家计算出的亲和力分数中K个最高分数的集合，在DeepSeekV3中，使用sigmoid函数计算亲和力分数，然后在所有选择的亲和力分数中应用归一化来生成门控值。
通常在MoE模型的训练过程中，不同专家因为路由策略的因素会导致接收的训练数据分布不均，比如所有的Token都被发送到只有少数几个受欢迎的专家，那么有些专家就可能没有被训练到。
业界通用的解决方案就是引入辅助损失，但是，有时候过大的辅助损失会损害模型性能。
为了在负载均衡和模型性能之间取得更好的平衡，DeepSeek开创了一种无辅助损失的负载均衡策略：为每个专家引入一个偏差项 bi，并将其添加到相应的亲和力分数 Si,t 中以确定top-K路由，具体来说：如果其对应的专家过载，我们将偏差项减少γ；如果其对应的专家负载不足，我们将偏差项增加γ，其中γ是一个称为偏差更新速度的超参数。

门控网络本质上就是一个softmax叠加一个分类网络，那么辅助loss往往就是添加一个惩罚项，对输出过大的 logits 进行惩罚，鼓励模型生成更加适度的 logits 值，防止模型生成过于极端的输出。

2.1.2 MLA 多头潜在注意力

大模型推理过程KV Cache机制一般是限制推理效率的一大瓶颈，而标准的Transformer 架构里面的MHA架构会产出非常多的KV Cache，为了减少对应的KV Cache业界实践过很多方案，例如PagedAttention、多查询注意力（MQA）和分组查询注意力（GQA），但是性能相比原生的MHA有一定差距。

DeepSeek-V2，提出一种创新的注意力机制：多头潜在注意力（MLA）。
相比MQA的KV共用和GQA的KV分组，MLA的核心是注意力键和值的低秩联合压缩，以减少推理过程中的键值(KV)缓存。相比MHA具有更好的性能，但需要的 KV 缓存量要少得多。

低秩矩阵是指其秩（rank）远小于其行数和列数的矩阵。
假设我们有一个矩阵，其实际结构允许它被分解为两个较小的矩阵的乘积。这种情况通常意味着原矩阵是低秩的。
假设我们有一个4×5的矩阵A，这个矩阵可以通过两个更小的矩阵的乘积来表示，比如一个4×2的矩阵B和一个2×5的矩阵C。这意味着原始矩阵A的信息可以通过这两个较小的矩阵来捕捉，表明A是一个低秩矩阵。

低秩压缩计算核心过程：

这里的 ht 表示第 t 个Token的输入，WDKV 表示KV的向下投影矩阵，将 ht 做降维压缩表示，实际得到 cKVt 就是要缓存的KV压缩隐向量；WUK和WUV是向上做升维的投影矩阵，将Token的压缩隐向量cKVt复原为原始KV矩阵；
MLA 模块架构图如下：

2.2 训练推理核心技术

2.2.1 训练框架HAI-LLM

DeepSeek-V3在一个配备了2048个NVIDIA H800 GPU的集群上进行训练，使用的是自研的HAI-LLM框架，框架实现了四种并行训练方式：ZeRO 支持的数据并行、流水线并行、张量切片模型并行和序列并行。  
这种并行能力支持不同工作负载的需求，可以支持数万亿规模的超大模型并扩展到数千个 GPU，同时还自研了一些配套的高性能算子haiscale，可以帮助 HAI-LLM 极大优化大模型训练的显存效率和计算效率。

2.2.2 核心算法DualPipe-创新流水线并行算法

i.通信计算重叠优化
DeepSeek-V3应用了16路流水线并行（PP），跨越8个节点的64路专家并行（EP），以及ZeRO-1数据并行（DP）。
与现有的流水线并行方法相比，DualPipe的流水线气泡更少。同时重叠了前向和后向过程中的计算和通信阶段，解决了跨节点专家并行引入的沉重通信开销的挑战。
DualPipe的关键思想是重叠一对单独的前向和后向块中的计算和通信：将每个块划分为四个组件：注意力、all-all调度、MLP和all-all组合

例如，假设我们有两个计算块，A和B：
1.在块A进行前向传播计算时，可以同时进行块B的后向传播通信过程。
2.当块A完成前向传播计算后，开始它的通信过程；而块B则开始它的前向传播计算。

通过优化排列这些功能模块，并精确调控用于通信和计算的 GPU SM资源分配比例，系统能够在运行过程中有效隐藏全节点通信和 PP 通信开销。
可以看出DeepSeek在PP这块，做了大量的通信计算重叠优化，从技术报告中看出，即使是细粒度的all-all专家通信，all-all的通信开销几乎为0。



• 计算通信重叠
  在深度学习大规模分布式训练过程中，通信的速度往往落后于计算的速度，如何在通信的gap期间内并行做一些计算就是高性能计算和通信重叠，是实现高效训练的关键因素。
• 流水线并行气泡问题
  一些大的模型会采用流水线并行策略，将模型的不同层放在不同的GPU上，但是不同层之间有依赖关系，后面层需要等前面的计算完才能开始计算，会导致GPU在一段时间是闲置的，如下图所示：

ii.跨节点全对全通信
DeepSeek还专门定制了高效的跨节点all-all通信内核(包括调度和组合)。
具体来说：跨节点 GPU 通过 IB 完全互连，节点内通信通过 NVLink 处理，每个Token最多调度到 4个节点，从而减少 IB 通信量。同时使用warp专业化技术做调度和组合的优化。

在调度过程中，(1) IB 发送，(2) IB 到 NVLink 转发，以及 (3) NVLink 接收分别由各自的 warp 处理。分配给每个通信任务的 warp 数会根据所有 SM 上的实际工作负载动态调整。
在合并过程中，(1) NVLink 发送，(2) NVLink 到 IB 的转发和累积，以及 (3) IB 接收和累积也由动态调整的 warp 处理。

通过这种方式，IB 和 NVLink 的通信实现完全重叠，每个 token 能够在不产生 NVLink 额外开销的情况下，在每个节点上平均高效选择 3.2 个专家。这意味着，虽然 DeepSeek-V3 实际只选择 8 个路由专家，但它可以将这个数字扩展到最多 13 个专家（4 个节点 × 3.2 个专家/节点），同时保持相同的通信成本。

DSV3采用了1个共享专家和256个路由专家的MoE架构，每个token会激活8个路由专家。

2.2.3 用于FP8训练的混合精度框架

这里并没有将全量参数FP8量化训练，大多数计算密集型操作都在FP8中进行，而一些关键操作则战略性地保留其原始数据格式，以平衡训练效率和数值稳定性。

哪些算子启用FP8量化去计算？取舍逻辑是什么？

• 大多数核心计算过程，即 GEMM 运算，都以 FP8 精度实现
• 涉及对低精度计算的敏感性的算子，仍然需要更高的精度
• 一些低成本算子也可以使用更高的精度
  以下组件保留了原始精度（例如，BF16 或 FP32）：Embedding模块、输出头、MoE 门控模块、Normalization 算子以及 Attention 算子。

如何提高低精度训练精度？

• 细粒度量化

  对激活，在token维度采用group-wise的量化(1128)；对权重，采用128 128的block-wise量化

• 提高累加精度

  在 TensorCore 上执行矩阵 MMA（矩阵乘法累加）操作时，每当累加达到一个间隔时，这些部分结果会被传输到 CUDA Cores 上的 FP32 寄存器中，并在那里进行FP32 精度的累加计算。

2.2.4 MTP的训练目标

DeepSeekV3训练过程设置了多Token预测的目标，从技术报告的消融实验看出，确实提高了模型在大多数评估基准上的性能，而且MTP模块还可以用于推理加速。

2.2.5 推理部署方案

DeepSeek-V3 整体参数量达到了671B，如此多的参数量，我们看下他的一个部署方案：
推理部署采用了预填充(Prefilling)和解码(Decoding)分离的策略，确保了在线服务的高吞吐量和低延迟。通过冗余专家部署和动态路由策略，模型在推理时保持了高效的负载均衡。
整套部署方案下来基本是跨机分布式推理。

2.2.5.1 Prefill 阶段
这个阶段简单说就是并行处理用户的Prompt，将其转为KV Cache。

预填充阶段的最小部署单元由4个节点组成，每个节点配备32个GPU。注意力部分采用4路张量并行（TP4）和序列并行（SP），并结合8路数据并行（DP8）。其较小的TP规模（4路）限制了TP通信的开销。对于MoE部分，我们使用32路专家并行（EP32）

2.2.5.2 Decoder 阶段
这个阶段就是做自回归的每个Token的输出。

解码阶段的最小部署单元由40个节点和320个GPU组成。注意力部分采用TP4和SP，结合DP80，而MoE部分使用EP320。对于MoE部分，每个GPU只承载一个专家，64个GPU负责承载冗余专家和共享专家

总结：为什么DeepSeekV3训练成本这么低？

训练成本主要由模型架构以及训练架构所决定，而且两者一定是相辅相成。从报告中可以看出以下几个原因：
I.MLA 机制：通过对KV做联合低秩压缩大幅减少KV Cache，相比业界从KV数量角度做KV Cache的减少，MLA 的压缩实现很考验研究团队的基本功。
II.FP8 训练：通过低精度计算减少了 GPU 内存使用和计算开销，技术报告中也提到FP8混合精度训练框架是首次在一个极大规模的模型上验证了其有效性，这一点也看出DeepSeek的Infra工程团队的底蕴。
III.MoE 架构：通过MoE稀疏激活机制大幅减少了计算量，相比Qwen和Llama的Dense架构有很大的训推先天优势，不过难题(专家的负载、通信、路由)也给到了Infra工程团队。

三、为什么是DeepSeek？

在硅谷，类似DeepSeek这样的AI创新并不少有，只是这次是一家中国公司做出了这个动作，相比传统的‘美国创新、中国应用’的模式显得格外的让人兴奋。

从最近的一些访谈以及DeepSeek的技术报告中也能看出以下几点：
1、大模型是一个知识密集型产业，如何组织高密度人才？显然DeepSeek做到了。
2、大模型技术没有魔法，更多时候就是考验基本功和驱动力。
3、不以商业化为第一要义，很多时候能轻装上阵。

四、个人思考

1、长远来看，后续可能会有专门的适配Transformer架构的芯片，就像为卷积设计了ASIC芯片。
2、多Token预测、MoE架构可能很长一段时间都是大模型训推架构热门研究方向。
3、在国内做AI，应用始终会比基础研究有市场，更有话语权，但是基础创新和海外的代际差距会越来越小。
4、大模型训练和推理，软硬件是一个协同的生态，DeepSeek的出现将会促进AI全行业的更加快速且低成本的迭代。

参考资料

1、Better & Faster Large Language Models via Multi-token Prediction
4、DeepSeek-V3 Technical Report
5、DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model
6、deepseek v3的成本这么低的根本原因是什么？
7、GPipe: Easy Scaling with Micro-Batch Pipeline Parallelism 

CBDC商业需求的框架：

1. 货币属性与分层（Monetary Hierarchy）
   • 明确性增强：
   建议进一步明确CBDC与现有货币（如现钞、存款货币）在法律地位和功能上的边界，特别是CBDC与稳定币的关系，以防止市场混淆。
   • 计息机制补充：
   动态利率调控应细化适用场景，如是否适用于长期零利率环境或应对通缩危机。增加对“负利率”选项的讨论（如欧盟报告提及），并评估其可能对现金的替代效应和公众接受度的影响。

2. 合规与监管（Compliance & Regulation）
   • 隐私与监管平衡细化：
   • 对于“小额匿名交易”的标准可结合具体国情调整，比如中国试点采用的「可控匿名」方案，可以在技术上设置交易金额、频率的动态监控上限，而非固定金额阈值。
   • 增加数据最小化（Data Minimization）原则，以减少不必要的信息收集，从而增强用户隐私保护。
   • 制裁合规优化：
   建议进一步细化跨境交易黑名单机制的实现方式，是否支持智能合约自动筛查，同时预防潜在的技术误判和冤假错案。

3. 技术架构（Technical Infrastructure）
   • 混合账本的弹性：
   明确不同机构的技术分工，例如央行核心账本是采用传统集中式数据库，还是许可链。对于子账本的具体功能，可以进一步说明其扩展范围（如钱包、支付场景）以及与核心账本的交互机制。
   • 隐私保护技术：
   除零知识证明（ZKP）和同态加密外，可增加多方安全计算（MPC）的讨论，特别是对于跨境支付中的敏感数据分割与安全计算的适用性分析。
   • 可扩展性补充：
   万级TPS的标准可细化到压力测试指标，如峰值负载下的系统响应时间、区块生成时间和网络延迟等。

4. 支付系统互操作性（Interoperability）
   • 增强描述：
   增加CBDC在跨境支付场景中的“桥接角色”功能说明，例如mBridge、ICE项目的架构特点；明确自动外汇兑换的具体技术实现（是否基于去中心化市场或官方清算系统）。
   • 与商业银行系统的协同：
   明确CBDC是否会与商业银行账户体系直接交互，以及在支付链条中，如何避免资源争夺（如存款转移至CBDC后对商业银行的影响）。

5. 用户体验与普惠性（User-Centric Design）
   • 普惠性增强：
   • 硬件钱包的支持范围可进一步说明，如是否采用低成本芯片（例如安全芯片SE），以应对农村或偏远地区普及难题。
   • 对无智能手机用户的支持还可以讨论二维码与短信支付结合方案。
   • 双离线能力补充：
   增加离线交易后同步验证机制的技术细节（如通过时间戳或单次签名以防双花攻击）。

6. 货币政策传导（Monetary Policy Implementation）
   • 定向发放机制优化：
   明确技术实现，例如智能合约中的补贴精确传导机制，并讨论此类功能对社会福利政策的潜在影响（如精准扶贫）。
   • 数据采集分析透明性：
   增加对数据使用的透明化要求，例如统计数据是否匿名化处理以及其公开程度，以增强公众信任。

7. 法律与治理框架（Legal & Governance）
   • 治理多元化：
   增加外部监督机制，例如是否允许第三方审计机构对央行CBDC系统进行独立评估。
   • 国际合作机制：
   考虑到跨境支付需求，建议增加CBDC在国际治理框架中的角色说明，例如是否支持与IMF、BIS等国际组织协同制定技术标准。

8. CBDC参与方-央行，商业银行和金融中介等金融机构的权利，责任和义务。

9. 补充建议
   • 动态演进需求的细化：
   对智能合约的可编程性增加限制性条款，以避免复杂合约逻辑引发系统性风险。同时可支持模块化智能合约，便于后期升级或维护。
   • 技术中立性再明确：
   技术中立性框架下，可列举具体的“避免绑定特定技术”的实现方法，例如通过开放API接口或支持多种基础设施并行部署。

CBDC继续需求的框架：

核心目标：为公众和企业提供安全、可靠、高效、可普惠的数字支付手段，同时支持央行在货币政策、支付监管和金融创新中的核心职能。

1. 货币核心功能

1.1 法定地位与可兑换性
• 法定货币属性：确保CBDC具有与纸币等值的货币权威性（M0级别），直接体现央行负债。
• 兑换机制：支持与现钞、商业银行存款的无缝兑换，保障CBDC与现有货币体系平稳共存。
• 多面额与精确支付：允许最低单位交易（如0.01元），满足日常交易需求。

1.2 利息与价值管理
• 默认无息设计：CBDC保持与纸币一致的零利率，避免对银行存款造成挤压。
• 动态调节选项：在特殊经济场景下（如通缩或危机）允许设计利息方案，支持货币政策工具创新。

2. 用户与场景需求

2.1 便捷性与普惠性
• 广泛的终端支持：兼容智能手机、非智能手机（如USSD短信支付），以及硬件钱包（适用于无银行账户用户）。
• 离线支付能力：在网络中断时支持小额支付（如公交、零售场景），同步额度可灵活设置（如3天内最高500元）。
• 普适设计：提供多语言界面、语音辅助功能，并支持残障人士友好的交互方式（如盲文触觉反馈）。

2.2 交易隐私保护
• 分层隐私：
• 小额匿名交易：单笔<100美元时，避免用户身份被记录；
• 大额追溯交易：交易>1000美元时，需绑定实名身份以满足合规要求。
• 用户数据保护：限制不必要的用户数据采集，确保数据在监管无需要的情况下可在设定时间后销毁（如90天）。

3. 支付与互操作性

3.1 国内支付整合
• 支付系统对接：支持CBDC与现有实时全额结算系统（RTGS）和其他支付网络的互联互通，保障T+0清算能力。
• 银行与钱包融合：允许用户将CBDC钱包与银行账户快速绑定，实现账户资金的灵活转移与管理。

3.2 跨境支付功能
• 跨境支付便捷性：通过多边央行合作（如mBridge项目）实现跨境支付无缝结算，并提供实时汇率支持。
• 合规性保障：在跨境支付中，实时筛查国际制裁名单，确保不涉及高风险交易。

4. 监管与合规支持

4.1 反洗钱（AML）与反恐融资（CFT）
• 实时监控：提供可疑交易的实时预警和链上追踪功能，确保资金来源与用途透明。
• 自动报告：支持生成符合国际标准的资金流动报告（如FATF旅行规则），减少金融机构合规负担。

4.2 账户管理与司法协助
• 账户冻结功能：在司法授权情况下，允许央行冻结特定用户的CBDC账户。
• 资金追回：支持误转账资金的快速追踪和人工审批返还流程。

5. 货币政策与数据支持

5.1 流动性与脱媒管理
• 余额上限：允许设置用户钱包的持币上限，避免商业银行存款大规模流失。
• 定向发放能力：支持政府专项资金（如灾害补贴）精准下发到用户钱包，提高政策执行效率。

5.2 数据驱动的经济监测
• 实时监测：通过交易数据流动情况（如频率、金额、地域分布）支持央行货币政策分析与调整。
• 宏观经济评估：基于CBDC的实时数据反馈，优化货币流通结构，替代传统滞后的M0统计方法。

6. 安全与稳定性

6.1 抗风险能力
• 高安全性：采用先进加密算法保护交易信息，确保CBDC对网络攻击（如量子计算攻击）具有抗风险能力。
• 离线交易风控：离线支付额度和时间窗可动态调整，防止双花攻击及恶意使用。

6.2 系统容灾
• 多活备份：在不同地区部署容灾节点，确保系统在灾难情况下的持续运行。
• 快速恢复：所有用户交易记录可在网络恢复后10分钟内同步，保障支付体验连续性。

7. 智能合约与可编程货币

7.1 可编程场景
• 政府补贴发放：支持通过智能合约精确发放专项资金，确保资金流向符合政策目标。
• 绿色金融：支持碳积分兑换等创新应用，鼓励低碳消费行为。

7.2 合约管理与更新
• 部署权限：仅允许央行授权的机构发布智能合约，确保安全性与规范性。
• 动态升级：智能合约需支持紧急修复能力，避免代码漏洞引发系统性风险。

8. 附加说明

• 动态调整需求：针对不同试点国家的具体需求（如普惠金融优先级或隐私保护程度），设计需灵活调整。
• 技术中立性：选择适配性广的基础架构，避免过度依赖单一技术，保障未来系统升级的灵活性。

Below are the characteristics of different types of Bitcoin addresses:

1. P2PKH Address (Pay-to-PubKey-Hash):
   • Starts with the letter “1”.
   • Length is 26 to 35 characters.
2. P2SH Address (Pay-to-Script-Hash):
   • Starts with the letter “3”.
   • Length is 26 to 35 characters.
3. Bech32 Address (SegWit Address):
   • Starts with “bc1”.
   • Length is 42 to 62 characters.

另外，Thief on Solana

• CEzN7mqP9xoxn2HdyW6fjEJ73t7qaX9Rp2zyS6hb3iEu
• 5WwBYgQG6BdErM2nNNyUmQXfcUnB68b6kesxBywh1J3n

Scam on ETH

• 0x84eb60e6732848f837f48402dcfff25e3d3d9304

工具介绍

Burp 抓包，改包工具， 基于java，运行，需要JRE
需要搭梯子才能登录其网站主页，美国公司，商业软件，年费399年费，有社区开源版本

Burp未启动时，网络的路由环境
本地（浏览器） — 服务器
Burp启动后，网络的路由环境
本地（浏览器 — Burp） — 服务器
Burp extensions — https://github.com/snoopysecurity/awesome-burp-extensions

DVWA靶场，里面是各种漏洞攻击的介绍和说明，是一个入门的联系资源，英文资源。

Pikachu 漏洞练习平台，同理，中文资源。

https://www.kali.org/ , 一个Linux发行版本，是专门针对各种信息安全任务或者练习而准备的。

前端一切不可靠，如上Burp在客户端做网络流量拦截，做中间人攻击

对应的措施：
1.后端校验；2.前端不做逻辑判断；3.前端加密混淆；4.移动端加壳；5.反调试检测，防止逆向工程; 6.后台数据库存储字段最好经过KMS后端密文，常见的服务器本地算法 — hash(明文+盐值)
通常，www.website.com/robots.txt，如 https://www.bilibili.com/robots.txt ，很多网站都有这样子一个网站URL的列表，表示本网站允许访问的URL。

Burp 启动浏览器，在网站的http://burp/地址，
在网页右上角点击CA Certificate 下载Burp颁发的证书。

Burp暴力破解，尝试用户名和密码时，可以使用“Repeater”和“Intruder”两个菜单的功能。
通常登录成功后，response 的长度会有不同。

暴力破解的本质是 自动化，大量发送请求，猜测密码。
应对方法：
1.要求用户密码设置的复杂度；
2.识别爬虫/机器人：验证码，滑块，随机验证码；
3.限制登录频率：每次登录n秒以上方可，错误m次后冻结该用户x分钟，这样会带来问题：
A.前端限制，通过重置本地数据可以绕过；
B.IP地址限制，可能会误封正常用户，攻击者租用地址池拥有大量IP。
C.账号限制，会造成正常用户无法登录，恶意攻击者可以制造拒绝服务攻击。
4.增加密码强度，特别是增加密码长度是最有效的强度。
A.密码一户一用，避免一个密码到处使用，避免撞库攻击。
密码的本质是进行身份验证的手段。
密码的应用场景是基于以下假设：只有用户和服务器知道该密码
其他方式验证身份：短信验证码，指纹，面部识别，USBKEY，2FA，多因子验证等等。

社会工程

黑客通过社会工程学（Social Engineering）实现攻击的手法多种多样，主要是利用人类的心理弱点和信任机制来获取信息或访问权限。
钓鱼攻击，尾随攻击，假冒身份，电话攻击，非技术性攻击，社交媒体欺骗，媒体投影攻击，关系建立攻击等等。

OWASP — Open Web Application Security Project

OWASP Top 10 提供了Web 安全领域发生最频繁的10种事故。最新版本是 2021 年发布的 — https://owasp.org/Top10/zh_CN/

WebShell - 以网页形式实现shell的功能，能够对系统进行操作。例如，文件读写，命令执行等。也被称为网页木马。
首先，网站如果对用户上传的文件，不做控制，黑客则有可能会上传木马文件，黑客通过木马文件控制后台服务器，如下，
通过 https://github.com/AntSwordProject/ 工具可以执行网页木马。

执行木马 成功，成功访问到后端服务器的目录和文件。

仅仅依赖客户端 JavaScript 验证和服务器端 MIME 类型检查仍然不够安全，因为客户端验证很容易被绕过，而且 MIME 类型本身也可能被伪造，尽管概率较低。 为了构建一个更加严谨的文件上传系统，需要采取更全面的安全措施，将验证和安全检查融入整个上传流程的各个阶段。

一个更严谨的文件上传系统应该包含以下措施：

1. 客户端验证 (加强):
   文件类型检查 (加强): 虽然 file.type 相对可靠，但仍然不是绝对安全的。 可以考虑结合一些额外的检查：
   文件头部信息检查: 读取文件的前几个字节，检查是否符合已知的文件格式规范。 这需要对不同文件类型的头部结构有深入的了解。 但这仍然只能作为辅助手段，不能完全依赖。
   更严格的正则表达式: 使用更精确的正则表达式来验证文件名，但这仍然不能防止恶意文件伪装。
   文件大小限制: 设置一个合理的文件大小限制，并进行客户端验证。
   用户反馈: 提供清晰的用户反馈，告知用户文件上传失败的原因，例如文件类型不允许、文件大小超过限制等。
   禁止直接拖拽上传: 避免用户直接拖拽文件到上传区域，强制用户通过“选择文件”按钮选择文件，这样可以更好地控制文件上传过程。
2. 服务器端验证 (多层防御):
   文件类型检查 (多重验证): 不要仅仅依靠 MIME 类型，结合多种方法进行验证：
   文件签名: 检查文件的魔术数字 (magic number)，这是一种非常可靠的方法。 不同的文件格式通常有独特的魔术数字。
   文件内容分析: 对于一些关键的文件类型，可以进行更深入的内容分析，检查文件结构是否符合规范。 这需要根据具体的文件类型定制相应的分析方法。 这可能需要耗费较多资源。
   文件大小限制: 设置严格的文件大小限制，防止资源耗尽攻击(Denial of Service,DoS)。
   临时文件存储: 将上传的文件先保存到一个临时目录，然后再进行后续处理，这样可以避免恶意文件直接影响服务器。
   文件扩展名检查 (补充): 虽然不完全可靠，但作为附加的检查，可以辅助判断文件的类型。
   内容安全扫描 (关键): 使用专业的安全扫描工具，扫描上传的文件是否包含恶意代码、病毒或其他有害内容。 这可能是最关键的安全步骤，但会增加系统复杂性和成本。 一些云服务提供商提供此类服务。
   白名单机制: 只允许特定类型的文件上传。 尽量避免使用黑名单，因为黑名单很难完全覆盖所有的恶意文件类型。
   沙盒环境: 在沙盒环境中执行文件分析，以最大程度地限制恶意代码对服务器的影响。
   日志记录: 记录所有的文件上传事件，包括文件名、MIME 类型、文件大小、上传时间以及验证结果。 这有助于追踪和分析安全事件。
3. 其他安全措施:
   HTTPS: 使用 HTTPS 加密上传过程，防止数据被窃取。
   输入验证: 对所有用户输入进行严格的验证，防止注入攻击。
   代码安全审计: 定期对代码进行安全审计，查找和修复潜在的安全漏洞。
   服务端代码示例，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105

package main

import (
	"fmt"
	"io"
	"mime/multipart"
	"net/http"
	"os"
	"path/filepath"
	"regexp"
	"strings"

	"github.com/gabriel-vasile/mimetype" // 用于更准确的 MIME 类型检测
	"github.com/google/uuid"             // 用于生成唯一的文件名
)

// AllowedMimeTypes 定义允许上传的文件类型
var AllowedMimeTypes = map[string]bool{
	"image/jpeg": true,
	"image/png":  true,
	"image/gif":  true,
	// 添加其他允许的 MIME 类型
}

// MaxFileSize 定义允许上传的最大文件大小 (字节)
const MaxFileSize = 10 * 1024 * 1024 // 10MB

// uploadHandler 处理文件上传请求
func uploadHandler(w http.ResponseWriter, r *http.Request) {
	if r.Method != http.MethodPost {
		http.Error(w, "Method Not Allowed", http.StatusMethodNotAllowed)
		return
	}

	file, handler, err := r.FormFile("file") // 假设表单字段名为 "file"
	if err != nil {
		http.Error(w, err.Error(), http.StatusBadRequest)
		return
	}
	defer file.Close()

	// 客户端验证 (加强)
	fileName := handler.Filename
	if !isValidFileName(fileName) { // 检查文件名是否合法
		http.Error(w, "Invalid file name", http.StatusBadRequest)
		return
	}

	fileSize := handler.Size
	if fileSize > MaxFileSize {
		http.Error(w, "File too large", http.StatusRequestEntityTooLarge)
		return
	}

	// 服务器端验证 (多层防御)
	detectedMimeType, err := mimetype.DetectReader(file)
	if err != nil {
		http.Error(w, "Failed to detect MIME type", http.StatusInternalServerError)
		return
	}

	if !AllowedMimeTypes[detectedMimeType.String()] {
		http.Error(w, "Invalid file type", http.StatusBadRequest)
		return
	}

	// 使用 UUID 生成唯一的文件名，避免文件名冲突
	newFileName := uuid.New().String() + filepath.Ext(fileName)
	uploadPath := "./uploads/" + newFileName // 定义上传文件的存储路径

	// 创建上传目录，如果不存在
	os.MkdirAll("./uploads/", 0755)

	// 创建文件并保存
	newFile, err := os.Create(uploadPath)
	if err != nil {
		http.Error(w, err.Error(), http.StatusInternalServerError)
		return
	}
	defer newFile.Close()

	_, err = io.Copy(newFile, file)
	if err != nil {
		http.Error(w, err.Error(), http.StatusInternalServerError)
		return
	}

	//  此处添加更严格的安全检查，例如：
	//  1. 使用第三方库进行病毒扫描 (ClamAV, VirusTotal API 等)
	//  2. 更深入的文件内容分析，根据文件类型进行特定检查

	fmt.Fprintf(w, "File uploaded successfully: %s\n", newFileName)
}

// isValidFileName 检查文件名是否合法，防止目录遍历攻击等
func isValidFileName(fileName string) bool {
	re := regexp.MustCompile(`^[a-zA-Z0-9._-]+$`) // 只允许字母、数字、点、下划线和短横线
	return re.MatchString(fileName)
}

func main() {
	http.HandleFunc("/upload", uploadHandler)
	fmt.Println("Server listening on port 8080")
	http.ListenAndServe(":8080", nil)
}

AllowedMimeTypes: 定义了允许上传的文件类型，使用 map[string]bool 更易于管理。
MaxFileSize: 设置了最大文件大小限制。
mimetype 库: 使用了 github.com/gabriel-vasile/mimetype 库来更准确地检测 MIME 类型。 这比只依赖 handler.Header.Get(“Content-Type”) 更可靠。
UUID 生成文件名: 使用 UUID 生成唯一的文件名，避免文件名冲突和潜在的安全问题。
isValidFileName 函数: 对文件名进行简单的验证，防止目录遍历等攻击。 这只是一个基本的示例，实际应用中可能需要更复杂的验证规则。
临时文件存储 (缺失但建议): 为了更安全，应该先将文件保存到临时目录，验证通过后再移动到最终存储位置。
安全扫描 (缺失但必须): 代码中用注释标注了需要添加安全扫描的地方。 你需要集成一个专业的安全扫描库或服务 (例如 ClamAV, VirusTotal API 等) 来扫描上传的文件是否包含恶意代码。 这是至关重要的安全步骤。

Linux 系统排查

1.查看用户行为
/etc/passwd，/etc/shadow 中存储了account和密码信息，黑客可能会增加高权限用户在如上两个文件夹中
如 macOS 中，
➜  ~ sudo dscl . -list /Users | while read user; do sudo dscl . -read /Users/“$user” UserShell | grep -q ‘/bin/bash’ && echo $user; done
_mbsetupuser
postgres
➜  ~ last
Zzz  ttys000                         Tue Dec 10 14:05   still logged in
Zzz  ttys000                         Mon Dec  9 11:29 - 11:29  (00:00)
Zzz  ttys000                         Sat Dec  7 19:35 - 19:35  (00:00)
Zzz  console                         Tue Dec  3 14:51   still logged in
reboot time                                Tue Dec  3 14:50
还有，如查看用户的密码是否为空，用户执行过的命令，等等。
3.查看进程，例如，黑客通过服务器在挖矿等异常。lspf， top等命令。
更多可以查看 Linux 应急响应手册 — https://github.com/Just-Hack-For-Fun/Linux-INCIDENT-RESPONSE-COOKBOOK

威胁情报中心：

Windows 系统工具 - https://learn.microsoft.com/en-us/sysinternals/
腾讯威胁情报中心 - https://tix.qq.com/
可疑文件分析 - https://www.virustotal.com/gui/home/upload