CatCoding

程序员的喵

Obr: a Web UI for My Obsidian Vault

A few years ago I built a tiny personal tool called <a target="_blank" rel="noopener" href="https://github.com/chenyukang/obweb">Obweb</a>. Its purpose was dead simple: open a browser, type a quick thought, and append it to my Obsidian notes. Then one day the VPS was shutdown for some reasons, I need to redeploy it on another VPS and it involve some extra boring stuff, such as rebind a sub-domain and configing on VPS. I’m too lazy for this. Obweb slowly became unmaintained since it was developed in JavaScript when I tried to pick some frontend stuff, and I hate JavaScript, luckly, I don’t need to learn it since AI is good at frontend. I tried going back to the official Obsidian Android app one year ago, but it still felt too heavy for the thing I wanted most: fast capture. It takes too long to open, slow to respond, and I remember Termux is needed for some automatic tasks. I just don’t like it. I am clearly not the only one who feels this way, because I still randomly get emails from people asking about Obweb. Recently I read an article about <a target="_blank" rel="noopener" href="https://blog.ppb1701.com/self-hosting-vaultwarden-taking-back-password-management-part-8-of-building-a-resilient-home-serve">self-hosting Bitwarden with Tailscale</a>. That reminded me that Obweb was almost made for this style of deployment. It does not need to live on a VPS. It can just run on my local dev machine, reachable from my own devices, without a public-domain, a nginx or another server to babysit. So I rewrote it, in the vibe coding way. The new app is called <a target="_blank" rel="noopener" href="https://github.com/chenyukang/obr">Obr</a>. Obr is very much a tool shaped around my own workflow. But I think that is also what makes it worth writing about: small personal tools are often where the most honest product decisions happen. <hr /> The basic idea is straightforward. Obr puts a lightweight Web interface in front of an Obsidian vault, with search, capture, and editing for the parts I use most often. Its config points at a few vault-relative paths: <pre class="line-numbers language-toml" data-language="toml"><code class="language-toml">vault_path = "/path/to/obsidian/vault" daily_dir = "Daily" entry_dir = "Posts" image_dir = "Pics" todo_path = "Posts/todo.md" annotation_dir = "annotations" </code></pre> Daily notes go into <code>Daily/YYYY-MM-DD.md</code>, Images live under <code>Pics/</code>. RSS annotations are just Markdown files under <code>annotations/</code>. Obr does not try to invent a new storage model. It stays close to the vault. <h2 id="Capture-comes-first"><a href="#Capture-comes-first" class="headerlink" title="Capture comes first"></a>Capture comes first</h2> The original reason for Obr was capture. On my phone, I want to open a page, write a few lines, pick a path, optionally attach a link or image, and submit. The backend appends the content to the right Markdown file. A daily note goes into today’s file. A regular entry goes under the configured entry directory. A todo goes into the todo file. By the way, I have found Hermes is also good fit for this kind of thing with proper training. Image uploading is the one part that needs a little more care. Uploading through Tailscale is not always fast, and mobile networks are not exactly famous for being polite. So Obr has offline drafts and a sync outbox. If a request fails, the note should not disappear. It should sit locally and retry quietly in the background. That is the kind of feature that sounds boring until the first time it saves a paragraph you wrote on the subway. <img src="http://catcoding.me/images/ob_635f0d6d5fc60528afc8c5892738a70c.jpg" alt="" style="width:50%; height:auto;" /> <h2 id="Making-it-feel-less-like-a-Web-page"><a href="#Making-it-feel-less-like-a-Web-page" class="headerlink" title="Making it feel less like a Web page"></a>Making it feel less like a Web page</h2> I use Chrome’s “Add to Home screen” to put Obr on my phone as an app icon, and I allow it to keep running in the background. That alone makes the whole thing feel much closer to a small mobile app than a web page I occasionally visit. Under the hood, Obr uses a service worker and a manifest. The shell of the app, along with its CSS and JavaScript, can be cached locally. If the phone is offline, the app can still open, and recently viewed or edited content can often be restored from local cache. Anything that needs to write to the vault goes into the sync outbox when the network is down, then retries after the connection comes back. The UI also shows the real connection state. Obr pings the backend and updates the online/offline indicator based on actual requests. The tiny dot in the top-right corner is easy to ignore, but it answers the important question: did this reach my vault, or is it still waiting on this device. Images lazy-load so one article with several large screenshots does not clog the whole connection pool. Reading pages have a progress bar. The RSS detail page hides the top bar while scrolling. None of these are big features by themselves, but together they make the app feel much calmer on a phone. <h2 id="Editing-one-block-at-a-time"><a href="#Editing-one-block-at-a-time" class="headerlink" title="Editing one block at a time"></a>Editing one block at a time</h2> Obr can render Markdown as HTML, and it can also show the raw file content. But for mobile editing, I wanted something smaller than a full editor. Most of the time, I do not want to edit an entire article from my phone. I want to fix one sentence, delete one block, or check off one todo item. So Obr supports block-level editing. The backend splits a Markdown file into blocks, and the frontend can save or delete a single block without putting the whole document into a giant textarea. This matters more than it sounds. Long-form editing on a phone is fragile: the cursor jumps, the keyboard covers half the screen, and suddenly you are questioning your stupid choice on editing something on a phone. Block editing keeps the task small, I am not editing a document, I am editing this paragraph. <h2 id="RSS-inside-the-vault-workflow"><a href="#RSS-inside-the-vault-workflow" class="headerlink" title="RSS inside the vault workflow"></a>RSS inside the vault workflow</h2> Obweb had an RSS reader years ago, and I always missed it. Obr brings it back in a more complete form. When RSS is enabled, Obr reads feed subscriptions from a file in the vault: <pre class="line-numbers language-toml" data-language="toml"><code class="language-toml">rss_enabled = true rss_feeds_path = "Zero/feeds.md" rss_data_dir = "data/rss" rss_refresh_minutes = 30 rss_fetch_full_content = true </code></pre> RSS metadata and read state are stored in a local SQLite database. Article bodies are cached under <code>data/rss/content/</code>. If full-content fetching is enabled, Obr uses <code>rs-trafilatura</code> to extract the page body into Markdown. If extraction fails, it falls back to the feed content or summary. <img src="http://catcoding.me/images/ob_e321f0b192c0dc63bfc0c4e7d523b9b2.jpg" alt="" style="width:50%; height:auto;" /> The RSS detail page also supports annotations. When I find a paragraph worth keeping, I can write a note beside it, and Obr saves that note as Markdown under <code>annotations/</code>. <h2 id="AI-summaries-and-translation"><a href="#AI-summaries-and-translation" class="headerlink" title="AI summaries and translation"></a>AI summaries and translation</h2> Once RSS was local, adding AI summaries felt like the obvious next step. Obr can generate Chinese summaries for newly fetched non-Chinese articles. It supports DeepSeek-based summary translation, and it can also translate the full text. <pre class="line-numbers language-toml" data-language="toml"><code class="language-toml">rss_ai_summary_enabled = true rss_ai_summary_chars = 200 deepseek_api_key = "sk-..." deepseek_model = "deepseek-v4-flash" </code></pre><img src="http://catcoding.me/images/ob_pasted-image-20260622202701.png" alt="" style="width:50%; height:auto;" /> <h2 id="Security-has-to-be-part-of-the-design"><a href="#Security-has-to-be-part-of-the-design" class="headerlink" title="Security has to be part of the design"></a>Security has to be part of the design</h2> Obr can read and write my Obsidian vault, so security comes first. At the moment it supports: <ul> <li>Argon2 password hashing;</li> <li>WebAuthn / Passkey login;</li> <li>secure cookies when running over HTTPS;</li> <li>Host header validation;</li> <li><code>Origin</code> and <code>Sec-Fetch-Site</code> checks for cross-site write requests.</li> </ul> Obr’s <code>init --tailscale</code> command starts a separate userspace <code>tailscaled</code>, stores its state in <code>$HOME/.local/share/tailscale-obr</code>, and exposes the local <code>127.0.0.1:8010</code> service through a stable <code>*.ts.net</code> HTTPS address. Tailscale can make the app reachable only inside my private network, which feels much better than putting it directly on the public Internet. The downside is that I need the Tailscale client and VPN running on my phone, and that conflicts with the VPN I normally use daily. So I do not always run Obr this way. Tailscale handles the secure device-to-device tunnel; Obr still handles login and authorization. Passkeys are a good fit for that on mobile. <h2 id="A-few-implementation-notes"><a href="#A-few-implementation-notes" class="headerlink" title="A few implementation notes"></a>A few implementation notes</h2> The backend is Rust + Axum. The frontend is plain HTML, CSS, and JavaScript, no 3rd party frontend library, no npm. I hate npm. Right now the project has about 15 Rust files, around 14,000 lines under <code>src/</code> including test files, and 7 frontend asset files. Most of my Mac development still happens with codex/gpt5.5, but a lot of Obr was built with hermes. The workflow is strange in a good way: I notice something annoying while using the app, send a voice message to Hermes, wait a few minutes, and then double check it after the AI agent restarts the service automatically. That may be the most interesting part of the project for me. Obr was not designed in a big upfront pass. It was shaped while I was using it, one small irritation at a time.

2026/6/22

ghr：把开源维护工作搬进终端

五一期间我看到 dhh 发的一个帖子推荐 <a target="_blank" rel="noopener" href="https://x.com/dhh/status/2050105129085415576">GitHub TUI: ghui</a>，我安装试了一下，发现还需要安装 bun，另外功能看起来也不太够用。 我也看过 <a target="_blank" rel="noopener" href="https://www.gh-dash.dev/">gh-dash</a>，这东西是 gh 的一个 extension，我试了一下同样感觉体验不好，于是手痒开始让 AI 帮我用 Rust 重新写一个。 最近在工作中也写过一个 Rust 的 TUI 工具，感觉 Rust 的生态已经很成熟了，写起来也很顺手。于是就有了 <a target="_blank" rel="noopener" href="https://github.com/chenyukang/ghr">ghr</a> 这个项目。 它的目标一开始很简单：我想少在 GitHub 网页里来回点。作为一个经常看 PR、review 代码、处理 notification 的人，我每天会重复很多小动作：打开 inbox，看谁 @ 了我，扫一眼 assigned PR，点进 diff，读评论，偶尔 checkout 到本地验证一下。 这些动作单独看都不复杂，但它们很碎。浏览器适合处理一次性的探索，不太适合让我连续地做几十个维护动作。于是 <code>ghr</code> 慢慢变成了一个终端里的 GitHub 工作台。如果你喜欢 lazygit，那么应该也会喜欢 <code>ghr</code>，因为 lazygit 主要是针对 Git 相关的操作，而 <code>ghr</code> 主要是围绕 GitHub 上协作的 TUI，比如看 issue、comments、review 代码，merge PR 等等。我甚至想命名为 lazyhub，这样组合起来就是 GitHub 😅。 <img src="http://catcoding.me/images/ob_pasted-image-20260508001332.png" alt="" /> <h2 id="先让它打开就能用"><a href="#先让它打开就能用" class="headerlink" title="先让它打开就能用"></a>先让它打开就能用</h2> 我最早在意的不是功能有多少，而是启动体验。 如果每次打开 TUI 都要等 GitHub API 慢慢返回，那这个工具很快就会被我自己弃用。终端工具有个很残酷的标准：它必须比打开网页更快，否则手会自动去点浏览器。 所以 <code>ghr</code> 现在是 snapshot-first。配置、数据库、日志和 UI 状态都放在 <code>~/.ghr</code> 下面。启动时先把本地 SQLite 里的 snapshot 展示出来，然后再后台刷新当前列表。这样哪怕网络慢一点，至少我能先看到上次的现场。 这个设计听起来不酷，但它很实用，后来我又回看 ghui，发现他也改成了这个方案。 <h2 id="完整的工作流"><a href="#完整的工作流" class="headerlink" title="完整的工作流"></a>完整的工作流</h2> 一开始它像一个 GitHub dashboard：Inbox、Pull Requests、Issues，几块列表摆出来。后面越写越发现，只看列表是不够的。 所以后面加了很多看起来很细的功能： <ul> <li>recent items 可以跳回最近认真看过的 PR/Issue</li> <li>我认为任何工具都应该有 command palette，然后默认会把最近用过的命令排前面</li> <li>diff 里可以直接看到 inline review comments，可以 toggle 是否显示 comments</li> <li>任何编辑页面都会自动保存 draft，避免误操作导致的内容丢失</li> <li>详情页可以保存滚动位置和选中的评论</li> <li>虽然是 TUI，但是几乎所有界面上的操作也可以通过鼠标点击操作</li> <li>在一个已经关联 GitHub remote 的本地目录，直接运行 <code>ghr</code> 会自动把这个 project 加到顶层列表</li> </ul> 等等各种细节，这些功能单独拿出来都不像“大功能”，但组合起来以后，<code>ghr</code> 才开始有了工作流的味道。 <img src="http://catcoding.me/images/ob_pasted-image-20260508001703.png" alt="" /> 但我也发现 TUI 的局限，比如 diff 这个功能，即使我把细节都打磨好了，但我认为一个 PR 改动比较多的情况下最好的代码 review 体验还是在 VS Code 里，通过 Pull Request 插件直接 checkout 到本地，毕竟代码的 review 还是很依赖于编辑器的功能的（这个插件是我离不开 VS Code 的一个重要原因）。 <h2 id="AI-让个人工具变得更奢侈"><a href="#AI-让个人工具变得更奢侈" class="headerlink" title="AI 让个人工具变得更奢侈"></a>AI 让个人工具变得更奢侈</h2> <code>ghr</code> 这类工具放在以前，我大概率不会写到这个程度。细节太多，投入产出不划算。 TUI 里的鼠标选择、快捷键冲突、评论编辑框、draft 保存、列表分页、缓存失效、各种 GitHub API 的形状，每一个都不难，但都要花时间。AI 让这些小改动的成本降了很多，于是个人工具可以变得更“奢侈”：它不需要证明自己有市场，只要能持续改善我的日常工作流，就值得往前推一点。 欢迎试用，欢迎提 issue，也欢迎 PR：<a target="_blank" rel="noopener" href="https://github.com/chenyukang/ghr">ghr</a>。

2026/5/8

GitHeron：把网页标注写到 GitHub

最近写了一个 Chrome 插件，叫 <a target="_blank" rel="noopener" href="https://github.com/chenyukang/git-heron">GitHeron</a>。它想解决的问题很简单： <blockquote> Web highlights and clippings, synced to GitHub as Markdown. </blockquote> 我一直使用 <a target="_blank" rel="noopener" href="https://web.hypothes.is/">Hypothesis</a> 来同步冲浪记录，然后使用一个 <a target="_blank" rel="noopener" href="https://github.com/weichenw/obsidian-hypothesis-plugin">Obsidian 插件</a>来同步到我的知识库。但 hypothesis 的浏览器插件体验不佳，时不时需要登录，选中文字打算做备注时又偶尔无法激活，我就想自己写个插件来解决这个问题。 GitHeron 的思路是直接使用 Github token 访问私有 repo，通过 API 把数据写入仓库。GitHub 当然不是传统意义上的数据库。但对个人工具来说，它已经提供了很多“数据库”才有的能力：同步、历史、权限、备份、API、跨设备访问。更重要的是，这些都完全是由自己控制的。 <h2 id="网页备注和高亮"><a href="#网页备注和高亮" class="headerlink" title="网页备注和高亮"></a>网页备注和高亮</h2> GitHeron 最核心的功能是网页标注。 在网页上选中一段文字，按下快捷键 (默认 <code>Ctrl+E</code>)，就可以打开 note 编辑框。写完之后，这段文字会在页面上变成高亮。下次再打开同一个页面，GitHeron 会自动把之前的高亮恢复出来。 这件事听起来不复杂，但体验上很重要。很多阅读笔记工具只能把内容保存走，却不能在原网页上重新建立上下文。GitHeron 更在意的是“回到现场”：当你再次打开这篇文章时，能立刻看到自己上次为什么停在这里。 写 note 时也可以加 tags，最近使用过的 tags 会出现在输入框附近： <img src="http://catcoding.me/images/ob_pasted-image-20260428224559.png" alt="" /> <h2 id="保存整篇网页"><a href="#保存整篇网页" class="headerlink" title="保存整篇网页"></a>保存整篇网页</h2> 除了高亮，GitHeron 还可以保存当前网页的主要内容。 按下快捷键 (默认 <code>Ctrl + O</code>) 后，它会提取页面正文，转换成 Markdown，然后保存到仓库中的 Clippings 目录。这里保存的是 main content，不是整个网页 HTML，所以导航栏、广告、推荐列表这些内容会尽量被过滤掉。 网页剪藏部分使用 Defuddle 来提取 main content，再转换成 Markdown。它不能保证所有网页都完美，但比直接保存整个 DOM 更接近“我真正想留下来的文章内容”。 这个功能更接近 Obsidian Web Clipper：遇到一篇值得完整保存的文章，不需要复制粘贴，也不需要手工整理格式，直接让它进入自己的 Markdown 仓库。 <h2 id="使用体验"><a href="#使用体验" class="headerlink" title="使用体验"></a>使用体验</h2> 在 Settings 填入一个 Github repo 地址，私有的或者公开的都行，然后去 <a target="_blank" rel="noopener" href="https://github.com/settings/personal-access-tokens">Github token</a> 页面生成一个 token 含有写入这个 repo 权限的 token，填入插件的配置里即可。 默认有两个快捷键： <ul> <li><code>Ctrl+E</code>：给当前选中文字添加 note；</li> <li><code>Ctrl+O</code>：保存当前网页正文。</li> </ul> 如果喜欢鼠标操作，也可以开启选中文字后的悬浮按钮；如果不喜欢它打扰阅读，可以在 settings 里关掉，只使用快捷键。 同步 GitHub 时也有两种模式。普通模式会等 GitHub 写入完成再结束；后台同步模式则会先更新页面状态，把任务放到后台慢慢同步。网络失败或 GitHub 返回错误时，可以在 settings 的 tasks 里看到最近任务，并进行 retry。 写 note 应该是一个很轻的动作，不应该因为网络慢而打断阅读节奏。 <img src="http://catcoding.me/images/ob_pasted-image-20260428224735.png" alt="" /> <h2 id="技术方案"><a href="#技术方案" class="headerlink" title="技术方案"></a>技术方案</h2> GitHeron 是一个 Chrome MV3 插件，主要由 content script 和 service worker 组成。 content script 负责页面里的交互：选区、高亮、快捷键、弹框和正文提取。为了避免被网页自身样式影响，弹框和面板都放在 Shadow DOM 里。 service worker 负责设置、后台任务和 GitHub API。写入仓库时使用 GitHub 的 Git Data API 来生成 commit，这样一次保存可以同时更新 Markdown 内容和用于恢复高亮的辅助数据。 这里有一个取舍：Markdown 文件应该尽量保持可读，不应该塞进大段元数据。所以 GitHeron 会把可读内容写进 <code>.md</code>，把用于定位高亮的 selector 信息放到旁边的 JSON 文件里。这样仓库里既有人能直接读的笔记，也有插件重新打开网页时需要的结构化数据。 <h2 id="小结"><a href="#小结" class="headerlink" title="小结"></a>小结</h2> GitHeron 是一个很个人化的工具，它的目标不是做一个复杂的标注系统，而是让“读到有用内容”到“进入自己的知识库”之间少一点摩擦。 对了，我最近还 Vibe coding 了另一个小插件 <a target="_blank" rel="noopener" href="https://github.com/chenyukang/auto-tabs">auto tabs</a>，也是解决我日常的具体问题的。在 AI 时代，稍微有点编程经验的人都会把自己的工作流优化到极致。

2026/5/1

开发 Runnel 的一些记录

最近断断续续 Vibe Coding 写了一个小工具，叫 <a target="_blank" rel="noopener" href="https://github.com/chenyukang/runnel">Runnel</a>。因为我之前用的两个机场都跪了 (虽然后来又逐渐恢复了)，于是萌生了自己写个工具来翻墙的想法，顺便把一些网络相关的东西重新摸一遍。 Runnel 有“小河流”的意思，我觉得还挺贴切：不是要做一个很宏大的网络基础设施，就是在本机和远端之间挖一条能用、能看、能调试的小通道。 先让 AI 快速撸了一个车 native-http 版本的，然后又加了多路复用的 native-mux 模式。后来又想到一个同事说他一直用自己写的代理工具叫做 <a target="_blank" rel="noopener" href="https://github.com/libraries/daze">daze</a>，所以立马让 AI 用 Rust 重写了一份跑了起来。 于是它现在支持几种模式：<code>native-http</code>、<code>native-mux</code>、几个 daze 风格的模式，以及后来主要投入精力做的 <code>wg</code> 模式。 前面这些更像传统 SOCKS 代理，应用明确连到本地 SOCKS 端口，然后 Runnel 把流量转到远端。WG 模式不一样，它走 TUN 设备和 WireGuard 风格的 UDP 包，更像日常会用的全局 VPN。 真正让我把重心转到 WG 模式的原因也很普通：SOCKS 在浏览器里挺好用，但到系统级流量、命令行工具、各种后台服务时就没那么舒服了。macOS 下总会碰到有些软件不吃系统代理，有些软件自己做 DNS，有些东西干脆只看路由表。最后还是得上 TUN。 <h2 id="先让它能跑"><a href="#先让它能跑" class="headerlink" title="先让它能跑"></a>先让它能跑</h2> WG 模式底层用的是 Cloudflare 的 <a target="_blank" rel="noopener" href="https://github.com/cloudflare/boringtun">boringtun</a>，目标很简单： <ul> <li>client 创建一个 TUN 设备；</li> <li>server 也创建一个 TUN 设备；</li> <li>两边用 WireGuard key 建立 peer；</li> <li>client 把默认路由打进去；</li> <li>server 开转发和 NAT。</li> </ul> 听起来像配置一遍 WireGuard 而已，但自己写以后就会发现，大部分时间并不在加密和解密上，而是在处理操作系统。 Linux 上需要 <code>/dev/net/tun</code>、<code>ip</code>、<code>sysctl</code>、<code>iptables</code>。macOS 上是 <code>ifconfig</code>、<code>route</code>、<code>networksetup</code>。命令不复杂，但出错方式很多。例如服务端没停干净，再起一次就会卡在： <pre class="line-numbers language-bash" data-language="bash"><code class="language-bash">ip address add 10.8.0.1 peer 10.8.0.2 dev runnel-wg0 </code></pre> 因为设备还在，地址也还在。再比如 macOS 上如果之前的 tunnel 没清理干净，WG endpoint 的路由可能会被系统解析到某个 <code>utun</code> 上。这个时候 client 还没真正起来，但发往 server endpoint 的 UDP 包已经准备钻进旧 tunnel，最后当然连不上。 这类问题很烦，但它们也逼着我把启动阶段做得更啰嗦一点。现在 Runnel 会做 preflight，会打印 hook，会在 client 装路由之前先做一次短 handshake probe。key、endpoint 或两端配置有问题时，最好在启动阶段直接报错，而不是把系统路由改完，然后留给用户一个没有响应的黑盒。 我写这类工具最大的感受是：网络工具的“好用”，很多时候不是吞吐量高一点，而是坏的时候知道坏在哪里。 <h2 id="配置生成"><a href="#配置生成" class="headerlink" title="配置生成"></a>配置生成</h2> WG 的配置很容易写错，尤其是 private key、peer public key、tunnel IP 这种互相交叉的字段。手写一次就够让人烦了，所以后来加了： <pre class="line-numbers language-bash" data-language="bash"><code class="language-bash">runnel wg-config --server-endpoint SERVER-IP:1443 > runnel.yaml </code></pre> 这个命令会一次生成 client 和 server 两边配置。两台机器用同一个 YAML，只是启动时分别执行： <pre class="line-numbers language-bash" data-language="bash"><code class="language-bash">sudo runnel --config runnel.yaml server sudo runnel --config runnel.yaml client --tui </code></pre> 它减少了很多“我复制错了吗”的问题，也方便把一些默认值放进去。比如现在生成配置默认带 adblock，默认启用 DNS capture，也会默认带上 noise engine 和 mask obfs： <pre class="line-numbers language-yaml" data-language="yaml"><code class="language-yaml">client: wg: engine: noise obfs: mask obfs_padding_min: 8 obfs_padding_max: 96 obfs_handshake_padding: 256 obfs_response_padding: 192 </code></pre> 这些东西不一定适合所有人，但它们很适合我自己的使用场景：默认配置应该尽量接近日常可用，而不是只给一个裸 tunnel。 <h2 id="分流"><a href="#分流" class="headerlink" title="分流"></a>分流</h2> 我原来只想做 IP 规则，例如： <pre class="line-numbers language-yaml" data-language="yaml"><code class="language-yaml">client: ip_rules: direct: - "10.*" - "192.168.*" </code></pre> 这个在 WG 模式下比较直观，<code>direct</code> 就是给这些 IP 加本地直连 route，不让它们进 tunnel。后来很快又想要域名规则： <pre class="line-numbers language-yaml" data-language="yaml"><code class="language-yaml">client: domain_rules: direct: - "*.baidu.com" - "*.cn" block: - "*.xxx.com" </code></pre> 问题是 WG 看到的是 IP 包，不知道这个连接原本访问的是 <code>github.com</code> 还是别的什么域名。能抓到域名的地方只有 DNS。 所以现在 WG 的 domain rules 是 DNS 驱动的。client 会把本机 DNS 指到 <code>127.0.0.1:53</code>，Runnel 在本地做一个很小的 DNS forwarder。它看到查询 <code>www.xxx.com</code>，发现命中 direct 规则，就等上游 DNS 返回 IP，然后动态加一条 host route，让这个 IP 走本地网关。 这个方案很实用，但并不完美。第一次访问一个域名时，如果系统还没有拿到解析结果，它可能已经先走了 tunnel。DoH、DoT、浏览器缓存、直接访问 IP，也都绕过这条逻辑。CDN 共享 IP 还会带来另一个问题：你为了某个域名加的直连 route，可能影响另一个解析到同一 IP 的域名。 这些限制没法假装不存在，所以文档里也写清楚了。能解决 80% 的日常问题就很好，剩下 20% 要靠更底层的 packet inspection 或系统扩展，那又是另外一个坑。 <h2 id="顺手加的-Adblock"><a href="#顺手加的-Adblock" class="headerlink" title="顺手加的 Adblock"></a>顺手加的 Adblock</h2> 后来我把 <a target="_blank" rel="noopener" href="https://github.com/brave/adblock-rust/">adblock-rust</a> 集成进来了。原因很简单：既然 WG 模式已经有 DNS capture，那 block 域名就可以顺手做掉。 这里我比较在意优先级。最后定下来是： <ol> <li>用户自己的 <code>domain_rules.block</code></li> <li>adblock 规则</li> <li>用户自己的 direct/proxy 规则</li> <li>默认走 proxy，也就是 tunnel</li> </ol> 用户手写规则永远应该赢过订阅规则。否则哪天 EasyPrivacy 把一个你需要的域名拦了，就会很难受。 性能上我一开始也有点担心。毕竟 tunnel 里每个包都可能很密集，如果每个请求、每个 packet 都去跑 adblock，那肯定不行。最后实现是 DNS 级别的：只有新的域名查询会进入规则匹配，订阅会缓存在本地，域名决策也有内存缓存。实际看下来，这个成本可以接受。 有次 TUI 里看到 <code>p.data.cctv.com</code> 被 block，我还专门去查了一下。它不是用户规则拦的，是订阅规则命中的。 <h2 id="TUI-比我预想中更有用"><a href="#TUI-比我预想中更有用" class="headerlink" title="TUI 比我预想中更有用"></a>TUI 比我预想中更有用</h2> Runnel 有一个 TUI，不是为了好看，主要是为了少开几个终端。 WG 模式刚开始出问题时，我经常要同时看： <ul> <li>client 有没有握手；</li> <li>server 有没有看到 endpoint；</li> <li>最近有没有 REKEY timeout；</li> <li>DNS 最近解析了什么域名；</li> <li>哪些域名被 direct、proxy、block；</li> <li>tunnel 有没有流量。</li> </ul> 这些信息散在 log、<code>netstat</code>、<code>route</code>、<code>tcpdump</code> 里会很痛苦。放到一个 TUI 里之后，很多问题一眼能看出方向。 比如看到 <code>HANDSHAKE(REKEY_TIMEOUT)</code> 连续刷，基本就是两边没有成功握手，先别怀疑浏览器。看到 <code>www.qq.com pending</code>，就知道 DNS query 被捕获了，但还没拿到可用于直连的 IP。 <h2 id="Benchmark-测试"><a href="#Benchmark-测试" class="headerlink" title="Benchmark 测试"></a>Benchmark 测试</h2> 我给所有模式都加了一个 <code>mode_perf</code> benchmark。小请求跑 1000 次，大响应跑 8 个 1MiB 下载。非 WG 模式走 SOCKS path，WG 模式会真正拉起 child process，创建 TUN 设备，然后从 tunnel IP 发 HTTP 请求。 本机测试的结果挺有意思： <pre class="line-numbers language-text" data-language="text"><code class="language-text">native-mux 小请求大约 3300 req/s daze-czar 小请求大约 3400 req/s wg 小请求大约 2500 req/s </code></pre> 但大响应吞吐 WG 看起来很低，只有几十 MiB/s。刚看到这个数字我也有点怀疑，毕竟实际用起来 WG 并不觉得卡。后来想想也正常：这个 benchmark 是 localhost 上的端到端测试，WG 走真实 TUN 设备，会经过内核路由、用户态加解密、UDP socket、NAT 这些路径；而很多 SOCKS 模式本质上就是本机 TCP 流转发，少了不少系统边界。 日常使用的“流畅”也不完全由大文件吞吐决定。连接建立、DNS、浏览器并发、小请求延迟，这些东西更容易影响体感。WG 在小请求上的数据并不差，而且系统级接管以后，很多应用不用再单独配置代理，反而省心。 所以 benchmark 还是要有，但不能只看一个数。尤其是代理/VPN 这种东西，不同 workload 差别太大。 <h2 id="Noise-和混淆"><a href="#Noise-和混淆" class="headerlink" title="Noise 和混淆"></a>Noise 和混淆</h2> 标准的 WireGuard 长度非常固定，所以基本上会容易检测出来。我在最初使用单纯的 WG 用一段时间开始丢包，于是我开始琢磨如何加噪音来抗审查。 于是给 WG mode 加了 noise engine。默认的 device engine 是让 boringtun 自己管理 WireGuard 设备和 UAPI socket，比较标准。noise engine 则是 Runnel 自己跑 TUN/UDP loop，直接用 <code>boringtun::noise::Tunn</code> 做加解密。 这样做的好处是 transport 变得更可控。比如可以在 WireGuard UDP 包外面包一层 mask，把包头和长度藏一下，再加一些 padding。现在的 <code>obfs: mask</code> 做的就是这个方向。 我不想把它说成什么“抗审查神器”，但从我平稳使用的一周结果看这样的混淆对于个人使用已经足够。现实网络环境要麻烦得多，包长、时序、UDP 行为、重传模式，都可能暴露特征。 我也看了一些类似工具的方向，比如 <a target="_blank" rel="noopener" href="https://github.com/amnezia-vpn">AmneziaVPN</a>、Nym 把 QUIC 和 WG 组合起来的思路，Runnel 现在还只是很早期的版本，但 noise engine 让后面继续试 QUIC、padding profile、甚至更麻烦的 packet shaping 都方便了一些。 <hr /> Runnel 还没有到我觉得很完整的阶段，还有些细节可以继续打磨，比如 IPv6 和双栈还需要更好的 schema，macOS 上更细粒度的 app split tunneling 也不是简单路由表能解决的。 但目前这个状态我已经挺满意了，它不是一个周末玩具了，至少已经变成了我自己会认真拿来使用、测试、折腾网络问题的工具。 这大概就是个人项目最舒服的地方：先让自己用得爽一点，遇到问题再修复。我的日常使用场景是 macOS(client) + Linux(server)，其他路径目前只是在单元测试中有覆盖，也许其他实际场景会碰到一些配置问题，欢迎 PR。

2026/4/23

macOS 奇怪的安全扫码机制

今天跑 Rust 编译器测试的时候又发现非常地慢，CPU 资源根本无法利用起来，我记得几年前碰到过这个问题，当时我写了篇<a target="_blank" rel="noopener" href="https://catcoding.me/p/apple-perf/">文章</a>分享出来，并发现很多人都有同样的困扰。 而我今天碰到的这个问题虽然现象一样，但解决方法又不同了。我不确定是 macOS 系统更新，亦或是我更新了 VS Code 造成的。 <h2 id="问题"><a href="#问题" class="headerlink" title="问题"></a>问题</h2> 复现脚本很简单，循环创建随机命名的 shell 脚本，然后对比首次和再次执行的耗时： <pre class="line-numbers language-bash" data-language="bash"><code class="language-bash">#!/bin/bash rm -rf /tmp/speed_test mkdir -p /tmp/speed_test for i in {1..10}; do FILENAME=$(openssl rand -hex 10) echo $'#!/bin/sh\necho Hello' > "/tmp/speed_test/$FILENAME.sh" chmod a+x "/tmp/speed_test/$FILENAME.sh" FILE="/tmp/speed_test/$FILENAME.sh" first=$(TIMEFORMAT="%R"; (time $FILE > /dev/null) 2>&1) second=$(TIMEFORMAT="%R"; (time $FILE > /dev/null) 2>&1) echo "第一次: $first 第二次: $second" done </code></pre> 在 VS Code 终端的输出： <pre class="line-numbers language-console" data-language="console"><code class="language-console">第一次: 0.525 第二次: 0.007 第一次: 0.290 第二次: 0.009 第一次: 0.280 第二次: 0.007 第一次: 0.272 第二次: 0.008 第一次: 0.307 第二次: 0.008 ... </code></pre> 差距大概 30-50 倍。换到 Warp 终端跑同一个脚本，两次都在 0.006s 左右。 <h2 id="定位：syspolicyd"><a href="#定位：syspolicyd" class="headerlink" title="定位：syspolicyd"></a>定位：syspolicyd</h2> 应该不是我上篇文章提到的 SIP 问题，我确定 System Settings → Privacy & Security → Developer Tools 中已经加入了 VS Code。 看起来也不像是文件系统缓存的原因，因为 0.2-0.5 秒远超磁盘缓存的量级。用 <code>log show</code> 看了下系统日志： <pre class="line-numbers language-bash" data-language="bash"><code class="language-bash">log show --predicate 'subsystem == "com.apple.syspolicy.exec"' --last 2m --style compact </code></pre> 输出大量这样的记录： <pre class="line-numbers language-console" data-language="console"><code class="language-console">GK performScan: PST: (path: 8d0e4c2de41c3e77), (team: (null)), (id: (null)), (bundle_id: (null)) Error Domain=NSOSStatusErrorDomain Code=-67062 GK evaluateScanResult: 2, PST: (path: 8d0e4c2de41c3e77), ... (bundle_id: NOT_A_BUNDLE), 0, 0, 1, 0, 7, 7, 0 </code></pre> 从日志上看每次执行新文件 <code>syspolicyd</code> 都会做一次 <code>GK performScan</code>。这就是 macOS 的 Gatekeeper 安全扫描——对首次执行的新可执行文件做代码签名验证和恶意软件检查。扫描结果会被缓存，所以同一个文件第二次执行就快了。 进一步验证：我们把测试脚本里改成 <code>(time /bin/sh $FILE > /dev/null) 2>&1</code>，这样就是直接通过 sh 来执行： <pre class="line-numbers language-console" data-language="console"><code class="language-console">直接执行 ./script.sh → 0.248s (触发 execve → Gatekeeper 扫描) /bin/sh ./script.sh → 0.006s (只是让 /bin/sh 读取文件，不触发安全扫描) </code></pre> 原因确认了。当用 <code>./script.sh</code> 执行时，内核的 <code>execve</code> 系统调用会触发 <code>AppleSystemPolicy.kext</code> 中的 MACF hook (<code>mpo_proc_notify_exec_complete</code>)，通知 <code>syspolicyd</code> 进行评估。而 <code>/bin/sh script.sh</code> 只是让已受信的 <code>/bin/sh</code> 进程读取文件内容来解释执行，不触发 <code>execve</code> 的安全检查路径。 <h2 id="Full-Disk-Access-有效"><a href="#Full-Disk-Access-有效" class="headerlink" title="Full Disk Access 有效"></a>Full Disk Access 有效</h2> 接着试了 System Settings → Privacy & Security → Full Disk Access，给 VS Code 完全磁盘访问权限。重启 VS Code，再跑脚本： <pre class="line-numbers language-console" data-language="console"><code class="language-console">第一次: 0.005 第二次: 0.005 第一次: 0.005 第二次: 0.005 第一次: 0.006 第二次: 0.006 ... </code></pre> 问题消失了。<code>syspolicyd</code> 日志中的 <code>performScan</code> 也不再出现。 <h2 id="为什么-Full-Disk-Access-有效"><a href="#为什么-Full-Disk-Access-有效" class="headerlink" title="为什么 Full Disk Access 有效"></a>为什么 Full Disk Access 有效</h2> Full Disk Access (FDA) 在 macOS 的 TCC (Transparency, Consent, and Control) 框架中对应的是 <code>kTCCServiceSystemPolicyAllFiles</code> 权限。这个权限的含义远超“磁盘访问“——它实际上是 TCC 框架中最高级别的信任授权。 macOS 会追踪每个进程的 responsible process（负责进程）。在 VS Code 终端中敲的命令，它的 responsible process 是 VS Code 本身。当 <code>AppleSystemPolicy.kext</code> 的 MACF hook 拦截到 <code>execve</code> 后，会检查 responsible process 的信任级别。拥有 FDA 授权的进程被识别为高信任来源，<code>syspolicyd</code> 会走快速路径，跳过完整的 Gatekeeper 扫描。 而 Warp 这些原生终端，因为我已经加入系统默认信任的开发工具列表，所以它们派生的子进程一开始就不会触发完整扫描。 需要说明：Apple 没有公开文档化这个具体流程。上面的描述来自实验推断和社区逆向分析，不是官方说法。 <h2 id="一个有趣的细节：信任会被“记住“"><a href="#一个有趣的细节：信任会被“记住“" class="headerlink" title="一个有趣的细节：信任会被“记住“"></a>一个有趣的细节：信任会被“记住“</h2> 发现 FDA 有效之后，我尝试反向验证：把 VS Code 从 FDA 列表中移除，重启 VS Code，再跑脚本。 结果：仍然很快。问题没有复现。 <code>syspolicyd</code> 的扫描评估结果存储在 <code>/var/db/SystemPolicyConfiguration/ExecPolicy</code> 这个 SQLite 数据库中（35MB），同时 <code>AppleSystemPolicy.kext</code> 在内核中维护了一个运行时缓存： <pre class="line-numbers language-bash" data-language="bash"><code class="language-bash">$ sysctl security.mac.asp.stats.cache_entry_count security.mac.asp.stats.cache_entry_count: 4700 </code></pre> 也就是说，当 VS Code 拥有 FDA 时，它被评估为可信 responsible process，这个信任结果被持久化了。移除 FDA 后，历史记录并不会被清除。macOS 的安全评估系统是“学习型“的——它记住过去的信任决策。 要彻底重现原来的问题，可能需要重启 Mac 清除内核缓存，或者更极端地清理 ExecPolicy 数据库。 <h2 id="总结"><a href="#总结" class="headerlink" title="总结"></a>总结</h2> 如果你也遇到类似的问题——新编译的程序、新创建的脚本首次执行莫名其妙地慢，可以检查一下是不是 Gatekeeper 的锅： <pre class="line-numbers language-bash" data-language="bash"><code class="language-bash"># 查看最近的 syspolicyd 扫描记录 log show --predicate 'subsystem == "com.apple.syspolicy.exec"' --last 5m --style compact | grep performScan </code></pre> 解决方案按排序： <ol> <li>给你的程序加如到 Developer Tools 列表</li> <li>给你的程序加 Full Disk Access</li> </ol> <h2 id="参考"><a href="#参考" class="headerlink" title="参考"></a>参考</h2> <ul> <li><a target="_blank" rel="noopener" href="https://support.apple.com/guide/security/gatekeeper-and-runtime-protection-sec5599b66df/web">Apple Platform Security - Gatekeeper and runtime protection</a></li> <li><a target="_blank" rel="noopener" href="https://knight.sc/reverse%20engineering/2019/02/20/syspolicyd-internals.html">Scott Knight - syspolicyd internals</a>（对 syspolicyd 内部机制的详细逆向分析，包括 ExecManager、AppleSystemPolicy.kext 的 MACF hook 等）</li> <li><a target="_blank" rel="noopener" href="https://eclecticlight.co">Howard Oakley - eclecticlight.co</a>（大量关于 macOS 安全扫描机制变化的独立研究）</li> </ul>

2026/2/12

hexo-rs：玩 Vibe Coding

月底升级了 Copilot Pro+，月初额度重置，这几天可以放开用，想到什么就 vibe 一把。 我的博客跑在 Hexo 上很多年了。其实没什么大问题，就是每次看到那几百 MB 的 node_modules，心里总有点膈应——生成几百个静态 HTML，真的需要这么多依赖吗？但迁移到别的博客系统又懒得折腾，所以一直拖着。 这次干脆试试：能不能用 AI 一个下午撸一个 Rust 版的 Hexo？我的目标比较简单：生成跟原来一样的静态文件，兼容我现在用的主题就行。 我用的是 OpenCode + Opus 4.5。陆陆续续聊了一下午，产出了 <a target="_blank" rel="noopener" href="https://github.com/chenyukang/hexo-rs">hexo-rs</a>。能用，但还有些边边角角的问题。 Vibe Coding 的工具和体会以后再写，这篇主要聊 hexo-rs 的实现和踩过的坑。 <h2 id="技术选型"><a href="#技术选型" class="headerlink" title="技术选型"></a>技术选型</h2><h3 id="EJS-模板引擎"><a href="#EJS-模板引擎" class="headerlink" title="EJS 模板引擎"></a>EJS 模板引擎</h3> Hexo 主题基本都用 EJS 模板——就是把 JavaScript 嵌到 HTML 里，跟 PHP 差不多。 用 <a target="_blank" rel="noopener" href="https://bellard.org/quickjs/">QuickJS</a> 跑 JS，通过 <code>quick-js</code> crate 调用。好处是不用依赖 Node.js，坏处是 Windows 上编不过（<code>libquickjs-sys</code> 挂了），所以暂时只支持 Linux 和 macOS。 <h3 id="其他"><a href="#其他" class="headerlink" title="其他"></a>其他</h3> Markdown 用 <code>pulldown-cmark</code>，代码高亮用 <code>syntect</code>，本地服务器用 <code>axum</code>。都是常规选择，没什么特别的。 <h2 id="踩过的坑"><a href="#踩过的坑" class="headerlink" title="踩过的坑"></a>踩过的坑</h2><h3 id="HashMap-的坑"><a href="#HashMap-的坑" class="headerlink" title="HashMap 的坑"></a>HashMap 的坑</h3> 这个 bug 藏得很深。生成 tag 和 category 页面时，一开始用 <code>HashMap</code> 存文章分组： <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">let mut tags: HashMap<String, Vec<&Post>> = HashMap::new(); </code></pre> <code>HashMap</code> 迭代顺序不确定，每次生成的 HTML 可能不一样。页面看着没问题，但 diff 一下就发现乱了。改成 <code>BTreeMap</code> 就好了： <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">let mut tags: BTreeMap<String, Vec<&Post>> = BTreeMap::new(); </code></pre><h3 id="Helper-函数"><a href="#Helper-函数" class="headerlink" title="Helper 函数"></a>Helper 函数</h3> Hexo 有一堆 helper 函数：<code>url_for</code>、<code>css</code>、<code>js</code>、<code>date</code> 之类的。都得在 Rust 里实现一遍，然后塞进 QuickJS。 最烦的是 <code>date</code>。Hexo 用 Moment.js 的格式（<code>YYYY-MM-DD</code>），Rust 的 chrono 用 strftime（<code>%Y-%m-%d</code>）。得写个转换函数，挺无聊的活。 <h3 id="Partial-嵌套"><a href="#Partial-嵌套" class="headerlink" title="Partial 嵌套"></a>Partial 嵌套</h3> EJS 的 <code>partial</code> 可以套娃，A 引用 B，B 又引用 C，变量还得一层层传下去。搞了个作用域栈，进 partial 压栈，出来弹栈。不难，但容易写错。 <h2 id="Vibe-Coding-体感"><a href="#Vibe-Coding-体感" class="headerlink" title="Vibe Coding 体感"></a>Vibe Coding 体感</h2> 代码 100% 是 AI 写的。我干的事：描述需求、review 代码、把报错贴给它让它改、偶尔拍板选方案。 像 EJS 模板引擎这种东西，自己从头写估计得半天，AI 几分钟就吐出来了。 但 AI 也挺蠢的： <ul> <li>HashMap 那个 bug 它就没注意到，我提出界面上的变化它也没反应过来</li> <li>一开始它写的 EJS parser 全是字符串 hardcode，丑得不行，我让它按 lexer -> AST 的套路重写了一遍</li> <li>代码多了以后它会忘事，前面写过的逻辑后面又写一遍</li> </ul> 但 AI 又确实非常强，我想到应该使用现在线上的 catcoding.me 来和新生成的内容一一对比，然后它就呼啦啦地一通操作把问题都找出来了，自己修改完。 <h2 id="使用"><a href="#使用" class="headerlink" title="使用"></a>使用</h2><pre class="line-numbers language-bash" data-language="bash"><code class="language-bash">cargo binstall hexo-rs # 或 cargo install hexo-rs hexo-rs generate # 生成静态文件 hexo-rs server # 本地预览 hexo-rs clean # 清理 hexo-rs new "标题" </code></pre><h2 id="局限"><a href="#局限" class="headerlink" title="局限"></a>局限</h2> 不支持 Hexo 插件，不支持 Stylus 编译（.styl 文件得先用 Node 编译好），Windows 也不行。 简单的博客应该够用。复杂主题可能会有兼容问题。 <hr /> 代码在这：<a target="_blank" rel="noopener" href="https://github.com/chenyukang/hexo-rs">github.com/chenyukang/hexo-rs</a> 用 Hexo 的可以试试。有问题提 issue，我让 AI 来修 :) 这篇文章到底是人写的，还是 AI 写的？ <hr /> Update 2026-02-13: 鉴于使用 quickjs 对于我来说还是太重了，我后续又做了一些改动，把 ejs template 换成了 tare template，这样就把 vexo 模板直接放在了 Rust 项目里，所以目前 hexo-rs 就是这个博客的 generator 了。

2026/1/30

How Fiber Network Works

I just got back from CKCon in beautiful Chiang Mai 🌴, where I gave a talk on the Fiber Network. To help everyone wrap their heads around how Fiber (CKB’s Lightning Network) actually moves assets, I hacked a visual simulation with AI. To my surprise, people didn’t just understand it—they loved it! 🎉 Here is the “too long; didn’t read” version. But first, go ahead and play with the dots yourself, 👉 Play the Simulation: <a target="_blank" rel="noopener" href="https://fiber-world.vercel.app/simulate.html">fiber-simulation</a> <img src="http://catcoding.me/images/ob_pasted-image-20251204113415.png" alt="" /> We all love Layer 1 blockchains like Bitcoin or CKB for their security, but let’s be honest: they aren’t exactly built for speed. Every transaction has to be shouted out to the entire world and written down by thousands of nodes. On CKB, you’re waiting about 8 seconds for a block; on Bitcoin, it’s 10 minutes! Plus, the fees can get nasty if you’re just trying to buy a coffee. ☕️ So, how do we fix this? The Lightning Network is a scalable, low-fee, and instant micro-payment solution for P2P payments. The secret sauce isn’t actually new. Even Satoshi Nakamoto hinted at this “high-frequency” magic in an <a target="_blank" rel="noopener" href="https://en.bitcoin.it/wiki/Payment_channels">early email</a>: <blockquote> Intermediate transactions do not need to be broadcast. Only the final outcome gets recorded by the network. </blockquote> A Lightning Network consists of Peers and Channels. A peer can send, receive, or forward a payment. A Channel is used for communication between two Peers. <img src="http://catcoding.me/images/ob_pasted-image-20251204113629.png" alt="" /> Imagine you and a friend want to trade money back and forth quickly: <ol> <li>Opening the Channel: You both put some money into a pot and sign a Funding Tx. This goes on the blockchain (L1).</li> <li>The Fun Part (Off-Chain): Now that the channel is open, you can send money back and forth a million times instantly! You just update the balance sheet between you two (using HTLCs and signatures). No one else needs to know, and no blockchain fees are paid yet.</li> <li>Closing the Channel: When you’re done, you agree on the final balance, sign a Shutdown Tx, and tell the blockchain.</li> </ol> Everything in the middle? That’s off-chain magic. ✨ Now, if Fiber was just about paying your direct neighbor, it would be boring. The real power comes from the Network. <img src="http://catcoding.me/images/ob_pasted-image-20251204113608.png" alt="" /> This means Alice can pay Bob even if they don’t have a direct channel between them. The payment can travel through one or more intermediate nodes. As long as there is a path with enough liquidity, the payment will reach its destination instantly. All data is wrapped in Onion Packets (yes, like layers of an onion). The nodes in the middle serve as couriers, but they are blindfolded: <ul> <li>They don’t know who sent the money.</li> <li>They don’t know who is receiving it.</li> <li>They only know “pass this to the next guy.”</li> </ul> They simply follow a basic rule: they forward the Hash Time Lock, and if the payment succeeds, they earn a tiny fee for their trouble. Easy peasy. The “Not So Easy” Part 😅 While the idea is simple, building it is… well, an engineering adventure. We’re dealing with cryptography, heavy concurrency, routing algorithms, and a whole jungle of edge cases. But hey, that’s what makes it fun! We’ve poured the last two years into building Fiber, and I’m proud to say it’s finally GA ready. If you want to geek out on the details, check these out: <ul> <li><a target="_blank" rel="noopener" href="https://github.com/lnbook/lnbook">Mastering the Lightning Network (LN)</a> and <a target="_blank" rel="noopener" href="https://github.com/lightning/bolts">Basis of Lightning Technology</a></li> <li><a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber">nervosnetwork/fiber</a></li> </ul> Here is the full presentation from my talk: <a target="_blank" rel="noopener" href="https://docs.google.com/presentation/d/1aKhG0ebR-UV4SqOWOd_Xjlz15hGVmmRUMLzIkwcUWeY/edit?usp=sharing">CKB Fiber Network Engineering Updates</a>

2025/12/9

在开源中使用 LLM

越来越多的开发者开始使用 LLM 等 AI 工具，过去半年我看到不少相关讨论：有人非常反感使用 LLM 工具，有人保持中立，但确实有相当数量的 AI 生成 PR 给开源项目维护者带来了负担和困扰。 现在出现了一些新苗头，比如 GitHub 账号也开始“养号”。我推测大概有以下几个原因： <h3 id="为了加密货币空投"><a href="#为了加密货币空投" class="headerlink" title="为了加密货币空投"></a>为了加密货币空投</h3> 2023–2024 年类似的情况比较多，有些加密货币项目会根据开发者的 GitHub 公开提交记录进行空投。如果一个账号给项目方关注的项目提过 PR，就更容易获得。例如 Rust 在区块链领域用得比较多，所以 Rust compiler 项目是比较容易获得空投的。我自己也因为一些开源记录拿到过空投，当时兑换了 1 万多人民币。我看到不少 Rust 社区维护者也得到了空投，不过他们对加密货币普遍不感兴趣；也有个别人因此换到了不少钱，觉得很惊讶。有同事给以太坊提过几个 PR，他的空投价值大约 15 万人民币，因此还出现了有人收购 GitHub 空投资格的情况。 但我认为这只是短期现象。现在再为了空投去养号是否还有机会？我不敢确定。因为“养号”的特征很明显，其实很好自动识别。而且到了 2025 年类似空投已经很少了，即使有，也会要求复杂的钱包交互，不是币圈的人通常不会折腾这些。 <h3 id="为了丰富简历"><a href="#为了丰富简历" class="headerlink" title="为了丰富简历"></a>为了丰富简历</h3> 很多开发人员都知道，一个拿得出手的 GitHub 账号应该会对找工作有帮助。但我对此保持怀疑，因为养出来的 GitHub 账号一眼就能看出，从面试官的角度，我认为加上一个这样的 GitHub 账号到简历里是减分项。 总之，如果只是为了以上两种目的去“养号”，我都建议停手，因为这通常是费时费力但得不偿失的事情。 <h3 id="为了参与到开源项目"><a href="#为了参与到开源项目" class="headerlink" title="为了参与到开源项目"></a>为了参与到开源项目</h3> 另外一部分人是真的想参与开源项目，他们可能认为使用 LLM 能降低难度。 现在的 AI 工具确实比以前更强大了。你可以把一个 GitHub issue 给它，稍微写点 prompt，AI 就能自动生成 PR，甚至自动发 PR。但这种方式通常会忽略一些开源项目本身的贡献约定，从而导致 PR 一发出来维护者就知道这人肯定连 contribution guide 都没看过，这样就会直接关闭掉这个 PR，这有个典型的<a target="_blank" rel="noopener" href="https://github.com/rust-lang/rust/pull/149296">例子</a>。 AI 的确比我原本想象的好用很多，我在日常开发中也会使用，但主要把它当成增强版搜索引擎或自动化工具。例如我会让 AI 帮我做一些自动化流程：我有一个 prompt 模板，只需要给一个 issue 号，LLM 就能帮我解析问题，把相关的 bug 重现代码放到测试目录，创建对应的 Git branch，尝试在本地重现问题，然后从 backtrace 定位可疑代码。这确实省了我不少时间。但这建立在我自己按这个流程做过很多遍，能找出一套比较稳定的方法。 正如我之前说的，如果你想用好 AI，你必须具备项目的 domain knowledge，才能判断 AI 有没有“骗你”。 在 Rust compiler 项目里，目前 LLM 生成的 PR 基本只有 typo fix 之类的会偶尔被接受。只要涉及稍微复杂一些的代码修改，一眼就能看出不是人写的。 如果真的想参与开源项目，最好的方式还是从项目中简单的 issues 开始。如果不懂就多问，多看文档和代码。每个人都是从新手阶段慢慢走过来的，维护者一般对真心想参与的贡献者会更有耐心。 即使用 LLM 生成代码，我们依然要逐行 review，确保正确、可维护、简洁。如果你丢一堆机器生成的代码，让 maintainer 帮你审核，这会引起极大的反感。 比如这位开发者，在 maintainer 审核后对代码发出质疑的时候也承认是 <a target="_blank" rel="noopener" href="https://GitHub.com/ocaml/ocaml/pull/14369#issuecomment-3556497947">AI 写的代码</a>: <img src="http://catcoding.me/images/ob_pasted-image-20251126091545.png" alt="" /> 建议大家可以去看看上面那个 PR 里的讨论，我觉得有些评论挺有价值。OCaml 的维护者 <a target="_blank" rel="noopener" href="https://GitHub.com/gasche">gasche</a> 表达的观点很明确： <blockquote> The fact that you were able to generate large amount of code that passes test is interesting, but that’s only 20% of the work, the other 80% are to get the feature discussed, reviewed and integrated, and this work will be paid by you and others. But you only focus on the initial writing phase and you personal success, over-communicate on this, and do not appear to realize that this has very real costs on others. </blockquote> 在多人协作的开源项目中，稍微复杂一点的功能，写代码其实只占很小一部分，更多的是协作与讨论。一个 PR 是否能 merge，还要考虑长期维护成本。 另外，LLM 生成的代码其实是非常容易检测的，比如现在就有类似的工具可以以比较高的准确度判断代码是否是 AI 写的： <a target="_blank" rel="noopener" href="https://code-detector.ai/">AI Code Detector by Span</a> 还有一些开发者 (尤其是非英语母语者)，他们可能对自己的英语不够自信，所以使用 LLM 来帮忙写 PR description 和 comments。有的开发者就是偷懒，认为 LLM 总结的即全面又好。但从维护者的角度来说，这是不友好的，因为 LLM 生成的内容<a target="_blank" rel="noopener" href="https://GitHub.com/rust-lang/rust/pull/149297#issuecomment-3573984021">过于冗长</a>: <blockquote> The comments left by you are significantly too verbose. While being detailed is good, please be respectful of reviewer time and avoid verbose text that mostly doesn’t convey any useful content. </blockquote> 在 Rust maintainer channel 里也讨论过这点，看起来很多人是反感读 LLM 生成的东西的，大家期待的鲜活的人类讨论，而不是机器生成的文字。 其实英语稍微差点的开发者，只要写的内容不是过于离谱，其他开发者也能理解，不用太在意 typo 之类的错误，因为人的大脑纠正的功能过于强大。后来我在 <a target="_blank" rel="noopener" href="https://GitHub.com/rust-lang/rustc-dev-guide/pull/2543/files">rustc-dev-guide</a> 上加了这么一段： <blockquote> If you’re not a native English speaker and feel unsure about writing, try using a translator to help. But avoid using LLM tools that generate long, complex words. In daily teamwork, simple and clear words are best for easy understanding. Even small typos or grammar mistakes can make you seem more human, and people connect better with humans. </blockquote> AI 工具在开源项目中的过度尝试，只会让更多人反感，比如 <a target="_blank" rel="noopener" href="https://GitHub.com/ziglang/zig?tab=readme-ov-file#strict-no-llm--no-ai-policy">zig 项目明确表明</a>: <blockquote> No LLMs for issues. No LLMs for patches / pull requests. No LLMs for comments on the bug tracker, including translation. </blockquote> <hr /> 我不知道未来会怎样。也许 AI 工具最终会更智能。但至少现在，它还处于一个尴尬的中间地带：用得好能帮你节省时间，用不好反而不如不用。

2025/11/26

Rust 背锅了：Cloudflare 故障分析

这两天都在讨论 Cloudflare 的安全事故 <a target="_blank" rel="noopener" href="https://blog.cloudflare.com/18-november-2025-outage/">Cloudflare outage on November 18, 2025</a>，我也写点自己的想法。 这个事故当然引起的范围特别广，我当时正在用 ChatGPT，突然再打开总是提示正在加载，我还以为是自己的 VPN 出了问题，第二天起来才知道 Cloudflare 跪了好久。 没多久 Cloudflare 就发出来了一个非常详细的事故说明。我对里面的场景非常熟悉，因为我之前因为类似的原因把大疆的大部分流量都给搞挂了，具体请看<a target="_blank" rel="noopener" href="https://catcoding.me/p/avoid-mistake/">谈谈工作中的犯错</a>中的配置错误。 这次事故里 Cloudflare 给出了一段 Rust 代码，所以讨论自然会集中在 Rust 上。但把事故归咎于 Rust 本身就不太合理。从他们的场景来看和我之前在 Kong 上做流量分发是非常类似的，无非是这里他们使用了机器学习的技术来判断一个流量是否为恶意请求，而文中所说的 features 文件是训练好的模型数据。 根本原因是数据库的权限更改，导致查询出来的 features 是有重复的，size 变成期望的两倍。而这个错误的配置通过自动同步机制会同步到全球各个节点。每个节点会有一个 bot 模块，根据 features 去计算是否拦截请求，可以想象这是个典型的机器学习分类问题，比如带有什么特征的 HTTP agent、或者是请求的 payload 之类的这些特征综合考虑来计算。这个 <a target="_blank" rel="noopener" href="https://www.cloudflare.com/application-services/products/bot-management/">Bot Management</a>具体内容可以参考其产品说明。 那么如果 features 坏了，这个机器学习模块 bot 能否正常工作？答案是不行的，这点文章已经说明： <blockquote> Both versions were affected by the issue, although the impact observed was different. </blockquote> <blockquote> Customers deployed on the new FL2 proxy engine, observed HTTP 5xx errors. Customers on our old proxy engine, known as FL, did not see errors, but bot scores were not generated correctly, resulting in all traffic receiving a bot score of zero. Customers that had rules deployed to block bots would have seen large numbers of false positives. </blockquote> 事故发生的时候新老组件都有同时在运行，两个组件在这种场景下都无法正常工作，只是错误呈现方式不同。这也解释了我当时用 ChatGPT 给出的浏览器错误是一个拦截错误。 所以这里，unwrap 其实已经算是整个错误的最后一环了。试想一下如果不 unwrap 无非是这几种场景： <ul> <li>因为 FL2 是内存受限的，需要预先分配好内存，最大 limit 本来就只能 load 200 个 feature 的配置，现在尺寸超过了，继续 load 应该就是 OOM 错误，不可恢复。</li> <li>load 到最大 limit 的时候停止，这时候不确定整个 feature 文件是否完整，按照上文所说，bot 用这个配置计算的 request score 是 0，同样请求拦截，甚至日志中可能都看不出来什么错误。</li> </ul> 可以看到这两种情形都差不多，甚至如果按照 <a target="_blank" rel="noopener" href="https://en.wikipedia.org/wiki/Fail-fast_system">fail fast</a> 的策略，日志中会有明显的 500 错误，我不知道 Cloudflare 是否做了错误监控，因为按理来说这种级别的错误是非常明显的，需要立即报警。 很多人都集中讨论在这里的 <code>unwrap</code>: <img src="http://catcoding.me/images/ob_pasted-image-20251120062013.png" alt="" /> 当然这不是最佳实践，但这时候即使使用 <code>.expect("invalid bots input")</code> 这样的写法也好不到哪里去，同样会 500 错误，只是日志里面多留一条错误信息。因为如果不监控错误码，是没人立即发现问题所在的。 更好的做法是对输入进行严格校验，例如检查特征数量和大小。如果不符合预期，应保留旧配置并拒绝加载新数据，而不是加载到一半才发现尺寸异常，更不应该没有 fallback 机制。 当然这里代码没有完全开源，我们从短短的代码片段无法了解整个项目的场景。 从这个经典的错误我们应该发现的是更高维度的警戒，开发管理和运维上有这些问题： <ol> <li>整个配置的更新居然没有灰度发布，比如你模型更新了应该是先同步到 5% 的节点，如果没有问题再继续同步到 20% 的节点，如果没问题再继续。如果有灰度更新，这次的事故不会造成这么大范围的影响，因为在早期应该就观察到了。即使是微软新版本操作系统的发布，都是会分成好几个阶段，比如 ring0, ring1 通常内部团队更新，这样问题就现在暴露在自家团队上。</li> <li>整个配置没有 fallback 机制或者全局开关，现在发现了问题，应该有一个安全的控制开关把配置切换到上一个能工作的配置。</li> <li>监控不到位，关键组件的 500 错误可以说是救命的警告，但从他们的排查过程上看花费了更长的时间在是否是攻击。</li> <li>应该是没有 fuzzing 测试，这种 input 非法的情况甚至需要在单元测试和集成测试中体现。</li> </ol> 网络上很多人玩 Rust 的梗，典型的说法是<a target="_blank" rel="noopener" href="https://x.com/skywind3000/status/1991178281954238851">这种</a>和<a target="_blank" rel="noopener" href="https://x.com/LundukeJournal/status/1991226162442355102">这种</a>: <blockquote> Rust 过去天天宣传“一旦学会 rust，即便是新手也能写出健壮安全的代码”，而真的出现问题了，又开始指责写代码的人是菜鸟。 </blockquote> <blockquote> Cloudflare Rewrote Their Core in Rust, Then Half of the Internet Went Down </blockquote> 这里有点混淆视听，因为 Rust 所说的要解决的安全问题是内存问题，不是逻辑问题。另外，也不是因为重写导致的问题发生。 为什么 Cloudflare 要用 Rust 重写一些关键组件，可以看看他们之前的文章 <a target="_blank" rel="noopener" href="https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/">Incident report on memory leak caused by Cloudflare parser bug</a> 当然我承认在有的公司，可能有的团队完全是为了绩效或者纯个人偏好而发起重写老组件的项目。而更多公司确实是被内存安全问题折磨得怀疑人生才会去重写，像上面文中所说的安全事故是底裤被人扒了，自己还不知道，得让旁观者告诉你才发现。和这次事故的因为工程管理上所做成的安全事故有明显的分别。所以 Rust 所说的安全，是如何避免内存安全。 甚至即使是用了 Rust，一些内存上的问题还是可能因为逻辑上的错误而出现，比如我这个工作中的 PR <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/pull/932">Avoid duplicated retryable tasks</a>就是避免往队列里加了重复的 task 而造成内存用得越来越多。 这次 Cloudflare 的事故就比如一个司机驾驶沃尔沃，结果碰上了山体滑坡被压死了，这种场景下就是换成任意其他品牌的车都会是一个结果。但如果你跑来说，看吧，沃尔沃号称安全，结果还不是一样死，这叫做虚假宣传。 这不叫虚假宣传，而是你对车有了不切实际的幻想。沃尔沃确实不完美，但每个人都会有不同的选择偏好。正常人理解沃尔沃说的安全是大部分场景下、对比其他车会安全一点，而不是说买了沃尔沃就会长生不老了。 永远记住：No Silver Bullet。 <hr /> 总之，这次 Cloudflare 的事故虽然造成的影响挺大，但这个公司也确实足够公开透明，事故分析写得非常清晰，值得大家学习并反思自己组织上有没有类似的工程问题。

2025/11/20

零知识证明入门

无论是在聊 L2、隐私还是下一代 Web 技术，零知识证明都是经常会碰到的技术术语，听起来就像是科幻小说里的东西：向你证明我知道一个秘密，但绝不透露这个秘密本身，这简直是程序员的终极浪漫。 大多数人粗看都会觉得这东西是密码学博士们的专属玩具，我花了一段时间学习后，发现这条通往魔法世界的路似乎有迹可循，希望这篇入门介绍能帮助到更多这方向的学习者。 <h2 id="魔法洞穴"><a href="#魔法洞穴" class="headerlink" title="魔法洞穴"></a>魔法洞穴</h2> 忘掉所有数学，我们先从一个故事开始——“阿里巴巴洞穴”，这是理解 ZKP 最经典的例子，最早由 <a target="_blank" rel="noopener" href="https://en.wikipedia.org/wiki/Jean-Jacques_Quisquater" title="Jean-Jacques Quisquater">Jean-Jacques Quisquater</a> 等人于 1990 年在他们的论文《如何向你的孩子解释零知识协议》中发表。 想象一个环形洞穴，A、B 两个入口在前方，深处有一扇只有知道咒语才能打开的魔法门。Alice 知道咒语，现在，Alice 想向 Bob 证明她知道咒语，但又不想让 Bob 听到咒语是什么。 <img src="http://catcoding.me/images/ob_pasted-image-20250915175921.png" alt="" /> 他们可以这样玩一个游戏： <ol> <li> 承诺 (Commitment)：Alice，作为证明者 (Prover)，独自进入洞穴。然后可以随机从 A 口进，也可以从 B 口进。Bob 在洞外等着，但不知道 Alice 走了哪条路。 </li> <li> 挑战 (Challenge)：Bob 作为验证者 (Verifier)，走到洞口然后随机喊出一个要求，比如：“从 B 通道出来！” </li> <li> 响应 (Response)：Alice 听到要求后： <ul> <li>如果她当初就是从 B 进去的，那简单，就直接从 B 走出来。</li> <li>如果她当初是从 A 进去的，就必须念动咒语打开那扇魔法门穿过去，然后从 B 通道出来。</li> </ul> </li> <li> 验证 (Verification)：Bob 看到 Alice 确实从 B 通道出来了，他对 Alice 的信任度增加了一点。 </li> </ol> 为什么说“一点”呢？因为如果 Alice 不知道咒语，她仍然有 50% 的概率蒙对（比如 Alice 从 B 进去，Bob 恰好也喊了 B）。 但如果这个游戏重复 20 次，Alice 每次都能从 Bob 指定的出口出来，那 Alice 每次都蒙对的概率就只有$$\left(\frac{1}{2}\right)^{20}$$，也就是大约是百万分之一。这时候 Bob 就有十足的把握相信，Alice 确实知道那个咒语。 这个小游戏完美地展示了 ZKP 的三大特性： <ul> <li>完整性 (Completeness)：如果 Alice 真的知道咒语，她总能完成挑战。</li> <li>可靠性 (Soundness)：如果 Alice 不知道咒语，她几乎不可能骗过 Bob。</li> <li>零知识性 (Zero-Knowledge)：在整个过程中，Bob 除了“Alice 知道咒语”这个事实外，没有学到任何关于咒语本身的信息。</li> </ul> 另外我们可以看到一个重要的属性是，零知识证明并非数学意义上的证明，因为可能存在一个很小很小的概率，即可靠性误差 – 作弊的证明者能够骗过验证者，但实际实践中我们几乎可以忽略这个极小的概率。 <h2 id="Where’s-Wally"><a href="#Where’s-Wally" class="headerlink" title="Where’s Wally"></a>Where’s Wally</h2> 还有另外一个比较简单的例子来说明零知识证明： <img src="http://catcoding.me/images/ob_pasted-image-20250916104843.png" alt="" /> Alice 和 Bob 玩游戏看谁先找到 Wally，Alice 说她找到了，她想要证明自己已经得到了结果，但又不想透露更多信息给 Bob，所以她可以用一个几倍面积黑色的纸片遮住整个图画，然后把 Wally 位置那里在黑色纸片上打个小孔，这样 Bob 就可以看到 Wally，而不知道 Wally 在哪儿。注意这里为什么强调几倍面积的黑色纸片，如果是和原图相同大小的纸片，就可能暴露了 Wally 的大致方向和范围。 这个例子展示的 ZKP 另外一个特性是 Prover 通常是更耗费资源的 (从图片中找到 Wally 需要花费一定的时间)，而 Verifier 通常能很快验证。这个特性才能让一些区块链项目利用 ZKP 把链上计算挪到链下计算，而链上只是做验证。 <h2 id="最简单的-ZKP-代码"><a href="#最简单的-ZKP-代码" class="headerlink" title="最简单的 ZKP 代码"></a>最简单的 ZKP 代码</h2> 两个例子很棒，但代码怎么写？ 我接触到的第一个协议叫 Schnorr 身份验证，它要证明的是：“我知道与公钥 <code>h</code> 对应的私钥 <code>x</code>，其中 <code>h = g^x mod p</code>”。这里的“咒语”就是 <code>x</code>，而那扇“魔法门”就是离散对数问题——从 <code>g, h, p</code> 反推出 <code>x</code> 极其困难。 这个协议的“交互式”版本，完美地复刻了洞穴里的“一来一回”： <ol> <li>Prover (我): 随机选个数 <code>k</code>，计算 <code>t = g^k mod p</code> 发给 Verifier。这叫“承诺”。</li> <li>Verifier (你): 随机给 Prover 一个数 <code>c</code>，这叫“挑战”。</li> <li>Prover: 根据收到的 <code>c</code>，计算 <code>r = k - c*x mod (p-1)</code> 并发回。这叫“响应”。</li> <li>Verifier: 验证 <code>g^r * h^c mod p</code> 是不是等于 Prover 一开始给的 <code>t</code>。</li> </ol> 完整代码在<a target="_blank" rel="noopener" href="https://github.com/chenyukang/ss/blob/06a90f7ec0cf7a3527eae2478c7dfea44b8a6240/schnorr-demo/src/main.rs#L8-L41">iteractive_schnorr</a> <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">fn iteractive_schnorr() { // 公开参数：素数 p=204859, g=5, x=6 (秘密), h = 5^6 mod 204859 = 15625 let p: BigInt = BigInt::from(204859u64); let g: BigInt = BigInt::from(5u32); let x: BigInt = BigInt::from(6u32); // 证明者的秘密 let h = g.modpow(&x, &p); // h = g^x mod p // 进行多轮证明 p for _ in 0..20 { // 证明者：生成承诺 t = g^k mod p let mut rng = thread_rng(); let k = rng.gen_bigint_range(&BigInt::one(), &(&p - BigInt::one())); let t = g.modpow(&k, &p); println!("证明者发送 t: {}", t); // 验证者：生成挑战 c (简化到 0..10) let c: BigInt = BigInt::from(rng.gen_range(0..10)); println!("验证者挑战 c: {}", c); // 证明者：响应 r = k - c * x mod (p-1) let order = &p - BigInt::one(); // 阶 let r = (&k - &c * &x).modpow(&BigInt::one(), &order); // 确保正数 println!("证明者响应 r: {}", r); // 验证者：检查 g^r * h^c == t mod p let left = g.modpow(&r, &p) * h.modpow(&c, &p) % &p; if left == t { println!("验证通过！"); } else { println!("验证失败！"); } } } </code></pre> 但一来一回也太麻烦了，互联网应用需要的是一次性的“证明”。经过一番研究，密码学家们想出的一个绝妙技巧，叫做 Fiat-Shamir 启发式证明。 它的核心思想是：用哈希函数来模拟一个不可预测的“挑战者”。 Prover 不再等待 Verifier 给出挑战 <code>c</code>，而是自己计算 <code>c = hash(公开信息, 自己的承诺 t)</code>。因为哈希函数的雪崩效应，Prover 无法预测 <code>c</code> 的值来作弊，这就巧妙地把交互过程压缩了。 我们可以用 Rust 写出这样一个完整的<a target="_blank" rel="noopener" href="https://github.com/chenyukang/ss/blob/06a90f7ec0cf7a3527eae2478c7dfea44b8a6240/schnorr-demo/src/main.rs#L43-L109">非交互式证明程序 fiat_shamir</a>： <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">fn fiat_shamir() { // --- 公开参数 --- // 在真实世界，p 应该是至少 2048 位的安全素数 let p: BigInt = BigInt::from(204859u64); let g: BigInt = BigInt::from(2u64); // Prover 的秘密 (只有 Prover 知道) let secret_x: BigInt = BigInt::from(123456u64); // Prover 的公钥 (所有人都知道) let public_h = g.modpow(&secret_x, &p); println!("--- 公开参数 ---"); println!("p = {}", p); println!("g = {}", g); println!("h = g^x mod p = {}", public_h); println!("-------------------"); // --- PROVER: 生成证明 --- println!("Prover 正在生成证明..."); let mut rng = thread_rng(); let order = &p - BigInt::one(); // 1. 承诺：随机选一个 k, 计算 t = g^k mod p let k = rng.gen_bigint_range(&BigInt::one(), &order); let t = g.modpow(&k, &p); // 2. 挑战 (Fiat-Shamir 的魔法在这里!): // 把公开信息和承诺 t 一起哈希，模拟一个无法预测的挑战 c let mut hasher = Sha256::new(); hasher.write_all(&g.to_bytes_be().1).unwrap(); hasher.write_all(&public_h.to_bytes_be().1).unwrap(); hasher.write_all(&t.to_bytes_be().1).unwrap(); let hash_bytes = hasher.finalize(); let c = BigInt::from_bytes_be(num_bigint::Sign::Plus, &hash_bytes) % &order; // 3. 响应：计算 r = k - c*x (mod order) let cx = (&c * &secret_x) % &order; let mut r = (&k - cx) % &order; if r < BigInt::zero() { r += &order; } println!("证明已生成：(r = {}, c = {})", r, c); println!("-------------------"); // --- VERIFIER: 验证证明 --- println!("Verifier 正在验证证明..."); // Verifier 为了验证，需要自己重新计算 t' = g^r * h^c mod p let gr = g.modpow(&r, &p); let hc = public_h.modpow(&c, &p); let t_prime = (&gr * &hc) % &p; // Verifier 再用算出来的 t' 计算 c' = H(g || h || t') let mut hasher = Sha256::new(); hasher.write_all(&g.to_bytes_be().1).unwrap(); hasher.write_all(&public_h.to_bytes_be().1).unwrap(); hasher.write_all(&t_prime.to_bytes_be().1).unwrap(); let hash_bytes = hasher.finalize(); let c_prime = BigInt::from_bytes_be(num_bigint::Sign::Plus, &hash_bytes) % &order; if c == c_prime { println!("✅ 验证通过！"); } else { println!("❌ 验证失败！"); } } </code></pre> 以上我们通过最简单的代码来演示了 ZKP 的基本思想，从数学原理上都是基于离散对数困难性。 <h2 id="发散到-Passkeys"><a href="#发散到-Passkeys" class="headerlink" title="发散到 Passkeys"></a>发散到 Passkeys</h2> 当我看到 Hash 的时候，我联想到了后台服务的密码存储，比如我们在做一个用户注册和登录功能的时候，为了安全我们是不会去存储用户的原始密码（秘密），而是会使用密码哈希方案，去存储 <code>hash(password + salt)</code>。 但这个密码哈希方案其实也泄露了“知识”，当你登录时会把 <code>123456</code> 发送给服务器，服务器计算 <code>hash("123456" + salt)</code> 并与数据库中的值对比。 <ul> <li>在传输过程中：密码是明文的（当然可以用 TLS/SSL 加密，但服务器在解密后会看到明文）。</li> <li>对服务器而言：服务器在验证那一瞬间是知道你的密码的。</li> <li>如果数据库被盗：攻击者拿到了 <code>hash(password + salt)</code> 的列表。这个哈希值本身就是一条重要的知识！它虽然不是密码原文，但它是密码的一个确定性指纹。攻击者可以进行： <ul> <li>字典攻击：尝试常用密码，计算哈希值来一一比对。</li> <li>彩虹表攻击：用一个预先计算好的哈希值数据库来反查。</li> <li>暴力破解：对所有可能的组合进行哈希计算。</li> </ul> </li> </ul> 这就是为什么我们需要“加盐（salt）”和使用慢哈希函数（如 Argon2, bcrypt），目的就是为了增加攻击者进行上述离线攻击的成本，但无论如何，哈希值本身就是泄露的“知识”。 所以如果我们要更安全，一点“知识”都不泄露，似乎 ZKP 适合做认证服务？注册时不存密码哈希，只存公钥 <code>h</code>。登录时，我发送一个 ZKP 证明，服务器验证一下就行了，数据库被拖库了都没事。 甚至更简单点其实就用公私钥对不是更方便和安全么，Nostr 就是这么做的 (钱包也是这个原理)，private key 是密码，每次发内容就用私钥签名内容，然后把 pubkey 带上，这样任何收到这条消息的节点都可以验证签名是否一致，这样就本质上通过各个 relay 节点形成一个去中心化的社交网络。 我按照这个思路去找 Web 相关的解决方案，业界给出的答案是 Passkeys (基于 WebAuthn 标准)，使用非对称加密来替代密码（私钥不出设备），Passkeys 是这样工作的： <ol> <li>注册： 你的设备（如 iPhone 或 Android 手机）在本地生成一对密钥（私钥和公钥）。私钥安全地存储在设备的硬件安全芯片中，永远不会离开设备。你把公钥发送给网站服务器。</li> <li>登录： <ul> <li>网站向你的设备发送一个“挑战”（一个随机数）。</li> <li>你的设备用私钥对这个“挑战”进行签名，然后把签名发回给网站。</li> <li>网站用它存储的你的公钥来验证这个签名是否有效。</li> </ul> </li> <li>用户体验： 整个过程对于用户来说，可能只是做一次指纹识别或面部识别来授权设备使用私钥。</li> </ol> <img src="http://catcoding.me/images/ob_pasted-image-20250916102634.png" alt="" /> 2019 年 3 月 4 日 WebAuthn Level 1 已经被 W3C 正式发布为“推荐标准 (Recommendation)”，标志着它成为了一个成熟、稳定、官方推荐的 Web 标准。 <h2 id="通过“电路”证明程序的运行"><a href="#通过“电路”证明程序的运行" class="headerlink" title="通过“电路”证明程序的运行"></a>通过“电路”证明程序的运行</h2> 从上面的例子我们看到，ZKP 很适合用来证明 Prover 知道某个秘密，比如一个数 <code>x</code> ，但 ZKP 的用途远不止于此，还可以证明任何计算过程的正确性。 为什么证明一个程序正确运行很重要，因为像以太坊这样的公链，如果所有的节点都运行同样的合约 (本质上就是一段程序代码) 多次，这无疑是很大的浪费，我们想通过 ZKP 把计算挪到链下，这样公链上的节点只需要验证程序被正确执行就可。 “我正确运行了一个复杂的程序，得到了这个输出。”—— 这要怎么证明？ 答案是四个字：万物皆可电路 (Arithmetization)。 ZKP 系统（比如我们后面会聊的 zk-SNARKs）的“世界观”非常单纯，甚至有点笨拙，它看不懂我们人类写的高级代码，比如 <code>if/else</code> 语句、<code>for</code> 循环。 如果我们想让 ZKP 为我们工作，就必须先把我们要证明的东西，翻译成它唯一能听懂的语言。这个翻译过程，就是“算术化 (Arithmetization)”。而“电路”或“约束系统”，就是我们翻译出来的最终稿。这个重写的过程，就是“拍扁 (Flattening)”。你把一个有层次、有复杂逻辑的程序，变成了一个长长的、线性的、只包含最基本算术运算的指令列表。 任何程序，无论多复杂，都可以被“拍扁”成一系列最基础的加法和乘法约束。比如 <code>out = x*x*x + x + 5</code> 这段代码，可以被分解为： <ul> <li><code>v1 = x * x</code></li> <li><code>v2 = v1 * x</code></li> <li><code>v3 = v2 + x</code></li> <li><code>out = v3 + 5</code></li> </ul> 于是，证明“我正确运行了程序”，就转化为了证明“我知道一组数 (x, v1, v2, v3, out) 能同时满足上面这一堆等式”。这个过程，就是把代码逻辑“算术化”，变成了 ZKP 系统可以处理的语言。 那我们来看 Verifier 如何验证上面的计算过程，最原始的当然是根据输入，来一条一条的执行上面被拍平后的指令集，但这样的工作量和自己去执行整个程序就差不多了。 为了避免这种蛮力验证，密码学家们引入了一个极其强大的数学工具：多项式 (Polynomials)。整个魔法流程如下： <ol> <li> Prover 的艰巨任务：将所有约束“编织”进一个多项式 Prover 会执行一个惊人的转换：他会找到一种方法 (Groth16、PLONK、STARKs 等)，将我们前面提到的那一整个约束系统 (<code>x * x - v1 = 0</code>, <code>v1 * x - v2 = 0</code>, …) 全部编码成一个单一的、巨大的多项式方程。 我们可以把这个巨大的“主多项式”记为 <code>P(z)</code>。这个 <code>P(z)</code> 有一个神奇的特性： <blockquote> 当且仅当 Prover 提供的所有见证值 (x, v1, v2…) 都完全正确、满足所有原始约束时，这个主多项式 <code>P(z)</code> 在某些特定的点上才会等于 0。 </blockquote> 如果 Prover 在任何地方作弊，哪怕只修改了一个微不足道的值，最终生成的那个 <code>P(z)</code> 就会是一个完全不同的多项式。 </li> <li> 验证者的捷径 – 随机点检查 (Random Spot-Check) ：现在验证者的问题从“检查成千上万个小等式”变成了“如何验证 Prover 的那个巨大多项式 <code>P(z)</code> 是正确的？” 难道要把整个巨大的多项式传输过来再计算一遍吗？当然不是！这里用到了密码学中一个非常深刻的原理，通常与 Schwartz-Zippel 引理 有关。 它的直观思想是： <blockquote> 如果我有两个不同的、阶数很高的多项式 <code>P(z)</code> 和 <code>F(z)</code>（F 代表伪造的），然后我从一个极大的数域里随机挑选一个点 <code>s</code>，那么 <code>P(s)</code> 和 <code>F(s)</code> 的计算结果相等的概率几乎为零。 </blockquote> 这就给了验证者一个巨大的捷径： <ul> <li>Verifier 不需要关心那个巨大的多项式长什么样。</li> <li>它只需要在一个秘密的、随机选择的点 <code>s</code> 上，对 Prover 的多项式进行一次“抽查”。</li> <li>它通过密码学协议向 Prover 发起一个挑战：“嘿，你声称你有一个正确的多项式，那你告诉我，在 <code>s</code> 这个点上，你的多项式计算出来的值是多少？”</li> </ul> </li> </ol> 所以这里的 ZKP 证明里到底包含什么？ 在一个典型的 zk-SNARK（比如 Groth16）中，那个小小的证明通常是由几个椭圆曲线上的点 (points on an elliptic curve) 组成的。可以把这些“点”想象成一种具备神奇数学特性的高级指纹。这些点就是 Prover 对他构造的那些巨大多项式（比如 <code>A(x)</code>, <code>B(x)</code>, <code>C(x)</code>，它们共同构成了我们之前说的那个主多项式 <code>P(x)</code>) 的“承诺”。 这里的魔法在于 Verifier 不需要通过这些“点”来反推出原始的多项式。相反，他可以直接在这些“点”上进行一种特殊运算，这种运算的结果等价于在原始多项式上进行“随机点检查”。这个特殊的运算，就是 zk-SNARKs 的核心引擎之一：配对 (Pairings)。并非所有 ZK 架构都用配对；Groth16/部分 KZG-based 系统用配对，STARKs 则用哈希/FRI 等替代方案。 让我们把整个流程串起来 (zk-SNARK)，看看 Prover 的多项式是如何被“隔空”验证的： <ol> <li> 准备阶段 (Setup)： <ul> <li>协议约定好了一套公共参数（包含一个“验证密钥”）。这个验证密钥里编码了“游戏规则”，包括对程序正确性的期望。</li> </ul> </li> <li> Prover 的工作： <ul> <li>他有他的秘密“见证 (Witness)”。</li> <li>他按照约定，将程序的约束系统转化成几个巨大的多项式 <code>A(x), B(x), C(x)</code>。（这些多项式满足 <code>A(x) * B(x) - C(x) = H(x) * Z(x)</code> 的关系，这是 R1CS 算术化的结果）。</li> <li>关键一步：他并没有把这些多项式发出去。而是用他的“证明密钥”，计算出这几个多项式在某个秘密点 <code>s</code> 上的椭圆曲线点表示。这些点就是对多项式的“承诺”。</li> <li>最终生成的证明 (Proof)，就是由这几个计算出来的椭圆曲线点组成的，它非常小。</li> </ul> </li> <li> Verifier 的工作： <ul> <li>Verifier 收到这个由几个点组成的、小小的证明。</li> <li>Verifier 完全看不到 Prover 的任何多项式 (<code>A(x)</code>, <code>B(x)</code>, <code>C(x)</code>)。</li> <li>Verifier 拿出“验证密钥”，并将 Prover 提交的这几个“承诺点”代入一个预设的配对验证方程 (Pairing Verification Equation)。</li> </ul> 这个方程被设计得极其巧妙，它的等号左边和右边分别对应着 Prover 原始多项式关系 <code>A*B-C=H*Z</code> 的加密形式。 <blockquote> 当且仅当 Prover 原始的、未知的那些多项式确实满足正确的数学关系时，这个配对验证方程的等号才能成立。 </blockquote> </li> </ol> 所以： <ul> <li>证明里是什么？ 是对 Prover 秘密多项式的密码学承诺（通常是几个椭圆曲线点）。</li> <li>Verifier 如何知道多项式？ 他不需要知道。他只需要知道验证规则（即那个配对验证方程）。</li> <li>如何验证？ 他把 Prover 的“承诺”（证明）代入“规则”（验证方程）。如果方程成立，他就知道那些他看不见的、被承诺了的多项式一定是正确的，进而推断出 Prover 的原始计算是正确的。</li> </ul> Prover 把“我知道所有题的答案”这个事实，通过复杂的计算，浓缩成了一个包含几个关键“密码学指纹”的信封（证明）。Verifier 不用拆开信封看所有答案，他只需要用一种特殊的“X 光机”（配对验证）照一下这个信封，就能瞬间知道里面的答案是不是都对。 <h2 id="ZKP-相关的应用"><a href="#ZKP-相关的应用" class="headerlink" title="ZKP 相关的应用"></a>ZKP 相关的应用</h2> 区块链因为其去中心化和对隐私性的严苛要求，ZKP 非常适合用在这个领域。 <h4 id="扩容-ZK-Rollups-让以太坊快如闪电"><a href="#扩容-ZK-Rollups-让以太坊快如闪电" class="headerlink" title="扩容 (ZK-Rollups): 让以太坊快如闪电"></a>扩容 (ZK-Rollups): 让以太坊快如闪电</h4> 以太坊慢又贵，因为每个节点都要重复执行每笔交易。ZK-Rollup 的思路就像是找了个超级课代表： <ol> <li>在链下 (L2) 执行成千上万笔交易。</li> <li>为“我已正确处理了这一切”这个声明，生成一个微小的 ZK 证明。</li> <li>把这个证明提交到链上 (L1)。</li> </ol> L1 的所有节点不再需要重复计算那几千笔交易，它们只需要做一件极其廉价的事：验证那个 ZK 证明。就像老师检查作业，不再需要自己从头算一遍，只需要看一眼课代表盖的“全对”印章。 总而言之，Rollup 的核心创新在于将计算执行与数据结算分离。它利用 ZKP 等密码学技术，将繁重的“执行”环节放在链下，然后只把一个轻量的“证明”和必要数据放在链上进行“结算”，从而实现了对以太坊主网的大规模扩容。 <h4 id="隐私-Tornado-Cash-你的钱，只有你知道"><a href="#隐私-Tornado-Cash-你的钱，只有你知道" class="headerlink" title="隐私 (Tornado Cash): 你的钱，只有你知道"></a>隐私 (Tornado Cash): 你的钱，只有你知道</h4> Tornado Cash 是个混币器，你存入 100 ETH，然后从一个全新的地址取出来，没人能把这两者联系起来。它的机制是： <ul> <li> 存款：你在本地生成一个秘密凭证（包含<code>Secret</code>和<code>Nullifier</code>），然后计算出它的哈希值——“承诺 (Commitment)”，把承诺和钱一起存入合约。 </li> <li> 取款：你用一个全新的地址，提交一个 ZK 证明，这个证明：“我知道某个树叶的 Secret 且未被花费”，同时提交 nullifier（通常是对秘密做散列得到的唯一标识）以标记已花费。这样合约无需关联存款者身份即可阻止双花。 </li> </ul> 整个过程，合约就像个盲人会计，它不知道是“谁”存的，也不知道取款对应的是“哪一一笔”存款，它只负责验证 ZKP 规则是否被遵守。 <h3 id="ZKP-在-AI-的应用"><a href="#ZKP-在-AI-的应用" class="headerlink" title="ZKP 在 AI 的应用"></a>ZKP 在 AI 的应用</h3> ZKP 应用在大模型也是最前沿、激动人心的领域。例如 AI 模型（尤其是大型语言模型）的权重是极其宝贵的商业机密。用户的数据又极其隐私。如何让一个 AI 模型在不暴露其内部权重的情况下，处理用户的隐私数据，并向用户证明它确实是用了那个宣称的高级模型，而不是一个廉价的“冒牌货”？ ZKP 解决方案 (ZKML - Zero-Knowledge Machine Learning)：模型推理证明：模型提供方可以对一次推理过程生成 ZK 证明，证实“我使用我宣称的那个模型（其哈希值是公开的），处理了你的输入数据，得出了这个输出结果”。这向用户保证了模型的真实性，同时保护了模型的知识产权。 数据隐私证明：用户可以对自己的数据生成 ZK 证明，证实“我的数据（例如医疗记录）符合某个特定标准（例如，有某种疾病特征）”，然后将这个证明提交给 AI 模型进行统计或研究，而无需上传原始的隐私数据。 这里有更多相关的资料：<a target="_blank" rel="noopener" href="https://world.org/blog/engineering/intro-to-zkml">An introduction to zero-knowledge machine learning (ZKML)</a> <h2 id="零知识证明和硬件"><a href="#零知识证明和硬件" class="headerlink" title="零知识证明和硬件"></a>零知识证明和硬件</h2> 前面我们谈到，在 ZKP 中Prover（证明者）端计算量最大，主要集中在以下几个方面： <ul> <li>多项式承诺方案：这是现代零知识证明（如 zk-SNARKs、zk-STARKs）的核心。证明者需要将计算任务转化为多项式，并对这些多项式进行一系列复杂的加密运算，例如多项式插值、求导、卷积、快速傅里叶变换（FFT） 等。这些运算的复杂度很高，尤其是当要证明的计算规模很大时。</li> <li>同态加密运算或椭圆曲线点运算：在一些零知识证明协议中，为了生成和验证证明，需要进行大量的椭圆曲线点乘运算。这种运算在数学上非常耗时，尤其是当需要处理大量的点时。</li> <li>哈希函数计算：为了将复杂的数据结构或计算结果进行压缩和承诺，证明者会使用到大量的加密哈希函数，例如 SHA-256、Poseidon 等。</li> </ul> 而在Verifier（验证者）端计算量相对较小，这也是零知识证明的重要优势之一，但它仍然需要进行一些关键的计算，比如： <ul> <li>椭圆曲线配对运算（Pairing）：在 zk-SNARKs 等协议中，验证者需要进行椭圆曲线配对运算来验证证明。这是一种特殊的加密操作，虽然比证明者的计算量小得多，但仍然需要一定的计算资源。</li> <li>哈希函数和多项式求值：验证者也需要进行一些哈希计算和多项式求值来检查证明的有效性。</li> </ul> 总的来说，零知识证明的计算量主要耗费在Prover端，因为它需要对整个计算过程进行完整的加密转换和证明生成，而这些步骤依赖于高复杂度的多项式和椭圆曲线运算。所以我们看到一些专门为此服务的硬件 FPGA、ASIC、GPU。 而 RISC-V 因为其可扩展性和模块化设计、开源的标准等优势，是实现零知识证明硬件加速的重要“基石”之一，<a target="_blank" rel="noopener" href="https://dev.risczero.com/api/getting-started">risc0 是个值得关注的项目</a> <h2 id="更多参考"><a href="#更多参考" class="headerlink" title="更多参考"></a>更多参考</h2> <ul> <li> <a target="_blank" rel="noopener" href="https://www.youtube.com/watch?v=fOGdb1CTu5c">Computer Scientist Explains One Concept in 5 Levels of Difficulty</a> 向不同知识背景的人介绍零知识证明。 </li> <li> 要深入理解 ZKP 需要更多数学知识，<a target="_blank" rel="noopener" href="https://vitalik.eth.limo/general/2017/11/09/starks_part_1.html">STARKs, Part I: Proofs with Polynomials</a> 以太坊创始人的博客，他用相对简单的语言解释极其复杂的密码学概念，是 ZKP 入门最经典的读物。 </li> <li> <a target="_blank" rel="noopener" href="https://rareskills.io/zk-book">The zk-book</a> 一个非常棒的在线开源书籍，逐步讲解构建一个零知识证明系统所需的数学知识，从有限域、椭圆曲线到多项式承诺，内容非常扎实。 </li> </ul>

2025/9/26

RISC-V from Scratch: Building a Virtual Machine

I’ve always wanted to learn RISC-V. A few days ago, I finally got my hands dirty with it now. This post will guide you through the process of building a simple RISC-V VM from the ground up, using Rust as our implementation language. <h2 id="Understanding-the-Core-Concepts"><a href="#Understanding-the-Core-Concepts" class="headerlink" title="Understanding the Core Concepts"></a>Understanding the Core Concepts</h2> Before writing any code, I need to grasp the fundamentals of RISC-V. <ul> <li>RISC vs. CISC: RISC (Reduced Instruction Set Computing) architectures use a small, highly optimized set of instructions. This is in contrast to CISC (Complex Instruction Set Computing), which has a large number of complex instructions. RISC-V’s simplicity makes it ideal for building a VM.</li> <li>Modular Architecture: RISC-V has a base instruction set (RV32I for 32-bit systems) and optional extensions like M (for multiplication) or F (for floating-point). We’ll focus on the RV32I base to keep things simple.</li> <li>The Three Pillars: At its core, a CPU (and thus our VM) consists of three main components: <ul> <li>Registers: A small set of high-speed memory locations used for calculations. RISC-V has 32 general-purpose registers (<code>x0</code>-<code>x31</code>).</li> <li>Memory: A much larger space for storing program code and data.</li> <li>Program Counter (PC): A special register that holds the memory address of the next instruction to be executed.</li> </ul> </li> </ul> We can get all the details of RISC-V instructions from <a target="_blank" rel="noopener" href="https://riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+Technical+Specifications">RISC-V Technical Specifications</a>. <h2 id="The-VM’s-Core-Logic"><a href="#The-VM’s-Core-Logic" class="headerlink" title="The VM’s Core Logic"></a>The VM’s Core Logic</h2> Our VM is essentially a program that emulates a real CPU’s behavior. The core of our VM is the instruction loop, which follows a simple fetch-decode-execute cycle. <ol> <li>Fetch: Read the 32-bit instruction from the memory address pointed to by the PC.</li> <li>Decode: Parse the instruction’s binary code to determine its type and what operation to perform.</li> <li>Execute: Perform the operation (e.g., an addition) and update the relevant registers or memory.</li> </ol> Here’s a simplified Rust code snippet to illustrate the <code>VM</code> structure and the <code>run</code> loop: <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">pub struct VM { x_registers: [u32; 32], pc: u32, memory: Vec<u8>, } impl VM { pub fn run(&mut self) { loop { // 1. Fetch the instruction let instruction = self.fetch_instruction(); // 2. Decode let decoded_instruction = self.decode(instruction); // 3. Execute self.execute_instruction(decoded_instruction); // 4. Increment the PC self.pc += 4; } } } </code></pre> The fetch instruction turns out to be very simple, we just load 4 bytes in little-endian format into a u32 integer: <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust"> /// Fetch 32-bit instruction from memory at current PC fn fetch_instruction(&self) -> Option<u32> { let pc = self.pc as usize; if pc + 4 > self.memory.len() { return None; } // RISC-V uses little-endian byte order let instruction = u32::from_le_bytes([ self.memory[pc], self.memory[pc + 1], self.memory[pc + 2], self.memory[pc + 3], ]); Some(instruction) } </code></pre> Then we need to decode the integer into a RISC-V instruction. Here’s how we decode <code>IType</code> and <code>RType</code> instructions. The specifications for these two types are: <img src="http://catcoding.me/images/ob_pasted-image-20251117091305.png" alt="" /> <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">/// Decode 32-bit instruction into structured format fn decode(&self, code: u32) -> Option<Instruction> { let opcode = code & 0x7f; match opcode { 0x13 => { // I-type instruction (ADDI, etc.) let rd = ((code >> 7) & 0x1f) as usize; let rs1 = ((code >> 15) & 0x1f) as usize; let funct3 = (code >> 12) & 0x7; let imm = (code as i32) >> 20; // Sign-extended Some(Instruction::IType { rd, rs1, imm, funct3, }) } 0x33 => { // R-type instruction (ADD, SUB, etc.) let rd = ((code >> 7) & 0x1f) as usize; let rs1 = ((code >> 15) & 0x1f) as usize; let rs2 = ((code >> 20) & 0x1f) as usize; let funct3 = (code >> 12) & 0x7; let funct7 = (code >> 25) & 0x7f; Some(Instruction::RType { rd, rs1, rs2, funct3, funct7, }) } _ => None, // Unsupported opcode } } </code></pre> Then we want to execute the instruction, just following the specification. For demonstration purposes, we return the execution debug string as a result: <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">/// Execute decoded instruction fn execute(&mut self, instruction_type: Instruction) -> Result<String, String> { match instruction_type { Instruction::IType { rd, rs1, imm, funct3, } => { match funct3 { 0x0 => { // ADDI - Add immediate self.write_register(rd, self.x_registers[rs1] + imm as u32); Ok(format!( "ADDI x{}, x{}, {} -> x{} = {}", rd, rs1, imm, rd, self.x_registers[rd] )) } _ => Err(format!("Unsupported I-type funct3: {:#x}", funct3)), } } Instruction::RType { rd, rs1, rs2, funct3, funct7, } => { match (funct3, funct7) { (0x0, 0x00) => { // ADD - Add registers let result = self.x_registers[rs1] + self.x_registers[rs2]; self.write_register(rd, result); Ok(format!( "ADD x{}, x{}, x{} -> x{} = {}", rd, rs1, rs2, rd, self.x_registers[rd] )) } (0x0, 0x20) => { // SUB - Subtract registers let result = self.x_registers[rs1] - self.x_registers[rs2]; self.write_register(rd, result); Ok(format!( "SUB x{}, x{}, x{} -> x{} = {}", rd, rs1, rs2, rd, self.x_registers[rd] )) } _ => Err(format!( "Unsupported R-type instruction: funct3={:#x}, funct7={:#x}", funct3, funct7 )), } } } } </code></pre> The simplest VM code is available at: <a target="_blank" rel="noopener" href="https://github.com/chenyukang/ss/tree/main/risc_vm_v0">riscv-vm-v0</a> <h2 id="From-Rust-to-RISC-V-binary"><a href="#From-Rust-to-RISC-V-binary" class="headerlink" title="From Rust to RISC-V binary"></a>From Rust to RISC-V binary</h2> Now we need to write more complex assembly code for testing our VM, but we don’t want to write assembly code by hand. To test our VM, we will write Rust code then use cross-compile toolchains to compile it into RISC-V executable files. <ol> <li>Prepare the Environment: Install the <code>riscv32imac-unknown-none-elf</code> target toolchain. This is a bare-metal target, meaning it doesn’t rely on any operating system.</li> </ol> <pre class="line-numbers language-bash" data-language="bash"><code class="language-bash">rustup target add riscv32imac-unknown-none-elf </code></pre> Next, you’ll need a RISC-V linker. You can get this from the official RISC-V GNU toolchain. <pre class="line-numbers language-bash" data-language="bash"><code class="language-bash"># On Linux or macOS sudo apt-get install gcc-riscv64-unknown-elf # Alternatively, on macOS brew install riscv-gnu-toolchain </code></pre> Note: The <code>gcc-riscv64-unknown-elf</code> package includes both 32-bit and 64-bit tools. <ol start="2"> <li>Write “Bare-Metal” Rust: Our Rust program must be written for a “bare-metal” environment, meaning you cannot use the standard library and must provide your own entry point and panic handler.</li> </ol> <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">#[unsafe(no_mangle)] pub extern "C" fn _start() { let mut sum = 0; for i in 1..=10 { sum += i; } // Store the result (which should be 55) in a known memory location. let result_ptr = 0x1000 as *mut u32; unsafe { *result_ptr = sum; } } #[panic_handler] fn panic(_info: &PanicInfo) -> ! { loop {} } </code></pre> <ol start="3"> <li>Cross-Compile: Use <code>cargo</code> with the specific target and a linker script to build the executable. We need to add options for Cargo in <code>.cargo/config.toml</code></li> </ol> <pre class="line-numbers language-toml" data-language="toml"><code class="language-toml">[target.riscv32imac-unknown-none-elf] rustflags = ["-C", "link-arg=-Tlink.ld"] </code></pre> The content for <code>link.ld</code> is as follows. It tells the linker the layout of the binary file generated. Notice that we specify the entry point at address <code>0x80</code>: <pre class="line-numbers language-plain" data-language="plain"><code class="language-plain">OUTPUT_ARCH(riscv) ENTRY(_start) SECTIONS { . = 0x80; .text : { *(.text.boot) *(.text) } .rodata : { *(.rodata) } .data : { *(.data) } .bss : { *(.bss) } } </code></pre> Then we can build the program to a binary: <pre class="line-numbers language-shell" data-language="shell"><code class="language-shell">cargo build --release --target riscv32imac-unknown-none-elf </code></pre> <ol start="4"> <li>Disassemble and check the binary code: We can use the tool <code>riscv64-unknown-elf-objdump</code> to double-check the generated binary file:</li> </ol> <pre class="line-numbers language-shell" data-language="shell"><code class="language-shell">riscv64-unknown-elf-objdump -d ./demo/target/riscv32imac-unknown-none-elf/release/demo ./demo/target/riscv32imac-unknown-none-elf/release/demo: file format elf32-littleriscv Disassembly of section .text._start: 00000080 <_start>: 80: 4501 li a0,0 82: 4605 li a2,1 84: 45ad li a1,11 86: 4729 li a4,10 88: 00e61763 bne a2,a4,96 <_start+0x16> 8c: 46a9 li a3,10 8e: 9532 add a0,a0,a2 90: 00e61863 bne a2,a4,a0 <_start+0x20> 94: a809 j a6 <_start+0x26> 96: 00160693 addi a3,a2,1 9a: 9532 add a0,a0,a2 9c: 00e60563 beq a2,a4,a6 <_start+0x26> a0: 8636 mv a2,a3 a2: feb6e3e3 bltu a3,a1,88 <_start+0x8> a6: 6585 lui a1,0x1 a8: c188 sw a0,0(a1) aa: 8082 ret </code></pre> The complete cross-compile Rust code is available at: <a target="_blank" rel="noopener" href="https://github.com/chenyukang/ss/tree/main/riscv_vm/demo">riscv-demo</a> <h2 id="Using-the-VM-to-Execute-Binary"><a href="#Using-the-VM-to-Execute-Binary" class="headerlink" title="Using the VM to Execute Binary"></a>Using the VM to Execute Binary</h2> The first problem is how do we parse the executable file? It turns out there is a crate called <code>elf</code> that can help us parse the header of an ELF file. We extract the interested parts from the header and record the <code>base_mem</code> so that we can convert <code>virtual address</code> to <code>physical address</code>. Of course, we also load the code into memory: <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">pub fn new_from_elf(elf_data: &[u8]) -> Self { let mut memory = vec![0u8; MEM_SIZE]; let elf = ElfBytes::<elf::endian::AnyEndian>::minimal_parse(elf_data) .expect("Failed to parse ELF file"); // Get the program entry point let entry_point = elf.ehdr.e_entry as u32; // Iterate through program headers, load PT_LOAD type segments for segment in elf.segments().expect("Failed to get segments") { if segment.p_type == PT_LOAD { let virt_addr = segment.p_vaddr as usize; let file_size = segment.p_filesz as usize; let mem_size = segment.p_memsz as usize; let file_offset = segment.p_offset as usize; // Address translation: virtual address -> physical address let phys_addr = virt_addr - entry_point as usize; // Check memory boundaries if phys_addr + mem_size > MEM_SIZE { panic!( "Segment is too large for the allocated memory. vaddr: {:#x}, mem_size: {:#x}", virt_addr, mem_size ); } // Copy data from ELF file to memory if file_size > 0 { let segment_data = &elf_data[file_offset..file_offset + file_size]; memory[phys_addr..phys_addr + file_size].copy_from_slice(segment_data); } } } let mut vm = VM { x_registers: [0; 32], // Set directly to entry_point to match the linker script pc: entry_point, memory, mem_base: entry_point, }; vm.x_registers[0] = 0; vm } </code></pre> What’s left is that we need to extend our VM to support all the instruction formats used in this binary file, including <code>li</code>, <code>bne</code>, <code>beq</code>, etc. There are 16-bit compressed instructions, so we can’t always increment the PC by 4; sometimes we only need to increment it by 2 for shorter ones. Another interesting thing is that some of them are conditional jump instructions, so we need to get the return <code>new_pc</code> from the execution of the instruction. So now we need to update the core logic of fetch and execution of instructions: <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">// Check the lowest 2 bits to determine instruction length if first_half & 0x3 != 0x3 { // 16-bit compressed instruction pc_increment = 2; new_pc = self.execute_compressed_instruction(first_half); } else { // 32-bit instruction pc_increment = 4; if physical_pc.saturating_add(3) >= self.memory.len() { break; } let second_half = u16::from_le_bytes([ self.memory[physical_pc + 2], self.memory[physical_pc + 3], ]); let instruction = (second_half as u32) << 16 | (first_half as u32); if instruction == 0 { break; } new_pc = self.execute_instruction(instruction); } </code></pre> The complete new VM which can run compiled RISC-V binary files is available at: <a target="_blank" rel="noopener" href="https://github.com/chenyukang/ss/tree/main/riscv_vm">riscv-vm</a> <h2 id="References"><a href="#References" class="headerlink" title="References"></a>References</h2> <ul> <li><a target="_blank" rel="noopener" href="https://riscv.org/technical/specifications/">RISC-V Technical Specifications</a></li> </ul>

2025/9/23

Rust Week 2025 杂记

5 月中旬我参加了在荷兰 Utrecht 举行的 Rust Week，想来可以写篇文章记录下所见所闻。 我年初和 Rust 基金会邮件确认参加，但直到 4 月 9 日才开始动手申请签证。在深圳办理荷兰签证流程简单，只需提交材料并录指纹，但我嫌麻烦找了中介帮忙。据说大概也就两周多就会有结果，但直到五一查询还是没结果，中介说可以加 600 元加急。看到官网解释近期审批延迟，我便花钱加急，第二周拿到了签证。不知道这其中是否有猫腻，但确实有华为的朋友同样卡在那个节点审批，结果没有如期下来。 从广州白云机场有直飞阿姆斯特丹的航班，只是起飞时间大概是凌晨 1 点多。飞机上座位空间狭小，难以入睡，趴着或躺着都不舒服，到了阿姆斯特丹是早晨 6 点多。通过海关后，我因不熟悉荷兰语而有些迷茫。由于未携带 Visa 卡，只能使用现金，幸好两位路人热心相助。我直接购买火车票前往 Utrecht，约于上午 10 点抵达酒店。因为时间还比较早没有空房，我把行李箱放在酒店自己去城里逛逛。 Utrecht 据说是荷兰第四大城市，交通方便。我查了一下，人口约为 30 万，这在中国估计只算是小镇了。我信步漫游，城市整洁如画，绿树成荫，空气清新怡人。由于是周六，商户大多已关门，街上行人多在跑步或散步，整体人口密度较低。5 月应该是荷兰最好的天气，不冷不热，只要不在太阳下就会感觉凉凉的。荷兰人身高马大，路上的自行车很多而汽车非常少，大多都是 A 级车，豪车基本没看到。很常见的场景是父母骑自行车，拉着个大篮筐里载着一两个小孩。 街头的人们神情轻松自在，仿佛时间在这里慢了下来。路旁一个年轻人倚着树，手捧书本读得入了神，旁边的金毛小狗却不耐烦地扯着牵绳，发出几声撒娇。草坪边，几个人懒洋洋地躺在长椅上晒着太阳，像是被微风哄睡了，手中未喝完的咖啡杯歪在一旁。运河边，一对白发苍苍的夫妇沐浴在阳光中，丈夫似乎想起什么趣事，侧身在妻子耳边低语几句，惹得她轻笑出声，随即两人轻轻接吻。这些场景对我这个匆匆旅客而言，宛如《楚门的世界》的开场，美好却略显不真实。 <img src="http://catcoding.me/images/ob_pasted-image-20250607184354.png" alt="" /> 更实际的问题是吃饭，到了中午饭点，主城区我都快粗略走完了，但只有一两个餐厅开着。无奈，我去超市买了点面包和牛奶当作午饭，顺便看了一下日用品的物价，水果和蔬菜比较贵，牛奶之类的东西便宜点。回到酒店有了空房，前台给我办理了入住，稍微睡了一个来小时，起来后已经是下午三点多了，这时候我才后悔今天应该多在阿姆斯特丹逛逛，可玩的地方应该更多。我只能又往还没逛的城市另一边漫步，城市面貌都挺漂亮，不过总体而言房子大多是联排，空间不是很大，不像多年前第一次逛圣何塞那样户户大别墅带给我震撼。 晚上看到 zulip 里有消息，和我一样提前到达的人开始组局吃饭了。我们一行四人挑了个餐厅聊了两个小时左右，一个美国教授、一个德国年轻学生、还有一个马来西亚人，聊的都是技术趣闻和 Rust 相关的。但我这时候有点困了，所以主要在听。没想到饭局结束后都晚上九点半了，天还微微暗，这时候 Utrecht 城市运河旁边的餐厅开着，游客熙熙攘攘，这大概是最热闹的时候了。 5.12 是周一，这天没有什么特别的活动，明天才是主会议的第一天，所以很多人还在路上。我上午去了会场注册领了参会牌，然后在会场逛了逛。我陆陆续续认出来了一些用真实照片做 Github 头像的人，期间和一个老哥聊了起来，他常年维护着 rustc-dev 这份开发文档，之前我提 PR 的时候帮我 Review 过。到了饭点就一起边聊边往市区走，我们想爬到教堂的楼顶参观，据说这里是城市的最高点，风景应该不错。去了之后发现一定要预约和请讲解员，而且一个下午才几十号人，便放弃了。走了 20 多分钟，都没找到什么看起来好吃的餐厅，碰到一个超市又买了点面包和牛奶，在附近的公园旁当作午餐。这老哥来自南非，比我大几岁，之前维护过 Debian 上的一些包。他给 Rust 做开源贡献快十年了，大多是一些文档类的工作。他现在全职远程在一个 Rust 相关的咨询公司工作，主要日常还是做些开源维护工作。 下午没什么特别的安排，我参加了一个 workshop。我们要做的是一个腐蚀的 Rust 实体 Logo，可以在背后用马克笔写上自己的名字，用磨砂纸摩擦一遍，然后用酒精还有各种化学染料涂在 Logo 的表面，等待一段时间就会形成腐蚀的效果和图案，我也跟着做了一个，是不是看起来很漂亮？但我第二天忘记去取了 :) <img src="http://catcoding.me/images/ob_pasted-image-20250607173912.png" alt="" /> 因为时差原因，我下午就开始犯困，在酒店睡了一下午后，看到群里又有人开始组饭局，这次是都是同住个酒店的人，我们在酒店大堂集合，总共大概有 10 个人左右。我看到了更多的熟悉面孔和 id，有几个维护 Rust 多年的成员，碰到了我第一次提 PR 帮我 review 的 estebank。 我们找了个店喝了点啤酒，然后服务员过来说后厨到点下班了，所以不提供晚餐。这对于中国人来说真是难以置信，哪有这么做生意的呢，这里果然是到点下班比挣钱更重要。后来我们坐火车去了主城区，接连询问了两家餐厅，均表示已快到打烊时间 (其实也就快晚上 9 点)，最后终于找了一个运河边上的餐厅坐下。我点了个海鲜意面，味道非常不错，20 欧元也值了，但没想到这就是我这一周吃得最满意的一顿饭了。 <img src="http://catcoding.me/images/ob_ad6b5b55398d6fe5b5c743a2f2bcd95c.jpg" alt="" /> 一群程序员吃饭聊的还是技术话题，作为 Rust 程序员和维护者，吐槽 C++ 是不可避免的，有的聊得比较细节，比如如何提高链接速度之类的。总体来说气氛非常好，大概是很多人都远程工作，平时无法找到这么一群志同道合的人聊天，而且这些人平时在开源社区里合作交流，能见面聊聊自然是非常开心的。 有趣的事发生在我们用完餐之后，老板估计是犯懒，结账说不能分开支付，所以我们需要找个人先替大家把单买了，然后大家再转给他。一群程序员大眼对小眼，那气氛有点尴尬。后来是 eholk 站出来先买了单，然后一群人围着他看账单转钱给他，反正是异常耗时和麻烦，看来还是中国手机支付 AA 来得更方便。 5.13 是 Conference 的第一天，主题很多，而且分了三个分会场：主会场、生态、行业应用。这两天参会的人非常多，我估计得有 500 来人。公司展台比较少，右边有 Jetbrains、Zed、左边有一些硬件相关的和 Rust 培训咨询相关的公司，华为有个招聘展台。现场看到了其他几个中国人，聊了一下他们是在 Cargo 项目团队做开源贡献的。在会场我见到了更多熟悉的面孔，因为挂牌上有 Github 账号，所以基本盯着对方的名片看看就知道是否打过交道，可以说这是一个大型的网友见面会。我在社区里面断断续续也做了四年，有的人只是通过 review comments 交流，有的人通过 zulip 私聊过，能见面聊聊真是一种难得的体验。另外我和华为爱尔兰可信计算实验室的余教授聊了比较久。 这次会场居然选在了一个电影院，一楼是一个大的会展活动空间，整体非常宽敞。这是我第一次坐在电影院听技术演讲，座位宽敞、音效和视觉都棒极了，他们甚至做了一个类似电影的<a target="_blank" rel="noopener" href="https://www.youtube.com/watch?v=E56STygm8i4">片头动画</a>，看起来诙谐可爱。第一天最热的主题应该是 Alex Crichton 的 10 Years of Rust，我第一场也去听了这个演讲。推荐任何对 Rust 感兴趣的去看看这个<a target="_blank" rel="noopener" href="https://www.youtube.com/watch?v=zIm6xIOLVkA&ab_channel=RustNL">视频</a>。 <img src="http://catcoding.me/images/ob_pasted-image-20250608105940.png" alt="" /> Rust 在嵌入式领域取得了长足的进展，所以也是这次会议的热点，<a target="_blank" rel="noopener" href="https://youtu.be/84bX1nPDBr4?t=13035">It’s Embedded Rust Time</a>这个演讲谈到长远来看这个领域里的人希望 Rust 能得到更多应用，volvo 的人分享了他们使用 Rust 开发和发布第一个 ECU 的过程。来自南京大学的 Xiaolong 分享了一个异步任务编程框架 Dagrs。<a target="_blank" rel="noopener" href="https://www.youtube.com/watch?v=UOP9q3BRiIA&t=24425s">Refactoring in Rust</a> 分享了些重构技巧，把一个典型场景的代码变得漂亮易维护。 <a target="_blank" rel="noopener" href="https://www.youtube.com/watch?v=UOP9q3BRiIA&t=26954s">We deserve helpful tools</a> 介绍了编译器里的错误信息如何更友好，很多初学者喜欢 Rust 的一个原因是 rustc 的错误信息看起来人性化又有帮助，这是社区里很多人努力的结果。 午饭期间，有个比利时的工程师来拼桌，所以就聊了起来，他几年前去广州待过一个多月，所以有些共同话题。他业余时间喜欢折腾硬件和数学，组织了一个学习系统编程的<a target="_blank" rel="noopener" href="https://sysghent.be/">小组</a>。这个人非常健谈有趣，我们一起聊了聊各自的工作经历等，在 Linkedin 上加了个好友。 第一天会议结束后，我跟着 estebank 一行八个人出去就餐。这次我们选的是一家印度餐厅，因为已经有两三天没吃米饭了，我点了一个看起来有点辣的鱼加米饭，结果菜上来之后让我震惊，不管味道还是品相都达不到沙县小吃级别，但这饭饭菜居然也要 20 欧，这是我这周吃过的最差的一顿饭了吧。这周后面几天的晚上我都不想吃晚饭，一方面是白天在会场吃了很多零食，另一方面到了晚上七点左右我就非常困，这边晚上天黑的时间短，所以我通常回到酒店就睡觉。 5.14 第二天我首先去听了 <a target="_blank" rel="noopener" href="https://www.youtube.com/watch?v=kDVRkcKHCLc&ab_channel=RustNL">Rust for Linux</a> 这个演讲，这场非常火爆，看来大家都非常关注这个领域，无论是在贡献者数量还是提交到主线内核中的代码行数方面，增长都非常快。然后我去听了大部分 Rust Project track 相关的演讲，compiler-errors 没写 PPT，居然直接在 VsCode 里面<a target="_blank" rel="noopener" href="https://www.youtube.com/watch?v=aFG5KtpEynk&ab_channel=RustNL">讲解代码</a> 。<a target="_blank" rel="noopener" href="https://youtu.be/8vz_pg-eI4I?t=29">The Rust Vision Doc and You</a>讲解了如何获取用户的意见和反馈，Rust 在全世界的整体采用情况，很高兴看到社区像是对待一个产品一样来发展一门编程语言。 所有两个天的 Conference 会议在油管上直播，也有录像，感兴趣的可以自己<a target="_blank" rel="noopener" href="https://www.youtube.com/@rustnederlandrustnl/videos">找来看看</a>。 5.15 第三天的上午有各种 workshop，会场地址也变了另一个郊区的办公场所，这个会场在运河的旁边，河上经常有各种运货大船漂过，感觉像苏州的运河的场景。华为余教授帮我弄了个参加 workshop 的机会，我去体验了一下玩了会儿跨平台的 Rust GUI 框架 Makepad。然后我去了对面的 Rust all hands 的办公场所，这里都是 Rust 项目维护者和贡献者，大家以分组的方式进行讨论，有的人干脆找个角落写代码。这次组织者非常用心，说不提供单一的 t-shirt，但找了一个打印 Logo 的机器，大家可以自己选择在衣服、背包、帽子上打印 Rust 相关的图案，我把自己的上衣上印了一个黄色的螃蟹。有的人把自己平时收集的一些笔记本贴纸分享出来，我第一次看到这么多 Geek 贴纸，选了好多。 <img src="http://catcoding.me/images/ob_pasted-image-20250608105055.png" alt="" /> 会场提供了很多酒水和小吃，我不停地喝橙汁。期间碰到了在华为俄罗斯工作的 petrochenkov，他穿着一件 Rust 1.0 发布的纪念 t-shirt，年龄和我相仿却已在开源社区工作十多年。他之前帮我 Review 过不少 PR，以前在中国华为办公室工作过，这次终于见面聊了聊。我们俩一起打乒乓球，虽然两个人水平都不太行，但玩得很来劲。 这天下午用来庆祝 Rust 1.0 发布 10 周年，有一个小型 Party，并且用实时发布 1.87 版本的方式进行庆祝。Niko 上台演讲了 <a target="_blank" rel="noopener" href="https://smallcultfollowing.com/babysteps/blog/2025/05/15/10-years-of-rust/">Rust turns 10</a>，余教授代表华为作为赞助商演讲了，华为应该是中国企业中对 Rust 投入最多的，不管是国内的华为还是海外分部都有投入，而且也在通过其他组织赞助社区的一些资深维护者。这会儿我才知道发行一个 Rust 新版本的脚本要运行一个多小时多，最后发布倒计时那会儿气氛达到高潮，拍下了这张照片，我大概在右边第三排的位置，但是身高不够被淹没了： <img src="http://catcoding.me/images/ob_pasted-image-20250607222131.png" alt="" /> 5.16 和 5.17 是两天的 Rust all hands meeting，可以自由选择参加分组讨论也可以自己找个地方工作一会儿。我选择性参与听了一些，比如 Rust society、Let’s talk about Burnout、Infra、Rust Foundation 的 office hours 等，感觉这两天讨论比较多的几个主题是和 C++ 的互操作性。期间也有很多时间留给大家自由讨论，有人安利 <a target="_blank" rel="noopener" href="https://github.com/jj-vcs/jj">jj</a>这个工具，我试用了一下还没理解好在哪里。我比较多时间和 Cargo 组的几个中国人待在一起，突然长时间处于全英文环境中，偶尔会感到表达上的疲惫。 第二天下午和一个德国大学生聊了比较久，很多社区的贡献者都是业余时间在做开源，比如这个大二学生，他在学校学的是音乐，计算机只是自己的业余爱好。为什么 RustNL 比较活跃呢，大多是因为荷兰这个国家其实 Rust 爱好者还挺多的，加上德国这些周围国家，整个欧洲的 Rust 活跃度比我想象中高很多。在聊天的过程中，我问到一个问题：为什么很多贡献者来自德国？可能是因为德国人最喜欢 follow rules 并且个性严谨，这和 Rust 的特性非常符合。 另外，我发现很多人采用的是自己开个咨询公司的方式工作，这样可以同时和多个公司签短期劳动合同，按项目收费，当然这样收入也许并不稳定，但这种方式贵在灵活。我们也聊了一些生活类的话题，总体而言我觉得欧洲的国家大多税收比较重，但基础的生活保障方面的福利也挺好，总得来说人对挣钱的欲望没有那么强烈，人的选择和路径也比较多。 这期间张汉东过来找 jackh726，他们约了一个大约半小时的会谈，主要是聊聊 Rust 在中国的发展和使用情况，jack 让我临时做个翻译。这是我第一次做类似口译这事，几乎有一半时间我只是用英语概括了一下他的讲话。最后我自己也表达了些自己的想法，从全球 IT 产业规模看，Rust 在中国具有广阔发展前景，未来或将有更多中国开发者活跃于 Rust 社区，贡献力量。当然这里有很多因素在影响，一方面大部分国内的 IT 工程师都太忙，还有语言方面的障碍，也许未来情况会好一些，当然这也需要社区的支持。 访谈完后在茶水间，我偶然瞟了一眼对面人胸前的牌子，这个名字看起来眼熟，原来是世界上 crate 包被下载最多的作者，如果你是 Rust 程序员应该都能猜出来他的名字。我上前打了个招呼聊了起来，他前几天的会议都没参加，只是今天过来逛逛，了解到他现在 FB 工作，我说感觉 FB 的社区贡献不多，他反驳说 FB 也是 Rust Foundation 的铂金赞助者，内部还不少 Rust 相关的项目。我突然想起 GOSIM 要找人 9 月份在杭州演讲，开玩笑邀请他来中国参加技术分享，他说那段时间有事委婉拒绝了。 在这次 RustWeek 一周的时间里，我见到了各式各样的工程师，多数人看起来简单纯粹，比如《硅谷》里的 Gilfoyle 式的人物，我见到了一个从头到脚都非常类似的人，长发飘飘还赤脚走来走去，随便找个位置就能完全陷入了自己的编程世界。有次回宾馆的大巴上，nnethercote 坐在我旁边，他是 valgrind 的作者，可以说是一个世界级的基础软件工程师，感兴趣的可以读读这篇 <a target="_blank" rel="noopener" href="https://nnethercote.github.io/2022/07/27/twenty-years-of-valgrind.html">Twenty years of Valgrind</a>。我的第一份工作写 C/C++，特别依赖 valgrind 找内存问题，所以我一路都在问他问题，聊他的技术旅程。他说 Rust 从语言级的角度解决内存的安全性问题，已经成了另外一条路，valgrind 完全由其他人维护了。社区里的很多人他也是第一次见，随口说 all hands 的一大作用是以后大家在 Review PR 的时候能想起对方的面容，这表述得太正确了！ 在会场乱逛我有时候会盯一下大家的开发环境，有的人真是非常极客，笔记本看起来巨大厚重，操作系统大多是 Linux。我发现一个编译器贡献排前三的大牛打字使用二指禅，有天早餐时他坐我对面，我问起为什么只用两个手指操作键盘，会不会效率不高。他说两个手指的速度已经够了，敲键盘能跟上我的思考速度就行。我那天早上刚好看到个视频，说是美国大学生使用 AI 写作业，把一个教授给逼得崩溃，我知道他在世界顶级大学 Eth 当教授，我问他如何看待学生使用 AI 完成作业或者写程序，他说他的作业 AI 基本无法解决，可能是因为程序语言类的很多作业都是证明，而 AI 通常只能完成简单的，稍微深入点的无法胜任，他还会和学生当面交流，如果依赖 AI 而脑子里没货是很容易被发现的。 这次没看到什么 AI 相关的主题，聊天时有人会偶尔吐槽一下 LLM。区块链更没有人聊了，每当有人问起我主业在干什么，我都有点不好意思说我在做这个行业，因为我知道社区里面很多人有些厌恶这个术方向，特别是一些投机者损坏了这行的口碑。我通常会解释说，从技术角度来说区块链就是一个抗拜占庭的分布式数据库，还是非常有趣和有挑战的，区块链这行也是 Rust 成为主流选择的第一个领域，推动了 Rust 的发展。仔细想想，做编程语言和编译器的，追求的就是确定性和速度，AI 有其不确定性，而区块链效率不高，所以这些人大多不喜欢相反特性的东西。从去年开始，有些人为了打造出来一个看似大有贡献的 Github 账号来获得某些加密货币的空投，于是用 AI 提出各种琐碎或者错误的 Pull Request，这些维护者看着这些毫无营养的 PR 浪费自己的时间，自然对这两个行业更加厌恶了。 虽然目前我还很喜欢自己在做的工作，但我顺带了解了些全职做 Rust 社区的工作机会，说不定以后会用到。通过和不同的人聊天，我发现主要有以下一些机构： <ol> <li>国内华为、<a target="_blank" rel="noopener" href="https://trusted-programming.github.io/">爱尔兰华为</a>，全职华为员工或者 Rust 相关工作的 contract</li> <li>亚马逊，总体而言公司文化比较 push，我听到不少关于亚马逊工作环境的抱怨</li> <li>微软，不一定是做社区的工作，而且微软最近也在裁员</li> <li><a target="_blank" rel="noopener" href="https://ferrous-systems.com/" title="https://ferrous-systems.com/">ferrous-systems</a> 不确定是否还有职位，contract 或者全职</li> <li><a target="_blank" rel="noopener" href="https://www.futurewei.com/careers" title="https://www.futurewei.com/careers">futurewei</a> 对员工很灵活，据说完全自己安排工作内容</li> <li>Rust Foundation，但主要偏 security 和 infra 相关的，社区里对 Rust 基金会直接雇人做语言方面的工作有顾及</li> </ol> 如果是全职 Rust 开发的工作，欧洲应该是相对好找一些 (但需要签证)，国内据我所知除了华为、还有字节、小米、汽车公司会用到 Rust。现在 AI 很火，AI 的 infra 也会用到些 Rust，我了解到社区里一个非常资深的维护者去了 OpenAI，这次也碰到一个 OpenAI 的人说公司内部有些 Rust 项目。但整体来说，整个世界的大环境不好，工作机会相比往年少很多。 <hr /> 十年无疑个具有纪念意义的里程碑，就像 Niko 在<a target="_blank" rel="noopener" href="https://smallcultfollowing.com/babysteps/blog/2025/05/15/10-years-of-rust/">Rust turns 10</a>所说的： <blockquote> I just felt that was the most Rust of all problems: having great success but not being able to decide who should take credit. The reality is there is no perfect list – every single person who got named on that award richly deserves it, but so do a bunch of people who aren’t on the list. That’s why the list ends with _All Rust Contributors, Past and Present </blockquote> Rust 目前的成功无法简单归功于个人和机构，无疑我们需要感谢项目发起人 Graydon Hoare 设置了宏大正确的愿景，而后 Rust 在开源社区自由生长，甚至完全不像是他所设想的编程语言了。现在几个 IT 巨头都有投入，但实际上也没有一个组织和个人能决定未来的发展，这既是社区的刻意设计，也是自然进化的结果。从我这种业余贡献者的角度来说，基金会虽然因为各种事饱受争议，但他们确实做了很好的幕后工作，比如这次参会的社区成员基本都能报销费用，甚至我的费用超过了计划申明的额度，基金会也直接说别担心，我们会如实报销所有费用。 总的来说，这次参会经历拓宽了我的视野。大家都因为对 Rust 和编程的激情和追求聚到了一起，交流起来非常有趣。十年前，我在 2015 年偶然发现了 Rust，当时并不知道它会塑造我的职业生涯，在我迷茫的时候重新捡起了 Rust，如今成为全职的 Rust 开发和社区贡献者。最近一年育儿和工作占据了我的大部分时间和精力，所以在 Rust 社区没那么活跃，我渴望通过编程和写作继续投入其中。 顺便一提，Rust Week 这一周我都没吃中餐，回家一称瘦了三四斤，算是意外达成健身目标！我应该是无法在欧洲长待的那类人。

2025/6/11

从椭圆曲线到 secp256k

区块链这行经常会和椭圆曲线密码算法打交道，我也在尝试理解这其中的数学原理，这里记录一下。 <h2 id="什么是椭圆曲线-elliptic-curve"><a href="#什么是椭圆曲线-elliptic-curve" class="headerlink" title="什么是椭圆曲线 (elliptic curve)"></a>什么是椭圆曲线 (elliptic curve)</h2> 先想象一个普通的曲线，比如抛物线（抛个球的轨迹）。椭圆曲线不是椭圆（名字有点误导），而是一种长得像“对称小山丘”或者“歪歪扭扭的环”的数学图形。 椭圆曲线通常表示为： $$ y^2 = x^3 + ax + b$$ 通过这个方程我们可以看到椭圆曲线是上下对称的，其中 (a) 和 (b) 是曲线参数，比如下面这些曲线就是 b = 1 的情况下，a 从 2 变到 -3 的情况： <img src="http://catcoding.me/images/ob_pasted-image-20250401152936.png" alt="" /> 我们通常使用的椭圆曲线必须满足<code>非奇异</code> 的特征，这些参数必须满足判别式： $$4a^3 + 27b^2 \neq 0$$ “非奇异”什么意思？在数学上，椭圆曲线要是“非奇异”（non-singular），就是说这条曲线长得“光滑正常”，没有奇怪的尖角、交叉点或者自己打结的地方。简单讲，就是曲线不能太“怪”，得是个平滑的、像个正常曲线的样子。 如果曲线“奇异”了，会出现两种毛病： <ol> <li>尖点（Cusp）：曲线像被捏了个尖角，某个地方变成一个尖尖的点，不光滑了。</li> <li>自交点（Node）：曲线自己交叉，像个“X”形，两个方向撞一块儿了。</li> </ol> 这些毛病会让“点加法”出问题，因为公式会算不下去，或者结果不唯一。关于<code>点加法</code>我们后面再谈，下面这两个椭圆曲线都是奇异的： <img src="http://catcoding.me/images/ob_pasted-image-20250401153156.png" alt="" /> <h2 id="阿贝尔群-Abelian-group"><a href="#阿贝尔群-Abelian-group" class="headerlink" title="阿贝尔群 (Abelian group)"></a>阿贝尔群 (Abelian group)</h2> 这名字来自数学家 Niels Henrik Abel，他研究了这种“顺序无所谓”的结构。 “群”（group）是数学里的一种概念，就像一个有规则的“俱乐部”。里面有一堆东西（叫元素），加上一个玩法（叫运算），得满足几个条件。阿贝尔群是群的一种特别类型，特点是这个玩法“顺序无所谓”。简单说，阿贝尔群就是一个集合，里面有些元素，能用某种运算（比如加法）组合起来，满足以下条件，而且运算顺序随便换都没问题。 群的四个基本条件： <ul> <li>能玩（封闭性）：你拿集合里两个东西玩一下（做运算），结果还是集合里的东西。比如，两个整数相加还是整数。</li> <li>有老大（单位元）：集合里有个特殊的东西，跟谁玩都不变。比如加法里的 0，$0+5=5$ ，什么也没变。</li> <li>能回头（逆元）：每个东西都有个“反着玩”的朋友，俩人玩一下变老大。比如加法里，5 的逆元是 −5，$-5 + 5 = 0$。</li> <li>括号随便（结合律）：玩的时候，先跟谁玩再跟谁玩都一样。比如 (2+3)+4=2+(3+4) 。</li> </ul> 群变成“阿贝尔群”，还得多一条： <ul> <li>顺序无所谓（交换律）：你拿两个东西玩，先后顺序换一下，结果一样。比如 $2+3 = 3+2$，都是 5。如果顺序有所谓（比如 $2−3≠3−2$），那就不是阿贝尔群了。</li> </ul> 密码学里用阿贝尔群（像椭圆曲线），因为它简单又有规律，适合搞安全。 <h2 id="椭圆曲线上的离散点"><a href="#椭圆曲线上的离散点" class="headerlink" title="椭圆曲线上的离散点"></a>椭圆曲线上的离散点</h2> 到了 1900 年代，椭圆曲线跟数论彻底绑定，而数论研究的是整数。 椭圆曲线方程 $$y^2 = x^3 + ax + b$$ 通常是在普通实数（无限多的小数）上定义的，画出来是个连续的曲线。但安全领域说的椭圆曲线通常是说通过椭圆曲线定义出来的群，其范围定义在某个有限域 : $F_p$ 。 简单说，整数也是一个无限数字的世界，而有限域就是一个只有有限个数字的“数字世界”。这里的表示这个世界里只有 <code>0, 1, 2, ..., p-1</code> 这 (p) 个数，(p) 必须是个素数。为什么是素数？因为这样能保证这个小世界里的数学运算（加减乘除）不会出乱子，规则特别“干净”。 在这个有限域里，所有的计算结果都得落在这 (p) 个数里面。如果算出来超了 (p)，就“绕回去”，用模 (p) 的方式把结果限制住。比如在 $F_5$ 里：3+4=7，但 7 不在范围内，所以 $7mod 5=2$，所以结果是 2。 这个时候，曲线不再是连续的，而是变成了散落在 $F_p \times F_p$ 网格上的一堆离散的点。比如我<a target="_blank" rel="noopener" href="https://github.com/chenyukang/elliptic-curve">这个程序</a>打印出来这条曲线上的点，这里打印的时候 $y =0$ 是在中间，从中间看上下是对称的： <img src="http://catcoding.me/images/ob_pasted-image-20250401160252.png" alt="" /> <h2 id="点加法和对数问题"><a href="#点加法和对数问题" class="headerlink" title="点加法和对数问题"></a>点加法和对数问题</h2> 上面我们只是通过椭圆曲线找到了一组数字，但这些数字之间还需要一种操作，这种操作才能让这些离散的数字组成一个群的概念。这里就需要引入一个“点加法”的概念。 点加法就像一个魔法公式，告诉你怎么从一个点“跳”到另一个点，或者同一个点“跳”两次变成新点。想象椭圆曲线是一条弯弯曲曲的线，上面有很多点，在不断做点加法的过程中不断地移动点。 在椭圆曲线上，点加法有几何和代数两种解释： <ol> <li> 几何解释：通过两个点画一条直线，与曲线的第三个交点取关于 x 轴的对称点。 <img src="http://catcoding.me/images/ob_pasted-image-20250401162659.png" alt="" /> </li> <li> 代数公式： <img src="http://catcoding.me/images/ob_pasted-image-20250401163340.png" alt="" /> </li> </ol> 离散对数问题是在一个有限的“数字圈”里玩，比如有限域 $F_p$ （( p ) 是素数）或者椭圆曲线的点群里。比如： <ul> <li>给你 $y = g^x \mod p$ ，已知 ( y, g, p )，求 x。</li> <li>在椭圆曲线上，变成 $Q = k \cdot P$ ，已知 Q 和 P（基点），求 k（跳了几次）。</li> </ul> 这里的 ( x ) 或 ( k ) 就是“离散对数”。这就是离散对数问题，数学家没找到一个快速方式能解决这个问题。 直观感受一下，我们修改上面那个程序，我定义一个起始点 P，然后不断通过 P + P 的方式进行 20 次，终点是黄色的，然后把中间通过的点用蓝色的线连接起来，可以看到我们经过的点是没有什么规律的。 反向破解就比如你拿到这幅图，如果不告诉你蓝色的连线，而只有那个黄色的终点，现在问你起点在哪里？这个问题是很难回答的。 <img src="http://catcoding.me/images/ob_pasted-image-20250401164453.png" alt="" /> 19 世纪数学家就研究过椭圆曲线的性质，但到 20 世纪数学家发现椭圆曲线上的点能通过点加法这类操作组成一个阿贝尔群，这些点的数量和分布特别“诡异”——既有限，又乱得没规律。而点加法这种正向容易、逆向难的特征刚好就适用于密码学。 <h2 id="从椭圆曲线到密码学"><a href="#从椭圆曲线到密码学" class="headerlink" title="从椭圆曲线到密码学"></a>从椭圆曲线到密码学</h2> Neal Koblitz 是专攻数论的数学家，对椭圆曲线很熟。他当时在研究有限域上的数学问题，注意到椭圆曲线的点群和传统离散对数有点像，但更“紧凑”。他想：如果把 Diffie-Hellman 的思路搬到椭圆曲线上，会不会更高效。 Victor Miller 在 IBM 搞应用数学，也盯着椭圆曲线的群性质。他发现，椭圆曲线的离散对数问题（ECDLP）似乎比普通离散对数还难破解，而且需要的数字（密钥长度）小得多。他俩不谋而合，都觉得这玩意儿能干大事。 他们的想法不是凭空来的，有几个关键“火花”： <ol> <li>群论的启发：密码学里的 Diffie-Hellman 用的是乘法群，Koblitz 和 Miller 看到椭圆曲线的点群也是阿贝尔群，觉得可以“照搬”过来。</li> <li>Hasse 定理：20 世纪数学家 Hasse 证明了椭圆曲线在 $F_p$ 上的点数大概是 $p + 1 \pm 2\sqrt{p}$，数量够大但分布随机，正好适合做离散对数问题。</li> <li>效率优势：他们算了算，椭圆曲线的运算（点加法和倍点）虽然复杂，但用小得多的数字（比如 160 位）就能达到传统方法 1000 位的安全级别，这对硬件来说太诱人了。</li> </ol> 为什么不随便挑个别的曲线？因为椭圆曲线（三次方程）正好有“三个交点”的几何性质，点加法规则简单又优雅，其他高次曲线要么太复杂，要么安全性不够。加上数学家几百年的研究，椭圆曲线的性质已经摸得透透的，拿来用最保险。 椭圆曲线加密从 1985 年的“怪胎”到今天的核心技术，走过了从冷门到爆款的路。它的历史是个典型的“学术变实用”的故事：数学家玩了好多年的椭圆曲线，被 Koblitz 和 Miller 一挖掘成了安全的利器。 <h2 id="secp256k1"><a href="#secp256k1" class="headerlink" title="secp256k1"></a>secp256k1</h2> secp256k1 是一个特殊的椭圆曲线，名字听起来高大上，其实就是密码学里用的一条数学曲线，secp256k1 的名字可以分成几个部分： <ul> <li>sec：Standards for Efficient Cryptography（高效加密标准）。</li> <li>p：Prime（素数），表示这个曲线是用素数域定义的。</li> <li>256：表示这个曲线的“大小”是 256 位（也就是密钥长度）。</li> <li>k：Koblitz 的缩写，指的是数学家 Neal Koblitz，他研究了这种类型的曲线。</li> <li>1：表示这是 Koblitz 曲线中的第一个（最简单的一个）。</li> </ul> 它是比特币、以太坊这些区块链的“安全锁”的核心。简单说，它定义了一个“跳跃游戏”的规则，靠这个规则保护你的私钥和公钥。 secp256k1 是这么来的： <ul> <li>方程：它的公式是 $y^2 = x^3 + 7$ 注意，这里的 $a = 0 , b = 7$，是个很简单的椭圆曲线。</li> <li>有限域：它不是在普通数字上玩，而是在一个超级大的“数字圈” $F_p$ ，这里的 (p) 是个特定的素数，大约是 $2^{256} - 2^{32} - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1$。</li> <li>基点 (P)：它有个固定的起跑点 (P)，坐标是 $(x_P, y_P)$，具体值很长（见下面），但它是公开的，大家都从这点开始跳。</li> </ul> secp256k1 就像一个超级复杂的“跳格子游戏”： <ul> <li>你挑一个秘密数字 (k)（私钥），从基点 (P) 开始，用点加法跳 (k) 次，跳到的点是 $Q = k \cdot P$ 公钥。</li> <li>别人看到 (P) 和 (Q)，想猜你跳了几次 (k)，但因为点加法逆运算（离散对数问题）太难，他们算不出来。</li> </ul> 类比一下，想象 secp256k1 是个巨大的迷宫，里面有 (p) 个格子（大概 $2^{256}$个，这个数字大到超乎想象，比宇宙里的原子、沙粒、甚至时间秒数都多得多。它不是“很大”，而是“大的离谱”）。迷宫的形状由上面的椭圆曲线决定，起点是 (P)。你拿着私钥 (k)，按迷宫的跳法（点加法）走 (k) 步，停在 (Q)。这个迷宫设计得太巧妙，别人站在 (Q) 看你走过的路，根本摸不着头脑，只能从 (P) 一步步试，试到宇宙爆炸也试不完，破解难度像“从银河系找一粒沙”。签名时，拿私钥和消息算出两个数（r, s），别人用公钥验证。 secp256k1 另外一个特点是计算快，主要来自它的特殊数学结构和参数选择。<a target="_blank" rel="noopener" href="https://github.com/bitcoin-core/secp256k1?tab=readme-ov-file">bitcoin-core/secp256k1</a> 是高度优化过的 C 语言实现，用了预存表、内敛汇编等各种优化手段来提高效率。通常我们在 Rust 程序上用的也是这个库的 binding。 <h2 id="结尾"><a href="#结尾" class="headerlink" title="结尾"></a>结尾</h2> 本来想查找更多资料来写得更详细，但我发现如此太耗费时间，倒不如先把已经理解的部分写在这里，以后如果有新的理解再丰富。在尝试理解的过程中仍然会有这种感受： <img src="http://catcoding.me/images/ob_pasted-image-20250402113142.png" alt="" /> 更多的参考资料在这里： <ul> <li><a target="_blank" rel="noopener" href="https://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/">Elliptic Curve Cryptography: a gentle introduction - Andrea Corbellini</a> 写的一系列文章很详细</li> <li>上面的程序分享在这里： <a target="_blank" rel="noopener" href="https://github.com/chenyukang/elliptic-curve">chenyukang/elliptic-curve</a></li> </ul>

2025/6/8

Future 的大小对性能的影响

在 Rust 异步编程中，有一种观点认为：Future 的大小显著影响性能。你是否怀疑过这个说法的真实性？如果是真的，这种性能差异的根源又是什么？今天，我翻阅了一些源码，并编写实验代码来一探究竟。 <h2 id="Future-的大小如何计算？"><a href="#Future-的大小如何计算？" class="headerlink" title="Future 的大小如何计算？"></a>Future 的大小如何计算？</h2> 为了验证“Future 大小影响性能”这一说法是否成立，我们先从一些简单代码入手。首要任务是弄清楚一个 Future 的大小是如何确定的。毕竟，在编译器眼里，Future 只是一个 trait： <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">pub trait Future { type Output; fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>; } </code></pre> 那么，其大小取决于实现这个 trait 的具体结构体吗？我翻阅了 smol 的源码，发现在 <a target="_blank" rel="noopener" href="https://github.com/smol-rs/async-executor/blob/2d72f8705b324c386d22227720d806ea8bc4e257/async-task/src/runnable.rs#L505-L535">spawn 一个 Future</a> 时，相关代码是这样处理的： <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust"> pub unsafe fn spawn_unchecked<'a, F, Fut, S>( self, future: F, schedule: S, ) -> (Runnable<M>, Task<Fut::Output, M>) where F: FnOnce(&'a M) -> Fut, Fut: Future + 'a, S: Schedule<M>, M: 'a, { // Allocate large futures on the heap. let ptr = if mem::size_of::<Fut>() >= 2048 { let future = |meta| { let future = future(meta); Box::pin(future) }; RawTask::<_, Fut::Output, S, M>::allocate(future, schedule, self) } else { RawTask::<Fut, Fut::Output, S, M>::allocate(future, schedule, self) }; let runnable = Runnable::from_raw(ptr); let task = Task { ptr, _marker: PhantomData, }; (runnable, task) } </code></pre> 这里可以看到 <code>mem::size_of::<Fut>()</code> 是在计算这个 Future 的大小，我来写个简单的 Future 验证： <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">use async_executor::Executor; use futures_lite::future; use std::future::Future; use std::pin::Pin; use std::task::{Context, Poll}; pub struct LargeFuture { pub data: [u8; 10240], } impl Future for LargeFuture { type Output = usize; fn poll(self: Pin<&mut Self>, _cx: &mut Context<'_>) -> Poll<Self::Output> { let value = self.data[0]; println!("First byte: {}", value); Poll::Ready(self.data.len()) } } fn main() { let ex = Executor::new(); let large_future = LargeFuture { data: [0u8; 10240] }; let res = future::block_on(ex.run(async { ex.spawn(large_future).await })); println!("Result: {}", res); } </code></pre> 在上面那个 async-task 的 <code>spawn_unchecked</code> 函数加上日志，打印出来的大小为 <code>10256</code>，刚好比这个 struct 的大小大 16，顺着代码往上可以看到<a target="_blank" rel="noopener" href="https://github.com/smol-rs/async-executor/blob/2d72f8705b324c386d22227720d806ea8bc4e257/src/lib.rs#L250">这里</a>在原始的 Future 上做了一个封装，这里的意思是如果这个 Future 以后执行完，需要从 runtime 里面删掉： <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">let future = AsyncCallOnDrop::new(future, move || drop(state.active().try_remove(index))); </code></pre> 这解释了尺寸略有增加的原因。对于结构体的尺寸，我们不难理解，但对于 async 函数，其大小又是如何计算的呢？这就涉及 Rust 编译器对 async 的转换机制。 <h2 id="异步状态机：冰山之下的庞然大物"><a href="#异步状态机：冰山之下的庞然大物" class="headerlink" title="异步状态机：冰山之下的庞然大物"></a>异步状态机：冰山之下的庞然大物</h2> 当你写下一个简单的 <code>async fn</code> 函数时，Rust 编译器在幕后悄然完成了一场复杂的转换： <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">async fn function() -> usize { let data = [0u8; 102400]; future::yield_now().await; data[0] as usize } </code></pre> 这段代码会被编译器转化为一个庞大的状态机，负责追踪执行进度并保存所有跨越 <code>.await</code> 点的变量。转换后的结构体封装了状态切换的逻辑： <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">enum FunctionState { // 初始状态 Initial, // yield_now 挂起后的状态，必须包含所有跨 await 点的变量 Suspended { data: [u8; 102400], // 整个大数组必须保存！ }, // 完成状态 Completed, } // 2. 定义状态机结构体 struct FunctionFuture { // 当前状态 state: FunctionState, // yield_now future yield_fut: Option<YieldNow>, } impl Future for FunctionFuture { // 3. 为状态机实现 Future traitimpl Future for FunctionFuture { type Output = usize; fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<usize> { // 安全地获取可变引用 let this = unsafe { self.get_unchecked_mut() }; match &mut this.state { FunctionState::Initial => { // 创建大数组及其长度 let data = [0u8; 102400]; // 创建 yield future 并保存 this.yield_fut = Some(future::yield_now()); // 状态转换，保存所有需要跨越 await 的数据 this.state = FunctionState::Suspended { data }; // 立即轮询 yield match Pin::new(&mut this.yield_fut.as_mut().unwrap()).poll(cx) { Poll::Ready(_) => { // 如果立即完成，返回结果 if let FunctionState::Suspended { data } = &this.state { let result = data[0] as usize; this.state = FunctionState::Completed; Poll::Ready(result) } else { unreachable!() } } Poll::Pending => Poll::Pending, } } FunctionState::Suspended { data } => { // 继续轮询 yield match Pin::new(&mut this.yield_fut.as_mut().unwrap()).poll(cx) { Poll::Ready(_) => { // yield 完成，读取数组首元素并返回 let result = data[0] as usize; this.state = FunctionState::Completed; Poll::Ready(result) } Poll::Pending => Poll::Pending, } } FunctionState::Completed => { panic!("Future polled after completion") } } } } </code></pre> 可以看到，<code>Suspended</code> 状态中包含了那个大数组。当状态从 <code>Initial</code> 切换到 <code>Suspended</code> 时，<code>data</code> 会被完整保留。 由此可知，对于一个 async 函数，若临时变量需跨越 await 存活，就会被纳入状态机，导致编译时生成的 Future 大小显著增加。 <h2 id="尺寸对性能的影响"><a href="#尺寸对性能的影响" class="headerlink" title="尺寸对性能的影响"></a>尺寸对性能的影响</h2> 明确了 Future 大小的定义后，我们接着通过代码验证其对性能的影响。在之前的 <code>mem::size_of::<Fut>() >= 2048</code> 条件中可以看到，如果 Future 的大小过大，<code>Box::pin(future)</code> 会从堆上分配内存，理论上会带来额外开销。这种设计可能基于几点考量：小型 Future 直接嵌入任务结构体中，能提升缓存命中率；而大型 Future 若嵌入，会让任务结构体过于臃肿，占用过多栈空间，反而不利于性能。 我通过实验验证，若 async 函数中包含较大的结构体，确实会导致 Future 执行变慢（即便计算逻辑相同）： <pre class="line-numbers language-console" data-language="console"><code class="language-console">RESULTS: -------- Small Future (64B): 100000 iterations in 30.863125ms (avg: 308ns per iteration) Medium Future (1KB): 100000 iterations in 61.100916ms (avg: 611ns per iteration) Large Future (3KB): 100000 iterations in 105.185292ms (avg: 1.051µs per iteration) Very Large Future (10KB): 100000 iterations in 273.469167ms (avg: 2.734µs per iteration) Huge Large Future (100KB): 100000 iterations in 5.896455959s (avg: 58.964µs per iteration) PERFORMANCE RATIOS (compared to Small Future): ------------------------------------------- Medium Future (1KB): 1.98x slower Large Future (3KB): 3.41x slower Very Large Future (10KB): 8.88x slower Huge Large Future (100KB): 191.44x slower </code></pre> 在微调这个 async 函数时，我发现了一些微妙的现象。为了让 <code>data</code> 跨越 await 存活，我特意在最后引用了它，以防编译器优化掉： <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">async fn huge_large_future() -> u64 { let data = [1u8; 102400]; // 10KB * 10 let len = data.len(); future::yield_now().await; (data[0] + data[len - 1]) as u64 } </code></pre> 理论上，若改成下面这样，由于 <code>len</code> 在 await 前已计算完成，后面又没用引用到，生成的 Future 大小应该很小： <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">async fn huge_large_future() -> u64 { let data = [1u8; 102400]; // 10KB * 10 let len = data.len(); future::yield_now().await; 0 } fn main() { let ex = Executor::new(); let task = ex.spawn(huge_large_future()); let res = future::block_on(ex.run(task)); eprintln!("Result: {}", res); } </code></pre> 然而，我发现 <code>data</code> 仍被保留在状态机中，即便 <code>len</code> 未被后续使用。这涉及到编译器如何判断变量是否跨越 await 存活的问题。当然，若显式限定 <code>data</code> 的生命周期在 await 之前，它就不会被纳入状态机： <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">async fn huge_large_future() -> u64 { { let data = [1u8; 102400]; // 10KB * 10 let len = data.len(); } future::yield_now().await; 0 } </code></pre><h2 id="编译器如何判断哪些变量应该保存"><a href="#编译器如何判断哪些变量应该保存" class="headerlink" title="编译器如何判断哪些变量应该保存"></a>编译器如何判断哪些变量应该保存</h2> 我查阅了 Rust 编译器的源码，发现变量是否跨越 await 存活由 <a target="_blank" rel="noopener" href="https://github.com/chenyukang/rust/blob/c089b1fe7d6b8ef5889f820fd8be4f78bb7efe42/compiler/rustc_mir_transform/src/coroutine.rs#L655-L660">locals_live_across_suspend_points 函数</a> 决定： <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">/// The basic idea is as follows: /// - a local is live until we encounter a `StorageDead` statement. In /// case none exist, the local is considered to be always live. /// - a local has to be stored if it is either directly used after the /// the suspend point, or if it is live and has been previously borrowed. </code></pre> 在我们的代码中，<code>let len = data.len()</code> 构成了对 <code>data</code> 的借用，因此 <code>data</code> 被保留在状态机中。或许这里仍有优化的空间？我去社区问问看。 <h2 id="结语"><a href="#结语" class="headerlink" title="结语"></a>结语</h2> 所有实验代码均可在以下链接找到：<a target="_blank" rel="noopener" href="https://github.com/chenyukang/async-executor/tree/yukang-post/examples">async-executor-examples</a>。 在 Rust 异步编程中，代码的细微调整可能引发性能的显著波动。深入理解状态机生成的内在机制，能助你打造更高效的异步代码。下次编写 <code>async fn</code> 时，不妨自问：这个状态机究竟有多大？

2025/3/24

Fiber Network: 基于 CKB 实现的闪电网络

最近一年我在做 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber">Fiber Network</a> 这个新的开源项目，上个月底刚好<a target="_blank" rel="noopener" href="https://x.com/FiberDevs/status/1895486339505893880">主网第一个版本发布</a>： <img src="http://catcoding.me/images/ob_pasted-image-20250316084708.png" alt="" /> 这个项目的挑战还是挺大的，上主网只是一个新的开始。我在开发过程中学到了很多东西，这是我前段时间写的一篇关于 Fiber 的大致介绍。 <h2 id="Fiber-简介"><a href="#Fiber-简介" class="headerlink" title="Fiber 简介"></a>Fiber 简介</h2> Fiber 是基于 CKB 构建的闪电网络协议，旨在实现快速、安全且高效的链下支付解决方案。借鉴了比特币闪电网络的核心理念，Fiber 针对 CKB 的独特架构进行了深度优化，提供低延迟、高吞吐量的支付通道，适用于微支付和高频交易等场景。与传统的闪电网络不同，Fiber 拥有多项关键特性： <ul> <li>多资产支持：不再局限于单一币种，能够处理多种资产交易，为复杂的跨链金融应用铺平道路。</li> <li>可编程性：基于 CKB 的图灵完备智能合约，支持更复杂的条件执行和业务逻辑，拓展了支付通道的应用边界。</li> <li>跨链互操作性：原生设计支持与其他 UTXO 链（如比特币）的闪电网络交互，提升了链间资产流动性和网络兼容性。</li> <li>更灵活的状态管理：得益于 CKB 的 Cell 模型，Fiber 可以更高效地管理通道状态，降低链下交互的复杂度。</li> </ul> 在这篇文章中，我们将从源码层面介绍 Fiber 的整体架构和主要模块，以及项目的后续展望和规划。 <h3 id="前提知识"><a href="#前提知识" class="headerlink" title="前提知识"></a>前提知识</h3> <ul> <li>Rust, and <a target="_blank" rel="noopener" href="https://github.com/slawlor/ractor">actor framework</a>，Fiber 是一个完全由 Rust 编程语言所实现的项目，另外我们在实现中采用了 actor model 的模式，依赖社区的项目 <a target="_blank" rel="noopener" href="https://github.com/slawlor/ractor">ractor</a> 框架。</li> <li>Lightning network，Fiber 的基本思想沿用了 Bitcoin 的闪电网络，基本原理是一致的，所以 <a target="_blank" rel="noopener" href="https://github.com/lnbook/lnbook">Mastering lightning network</a> 和 Bolts: <a target="_blank" rel="noopener" href="https://github.com/lightning/bolts">lightning/bolts</a> 是非常有用的参考资料。</li> <li>CKB transaction and contract，Fiber 会通过 RPC 与 CKB node 进行交互，比如 funding transaction 或者 shutdown commitment transaction 可能需要通过 RPC 提交给 CKB 的节点，所以掌握 Fiber 需要了解一些 CKB 合约开发方面的知识。</li> </ul> <h2 id="重要模块"><a href="#重要模块" class="headerlink" title="重要模块"></a>重要模块</h2> 我们从最高纬度去看一个 Fiber Node，主要包含下面几个主要模块： <img src="http://catcoding.me/images/ob_pasted-image-20250316082730.png" alt="" /> 其中： <ul> <li>Network Actor 是 Fiber Node 中负责节点内外的消息通信</li> <li>Network graph 包含一个节点对于整个网络里其他节点和 channel 的信息，当一个 Fiber Node 收到一个支付请求的时候，我们首先会尝试从 network graph 中找到一条路径能够触达收款节点，这个 network graph 结构是跟着网络上的 gossip 信息不断更新的</li> <li>PaymentSession 负责管理一个支付的生命周期</li> <li><a target="_blank" rel="noopener" href="https://github.com/cryptape/fiber-sphinx">fiber-sphinx</a> 是我们自己实现的 onion packet 加解密 Rust 库</li> <li>Gossip 是 Fiber 节点之间的交换网络消息的协议，用于 Node 和 Channe 的发现和更新。</li> <li>Watchtower，这里负责监听 Fiber node 所关心的 channel 里面的重要事件，另外如果某个 Node 提交一个老的 commitment transaction，watch tower 负责发出 revocation transaction 来进行惩罚</li> <li>Cross hub，这个模块负责跨链的互操作，比如付款者通过 Bitcoin 的闪电网络发出 Bitcoin，而接收者收到的是 CKB，cross hub 这里会进行一个转换，将 Bitcoin 的 payment 和 invoice 和 Fiber 这边的 payment 和 invoice 进行映射管理</li> <li><a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber-scripts/tree/main">Fiber-script</a> 在一个单独的代码仓库，这里面包含了两个主要的合约，<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber-scripts/tree/main/contracts/funding-lock">funding-lock</a> 是一个资金锁定合约，使用 ckb-auth 库来实现一个 2-of-2 多重签名，<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber-scripts/tree/main/contracts/commitment-lock">commitment-lock</a> 实现了 <a target="_blank" rel="noopener" href="https://eprint.iacr.org/2022/1295">daric</a> 协议来作为 Fiber 的惩罚机制</li> </ul> <h3 id="Actor-Model-和-Channel-管理"><a href="#Actor-Model-和-Channel-管理" class="headerlink" title="Actor Model 和 Channel 管理"></a>Actor Model 和 Channel 管理</h3> Channel 的管理是闪电网络中非常重要、也是异常复杂的部分。其中的复杂性主要来自于 Channel 内部数据和状态的改变来自于网络上 peer 之间的交互，事件的处理可能存在并发上的问题，一个 Channel 的双边可能同时都有 TLC 的操作。 闪电网络本质上是一个 P2P 系统，节点之间通过网络消息相互通信进而改变内部的数据状态，我们发现 Actor Model 非常适合这种场景： <img src="http://catcoding.me/images/ob_pasted-image-20250316082740.png" alt="" /> Actor Model 极大地简化了代码实现的复杂度，使用 Actor model 后我们不需要使用锁来保护数据的更新，当一个 Message handle 结束的时候，我们会把 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/81014d36502b76e2637dfa414b5a3ee494942c41/src/fiber/channel.rs#L2276">channel state 的数据更新写入 db</a>。而像 rust lightning 如果没用使用 actor model，就可能会涉及到非常复杂的<a target="_blank" rel="noopener" href="https://github.com/lightningdevkit/rust-lightning/blob/b8b1ef3149f26992625a03d45c0307bfad70e8bd/lightning/src/ln/channelmanager.rs#L1167">锁相关的操作</a>。 我们的所有的重要模块都采用了 Actor Model，<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/network.rs#L694-L789">Network Actor</a>负责节点内外的消息通信，比如一个节点要给另外一个节点发送 Open channel 的消息，这个消息首先会通过 Fiber node A 的 channel actor 发送到 network actor，node A 的 network actor 通过更底层的网络层 tentacle 发送到 node B 的 network actor，然后 network actor 再发给 node B 里面的所对应的 channel actor。 <img src="http://catcoding.me/images/ob_pasted-image-20250316082758.png" alt="" /> 在一个 Fiber Node 内部，每一个新的 Channel 我们都会建立一个对应的 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/channel.rs#L301-L308">ChannelActor</a>，而这个 ChannelActorState 里面包含了这个 Channel 所需要持久化的所有的数据。采用 Actor Model 的另外一个好处就是我们能够在代码实现过程中直观地把 HTLC 网络协议相关的操作映射到一个函数里，比如下图中展示了 HTLC 在多个节点之间的流转过程，对于 A 到 B 之间的 AddTlc 操作，节点 A 里的 actor 0 所应对的代码实现就是 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/channel.rs#L1251">handle_add_tlc_command</a>，而节点 B 里的 actor 1 所对应的代码实现是 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/channel.rs#L1069">handle_add_tlc_peer_message</a>。 <img src="http://catcoding.me/images/ob_pasted-image-20250316082810.png" alt="" /> Channel 之间的 TLC 操作是复杂度非常高的部分，我们在实现上延用了 rust-lightning 的方式，<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/channel.rs#L2463-L2496">使用状态机来表示 TLC 的状态</a>，根据 actor 之间的 commitment_sign 和 revoke_ack 的消息来改变状态机，总的来说 AddTlc 的操作流程和两个 Peer TLC 状态的改变过程如下： <img src="http://catcoding.me/images/ob_pasted-image-20250316082818.png" alt="" /> <h3 id="支付和多跳路由"><a href="#支付和多跳路由" class="headerlink" title="支付和多跳路由"></a>支付和多跳路由</h3> 每个 Fiber 节点都通过 Network graph 保存了自己对于整个网络的了解情况，本质上这是一个双向有向图，每一个 Fiber 节点对应于 Graph 里面的一个 vertex，每一个 Channel 对应于 Graph 里面的一个 edge，出于隐私保护的需求，Channel 的真实 balance 不会广播到网络中，所有 edge 的大小是 Channel 的 capacity。 在支付开始前，发起者会通过路径规划找到一条通往收款者的路径，如果有多条路径就需要找到各方面综合考虑最优的路径，而在信息缺失的图中找到最优路径是一个在工程上非常具有挑战性的问题，<a target="_blank" rel="noopener" href="https://github.com/lnbook/lnbook/blob/develop/12_path_finding.asciidoc#pathfinding-what-problem-are-we-solving">Mastering Lightning Network 对这个问题有很详细的介绍</a>： <img src="http://catcoding.me/images/ob_pasted-image-20250316082831.png" alt="" /> 在 Fiber 中，支付动作由用户向 Fiber Node <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/rpc/payment.rs#L171-L209">通过 RPC 发起请求</a>，节点收到请求后会创建对应的 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/network.rs#L1866-L1871">PaymentSession</a> 来追踪支付的生命周期。 目前我们的路径规划的算法是一个<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/graph.rs#L914-L925">变形的 Dijkstra 算法</a>，这个算法是通过 target 往 source 方向扩展的，搜索路径的过程中通过折算支付成功的概率、fee、TLC 的 lock time 这些因素到一个 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/graph.rs#L1110">weight 来进行排序</a>。其中的概率估算来自于每次支付的结果记录和分析，实现在 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/history.rs#L481-L506">eval_probability</a>。路径的选择质量好坏对于整个网络的效率和支付的成功率非常重要，这部分我们今后将会继续改进，Multipart payments (MPP) 也是一个今后可能要实现的功能。 路径规划完成后下一步就是<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/network.rs#L1634-L1656">构建 Onion Packet</a>，然后给通过 source node 发起 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/network.rs#L1657-L1667">AddTlcCommand</a>。后续如果 TLC 失败或者成功会通过事件通知的方式处理。 整个支付的过程可能会发生多次的重试，一个常见的场景就是我们使用 capacity 作为 Graph 里边的容量，可能路径规划出来的路线无法真实满足支付的大小，所以我们需要返回错误并更新 Graph，然后再继续自动发起<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/network.rs#L1767-L1772">下一次路径规划尝试进行支付</a>。 <h3 id="节点广播协议-Gossip"><a href="#节点广播协议-Gossip" class="headerlink" title="节点广播协议 Gossip"></a>节点广播协议 Gossip</h3> Fiber 的节点之间的通过相互发送广播消息交换新的 Node 和 Channel 信息，Fiber 中的 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/gossip.rs#L293-L331">Gossip 模块</a>实现了 <a target="_blank" rel="noopener" href="https://github.com/lightning/bolts/blob/master/07-routing-gossip.md">Botls 7 定义的 routing gossip</a>。在实现过程中我们的主要技术决策在这个 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/pull/308">PR: Refactor gossip protocol</a>里面有描述。 当一个 Node 节点第一次启动的时候，会通过配置文件里的 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/network.rs#L3169-L3174">bootnode_addrs</a>来的连接第一批 peers，广播消息的类型有三类：<code>NodeAnnouncement</code> 、<code>ChannelAnnouncement</code> 、<code>ChannelUpdate</code> 。 Fiber 会把收到的<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/store/store.rs#L482-L711">广播的原始数据保存下来</a>，这样方便通过 timestamp + message_id 组合的 cursor 来对广播消息进行检索，以方便来自 peer node 的 query 请求。 当一个节点启动的时候，Graph 模块会通过 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/graph.rs#L361">load_from_store</a>来读取所有的 messages，重新构建自己的 network graph。 我们采用基于订阅的方式在网络中传播消息。一个节点需要主动向另一个节点发送广播消息过滤器（BroadcastMessagesFilter），另一个节点收到了该消息之后会为其创建对应的 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/gossip.rs#L599-L614">PeerFilterActor</a>，在构造函数里创建 Gossip 消息订阅。通过基于订阅的模型这种方式，我们可以让其他节点接收在特定的 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/gossip.rs#L1027-L1049">cursor 之后接收到新保存的 Gossip 消息</a>。 <h3 id="隐私-Onion-加解密"><a href="#隐私-Onion-加解密" class="headerlink" title="隐私 Onion 加解密"></a>隐私 Onion 加解密</h3> 处于隐私保护的需求，payment 的 TLC 在多个节点之间传播的时候，每个节点只能知道自己所需要的信息，比如当前节点接收的 TLC 的 amount、expiry、下一个传播的节点等信息，而无法获得其他不必要的信息，而且每个 hop 在发送 TLC 给下一个节点的时候也需要做相应的混淆。 类似的，如果 payment 在某个节点传播的过程中发生了错误，这个节点也可能返回一个错误信息，而这个错误信息会通过 payment 的 route 反向传递给 payment 的发起节点。这个错误信息也是需要 Onion 加密的，这样确保中间节点无法理解错误的具体内容，而只有发送者能够获得错误内容。 我们参考了 rust-lightning 在 <a target="_blank" rel="noopener" href="https://github.com/lightningdevkit/rust-lightning/blob/master/lightning/src/ln/onion_utils.rs">onion packet 的实现</a>，发现其实现方式还是不够通用 (会绑定于其项目的具体数据结构)，所以我们自己从头开始实现了 <a target="_blank" rel="noopener" href="https://github.com/cryptape/fiber-sphinx/blob/develop/docs/spec.md">fiber-sphinx</a>，更详细的内容请参考项目的 spec。 涉及到 Onion 加解密的几个关键节点在这三个地方： <ul> <li>send payment 的时候<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/network.rs#L1640-L1666">创建 onion packet</a>，作为 AddTlcCommand 里的一个字段发送给第一个 hop</li> <li>payment route 中的每个节点收到 TLC 之后，尝试去解开 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/channel.rs#L920-L937">Onion Packet 的一层</a>，就像是剥离一层洋葱皮一样，如果判断自己是接收者则处理 payment settle 相关的逻辑，如果发现后续还有接收者则处理了 TLC 相关的逻辑之后继续<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/channel.rs#L1037-L1064">往下一个 hop 传递剩下的 onion packet</a>。</li> <li>如果某个 Hop 在转发 TLC 的过程中出现错误就<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/channel.rs#L774-L797">生成一个新的包含有错误信息的 onion packet</a>，并向前一个 hop 发送 onion packet。</li> <li>payment 的发起者收到 TLC fail event 的时候，从其中<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/e7bb8874e308445fdf63a5bc538fc00c100f3dc9/src/fiber/network.rs#L1518-L1527">解开包含有错误信息的 onion packet</a>，然后根据错误信息去判断是否需要重试和更新 Network graph。</li> </ul> <img src="http://catcoding.me/images/ob_pasted-image-20250316082911.png" alt="" /> <h3 id="Watchtower"><a href="#Watchtower" class="headerlink" title="Watchtower"></a>Watchtower</h3> Watchtower 是闪电网络中的重要安全机制，主要用于帮助离线用户防止资金被盗。它通过实时监测链上交易，并在发现违规行为时执行惩罚交易，从而维护闪电网络的公平性和安全性。 Fiber 的 watchtower 实现在 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/b5c38a800e94aaa368a4c8a8699f5db0c08ecfbd/src/watchtower/actor.rs#L73-L124">WatchtowerActor</a>里，这个 actor 会监听 Fiber 节点中发生的关键事件，比如一个新的 Channel 创建成功时将会收到 <code>RemoteTxComplete</code>，watchtower 就在数据库里插入一条对应的记录来开始监听这个通道，Channel 双方协商成功关闭时会收到 <code>ChannelClosed</code>，watchtower 从数据库中移除对应的记录。 在 Channel 中 TLC 交互时候，watchertower 将会收到 <code>RemoteCommitmentSigned</code> 和 <code>RevokeAndAckReceived</code>，分别去更新数据库中存储的 <code>revocation_data</code> 和 <code>settlement_data</code>，这些字段将会在后续创建 revocation transaction 和 settlement trasaction 的时候用到。 Watchtower 的惩罚机制是通过<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/b5c38a800e94aaa368a4c8a8699f5db0c08ecfbd/src/watchtower/actor.rs#L266">比较 <code>commitment_number</code> </a>来判断 CKB 的链上交易是否使用了老的 commitment transaction，如果发现违规则构建一个 revocation transaction 提交到链上进行惩罚，否则就构建发送一个 settlement transaction 提交到链上。 <h3 id="其他技术决策"><a href="#其他技术决策" class="headerlink" title="其他技术决策"></a>其他技术决策</h3> <ul> <li>存储：我们使用 RocksDB 作为存储层，写代码的过程中可以直接使用 serde 来序列化。但因为 scheme-less，所以不同版本的数据迁移仍然是一个挑战，我们通过这个<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber/blob/develop/migrate/src/main.rs">独立程序</a>来解决，比较粗暴，但目前没想到更好的办法。</li> <li>序列化：节点间的消息使用 Molecule 进行序列化和反序列化，带来效率、兼容性和安全性优势。要确保确定性，这样相同的消息在所有节点上序列化方式相同，这对于签名生成和验证非常重要。</li> </ul> <h2 id="后续展望"><a href="#后续展望" class="headerlink" title="后续展望"></a>后续展望</h2> 目前 Fiber 还处于前期活跃开发阶段，后续我们可能将继续做以下几个方面的改进： <ul> <li>修复还未处理好的 corner case，增强项目整体的健壮性</li> <li>目前的 cross hub 还处于 Demo 阶段，我们会对这部分增加如 payment session 等功能</li> <li>完善支付路由规划算法，可能会引入其他路径搜索策略，以适应用户不同的路由偏好和需求</li> <li>扩展合约的功能，比如引入基于版本号的撤销机制和更安全的 Point Time-Locked Contracts</li> </ul> Let’s scale P2P finance together! 🩵

2025/3/16

2024：简单的理想生活

2024 年快结束了，在这最后的一两个小时里我写着这篇年终总结准备跨年了，顺着大致时间线来回顾一下就好了。 年初就起了个好头，众多加密货币开始上涨。总体而言，2024 年是个加密货币和区块链的大年。有那么一小段时间我每天都在关注涨跌，渐渐地我发现这个领域涨跌都是太频繁了，而过多关注除了浪费时间并没有什么大的用处。因为两年前开始在这个领域工作，所以我自然也会投资一些加密货币。刚开始我稍微接触了一下合约，但很快亏掉了几千元，算是交了学费。然后很快理智地退出了，合约本质上来说和赌博有点类似，钱来得也快亏得也快，但大概率是要亏钱的。 我听从了一些行业老鸟的建议，拿住比特币就行，其他的看着买点。我从 2023 年开始陆续买入了一些比特币，当时的价格不算高，到今年年底看来也有不少涨幅了。我抱着长期拿住的心态在买入，打算至少持有八九年以上。所以现在我基本不怎么关心价格了，如果买了就当作这钱是存在那里好了，把时间幅度拉长，我相信比特币未来会更值钱。我愿意相信这个行业是因为从技术的角度考虑是即有趣又有挑战。这两年来我工作的项目和比特币是非常类似的，就当作为信仰充值。 2024 年 5 月开始我投入到了公司的一个新项目开发上，这是个完全开源的项目叫作 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/fiber">nervosnetwork/fiber</a>，简而言之就是 CKB 上的闪电网络实现。所以 2024 年的大部分时间我都专注于这个项目，因为这是个新项目所以很多功能都是从头开始实现，这对于程序员来说时段快乐时光，毕竟维护老项目很多时候都是在考虑兼容性，没有什么大量写代码的快感。 <a target="_blank" rel="noopener" href="https://zh.wikipedia.org/wiki/%E9%97%AA%E7%94%B5%E7%BD%91%E7%BB%9C">闪电网络</a>似乎现在已经过了最火的时候，但却是古典区块链技术的代表。如何在去中心的环境中构建出信任通道，这是个非常复杂的问题，大多数时候我们都是在参考 <a target="_blank" rel="noopener" href="https://github.com/lightning/bolts/tree/master">BOLT</a>这个规范。开发过程中一直需要考虑的是这样安全么，如果对方出错或者发出恶意的请求会怎样，channel 的基本保证是任何时候任意一方都可以退出，而不会造成资金上的损失，另外还需要兼顾的是隐私的问题，所以支付的多跳传输需要使用洋葱加密，错误的返回链路上也需要用洋葱加密。反正本质上，这些都归结为数学问题，多签、加密和解密、哈希时间锁合约，确保了交易的不可伪造性和隐私性。我不打算继续在这篇文中写更多关于闪电网络的技术细节，也许以后会写一系列的相关文章。 总体来说，2024 年又开心地写了一年代码，甚至我觉得技术越做越有意思了： <img src="http://catcoding.me/images/ob_pasted-image-20241228233657.png" alt="" /> 远程工作两年后，我更多采用把问题留在脑海中，时不时拿出来思考的工作方式。有几次这样的经历，我像是在睡觉的过程中还在思考某个问题，然后第二天起来还记得当时想出来的办法。 另一方面，有些遗憾的是我今年参与 Rust 等开源项目的时间比较少了，写文章也比较少。似乎在公司的项目上工作得足够有趣、找到了足够的收获感，没有多少动力和时间去做其他项目。但意想不到的是今年年底还是收到了 Rust 基金会的邮件，愿意资助我一年继续做贡献。所以明年我应该还是会把一些业余时间投入到 Rust 项目上，这也算是把爱好折腾成了责任和义务。可以说 Rust 延长了我的技术生命，让我幸运地投入到一堆 Rust 开源项目上，并且找到适合自己的公司，以远程的方式工作。 因为整天除了带娃和宅在家编程，2024 年我似乎没认识什么新的人，社交圈很小，甚至到了年底我才想起是不是该约上许久不见的朋友线下聊聊。我不知道如何解决这个问题，这有一半是远程工作带来的副作用，另一半就是人到中年在社交上的需求小了。我还在 Cambly 上练习口语，这已经变成了我强迫自己和人沟通的一个渠道，我每周三节课一共一个半小时，其中一个小时大多数都是和我的固定老师聊，他比我大 10 岁左右，我们聊过很多话题，我给他科普区块链等技术领域、做模拟演讲等。另外我喜欢找那些一直在旅游的人或者退休了的人聊，因为通常能听到一些好玩的事情，有次有个一直满世界漂流的人对我说他希望的是 die with my boots on，我一下子没听出其含义，后来通过他的解释我知道了这个俗语的意思：一个穿着靴子死去的人会一直生活和战斗到最后，他们像往常一样生活时去世，而不是因为年老和因疾病、体弱等卧床不起，对他来说他希望自己死在旅游的途中。我想这种生活态度真是太好了，而且他也在践行自己的这种生活方式。我喜欢看那些一直在路上的博主，比如 <a target="_blank" rel="noopener" href="https://www.youtube.com/@shisanyao/videos">十三要和拳头</a> 和 <a target="_blank" rel="noopener" href="https://www.youtube.com/@liuweiyuan">刘伟元的旅行</a>，可能正是因为我已经不太可能做到像他们那样随心所欲地玩耍。 说到旅行，今年五月底公司团建我们去了大理待了一周，那里的风景和气候都还挺不错，有些地方显得商业化太重，但沿着洱海骑行和在苍山徒步都非常惬意。夏天我和家人去了一趟北方，走的是比较热门的路线，青岛、威海、大连。不过这趟很累，因为暑假期间都是家长带着孩子，所以去哪里都是人挤人，但其实孩子们也还太小，他们只是想找个地方玩沙子赶海，而对于历史遗迹之类的地方则完全不感兴趣。 11 月公司组织去了趟清迈，我们在那里举行了第一次的 <a target="_blank" rel="noopener" href="https://www.bitgetapps.com/zh-CN/news/detail/12560604322596">CKCON</a>，我也是第一次用英语做技术演讲。感觉清迈的基础设施还有待提升，有一次我一个人打车，司机好像是中途拐进了城中小道上歪歪扭扭的乱窜，我开始担心自己会不会被拉去割腰子。其实司机是个好人，到了终点后我才发现自己的 Grab 不能付款，他就耐心得等我去找人借现金。 我很喜欢公司组织的线下聚会，不但可以和平时合作的同事见面聊聊，也可以暂时从一直带娃的生活中抽离出来，每次出去我的感受是这样的： <img src="http://catcoding.me/images/ob_pasted-image-20241229004417.png" alt="" /> 所以带孩子真的很累么？确实比较累，而且得看这个孩子是几岁。我喜欢带两三岁到五岁这个年龄段的孩子，因为这时候的孩子都是天真，又比较听话。像我大女儿到了七岁八岁，开始有自主意识了就很淘气，很多时候也不怎么听话，有时候会让我焦头烂额。小学二年级的作业比较多，我女儿每天需要在家里花大概一个小时来写作业，而且现在的数学作业看起来很多应用题，像我女儿这种没接受过幼小衔接的做起来就很慢，肯定需要家长帮忙。有时候孩子做了坏事，我会想起自己小的时候也做过类似的事情，但我现在已经变成了孩子眼中那个严格的父亲了。有次父亲看我对孩子发火，就对我说对孩子还是要适当宽容一些，然后提起小时候每次打了我之后都会心里很后悔，我听了就很感慨。 今年下半年开始，我又开始经常打篮球了。刚开始主要是为了缓解久坐的疲劳，后来就变成每天不断地提升自己的投篮技术。深圳的秋冬季节很舒服，我经常中午 11 点半去小区篮球场投篮差不多一个小时，顺便晒晒太阳。每天这样练习之后投篮技术有了很大的提升，无人防守的情况下基本有 70% 左右的命中率。一个人投篮这种事情看起来很枯燥和无聊，但其实沉下心来运动的感受非常好，我把刻意练习的心态投入到了这个项目上，那一个小时内能达到类似心流的状态，时间变得清澈，仿佛只有我和篮球了。投篮最重要的是掌握出手时候的平衡度，手腕和手指用力，让篮球后旋起来，练习多了投篮动作就形成了肌肉记忆，只要动作做完就大致能知道是否命中，篮球空心入网的声音真是太悦耳了。磨练技艺真是一种最好的状态，而编程、写作、篮球都是这样的事情。 打篮球已经是我整整 20 年的爱好了，但我从未好好练习过投篮，可惜左膝盖在 2017 年伤过一次，运动激烈了容易酸疼，所以再也不怎么去和年轻人打半场了，即使偶尔玩玩总是担心自己受伤，在场上变得畏手畏脚。那些之前理所当然的事情变得奢求了，能力和自由渐渐地丧失，这真是大龄带来的切身痛苦。 有一次我傍晚还在练习投篮，有个看起来比我大七八岁的大哥过来，渐渐地我们聊了起来。我看他的篮球鞋很漂亮，他说是他儿子的，应该叫作空军一号。我们边投篮边聊天，一直聊到天完全黑掉看不到篮筐。没想到这样一个在国企工作的大哥也经常翻墙看新闻，说这几年的情形是聪明人都在蛰伏和休息。还有一次我正在投篮，刚好碰到一个幼儿园班的小朋友们经过，因为球场上就只有我一个人在锻炼，他们就围在场边观看，渐渐地我每进一个球小朋友们就开始欢呼，每次没进就惋惜叹声，这真是个有趣的经历。日子大多平淡如水，但这些小瞬间却留在了心里。 回想起来，今年生活中的一些其他变化，彻底不看朋友圈，不怎么追新闻，总体来说信息更闭塞了。但 2024 却是我生活上最朴素充实的一年，上班做感兴趣的项目下班做喜欢的运动，在我做了很多减法后，现在的生活好像就是自己理想中的状态。 祝各位新年快乐！

2025/1/1

CKB new script verification with VM pause

CKB 相关技术文章第三篇。 <h2 id="背景"><a href="#背景" class="headerlink" title="背景"></a>背景</h2> CKB 的每一个交易在提交到交易池之前都会经过一个 script verification 的过程，本质上就是通过 CKB-VM 把交易里的 script 跑一遍，如果失败了则直接 reject，如果通过了才会继续后面的流程。 <img src="http://catcoding.me/images/ob_what-is-verification.png" alt="" /> 这里的 script 就是一种可以在链上执行的二进制可执行文件，也可以称之为 CKB 上的合约。它是图灵完备的，我们通常可以通过 C、Rust 来实现这些 script，比如 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb-system-scripts">nervosnetwork/ckb-system-scripts</a> 就是 CKB 上的一些常用的系统合约。用户在发起交易的时候就设置好相关的 script，比如 lock script 是用来作为资产才所有权的鉴定，而 type script 通常用来定义 cell 转换的条件，比如发行一个 User Define Token 就需要指定好 UDT 所对应的 type script。script 是通过 RISC-V 指令集的虚拟机上运行的，更多内容可以参考 <a target="_blank" rel="noopener" href="https://docs.nervos.org/docs/script/intro-to-script">Intro to Script | Nervos CKB</a>。 <h2 id="大-cycle-交易的挑战"><a href="#大-cycle-交易的挑战" class="headerlink" title="大 cycle 交易的挑战"></a>大 cycle 交易的挑战</h2> 通常一个简单的 script 在 CKB-VM 里面执行是非常快的，VM 上跑完之后会返回一个 cycle 数目，这个 cycle 数量很重要，我们用来衡量 script 校验所耗费的计算量。一个合约的 cycle 数多少，理论上来说依赖于 VM 跑的使用用了多少个指令，这由 VM 在跑的时候去计算 <a target="_blank" rel="noopener" href="https://docs.nervos.org/docs/script/vm-cycle-limits">VM Cycle Limits</a>。 随着业务的复杂，逐渐出现了一些大 cycles 的交易，跑这些交易可能会耗费更多的时间，但我们总不可能让 VM 一直占着 CPU，比如在处理新 block 的时候，<a target="_blank" rel="noopener" href="https://github.com/chenyukang/ckb/blob/8cb49e4d727f337a2c80e210507a9e277bab3391/chain/src/verify.rs#L79-L87">CPU 应该在让渡出来</a>。但之前 CKB-VM 对这块的支持不够，为了达到变相的暂停，处理大 cycles 的时候我们可以设置一个 step cycles，假设我们设置为 100 cycles，每次启动的时候就把 max_cycles 设置为 100，这样 VM 在跑完 100 cycle 的时候会退出，返回的结果是 cycle limitation exceed，然后我们就知道这个 script 其实是没跑完的，先把状态保存为 suspend，然后切换到其他业务上做完处理之后再继续来跑。回来后如何才能恢复到之前的执行状态呢，这就需要保存 VM 的 <a target="_blank" rel="noopener" href="https://github.com/chenyukang/ckb/blob/aaa51583656f022ad64ec98d1fb0205fc2878dba/script/src/types.rs#L319-L333">snapshot</a>，相当于给 VM 当前状态打了一个快照： <img src="http://catcoding.me/images/ob_ckb-vm-snapshot.png" alt="" /> 根据这个机制，我们老的 script 校验大交易的整个流程是通过一个 FIFO 的队列保存大交易，然后通过一个后台任务不断地从这个队列中取交易跑 VM，每次都跑 1000w cycle 左右，在这个过程中就可能切换出去，没跑完的交易继续放入队列等待下一次执行： <img src="http://catcoding.me/images/ob_pasted-image-20241106114040.png" alt="" /> 对应到代码就是 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/blob/develop/tx-pool/src/chunk_process.rs">ChunkProcess</a> 这个单独服务来处理的。由于 ChunkProcess 是一个单独的服务，它的处理流程和其他交易的处理流程是不一样的，这样会导致代码的复杂度增加，比如： <ol> <li>要针对 ChunkProcess 里面的交易额外判断，<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/blob/3d674d558e5574f0c77a52798775c903561a933a/tx-pool/src/process.rs#L321">例子 1</a>, <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/blob/3d674d558e5574f0c77a52798775c903561a933a/tx-pool/src/process.rs#L350">例子 2</a></li> <li>暂停 / 恢复 ChunkProcess 处理的时候，需要对 ckb-vm 做相关的状态保存和恢复处理，参考结构 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/blob/3d674d558e5574f0c77a52798775c903561a933a/script/src/types.rs#L308">TransactionSnapshot</a>, 代码比较复杂且容易遗漏，历史上也有过相关的 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/pull/3188">bug 1</a>, <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/pull/3177">bug 2</a>, 以及安全问题。</li> <li>代码中包含重复逻辑，比如 <code>chunk_process</code> 里的 <code>process_inner</code> 和 <code>_resumeble_process_tx</code>。</li> <li>由于它只能同时处理一个大 cycle 交易，在 tx pool 本身比较空闲的情况下如果收到了多个大 cycle 交易也不能并行处理，比如 .bit 团队之前有过反馈他们通过本地 rpc 同时提交多个大 cycle 交易会比较慢的问题。</li> </ol> <h2 id="CKV-VM-pause"><a href="#CKV-VM-pause" class="headerlink" title="CKV-VM pause"></a>CKV-VM pause</h2> 这些问题的根本是 VM 只能通过 cycle step 的方式来暂停，有没有一种方式是我们任何时候想暂停就暂停，就是 event based 的方式。所以后来 CKB-VM 团队做了一些改进： <ul> <li><a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb-vm/pull/348">ckb-vm 新的暂停方式</a></li> <li><a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb-vm/pull/345">feat: Add alternative snapshot design. #345</a></li> <li><a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb-vm/pull/299">Make ckb-vm thread-safety #299</a></li> <li><a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/pull/3752">CKB feature: thread-safe vm</a></li> </ul> 这个方法的本质是通过 VM 的 <code>set_pause</code> 接口，把一个 <code>Arc<AtomicU8></code> 的 pause 共享变量设置给 VM。然后在 VM 外通过更新这个 pause 的变量让 VM 进入暂停状态或者继续执行，这样我们就不需要 dump snapshot 等操作，因为 VM 整个就还是在内存中等着： <img src="http://catcoding.me/images/ob_ckb-vm-pause.png" alt="" /> <h2 id="新的实现方案"><a href="#新的实现方案" class="headerlink" title="新的实现方案"></a>新的实现方案</h2> 基于这些改进我们可以重新设计和实现 CKB verify 这部分的代码，主要是为了简化这部分代码，并且提高大交易处理的效率。这是一个典型的 queue based multiple worker 方案： <img src="http://catcoding.me/images/ob_new-ckb-verify.png" alt="" /> 主要的核心是就是这段异步执行 VM 的逻辑：<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/blob/develop/script/src/verify.rs#L1166-L1269">chunk_run_with_signal</a>。做的过程中发现一些其他问题： <ul> <li>交易提交的时候，<code>SubmitLocalTx</code> 和 <code>SubmitRemoteTx</code> 如果 verify 失败目前会立即返回 <code>Reject</code>，如果改成加入队列的方式，这个结果无法实时给到，所以做了如下改动： <ul> <li>优先处理本地的交易，本地提交的交易不会放入 queue，而是直接会在 RPC 的处理阶段执行</li> <li>所有的来自网络 peer 的交易都全到放入到 queue</li> </ul> </li> <li>后来 CKB vm 又新增了 spawn 的实现，所以会有 parent、child 的概念，那么<code>Child VM</code> 是执行 syscall 的时候执行 <code>machine.run</code> ，如果不改这块执行 child vm 的时候不可暂停 <ul> <li>后来我们讨论了之后决定 spawn 时把父的 <code>Pause</code> 传递给子，然后暂停的时候给父的 <code>Pause</code> 设置暂停，这样所有的子 machine 同样返回 <code>VMError::Pause</code> ，同时把当前的 machine 栈重新入栈，恢复的时候继续执行，这里逻辑比较重，相关代码实现：<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/blob/6f643220c704138298e693b0ef737c56a98ed762/script/src/verify.rs#L1452">run_vms_child</a>。</li> </ul> </li> <li>后来用重新设计了 spawn，使用了一种新的 determined scheduler 的方式去管理所有的 vms 和 IO，之前和 VM 的使用者角度来说之前需要和 VM 交互，现在变成了都通过<a target="_blank" rel="noopener" href="https://github.com/chenyukang/ckb/blob/8cb49e4d727f337a2c80e210507a9e277bab3391/script/src/scheduler.rs#L207-L236"> scheduler 来管理</a>。关于 spawn 的设计参考这个文档：<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/rfcs/pull/436/files">Update spawn syscalls</a>。</li> </ul> <hr /> 整个 PR 在这里：<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/pull/4291">New script verify with ckb-vm pause</a>

2024/11/7

CKB RBF 设计和实现

CKB 相关技术文章第二篇。 <h2 id="Replace-by-fee"><a href="#Replace-by-fee" class="headerlink" title="Replace by fee"></a>Replace by fee</h2><h3 id="问题"><a href="#问题" class="headerlink" title="问题"></a>问题</h3> 如果一个交易成功发送到交易池，但可能出现因为费用较低而一直得不到处理。之前 CKB 没有其他措施来处理这种情况。 例如 <a target="_blank" rel="noopener" href="https://www.notion.so/Dotbit-4-45e129cb4c434bd2902569aff67c4383?pvs=21">Dotbit 4 位域名注册拥堵</a> 这个事故发生过程中，<code>CKB</code> 的应用方无法使用任何方式来尽快让自己的交易被打包，这就是引入 <code>Replace-by-fee（RBF)</code> 的原因，我们需要一个机制来提高已经在交易池里交易的费用，替换掉旧的交易，让新的交易尽快被打包。 在新的 <code>multi_index_map</code> 重构后，交易在 <code>pending</code> 阶段也会按照交易的 <code>score</code> 来优先处理 (通常费用高的交易 <code>score</code> 也会高)，这会避免高费用的交易被阻塞住，所以理论上述需要手动提高费用的情况会减少，但我们还是需要 RBF 来手动提高交易的费用，应对意外的情况。 另外，RBF 可能将多个老的交易替换出去，因此也是将两个或多个支付合并为一的方法，例如下图所示，如果满足条件 <code>tx-a</code>, <code>tx-b</code>, <code>tx-c</code>, <code>tx-d</code> 都会被 <code>tx-e</code> 这个交易替换掉： <img src="http://catcoding.me/images/ob_pasted-image-20241031103004.png" alt="" /> <h3 id="参考"><a href="#参考" class="headerlink" title="参考"></a>参考</h3> <ul> <li><a target="_blank" rel="noopener" href="https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki">bips/bip-0125.mediawiki</a></li> <li><a target="_blank" rel="noopener" href="https://bitcoincore.org/en/faq/optin_rbf/">Bitcoin Core :: Opt-in RBF FAQ</a></li> <li><a target="_blank" rel="noopener" href="https://www.notion.so/RBF-in-CKB-draft-2023-01-05-79736edd0c824fae98f1e7ee42d4e436?pvs=21">RBF in CKB(draft 2023.01.05)</a></li> <li><a target="_blank" rel="noopener" href="https://bitcoinops.org/en/newsletters/2022/03/16/#ideas-for-improving-rbf-policy">Bitcoin Optech Newsletter #191 | Bitcoin Optech</a></li> </ul> 中本聪最初的 Bitcoin 版本中就有引入一个 <code>nSequence</code> 的字段，如果相同交易的 <code>nSequence</code> 更高，就可以<a target="_blank" rel="noopener" href="https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp#L434">替换</a>之前老的交易，这个实现的问题是没有支付额外的 fee，miner 没用动力去替换交易，另外因为没有 rate-limiting 从而导致可能被滥用，所以 Bitcoin 在 0.3.12 版本中禁止了这个功能。后来 Bitcoin 重新引入了新的 RBF 改进，主要包括需要支付额外的费用来替换老交易，另外为 RBF 指定了更多的限制条件。 在 CKB 上我们之前做过两次 RBF 的相关调研，因为之前 <code>Pending</code> 是一个 FIFO 的数据结构，所以处理替换不是很方便，在 RBF in CKB(draft 2023.01.05) 尝试引入一个 <code>high priority queue</code> 来实现 <code>inject-replace</code>。交易池改造之后，整个交易池可当作一个优先队列，所以应对 <code>RBF</code> 会简单很多。 <h2 id="新增-RBF-的流程"><a href="#新增-RBF-的流程" class="headerlink" title="新增 RBF 的流程"></a>新增 RBF 的流程</h2> <img src="http://catcoding.me/images/ob_rbf2.png" alt="" /> <h2 id="实现细节"><a href="#实现细节" class="headerlink" title="实现细节"></a>实现细节</h2> <ul> <li><code>pre-check</code> 为 entry 加入到 tx-pool 之前必须要做的检查，之前只是做双花的检查，新增 RBF 后如果双花检查失败（这里意味着冲突），继续做 RBF 的相关检查，如果 RBF 检查成功则也返回成功，否则直接返回错误。这里默认直接做 resolve_tx 的检查，如果成功则走正常流程，目的是不给正常流程增加额外成本。所以这就是<a target="_blank" rel="noopener" href="https://github.com/chenyukang/ckb/blob/44331ec5b9fcda217f33c471057fa479bd36a89f/tx-pool/src/process.rs#L216-L255"><code>pre-check</code> 修改后的主要逻辑</a> 。</li> </ul> RBF 的检查规则参考 Bitcoin 的六条，<a target="_blank" rel="noopener" href="https://github.com/chenyukang/ckb/blob/2be67e79acec94369a96f786d3041e6cb00cf1f2/tx-pool/src/pool.rs#L483-L565">check_rbf 初步实现</a> <pre class="line-numbers language-plain" data-language="plain"><code class="language-plain">实现细节：（Bitcoin Core 0.12.0） ~~1. 交易需要声明为可替换交易~~ 2. 新替换交易没有包含新的、未确认的 inputs 3. 新替换交易的交易费用比待替换交易费用高 4. 新替换交易费用必须比节点的 min relay fee 高 5. 待替换交易的子交易数量不可超过 100 条（即使用了该交易的任意 outputs，该交易替换后它们将被从内存池中移出） 6. 因为 ckb 是做了两步提交，我们新增规则：被替换的交易只能是 Pending 或者 Gap 阶段的。 </code></pre> 我们不给交易加新的字段表示是否可以被替换，而是通过节点是否配置了 <code>min_rbf_rate</code> 来决定是否能做替换，因此 <code>规则 1</code> 不做对应考虑。 <h3 id="替换和提交"><a href="#替换和提交" class="headerlink" title="替换和提交"></a>替换和提交</h3> 修改 <code>tx-pool</code> 的 <code>submit_entry</code> 函数，传入 <code>conflicts</code>，在新增 entry 之前把所有冲突的交易删除放入 <code>rejected</code> 记录，另外确保所有检查完成了之后才做删除和写操作：<a target="_blank" rel="noopener" href="https://github.com/chenyukang/ckb/blob/2be67e79acec94369a96f786d3041e6cb00cf1f2/tx-pool/src/process.rs#L99-L154">submit_entry 逻辑</a>。 最终实现在这个 PR 里<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/pull/4079">Tx pool Replace-by-fee</a>。 <h3 id="并发的-Bug"><a href="#并发的-Bug" class="headerlink" title="并发的 Bug"></a>并发的 Bug</h3> 在最初的实现版本中，隐藏了一个并发的 bug 后来在测试发现了。RBF 的检查如果放在 <code>pre-check</code> 中，如果多个线程中的多个交易发生了冲突，input resolve 可能会出问题。<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/pull/4258">Fix concurrency issue for RBF</a> 这个 PR 修复了这个问题，把 RBF 的冲突检查移动了 submit entry 之前，因为在这个函数里面会持有 write 锁。 <h3 id="cycling-attack"><a href="#cycling-attack" class="headerlink" title="cycling attack"></a>cycling attack</h3> 后来我们在做闪电网络的时候又发现 RBF 可能会引入 cycling attack 的风险，这个攻击通过构造巧妙的新交易，让支付路径上的中间节点的 commitment tx 不能按时上链，<a target="_blank" rel="noopener" href="https://blog.satsbridge.com/lightning-replacement-cycling-attack-explained-45636e41bc6f">Lightning Replacement Cycling Attack Explained</a>这篇文章有更详细的描述。 所以我们后来又做了这么一个改进：<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/pull/4561">Recover possible transaction in conflicted cache when RBF</a> 来规避这个问题。

2024/11/6

CKB 交易池重构

在 11.9 号清迈的 <a target="_blank" rel="noopener" href="https://share.foresightnews.pro/article/detail/70811">CKCON</a> 会议上我会做一个关于 CKB 交易池的演讲，这是我准备的 slides <a target="_blank" rel="noopener" href="https://ckb-tx-pool.vercel.app/1">Key Upgrades of the CKB Core</a> 。所以这段时间在整理之前做项目的时候写的一些文档，顺便分享到自己的博客上。既然我们整个项目的源码都是公开的，这些文档其实也是可以分享的。 第一次听说 CKB 的读者可以参考这个文档以了解什么是 CKB 以及如何工作的：<a target="_blank" rel="noopener" href="https://docs.nervos.org/docs/getting-started/how-ckb-works">How CKB Works | Nervos CKB</a>。 我加入 Cryptape 之后一年内做的主要工作，涉及到交易池重构、Replace-by-fee 功能、以及 new-verify。这是第一篇关于交易池重构的文章。 <h2 id="什么是交易池"><a href="#什么是交易池" class="headerlink" title="什么是交易池"></a>什么是交易池</h2> 在 bitcoin 中交易池叫作 mempool，比如 <a target="_blank" rel="noopener" href="https://mempool.space/">mempool - Bitcoin Explorer</a> 这个网站就很好地展示了其当前的状态。 交易池是 bitcoin 中的一个重要的组件，但感觉专门关于这块的资料很少，只能通过 PR 和邮件列表上的讨论看到一些文档。但交易池非常重要，因为一个交易要上链必须会通过交易池，而其中的交易打包算法涉及到如何选择合适的交易，这里面有很多因素需要考虑，所以在实现上也是比较复杂的。 当一个交易被提交到一个节点时，或者一个节点从网络中同步到交易时，这个交易首先需要被加入到交易池中，交易池里会根据一定的算法去选择下一个需要被打包的交易，另外交易池作为一个缓存，我们需要为其设置一个最大的 size。所以交易池里面最重要的两个操作就是 packaging 和 evicting。 交易池里面的交易存在父子关系，打包的时候需要从交易链的纬度去考虑，后面的 Replace by fee 这些功能也需要关注整个交易的所有子交易。 <img src="http://catcoding.me/images/ob_pasted-image-20250221102123.png" alt="" /> <h2 id="交易池重构"><a href="#交易池重构" class="headerlink" title="交易池重构"></a>交易池重构</h2><h3 id="问题"><a href="#问题" class="headerlink" title="问题"></a>问题</h3> 根据 RFC <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0020-ckb-consensus-protocol/0020-ckb-consensus-protocol.md#two-step-transaction-confirmation">consensus-protocol</a> 的设计，CKB 里的 tx-pool 采用了两段提交的方式： <img src="http://catcoding.me/images/ob_pasted-image-20241031100804.png" alt="" /> 相应地在交易池最初实现的时候， <code>ckb</code> 的代码实现中 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/blob/rc/v0.111.x/tx-pool/src/pool.rs">tx-pool</a> 同样采用了三个独立的队列，具体定义如下： <ul> <li><code>pending</code> 交易刚加入到交易池时候的状态，我们每次只能处理不多于 <code>MAX_BLOCK_PROPOSALS_LIMIT</code> 个交易，交易需要先进入 <code>gap</code> 备选，具体代码逻辑在 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/blob/3de5a20ce60619927f41f81d9584cab9d39d1275/tx-pool/src/block_assembler/mod.rs#L345C11-L345C11">update_proposals</a> 。</li> <li><code>gap</code> 已经被 proposed 了，但是还不能被打包，需要等一个块后才能被打包，所以这只是内部中间过渡状态。</li> <li><code>proposed</code> 交易可以加入到 <code>block_template.transactions</code> , 最终打包到 block 里，具体代码逻辑在 <a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/blob/e75ab3faf0f7b1d182be2f1daa30f300cfefabc8/tx-pool/src/block_assembler/mod.rs#L195">block_assembler</a>。</li> </ul> 实现中 <code>pending</code> 和 <code>gap</code> 同样都是使用了 <code>PendingQueue(LinkedHashMap)</code>，而 <code>proposed</code> 采用了 <code>SortedTxMap(HashMap + BTreeSet)</code> ： <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">pub struct TxPool { pub(crate) config: TxPoolConfig, /// The short id that has not been proposed pub(crate) pending: PendingQueue, /// The proposal gap pub(crate) gap: PendingQueue, /// Tx pool that finely for commit pub(crate) proposed: ProposedPool, .... pub(crate) expiry: u64, } </code></pre> 这样的实现存在以下问题： <ul> <li> 我们不容易对所有在交易池中的 entry 做统一排序，这样会存在以下问题： <ul> <li>一个 fee 高的交易可能在 transaction 多的情况下在 pending 阶段一直卡着，因为我们在 pending 和 gap 阶段只是按照时间顺序来处理，只在 proposed 后的打包阶段按照交易费来处理。</li> <li><a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/issues/3942">issue 3942</a> 交易池满了之后，我们需要选择一些 entry 做 evict，我们目前的 evict 逻辑很<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/blob/fdee47bbd87c66d8a0e54c3ac1f5386cb9aba643/tx-pool/src/pool.rs#L322">简单粗暴</a>。我们希望尽量选择最小 descendants 的交易，这样能避免在 evict 过程中删除过多交易。我们目前在 pending 和 gap 阶段没有记录 descendants，而需要加入这个逻辑就和 proposed 阶段完全重复，而且因为不会统一排序，后续实现也不容易。</li> </ul> </li> <li> pending, gap 和 proposed 除了所采用的数据结构不同外，有很多逻辑雷同的代码，比如 entry 的新增和删除等操作，同样都维护了 deps 和 header_deps，resolve_conflict, resolve_conflict_header_dep, resolve_tx 等函数的逻辑也是类似的，但实现上有些细微差异，这导致长期来说代码不容易维护。 </li> <li> 同样我们在 <code>tx-pool</code> 上对 entry 做迭代和查询时，需要依次针对 pending, gap, proposed 做相同的逻辑，比如 resolve_conflict_header_dep 这样的函数在 pool 中有几个类似的，甚至 get_tx_with_cycles 这样的函数，需要依次判断各个队列。 </li> <li> 实现其他功能不方便，比如我们如果要实现 Replace by fee，就需要找交易池中和新交易有冲突的交易，我们需要在三个数据结构上分别进行检查才能得到结果。 </li> </ul> <h3 id="方案"><a href="#方案" class="headerlink" title="方案"></a>方案</h3> 基于以上解决现有问题、应对未来的潜在需求、保持代码可维护性的角度，同时参考 <a target="_blank" rel="noopener" href="https://github.com/bitcoin/bitcoin/blob/322ec63b01499c1ec52d3912ee382ebd59f2366b/src/txmempool.h">Bitcoin txmempool</a> 的实现，我们提出引入 Multi_index_map 对 tx-pool 进行重构。 总体方向是把所有的 <code>entry</code> 放入统一的数据结构中进行管理，加入一个新的字段 <code>status</code> 标识目前 <code>entry</code> 所处的阶段，然后通过 index_map 的方式根据不同的属性进行排序和迭代： <pre class="line-numbers language-rust" data-language="rust"><code class="language-rust">pub enum Status { Pending, Gap, Proposed, } #[derive(MultiIndexMap, Clone)] pub struct PoolEntry { #[multi_index(hashed_unique)] pub id: ProposalShortId, #[multi_index(ordered_non_unique)] pub score: AncestorsScoreSortKey, #[multi_index(ordered_non_unique)] pub status: Status, #[multi_index(ordered_non_unique)] pub evict_key: EvictKey, // other sort key pub inner: TxEntry, } </code></pre> 其中根据 Rust 社区的 <a target="_blank" rel="noopener" href="https://github.com/lun3x/multi_index_map">multi_index_map</a> 内部实现采用的数据结构看，性能上应该没有什么大问题： <ul> <li>Hashed index retrievals are constant-time. (FxHashMap + Slab).</li> <li>Sorted indexes retrievals are logarithmic-time. (BTreeMap + Slab).</li> <li>Non-Unique Indexes <ul> <li>Hashed index retrievals are still constant-time with the total number of elements, but linear-time with the number of matching elements. (FxHashMap + (Slab * num_matches)).</li> <li>Sorted indexes retrievals are still logarithmic-time with total number of elements, but linear-time with the number of matching elements. (BTreeMap + (Slab * num_matches)).</li> <li>Iteration within an equal range of a non-unique index is fast, as the matching elements are stored contiguously in memory. Otherwise iteration is the same as unique indexes.</li> </ul> </li> </ul> 具体实现时我们是否把 inner 也放在 Slab 里面以后可以通过 benchmark 来选择，从实现的简洁性角度考虑统一放在一个数据结构里面更容易。 目前的实现版本：<a target="_blank" rel="noopener" href="https://github.com/nervosnetwork/ckb/pull/3993">Tx pool rewrite with multi_index_map #3993</a> <h2 id="实现结果"><a href="#实现结果" class="headerlink" title="实现结果"></a>实现结果</h2> 我们首先只是做模块内的重构 (保持对外逻辑和以前一样)，当然考虑引入了新的数据结构，不管是从性能上还是内存占用上都会有一些影响。 为了做统一排序这件额外的事，本质上我们引入了额外的 Map(FxHashMap 或 BTreeMap) 来存储，所以比以前需要更多内存。另外，我们有时候需要调用 <code>get_by_status</code> 来筛选某个状态的 entries，这在新的实现里面需要先从 index 里面找出 slab 的 id，然后再找到对应的 entry，所以必然也会比以前慢。 从最终的性能对比结果上，除了内存会稍微有增加，性能上没有大的变化。另外我们在实现的过程中对所用到的 Rust 包 multi-index-map 做了一些贡献：<a target="_blank" rel="noopener" href="https://github.com/lun3x/multi_index_map/pull/23">Non-unique index support, capacity operations, performance improvement & more by wyjin</a>

2024/11/6

xz-backdoor 观感

写写最近一周的大瓜 xz-backdoor，该事件可能成为开源供应链安全的一个分水岭，从技术角度看，这里面的社工和混淆也是精彩。 简单介绍一下背景，xz 是一个开源的无损压缩工具，在出事之前可能很少有人注意到这个压缩库使用如此之广，几乎任何一个 Unix-Like 的操作系统里面都有 xz-utils。在两年多的时间里，一个名为 <code>Jia Tan</code> 的程序员勤奋而高效地给 xz 项目做贡献，最终获得了该项目的直接提交权和维护权。之后他在 libzma 中加入了一个非常隐蔽的后门，该后门可以让攻击者在 SSH 会话开始时发送隐藏命令，使攻击者能够跳过鉴权远程执行命令。 <a target="_blank" rel="noopener" href="https://research.swtch.com/xz-timeline#jia_tan_arrives_on_scene_with_supporting_cast">Timeline of the xz open source attack</a> 总结了该事件的主要时间点，这里我挑一些关键节点： <h4 id="潜伏"><a href="#潜伏" class="headerlink" title="潜伏"></a>潜伏</h4> <ul> <li>2005 ~ 2008 xz 项目的初始版本，这是一个文件压缩算法，主要由 <a target="_blank" rel="noopener" href="https://github.com/kobolabs/liblzma/blob/87b7682ce4b1c849504e2b3641cebaad62aaef87/doc/history.txt">Lasse Collin</a> 开发和维护。</li> <li>2021-10-29 ~ 2022-06-29 Jia Tan 开始较为密集地给 xz 项目贡献代码，同时几个类似马甲的账号 (Jugar Kumar, Dennis Ens) 在邮件列表里抱怨 Merge 得不到及时处理，问题得不到回复，有点逼宫的意思，在这个过程中项目主导者 Lasse Collin 把最近的优秀贡献者加入了维护者列表。</li> </ul> <h4 id="准备"><a href="#准备" class="headerlink" title="准备"></a>准备</h4> <ul> <li>2022-09-27 Jia Tan 获得了信任，并开始主导新版本的发布，他在这期间做了几个看似合理的 PR，但其实是在为今后的后门做伏笔，另一个马甲 Hans Jansen 提供了一个钩子可以让后门里的代码替换全局函数，从而绕过检查。</li> <li>2023-07-07 Jia Tan 在 Google 的 oss-fuzz 提供修改禁用了 <code>ifunc</code>，这也是为了避免 fuzz 可能发现后门。</li> </ul> <h4 id="发动"><a href="#发动" class="headerlink" title="发动"></a>发动</h4> <ul> <li>2024-02-23 Jia Tan 发布了第一个有害的 PR，在测试代码中包含了几个 binary 文件，这些文件看起来只用于测试，所以在代码 review 的过程中肯定不会被仔细查看。</li> <li>2024-02-26 Jia Tan 通过一个<a target="_blank" rel="noopener" href="https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7">非常隐蔽的提交</a>，给 CMakeList.txt 增加了一个 <code>.</code>，使得代码会编译失败从而让 Landlock 不会被激活。</li> <li>2024-02-24 Jia Tan 发布 v5.6.0，其中使用脚本混淆悄悄地把后门的 payload 塞进了目标文件中。Gentoo 和 Debian 开始在 unstable 版本中含有后门。</li> <li>Hans Jansen 同时在发邮件催促 Debian 升级 xz 到 v5.6.1</li> </ul> <h4 id="暴露"><a href="#暴露" class="headerlink" title="暴露"></a>暴露</h4> <ul> <li>2024-03-29: 一个叫 Andres Freund 的开发者在分析一个 sshd 可疑的 500ms 延迟时，发现了隐藏在 xz 的恶意后门。如果不是偶然的发现，估计现在世界上无数的服务器处于肉鸡状态，这位微软的员工如英雄一般拯救了世界。</li> </ul> <hr /> <h2 id="攻击者是中国人？"><a href="#攻击者是中国人？" class="headerlink" title="攻击者是中国人？"></a>攻击者是中国人？</h2> 从主要攻击者的名称看似乎是中国人，但 Git 昵称和时区这种东西很容易伪造，有人分析过开发者的代码提交时间，分析得出实际可能是欧洲人/以色列人冒充。 但不可否认，肯定会有不少国外的开发者会默认这就是中国人所为，我也看到了一些开发者开始带节奏，开始找各种和 Jia Tan 有过互动的中国程序员。 我倾向于相信这不是中国攻击者，感觉其 commit 信息里面的英文中没找到中式表达。比较确定的是，从这些马甲之间的密切配合来看，这像是一个有密谋的组织团体。 <h2 id="开源软件的脆弱性"><a href="#开源软件的脆弱性" class="headerlink" title="开源软件的脆弱性"></a>开源软件的脆弱性</h2> 开源意味着透明，但并不意味着安全。 10 多年前我们经历了 OpenSSL 的心脏滴血，如今类似的事情再次发生。甚至这次事件的性质更严重，心脏滴血漏洞本身是因为代码的逻辑问题导致被恶意利用，而这次是攻击者通过供应链恶意植入后门。 有一种观点是开源软件被更多人 review，所以理论上来说安全漏洞更容易被发现。但实际上看来，被巧妙设计过的代码改动，很不容易被发现问题，比如这次事件中这个提交，我相信绝大部分开发者无法发现被恶意添加的 <code>.</code>: <img src="http://catcoding.me/images/ob_pasted-image-20240403114716.png" alt="" /> 这次后门被发现有很大的运气成分，多亏了 Andres Freund 的细心和刨根问底的精神，这也算是有足够多的眼睛盯着所以发现了问题吧。 <h2 id="如何预防"><a href="#如何预防" class="headerlink" title="如何预防"></a>如何预防</h2> 如果有一个开源贡献者的身份识别机制，就可能预防类似的事情。我看到有人举例 Linux Kernel 提交必须使用 Git 的 Sign-off，但这个 Sign-off 更多的是在解决法律上的问题，Sign-off 本来就是因为法律诉讼而引入的。而且，在最坏情况下，一个开发者可能被社工或者入侵而导致身份被冒用，所以 Sign-off 并不意味着身份识别。 有的人提到通过支付来进行 KYC(Know Your Customer)，这必然是不可能的，因为开源本来就是一个黑客文化的产物，大量的开发者会刻意选择使用匿名身份提交代码。 我们来看看 Bitcoin，如果论项目值钱程度，比特币的代码应该能排得上号。但比特币是支持 Permissionless and Pseudonymous development 的，甚至这是保证比特币去中心化的两个很重要的手段，中本聪的身份仍然是一个迷。中本聪选择匿名对比特币本身来说也至关重要，<code>No one controls Bitcoin</code> 是其价值根本。 那比特币如何保证不会被植入后门，比如这种供应链攻击？ <ul> <li>Reproducible builds，这是个极大地缓解供应链风险的办法，不同的人编译相同的源代码必然得到相同的二进制文件，binary file 不能存在于源码库中。Bitcoin 使用 Guix container 从源码编译所有的东西，<a target="_blank" rel="noopener" href="https://github.com/bitcoin/bitcoin/pull/15277">contrib: Enable building in Guix containers</a>，这个过程可以在任何 Linux 发行版上重现。在这个过程中，几乎所有的一切都从源码编译，所以会存在一个鸡生蛋蛋生鸡的问题，为了解决这个问题必然会需要一些 binary files，但最好是将这个范围限制到最小，<a target="_blank" rel="noopener" href="https://guix.gnu.org/manual/en/html_node/Preparing-to-Use-the-Bootstrap-Binaries.html">Preparing to Use the Bootstrap Binaries</a>。</li> <li>Don’t forget to verify yourself！</li> </ul> 另外比特币的安全在于 PoW，其设计本来就假设了少部分节点可能是恶意节点，除非黑客控制住了大部分节点才能造成破坏，而要达成这点在的概率可以认为就是零 <h2 id="开源的可持续性"><a href="#开源的可持续性" class="headerlink" title="开源的可持续性"></a>开源的可持续性</h2> 从这个安全事件我们可以继续探讨开源的可持续性这个问题。这个事件中 xz 的维护者 Lesse Collin 看起来已经是处于疲于应付的地步。从<a target="_blank" rel="noopener" href="https://github.com/xz-mirror/xz/graphs/contributors">贡献者统计</a>可以看到这么多年几乎就是他一个人在给项目提交代码，Jia Tan 通过两年的潜伏就成为了贡献者第二的开发者： <img src="http://catcoding.me/images/ob_pasted-image-20240403140505.png" alt="" /> 长时间维护一个被大量使用的开源项目是个巨大的负担，对维护者而言不仅仅是时间的投入，有时候也是精神上的折磨，即使开发者当初的有多好的愿景，但谁也无法保证常年的持续投入。关于这点可以阅读这篇文章，<a target="_blank" rel="noopener" href="https://kettanaito.com/blog/the-dark-side-of-open-source">The Dark Side of Open Source</a>。 Lesse Collin 在这次事件中被利用了这个弱点，他在这封邮件里解释到自己作为项目主导者的困境： <img src="http://catcoding.me/images/ob_pasted-image-20240403014036.png" alt="" /> 写到这里我想起自己也曾经催过一个库的作者，是不是考虑让更多人来维护项目 <a target="_blank" rel="noopener" href="https://github.com/GREsau/schemars/issues/272">Maintenance status · Issue</a> 😅。 也许未来可能有一套机制，能够让基础开源软件的维护者得到经济激励，但这条路如何演化出来我还没看出来，如果真的出来或许与加密货币有一定关联。 可怕的是，现在还有很多人没有意识到开源贡献者困境，那些价值几千上万亿的公司也是在期望开源的开发者能够像雇员似的响应他们的 High Priority： <img src="http://catcoding.me/images/ob_pasted-image-20240403013012.png" alt="" /> 这个世界上还是有无数的默默耕耘的开源代码维护者，比如 SQLite，全球大概有上万亿的 SQLite 数据实例跑在服务器上、手机上、浏览器里，但这个软件其实只由 3 个程序员维护了 20 多年；几乎所有工程师都使用的工具 curl，由 Daniel Stenberg 从 1998 维护到至今；vim 的作者 Bram Moolenaar 从 1991 年维护项目到自己去世，总共整整 32 年。 实际上没有人知道，多少被广泛使用的基础组件和代码是由各种默默无闻、分毫未取的开发者在用自己的业余时间维护着。 <img src="http://catcoding.me/images/ob_pasted-image-20240403135349.png" alt="" /> 从这个角度看，人类数字基础设施这艘巨轮其实建立在非常脆弱的基础上，说不定哪天一个地方就裂开了。我现在养成了一个习惯，升级从来不追新，任何安装到自己电脑上的二进制都小心翼翼。 这个世界上有无数的恶魔，也会有一些英雄和吹哨人，致敬 Andres Freund。

2024/4/4