plan_250917~250930

发表于 2025-09-17

9.17—9.30

主要的学习关注点：

CKKS-OPENMINED 9.17
唐师兄推荐的论文阅读 9.18/19
Dpad-HE论文以及代码阅读 9.20——23
PPT制作
准备博士英语免修

if otherwise

观看NVIDIA讲座，知乎文章，官方文档，github实现等。
公众号，X等。

CKKS学习笔记

发表于 2025-09-05

我最近需要学习CKKS，我之前看过openmined的教程，当时看懂了，但过去了一个月，我就几乎忘得差不多了，我认为必须要自己手动进行代码实现才能加深理解，同时，师兄也推荐我去阅读CKKS的原论文

CKKS 同态加密学习路径（三层次法）

学习 CKKS 不必一次吃透。结合“框架 → 实践 → 理论”三步走，能有效打通从理解到实现的闭环。

一、建立高层框架（先见森林）

在读论文前，先掌握整体脉络，避免迷失细节：

核心目标：支持浮点/实数的近似同态加密（允许一定误差）
关键思想：
- 复数向量编码数据
- 多项式上进行同态加/乘
- 通过 rescaling 控制噪声与精度平衡
主要流程：
编码 → 加密 → 同态运算 → 解密 → 解码
核心挑战：
- 噪声增长 vs. 计算精度
- 乘法次数受限 → 需 rescaling + 模数链（modulus chain）

📌 推荐材料：OpenMined 教程、简明综述或课程笔记，快速唤醒记忆。

二、动手实验（代码驱动理解）

用现成库上手，让抽象概念落地：

✅ 使用库：SEAL / Lattigo / TenSEAL
🔬 实验内容：
- 跑通 CKKS 加法、乘法示例
- 观察：加法几乎无精度损失，乘法后需 rescale
- 手动封装完整流程：encode → encrypt → eval → decrypt → decode
- 记录误差来源（如 rescale 引入的舍入）
🧩 进阶：
- 复现 OpenMined 示例，边跑边注释
- 提问并尝试回答：“为什么这里要 rescale？” “乘法为何有限？”

💡 好处：再看论文时，公式=代码中的某一步，理解更直观。

三、精读原论文（带问题深入）

论文：Cheon et al., Homomorphic Encryption for Arithmetic of Approximate Numbers (2017)

分模块阅读，优先关注与代码对应的机制：

模块	学习重点
Introduction	对比 BGV/BFV，理解 CKKS 为何适合近似计算
Encoding/Decoding	复数向量如何编码实数向量？精度损失来源？
Homomorphic Ops	加法、乘法的数学形式，对应代码中的 `add` 和 `mul`
Rescaling & Modulus Switching	核心创新！为何要除 `q_i`？如何维持规模？
Security & Params	安全基于 RLWE；参数选择影响安全与性能

📘 阅读技巧：

带着实验中的疑问去读（如：“rescale 为什么必须降模？”）
公式看不懂？先找代码实现，反向理解
安全性证明等硬核部分可暂时跳过

四、巩固与提升

📝 写读书笔记：每部分用自己的话总结成“小白也能懂”的解释
🔍 多源对照：参考 Lattigo 文档、SEAL 示例等工程化资料
💬 自测能力：如果让我实现 CKKS，我能写哪部分？哪些依赖库？

✅ 可选：三周学习计划（实践导向）

周数	目标
第1周	熟悉 TenSEAL/SEAL，跑通编码、加/乘、rescaling 示例
第2周	对照论文，精读 Encoding、HomOp、Rescaling 部分，标注代码对应点
第3周	实现一个“极简版 CKKS”原型（仅支持编码+加密+加法）或写详细流程图解

这样三周下来，你不仅能读懂论文，还能讲清楚、写出来。

📌 结语：
CKKS 的难点不在单一知识点，而在数学、安全、工程的交叉理解。
坚持“先会用，再懂原理”，你会越学越通透。

好👌 我给你设计一个 3 周 CKKS 学习计划，目标是：

不只是看懂，还能动手实现，把论文和代码结合起来。
节奏循序渐进，避免“一次性啃死”。

📅 三周 CKKS 学习计划

第 1 周：重建框架 &动手实验

目标：重新建立 CKKS 的整体理解，用代码跑通基本流程。

Day 1-2
- 回顾 openmined 的 CKKS 教程，写总结：
  - CKKS 解决的问题
  - 编码/加密/解密流程
  - rescale 在哪里用到
- 输出 1 页笔记（可以画流程图）。
Day 3-4
- 用 TenSEAL 或 SEAL 跑几个 demo：
  - 加法、乘法、rescale
  - 对比误差来源
- 给每段代码加注释，写出你“理解”的解释。
Day 5-6
- 阅读 1 篇 CKKS 入门综述（比原论文轻量的资料）。
- 总结：CKKS 相比 BGV/BFV 的不同点。
Day 7
- 复盘一周：写一个“CKKS 小白笔记”，不超过两页。

第 2 周：论文精读（带问题读）

目标：啃原论文的核心部分，把公式和代码对照起来。

Day 1-2
- 精读原论文 Introduction + Background
- 写出论文想解决的痛点 & 为什么需要“近似”同态加密。
Day 3-4
- 精读 Encoding & Decoding 部分
- 在代码里跑 encode/decode，观察误差。
- 笔记：如何把实数/复数映射到多项式？
Day 5-6
- 精读 Homomorphic Addition & Multiplication
- 跑对应代码，验证 rescale 的作用。
Day 7
- 输出一份“代码-公式对照表”。

第 3 周：实现 &深化理解

目标：动手写简化实现，把 CKKS 的机制讲出来。

Day 1-2
- 尝试实现“玩具版 CKKS”：
  - 只做 encode → encrypt → decrypt → decode（用 Python/Numpy）
  - 暂时不管安全性。
Day 3-4
- 加入加法、乘法运算，手动实现 rescale（哪怕是简化版）。
Day 5
- 对照论文 Security 部分，理解为什么要选择那么大的参数。
- 可以查一下 Lattigo/SEAL 的参数推荐。
Day 6
- 写一篇“CKKS 学习笔记”：
  - 论文精华
  - 代码实验总结
  - 哪些地方还没弄懂（留下问题）。
Day 7
- 分享/讲解（假设要给别人讲 CKKS，你会怎么讲？）

✨ 最终成果：

3 周后你会有：
- 一份完整的 CKKS 学习笔记
- 一份“代码-公式对照表”
- 一个玩具版 CKKS 小实现
- 对原论文核心思路的理解

要不要我顺便帮你整理一些 论文 + 教程 + 库文档 的推荐阅读清单？这样你就不用自己到处找资料了。

hexo-next博客评论系统搭建

发表于 2025-08-25

综合调查后，对于next主题，gitalk是最简易部署且免费的评论系统。
大致流程如下：

1.安装：
npm install hexo-helper-live2d gitalk --save #看板娘是可选的（hexo-helper-live2d）

2.配置文件
在/themes/next/_config.yml中
首先配置comment部分：
comments:
  style: tabs
  active: gitalk
  storage: true
  lazyload: true
  nav:
    giscus:
      text: GitHub 评论
      order: -1

然后按照网页：
https://ericasun.github.io/2024/03/15/hexo/2024/Hexo添加评论系统gitalk/
中的方法配置配置Gitalk，注意，在第二步时只是用方法1即可，且proxy:无需配置。

上传博客方式

发表于 2025-08-25

发现使用https代理上传博客老出现网络TLS问题，咨询GPT后改用SSH进行上传。
步骤如下：

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa  #对应Ada密钥，提示词是ustc
ssh-add -l #检查是否通过
hexo new xxx  #开始写博客
hexo clean && hexo g && hexo d #上传

20250818

发表于 2025-08-18

今天中午睡到了1点，吃完早饭就去工位了，大约是2点半到工位。
现在时间是晚上9点，中途没休息或者吃饭，做了些什么呢？

修改学长的大论文，添加及修正了2/3phase的内容，添加了实验表格数据。
编写纵横论坛新闻稿
实现了kyber中keygen阶段的外积矩阵向量乘法，但mont约简没适配，还需修改
似乎能够使用openvpn连接服务器了？

我发觉用在写代码的时间（时间3）上绝对没有超过两小时，那么剩下的5小时去哪里了呢？
我不理解，总是在做一些低效且不知所云的事情。

明天计划：

彻底回顾Montgomery约简，修正keygen中的算法流程，分析MMV中为什么会有：

1
2
3

 int16_t tmp = Mont_Rdc_Dev(tmp_sum[ind]);
tmp = Mont_Rdc_Dev(tmp*MONT_SQUARE);
out_t[KYBER_N*i + ind] = Barrt_Rdc_Dev(tmp);

测试调研一下约简和普通实现的性能差距？
尽量早起，下午晚饭后下工

博客重生

发表于 2025-08-16 更新于 2025-08-25

2025-08-16 01:48:10 ，经过QWen的帮助，我现在可以继续使用此博客了。

但如何更好的管理还在探索中。

一下是保存的一些tips:

我记得我以前使用了hexo，可以通过写markdown进行编辑提交，但现在我找不到任何的.md文件

完全理解您的情况。您记得使用了 Hexo，并且是通过编辑 Markdown (.md) 文件来发布内容，但现在克隆下来的仓库里找不到这些文件，这确实会让人困惑。

这其实是一个非常常见且合理的现象，根本原因在于 GitHub Pages 的发布机制。

让我为您详细解释，并告诉您如何解决。

为什么找不到 `.md` 文件？

在使用 Hexo 这类静态网站生成器（Static Site Generator, SSG）时，您的项目通常包含两个部分：

源代码 (Source Code): 这是您进行创作和编辑的地方，包含：
- source/_posts/ 目录下的 .md 文件（您的博客文章）。
- 主题配置文件（_config.yml）。
- 草稿、页面等。
生成的静态文件 (Generated Static Files): 当您运行 hexo generate 命令时，Hexo 会读取 .md 文件，应用主题模板，将它们转换成纯 HTML、CSS 和 JavaScript 文件。

关键点在于，您部署到 GitHub Pages 的，是“生成的静态文件”，而不是“源代码”。

main / master 分支: 这个分支通常只包含生成后的 index.html, css/, js/, images/ 等文件。GitHub Pages 会直接从这个分支发布网站。您现在克隆下来的就是这个分支，所以里面没有 .md 文件。
source 分支 (或 dev 分支): 这是一个非常常见的最佳实践。开发者会创建一个单独的分支来存放 Hexo 的源代码（包括所有 .md 文件）。当需要更新网站时，他们会：
1. 在 source 分支上写 .md 文件。
2. 运行 hexo generate 生成新的静态文件。
3. 将生成的文件复制或部署到 main 分支（或使用 hexo deploy 命令自动完成）。

结论：您的 .md 文件很可能在一个名为 source、dev 或 hexo-source 的独立分支上，而不在您现在看到的 main 分支里。

如何找回您的 `.md` 文件？

请按照以下步骤操作：

第一步：检查是否有 `source` 分支

打开您的浏览器，进入您 GitHub 仓库的主页（例如 https://github.com/你的用户名/你的用户名.github.io）。
在仓库文件列表的左上角，您会看到一个下拉菜单，显示当前的分支名（很可能是 main 或 master）。
点击这个下拉菜单。
在搜索框中输入 source。
如果存在一个名为 source、dev 或类似名称的分支，请点击它。
浏览这个分支的文件结构。您应该能看到 source/_posts/ 目录，您的所有 .md 文件就在这里！

第二步：如果找到了 `source` 分支

在新电脑上克隆 source 分支:
- 在 source 分支的页面上，点击绿色的 Code 按钮。
- 复制仓库的 URL。
- 打开终端，先删除之前克隆的 main 分支仓库（或者换一个文件夹）。
- 执行克隆命令，并指定 source 分支：
  1
  git clone -b source https://github.com/你的用户名/你的用户名.github.io.git
- 这样，您克隆下来的就直接是包含 .md 文件的源代码仓库了。
安装 Hexo 环境:
- 您需要在新电脑上重新安装 Node.js 和 Hexo CLI。
- 在终端中进入您克隆的 source 仓库目录：
  1
  cd 你的用户名.github.io
- 安装项目依赖：
  1
  npm install
- 安装 Hexo 命令行工具（如果尚未安装）：
  1
  npm install -g hexo-cli
开始维护:
- 现在，您可以像以前一样，在 source/_posts/ 目录下创建和编辑 .md 文件。
- 预览：运行 hexo server，然后在浏览器访问 http://localhost:4000。
- 发布：完成修改后，运行以下命令来生成并部署：
  1
  2
  3
  hexo clean # 清理缓存
  hexo generate # 生成静态文件
  hexo deploy # 部署到 main 分支 (这一步会自动将生成的文件推送到 main 分支)

第三步：如果没找到 `source` 分支

这说明您可能没有使用分支分离的策略，而是直接在 main 分支上进行操作，但这非常不推荐，因为会把源代码和生成文件混在一起。

检查本地是否有旧文件:
- 回想一下，您是否在旧电脑的某个文件夹里直接运行 hexo init 创建了项目？如果那个旧电脑还能用，去那个文件夹里找找看。
重新开始:
- 如果确认 .md 文件已经丢失，您需要重新开始。
- 保留您克隆下来的 main 分支仓库作为您的“发布目录”。
- 在另一个文件夹里，重新初始化一个 Hexo 项目：
  1
  2
  3
  hexo init my-blog
  cd my-blog
  npm install
- 将您 main 分支里的 CNAME 文件（如果有的话）复制到新项目的根目录。
- 配置 _config.yml 中的 deploy 部分，确保它指向您的 your-username.github.io 仓库。
- 之后，您就可以开始用 Markdown 写新文章了。

总结

您找不到 .md 文件，几乎可以肯定是它们在一个独立的 source 分支上。请立即去 GitHub 仓库页面检查分支列表。一旦找到并克隆了 source 分支，您就可以在新电脑上恢复完整的 Hexo 工作流，继续通过写 Markdown 来维护您的网站了。

只有main分支

好的，收到您的反馈。如果您的 GitHub 仓库中只有 main 分支，并且里面只有生成的 HTML、CSS、JS 等静态文件，而没有 Hexo 的源代码（如 _config.yml, source/_posts/ 目录和 .md 文件），那么您的原始源代码确实已经丢失了。

不过，别担心，您仍然可以在新电脑上恢复对网站的维护。我们无法找回旧的 .md 文件，但可以重建一个全新的 Hexo 工作环境，并将其连接到您现有的 GitHub 仓库。这样，您就可以重新开始用 Markdown 写文章了。

以下是详细的恢复步骤：

第一步：在新电脑上安装必要工具

安装 Git
- 访问 https://git-scm.com/ 下载并安装 Git。
- 安装后，打开终端（Terminal）或命令行，输入 git --version，确认安装成功。
安装 Node.js
- Hexo 是基于 Node.js 的框架。访问 https://nodejs.org/ 下载并安装 LTS（长期支持）版本的 Node.js。
- 安装后，在终端输入 node --version 和 npm --version，如果能显示版本号，说明安装成功。
安装 Hexo CLI
- 在终端中运行以下命令来全局安装 Hexo 命令行工具：
  1
  npm install -g hexo-cli

第二步：克隆您的 GitHub 仓库作为“发布目录”

这个仓库（your-username.github.io）将专门用于存放生成的静态文件，由 GitHub Pages 直接发布。

在终端中，导航到您希望存放代码的文件夹，例如：
1
cd ~/Documents/MyProjects
克隆您的 GitHub Pages 仓库：
1
git clone https://github.com/你的用户名/你的用户名.github.io.git
- 这个文件夹现在就是您的“发布目录”。

第三步：创建新的 Hexo 源代码项目

现在，您需要创建一个新的 Hexo 项目，这个项目将包含您的所有 .md 文件和配置。

在一个与“发布目录”不同的位置创建一个新的文件夹，例如：
1
2
mkdir hexo-source
cd hexo-source
初始化一个新的 Hexo 项目：
1
2
hexo init
npm install
- 这会在当前文件夹下创建完整的 Hexo 源代码结构，包括 source/_posts/ 目录。
（重要）配置 _config.yml
- 用文本编辑器打开 hexo-source 文件夹里的 _config.yml 文件。
- 找到 deploy 部分，将其配置为指向您第一步中克隆的“发布目录”。配置如下：
  1
  2
  3
  4
  deploy:
  type: git
  repo: https://github.com/你的用户名/你的用户名.github.io.git
  branch: main
- 关键点：这里的 repo 地址必须是您 your-username.github.io 仓库的 HTTPS 地址。

第四步：建立两个目录的连接

为了让 Hexo 知道应该把生成的文件部署到哪个文件夹，我们需要进行一个巧妙的设置。

进入“发布目录”：
1
cd ../your-username.github.io
初始化一个临时的 Git 仓库（如果还没有的话）：
1
git init
将“发布目录”设置为“源代码目录”的“部署仓库”：
- 回到“源代码目录”：
  1
  cd ../hexo-source
- 运行以下命令，将“发布目录”的路径添加为一个远程仓库，命名为 deploy：
  1
  git remote add deploy ../your-username.github.io
- 这个命令告诉 Git：当我说 git push deploy 时，实际上是把文件推送到 ../your-username.github.io 这个本地文件夹。

第五步：测试并开始维护

现在，一切都设置好了。让我们来测试一下流程。

写一篇新文章：
在 hexo-source 文件夹中运行：
1
hexo new "我的第一篇新文章"
这会在 source/_posts/ 目录下创建一个名为 我的第一篇新文章.md 的文件。
编辑文章：
用编辑器打开这个 .md 文件，写一些内容。
生成并部署：
运行以下命令：
1
2
3
hexo clean
hexo generate
hexo deploy
- hexo generate 会将您的 .md 文件生成 HTML、CSS 等静态文件。
- hexo deploy 会将这些生成的文件推送到 deploy 远程仓库，也就是我们设置的 ../your-username.github.io 文件夹。
推送更新到 GitHub：
- 进入“发布目录”：
  1
  cd ../your-username.github.io
- 检查状态：
  1
  git status
  您会看到有新的文件被添加。
- 提交并推送到 GitHub：
  1
  2
  3
  git add .
  git commit -m "发布新文章：我的第一篇新文章"
  git push origin main
查看结果：
几分钟后，访问 https://你的用户名.github.io，您应该就能看到新发布的内容了。

总结

通过以上步骤，您已经成功地在新电脑上重建了一个完整的、可维护的 Hexo 工作流。虽然您丢失了旧的 .md 文件，但您获得了一个更清晰的项目结构：

hexo-source 文件夹：存放您的所有源代码和 .md 文件（这是您日常工作的目录）。
your-username.github.io 文件夹：存放生成的静态文件，专门用于 GitHub Pages 发布。

从现在起，您只需要在 hexo-source 目录下写 Markdown，然后运行 hexo deploy 和 git push，就可以轻松地维护您的网站了。

总之，我以后我只需要在hexo new 文件后使用
hexo clean
hexo generate
hexo deploy就行了

Hello World

发表于 1970-01-01 更新于 2025-08-16

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

Quick Start

Create a new post

1	$ hexo new "My New Post"

More info: Writing

Run server

1	$ hexo server

More info: Server

Generate static files

1	$ hexo generate

More info: Generating

Deploy to remote sites

1	$ hexo deploy

More info: Deployment