2025-09-27 00:49:47
无论是在聊 L2、隐私还是下一代 Web 技术，零知识证明都是经常会碰到的技术术语，听起来就像是科幻小说里的东西：向你证明我知道一个秘密，但绝不透露这个秘密本身，这简直是程序员的终极浪漫。
大多数人粗看都会觉得这东西是密码学博士们的专属玩具，我花了一段时间学习后，发现这条通往魔法世界的路似乎有迹可循，希望这篇入门介绍能帮助到更多这方向的学习者。
忘掉所有数学，我们先从一个故事开始——“阿里巴巴洞穴”，这是理解 ZKP 最经典的例子，最早由 Jean-Jacques Quisquater 等人于 1990 年在他们的论文《如何向你的孩子解释零知识协议》中发表。
想象一个环形洞穴，A、B 两个入口在前方，深处有一扇只有知道咒语才能打开的魔法门。Alice 知道咒语，现在，Alice 想向 Bob 证明她知道咒语，但又不想让 Bob 听到咒语是什么。
他们可以这样玩一个游戏：
承诺 (Commitment)：Alice，作为证明者 (Prover)，独自进入洞穴。然后可以随机从 A 口进，也可以从 B 口进。Bob 在洞外等着，但不知道 Alice 走了哪条路。
挑战 (Challenge)：Bob 作为验证者 (Verifier)，走到洞口然后随机喊出一个要求，比如：“从 B 通道出来！”
响应 (Response)：Alice 听到要求后：
验证 (Verification)：Bob 看到 Alice 确实从 B 通道出来了，他对 Alice 的信任度增加了一点。
为什么说“一点”呢？因为如果 Alice 不知道咒语，她仍然有 50% 的概率蒙对（比如 Alice 从 B 进去，Bob 恰好也喊了 B）。
但如果这个游戏重复 20 次，Alice 每次都能从 Bob 指定的出口出来，那 Alice 每次都蒙对的概率就只有$$\left(\frac{1}{2}\right)^{20}$$，也就是大约是百万分之一。这时候 Bob 就有十足的把握相信，Alice 确实知道那个咒语。
这个小游戏完美地展示了 ZKP 的三大特性：
另外我们可以看到一个重要的属性是，零知识证明并非数学意义上的证明，因为可能存在一个很小很小的概率，即可靠性误差 – 作弊的证明者能够骗过验证者，但实际实践中我们几乎可以忽略这个极小的概率。
还有另外一个比较简单的例子来说明零知识证明：
Alice 和 Bob 玩游戏看谁先找到 Wally，Alice 说她找到了，她想要证明自己已经得到了结果，但又不想透露更多信息给 Bob，所以她可以用一个几倍面积黑色的纸片遮住整个图画，然后把 Wally 位置那里在黑色纸片上打个小孔，这样 Bob 就可以看到 Wally，而不知道 Wally 在哪儿。注意这里为什么强调几倍面积的黑色纸片，如果是和原图相同大小的纸片，就可能暴露了 Wally 的大致方向和范围。
这个例子展示的 ZKP 另外一个特性是 Prover 通常是更耗费资源的 (从图片中找到 Wally 需要花费一定的时间)，而 Verifier 通常能很快验证。这个特性才能让一些区块链项目利用 ZKP 把链上计算挪到链下计算，而链上只是做验证。
两个例子很棒，但代码怎么写？
我接触到的第一个协议叫 Schnorr 身份验证，它要证明的是：“我知道与公钥 h 对应的私钥 x，其中 h = g^x mod p”。这里的“咒语”就是 x，而那扇“魔法门”就是离散对数问题——从 g, h, p 反推出 x 极其困难。
这个协议的“交互式”版本，完美地复刻了洞穴里的“一来一回”：
k，计算 t = g^k mod p 发给 Verifier。这叫“承诺”。c，这叫“挑战”。c，计算 r = k - c*x mod (p-1) 并发回。这叫“响应”。g^r * h^c mod p 是不是等于 Prover 一开始给的 t。完整代码在iteractive_schnorr
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!("验证失败！"); } }}但一来一回也太麻烦了，互联网应用需要的是一次性的“证明”。经过一番研究，密码学家们想出的一个绝妙技巧，叫做 Fiat-Shamir 启发式证明。
它的核心思想是：用哈希函数来模拟一个不可预测的“挑战者”。
Prover 不再等待 Verifier 给出挑战 c，而是自己计算 c = hash(公开信息, 自己的承诺 t)。因为哈希函数的雪崩效应，Prover 无法预测 c 的值来作弊，这就巧妙地把交互过程压缩了。
我们可以用 Rust 写出这样一个完整的非交互式证明程序 fiat_shamir：
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) % ℴ // 3. 响应：计算 r = k - c*x (mod order) let cx = (&c * &secret_x) % ℴ let mut r = (&k - cx) % ℴ if r < BigInt::zero() { r += ℴ } 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) % ℴ if c == c_prime { println!("✅ 验证通过！"); } else { println!("❌ 验证失败！"); }}以上我们通过最简单的代码来演示了 ZKP 的基本思想，从数学原理上都是基于离散对数困难性。
当我看到 Hash 的时候，我联想到了后台服务的密码存储，比如我们在做一个用户注册和登录功能的时候，为了安全我们是不会去存储用户的原始密码（秘密），而是会使用密码哈希方案，去存储 hash(password + salt)。
但这个密码哈希方案其实也泄露了“知识”，当你登录时会把 123456 发送给服务器，服务器计算 hash("123456" + salt) 并与数据库中的值对比。
hash(password + salt) 的列表。这个哈希值本身就是一条重要的知识！它虽然不是密码原文，但它是密码的一个确定性指纹。攻击者可以进行：这就是为什么我们需要“加盐（salt）”和使用慢哈希函数（如 Argon2, bcrypt），目的就是为了增加攻击者进行上述离线攻击的成本，但无论如何，哈希值本身就是泄露的“知识”。
所以如果我们要更安全，一点“知识”都不泄露，似乎 ZKP 适合做认证服务？注册时不存密码哈希，只存公钥 h。登录时，我发送一个 ZKP 证明，服务器验证一下就行了，数据库被拖库了都没事。
甚至更简单点其实就用公私钥对不是更方便和安全么，Nostr 就是这么做的 (钱包也是这个原理)，private key 是密码，每次发内容就用私钥签名内容，然后把 pubkey 带上，这样任何收到这条消息的节点都可以验证签名是否一致，这样就本质上通过各个 relay 节点形成一个去中心化的社交网络。
我按照这个思路去找 Web 相关的解决方案，业界给出的答案是 Passkeys (基于 WebAuthn 标准)，使用非对称加密来替代密码（私钥不出设备），Passkeys 是这样工作的：
2019 年 3 月 4 日 WebAuthn Level 1 已经被 W3C 正式发布为“推荐标准 (Recommendation)”，标志着它成为了一个成熟、稳定、官方推荐的 Web 标准。
从上面的例子我们看到，ZKP 很适合用来证明 Prover 知道某个秘密，比如一个数 x ，但 ZKP 的用途远不止于此，还可以证明任何计算过程的正确性。
为什么证明一个程序正确运行很重要，因为像以太坊这样的公链，如果所有的节点都运行同样的合约 (本质上就是一段程序代码) 多次，这无疑是很大的浪费，我们想通过 ZKP 把计算挪到链下，这样公链上的节点只需要验证程序被正确执行就可。
“我正确运行了一个复杂的程序，得到了这个输出。”—— 这要怎么证明？
答案是四个字：万物皆可电路 (Arithmetization)。
ZKP 系统（比如我们后面会聊的 zk-SNARKs）的“世界观”非常单纯，甚至有点笨拙，它看不懂我们人类写的高级代码，比如 if/else 语句、for 循环。
如果我们想让 ZKP 为我们工作，就必须先把我们要证明的东西，翻译成它唯一能听懂的语言。这个翻译过程，就是“算术化 (Arithmetization)”。而“电路”或“约束系统”，就是我们翻译出来的最终稿。这个重写的过程，就是“拍扁 (Flattening)”。你把一个有层次、有复杂逻辑的程序，变成了一个长长的、线性的、只包含最基本算术运算的指令列表。
任何程序，无论多复杂，都可以被“拍扁”成一系列最基础的加法和乘法约束。比如 out = x*x*x + x + 5 这段代码，可以被分解为：
v1 = x * xv2 = v1 * xv3 = v2 + xout = v3 + 5于是，证明“我正确运行了程序”，就转化为了证明“我知道一组数 (x, v1, v2, v3, out) 能同时满足上面这一堆等式”。这个过程，就是把代码逻辑“算术化”，变成了 ZKP 系统可以处理的语言。
那我们来看 Verifier 如何验证上面的计算过程，最原始的当然是根据输入，来一条一条的执行上面被拍平后的指令集，但这样的工作量和自己去执行整个程序就差不多了。
为了避免这种蛮力验证，密码学家们引入了一个极其强大的数学工具：多项式 (Polynomials)。
整个魔法流程如下：
Prover 的艰巨任务：将所有约束“编织”进一个多项式 Prover 会执行一个惊人的转换：他会找到一种方法 (Groth16、PLONK、STARKs 等)，将我们前面提到的那一整个约束系统 (x * x - v1 = 0, v1 * x - v2 = 0, …) 全部编码成一个单一的、巨大的多项式方程。
我们可以把这个巨大的“主多项式”记为 P(z)。这个 P(z) 有一个神奇的特性：
当且仅当 Prover 提供的所有见证值 (x, v1, v2…) 都完全正确、满足所有原始约束时，这个主多项式
P(z)在某些特定的点上才会等于 0。
如果 Prover 在任何地方作弊，哪怕只修改了一个微不足道的值，最终生成的那个 P(z) 就会是一个完全不同的多项式。
验证者的捷径 – 随机点检查 (Random Spot-Check) ：现在验证者的问题从“检查成千上万个小等式”变成了“如何验证 Prover 的那个巨大多项式 P(z) 是正确的？”
难道要把整个巨大的多项式传输过来再计算一遍吗？当然不是！这里用到了密码学中一个非常深刻的原理，通常与 Schwartz-Zippel 引理 有关。
它的直观思想是：
如果我有两个不同的、阶数很高的多项式
P(z)和F(z)（F 代表伪造的），然后我从一个极大的数域里随机挑选一个点s，那么P(s)和F(s)的计算结果相等的概率几乎为零。
这就给了验证者一个巨大的捷径：
s 上，对 Prover 的多项式进行一次“抽查”。s 这个点上，你的多项式计算出来的值是多少？”所以这里的 ZKP 证明里到底包含什么？
在一个典型的 zk-SNARK（比如 Groth16）中，那个小小的证明通常是由几个椭圆曲线上的点 (points on an elliptic curve) 组成的。可以把这些“点”想象成一种具备神奇数学特性的高级指纹。这些点就是 Prover 对他构造的那些巨大多项式（比如 A(x), B(x), C(x)，它们共同构成了我们之前说的那个主多项式 P(x)) 的“承诺”。
这里的魔法在于 Verifier 不需要通过这些“点”来反推出原始的多项式。相反，他可以直接在这些“点”上进行一种特殊运算，这种运算的结果等价于在原始多项式上进行“随机点检查”。这个特殊的运算，就是 zk-SNARKs 的核心引擎之一：配对 (Pairings)。并非所有 ZK 架构都用配对；Groth16/部分 KZG-based 系统用配对，STARKs 则用哈希/FRI 等替代方案。
让我们把整个流程串起来 (zk-SNARK)，看看 Prover 的多项式是如何被“隔空”验证的：
准备阶段 (Setup)：
Prover 的工作：
A(x), B(x), C(x)。（这些多项式满足 A(x) * B(x) - C(x) = H(x) * Z(x) 的关系，这是 R1CS 算术化的结果）。s 上的椭圆曲线点表示。这些点就是对多项式的“承诺”。Verifier 的工作：
A(x), B(x), C(x))。Verifier 拿出“验证密钥”，并将 Prover 提交的这几个“承诺点”代入一个预设的配对验证方程 (Pairing Verification Equation)。
这个方程被设计得极其巧妙，它的等号左边和右边分别对应着 Prover 原始多项式关系 A*B-C=H*Z 的加密形式。
当且仅当 Prover 原始的、未知的那些多项式确实满足正确的数学关系时，这个配对验证方程的等号才能成立。
所以：
Prover 把“我知道所有题的答案”这个事实，通过复杂的计算，浓缩成了一个包含几个关键“密码学指纹”的信封（证明）。Verifier 不用拆开信封看所有答案，他只需要用一种特殊的“X 光机”（配对验证）照一下这个信封，就能瞬间知道里面的答案是不是都对。
区块链因为其去中心化和对隐私性的严苛要求，ZKP 非常适合用在这个领域。
以太坊慢又贵，因为每个节点都要重复执行每笔交易。ZK-Rollup 的思路就像是找了个超级课代表：
L1 的所有节点不再需要重复计算那几千笔交易，它们只需要做一件极其廉价的事：验证那个 ZK 证明。就像老师检查作业，不再需要自己从头算一遍，只需要看一眼课代表盖的“全对”印章。
总而言之，Rollup 的核心创新在于将计算执行与数据结算分离。它利用 ZKP 等密码学技术，将繁重的“执行”环节放在链下，然后只把一个轻量的“证明”和必要数据放在链上进行“结算”，从而实现了对以太坊主网的大规模扩容。
Tornado Cash 是个混币器，你存入 100 ETH，然后从一个全新的地址取出来，没人能把这两者联系起来。它的机制是：
存款：你在本地生成一个秘密凭证（包含Secret和Nullifier），然后计算出它的哈希值——“承诺 (Commitment)”，把承诺和钱一起存入合约。
取款：你用一个全新的地址，提交一个 ZK 证明，这个证明：“我知道某个树叶的 Secret 且未被花费”，同时提交 nullifier（通常是对秘密做散列得到的唯一标识）以标记已花费。这样合约无需关联存款者身份即可阻止双花。
整个过程，合约就像个盲人会计，它不知道是“谁”存的，也不知道取款对应的是“哪一一笔”存款，它只负责验证 ZKP 规则是否被遵守。
ZKP 应用在大模型也是最前沿、激动人心的领域。例如 AI 模型（尤其是大型语言模型）的权重是极其宝贵的商业机密。用户的数据又极其隐私。如何让一个 AI 模型在不暴露其内部权重的情况下，处理用户的隐私数据，并向用户证明它确实是用了那个宣称的高级模型，而不是一个廉价的“冒牌货”？
ZKP 解决方案 (ZKML - Zero-Knowledge Machine Learning)：
模型推理证明：模型提供方可以对一次推理过程生成 ZK 证明，证实“我使用我宣称的那个模型（其哈希值是公开的），处理了你的输入数据，得出了这个输出结果”。这向用户保证了模型的真实性，同时保护了模型的知识产权。
数据隐私证明：用户可以对自己的数据生成 ZK 证明，证实“我的数据（例如医疗记录）符合某个特定标准（例如，有某种疾病特征）”，然后将这个证明提交给 AI 模型进行统计或研究，而无需上传原始的隐私数据。
这里有更多相关的资料：An introduction to zero-knowledge machine learning (ZKML)
前面我们谈到，在 ZKP 中Prover（证明者）端计算量最大，主要集中在以下几个方面：
而在Verifier（验证者）端计算量相对较小，这也是零知识证明的重要优势之一，但它仍然需要进行一些关键的计算，比如：
总的来说，零知识证明的计算量主要耗费在Prover端，因为它需要对整个计算过程进行完整的加密转换和证明生成，而这些步骤依赖于高复杂度的多项式和椭圆曲线运算。所以我们看到一些专门为此服务的硬件 FPGA、ASIC、GPU。
而 RISC-V 因为其可扩展性和模块化设计、开源的标准等优势，是实现零知识证明硬件加速的重要“基石”之一，risc0 是个值得关注的项目
Computer Scientist Explains One Concept in 5 Levels of Difficulty 向不同知识背景的人介绍零知识证明。
要深入理解 ZKP 需要更多数学知识，STARKs, Part I: Proofs with Polynomials 以太坊创始人的博客，他用相对简单的语言解释极其复杂的密码学概念，是 ZKP 入门最经典的读物。
The zk-book 一个非常棒的在线开源书籍，逐步讲解构建一个零知识证明系统所需的数学知识，从有限域、椭圆曲线到多项式承诺，内容非常扎实。
2025-09-23 08:54:14
I’ve always wanted to learn RISC-V. A few days ago, I finally got my hands dirty with it.
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.
Before writing any code, I need to grasp the fundamentals of RISC-V.
x0-x31).We can get all the details of RISC-V instructions from RISC-V Technical Specifications.
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.
Here’s a simplified Rust code snippet to illustrate the VM structure and the run loop:
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; } }}The fetch instruction turns out to be very simple, we just load 4 bytes in little-endian format into a u32 integer:
/// Fetch 32-bit instruction from memory at current PCfn 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)}Then we need to decode the integer into a RISC-V instruction. Here’s how we decode IType and RType instructions. The specifications for these two types are:
/// Decode 32-bit instruction into structured formatfn 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 }}Then we want to execute the instruction, just following the specification. For demonstration purposes, we return the execution debug string as a result:
/// Execute decoded instructionfn 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 )), } } }}The simplest VM code is available at: riscv-vm-v0
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.
riscv32imac-unknown-none-elf target toolchain. This is a bare-metal target, meaning it doesn’t rely on any operating system.rustup target add riscv32imac-unknown-none-elfNext, you’ll need a RISC-V linker. You can get this from the official RISC-V GNU toolchain.
# On Linux or macOSsudo apt-get install gcc-riscv64-unknown-elf# Alternatively, on macOSbrew install riscv-gnu-toolchainNote: The gcc-riscv64-unknown-elf package includes both 32-bit and 64-bit tools.
#[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 {}}cargo with the specific target and a linker script to build the executable. We need to add options for Cargo in .cargo/config.toml
[target.riscv32imac-unknown-none-elf]rustflags = ["-C", "link-arg=-Tlink.ld"]The content for link.ld is as follows. It tells the linker the layout of the binary file generated. Notice that we specify the entry point at address 0x80:
OUTPUT_ARCH(riscv)ENTRY(_start)SECTIONS { . = 0x80; .text : { *(.text.boot) *(.text) } .rodata : { *(.rodata) } .data : { *(.data) } .bss : { *(.bss) }}Then we can build the program to a binary:
cargo build --release --target riscv32imac-unknown-none-elfriscv64-unknown-elf-objdump to double-check the generated binary file:riscv64-unknown-elf-objdump -d ./demo/target/riscv32imac-unknown-none-elf/release/demo./demo/target/riscv32imac-unknown-none-elf/release/demo: file format elf32-littleriscvDisassembly 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 retThe complete cross-compile Rust code is available at: riscv-demo
The first problem is how do we parse the executable file? It turns out there is a crate called elf that can help us parse the header of an ELF file. We extract the interested parts from the header and record the base_mem so that we can convert virtual address to physical address. Of course, we also load the code into memory:
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}What’s left is that we need to extend our VM to support all the instruction formats used in this binary file, including li, bne, beq, 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 new_pc from the execution of the instruction.
So now we need to update the core logic of fetch and execution of instructions:
// Check the lowest 2 bits to determine instruction lengthif 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);}The complete new VM which can run compiled RISC-V binary files is available at: riscv-vm
2025-06-11 18:23:14
5 月中旬我参加了在荷兰 Utrecht 举行的 Rust Week，想来可以写篇文章记录下所见所闻。
我年初和 Rust 基金会邮件确认参加，但直到 4 月 9 日才开始动手申请签证。在深圳办理荷兰签证流程简单，只需提交材料并录指纹，但我嫌麻烦找了中介帮忙。据说大概也就两周多就会有结果，但直到五一查询还是没结果，中介说可以加 600 元加急。看到官网解释近期审批延迟，我便花钱加急，第二周拿到了签证。不知道这其中是否有猫腻，但确实有华为的朋友同样卡在那个节点审批，结果没有如期下来。
从广州白云机场有直飞阿姆斯特丹的航班，只是起飞时间大概是凌晨 1 点多。飞机上座位空间狭小，难以入睡，趴着或躺着都不舒服，到了阿姆斯特丹是早晨 6 点多。通过海关后，我因不熟悉荷兰语而有些迷茫。由于未携带 Visa 卡，只能使用现金，幸好两位路人热心相助。我直接购买火车票前往 Utrecht，约于上午 10 点抵达酒店。因为时间还比较早没有空房，我把行李箱放在酒店自己去城里逛逛。
Utrecht 据说是荷兰第四大城市，交通方便。我查了一下，人口约为 30 万，这在中国估计只算是小镇了。我信步漫游，城市整洁如画，绿树成荫，空气清新怡人。由于是周六，商户大多已关门，街上行人多在跑步或散步，整体人口密度较低。5 月应该是荷兰最好的天气，不冷不热，只要不在太阳下就会感觉凉凉的。荷兰人身高马大，路上的自行车很多而汽车非常少，大多都是 A 级车，豪车基本没看到。很常见的场景是父母骑自行车，拉着个大篮筐里载着一两个小孩。
街头的人们神情轻松自在，仿佛时间在这里慢了下来。路旁一个年轻人倚着树，手捧书本读得入了神，旁边的金毛小狗却不耐烦地扯着牵绳，发出几声撒娇。草坪边，几个人懒洋洋地躺在长椅上晒着太阳，像是被微风哄睡了，手中未喝完的咖啡杯歪在一旁。运河边，一对白发苍苍的夫妇沐浴在阳光中，丈夫似乎想起什么趣事，侧身在妻子耳边低语几句，惹得她轻笑出声，随即两人轻轻接吻。这些场景对我这个匆匆旅客而言，宛如《楚门的世界》的开场，美好却略显不真实。
更实际的问题是吃饭，到了中午饭点，主城区我都快粗略走完了，但只有一两个餐厅开着。无奈，我去超市买了点面包和牛奶当作午饭，顺便看了一下日用品的物价，水果和蔬菜比较贵，牛奶之类的东西便宜点。回到酒店有了空房，前台给我办理了入住，稍微睡了一个来小时，起来后已经是下午三点多了，这时候我才后悔今天应该多在阿姆斯特丹逛逛，可玩的地方应该更多。我只能又往还没逛的城市另一边漫步，城市面貌都挺漂亮，不过总体而言房子大多是联排，空间不是很大，不像多年前第一次逛圣何塞那样户户大别墅带给我震撼。
晚上看到 zulip 里有消息，和我一样提前到达的人开始组局吃饭了。我们一行四人挑了个餐厅聊了两个小时左右，一个美国教授、一个德国年轻学生、还有一个马来西亚人，聊的都是技术趣闻和 Rust 相关的。但我这时候有点困了，所以主要在吃和听。没想到饭局结束后都晚上九点半了，天还微微暗，这时候 Utrecht 城市运河旁边的餐厅开着，游客熙熙攘攘，这大概是最热闹的时候了。
5.12 是周一，这天没有什么特别的活动，明天才是主会议的第一天，所以很多人还在路上。我上午去了会场注册领了参会牌，然后在会场逛了逛。我陆陆续续认出来了一些用真实照片做 Github 头像的人，期间和一个老哥聊了起来，他常年维护着 rustc-dev 这份开发文档，之前我提 PR 的时候帮我 Review 过。到了饭点就一起边聊边往市区走，我们想爬到教堂的楼顶参观，据说这里是城市的最高点，风景应该不错。去了之后发现一定要预约和请讲解员，而且一个下午才几十号人，便放弃了。走了 20 多分钟，都没找到什么看起来好吃的餐厅，碰到一个超市又买了点面包和牛奶，在附近的公园旁当作午餐。这老哥来自南非，比我大几岁，之前维护过 Debian 上的一些包。他给 Rust 做开源贡献快十年了，大多是一些文档类的工作。他现在全职远程在一个 Rust 相关的咨询公司工作，主要日常还是做些开源维护工作。
下午没什么特别的安排，我参加了一个 workshop。我们要做的是一个腐蚀的 Rust 实体 Logo，可以在背后用马克笔写上自己的名字，用磨砂纸摩擦一遍，然后用酒精还有各种化学染料涂在 Logo 的表面，等待一段时间就会形成腐蚀的效果和图案，我也跟着做了一个，是不是看起来很漂亮？但我第二天忘记去取了 :)
因为时差原因，我下午就开始犯困，在酒店睡了一下午后，看到群里又有人开始组饭局，这次是都是同住个酒店的人，我们在酒店大堂集合，总共大概有 10 个人左右。我看到了更多的熟悉面孔和 id，有几个维护 Rust 多年的成员，碰到了我第一次提 PR 帮我 review 的 estebank。
我们找了个店喝了点啤酒，然后服务员过来说后厨到点下班了，所以不提供晚餐。这对于中国人来说真是难以置信，哪有这么做生意的呢，这里果然是到点下班比挣钱更重要。后来我们坐火车去了主城区，接连询问了两家餐厅，均表示已快到打烊时间 (其实也就快晚上 9 点)，最后终于找了一个运河边上的餐厅坐下。我点了个海鲜意面，味道非常不错，20 欧元也值了，但没想到这就是我这一周吃得最满意的一顿饭了。
一群程序员吃饭聊的还是技术话题，作为 Rust 程序员和维护者，吐槽 C++ 是不可避免的，有的聊得比较细节，比如如何提高链接速度之类的。总体来说气氛非常好，大概是很多人都远程工作，平时无法找到这么一群志同道合的人聊天，而且这些人平时在开源社区里合作交流，能见面聊聊自然是非常开心的。
有趣的事发生在我们用完餐之后，老板估计是犯懒，结账说不能分开支付，所以我们需要找个人先替大家把单买了，然后大家再转给他。一群程序员大眼对小眼，那气氛有点尴尬。后来是 eholk 站出来先买了单，然后一群人围着他看账单转钱给他，反正是异常耗时和麻烦，看来还是中国手机支付 AA 来得更方便。
5.13 是 Conference 的第一天，主题很多，而且分了三个分会场：主会场、生态、行业应用。这两天参会的人非常多，我估计得有 500 来人。公司展台比较少，右边有 Jetbrains、Zed、左边有一些硬件相关的和 Rust 培训咨询相关的公司，华为有个招聘展台。现场看到了其他几个中国人，聊了一下他们是在 Cargo 项目团队做开源贡献的。在会场我见到了更多熟悉的面孔，因为挂牌上有 Github 账号，所以基本盯着对方的名片看看就知道是否打过交道，可以说这是一个大型的网友见面会。我在社区里面断断续续也做了四年，有的人只是通过 review comments 交流，有的人通过 zulip 私聊过，能见面聊聊真是一种难得的体验。另外我和华为爱尔兰可信计算实验室的余教授聊了比较久。
这次会场居然选在了一个电影院，一楼是一个大的会展活动空间，整体非常宽敞。这是我第一次坐在电影院听技术演讲，座位宽敞、音效和视觉都棒极了，他们甚至做了一个类似电影的片头动画，看起来诙谐可爱。第一天最热的主题应该是 Alex Crichton 的 10 Years of Rust，我第一场也去听了这个演讲。推荐任何对 Rust 感兴趣的去看看这个视频。
Rust 在嵌入式领域取得了长足的进展，所以也是这次会议的热点，It’s Embedded Rust Time这个演讲谈到长远来看这个领域里的人希望 Rust 能得到更多应用，volvo 的人分享了他们使用 Rust 开发和发布第一个 ECU 的过程。来自南京大学的 Xiaolong 分享了一个异步任务编程框架 Dagrs。Refactoring in Rust 分享了些重构技巧，把一个典型场景的代码变得漂亮易维护。 We deserve helpful tools 介绍了编译器里的错误信息如何更友好，很多初学者喜欢 Rust 的一个原因是 rustc 的错误信息看起来人性化又有帮助，这是社区里很多人努力的结果。
午饭期间，有个比利时的工程师来拼桌，所以就聊了起来，他几年前去广州待过一个多月，所以有些共同话题。他业余时间喜欢折腾硬件和数学，组织了一个学习系统编程的小组。这个人非常健谈有趣，我们一起聊了聊各自的工作经历等，在 Linkedin 上加了个好友。
第一天会议结束后，我跟着 estebank 一行八个人出去就餐。这次我们选的是一家印度餐厅，因为已经有两三天没吃米饭了，我点了一个看起来有点辣的鱼加米饭，结果菜上来之后让我震惊，不管味道还是品相都达不到沙县小吃级别，但这饭饭菜居然也要 20 欧，这是我这周吃过的最差的一顿饭了吧。这周后面几天的晚上我都不想吃晚饭，一方面是白天在会场吃了很多零食，另一方面到了晚上七点左右我就非常困，这边晚上天黑的时间短，所以我通常回到酒店就睡觉。
5.14 第二天我首先去听了 Rust for Linux 这个演讲，这场非常火爆，看来大家都非常关注这个领域，无论是在贡献者数量还是提交到主线内核中的代码行数方面，增长都非常快。然后我去听了大部分 Rust Project track 相关的演讲，compiler-errors 没写 PPT，居然直接在 VsCode 里面讲解代码 。The Rust Vision Doc and You讲解了如何获取用户的意见和反馈，Rust 在全世界的整体采用情况，很高兴看到社区像是对待一个产品一样来发展一门编程语言。
所有两个天的 Conference 会议在油管上直播，也有录像，感兴趣的可以自己找来看看。
5.15 第三天的上午有各种 workshop，会场地址也变了另一个郊区的办公场所，这个会场在运河的旁边，河上经常有各种运货大船漂过，感觉像苏州的运河的场景。华为余教授帮我弄了个参加 workshop 的机会，我去体验了一下玩了会儿跨平台的 Rust GUI 框架 Makepad。然后我去了对面的 Rust all hands 的办公场所，这里都是 Rust 项目维护者和贡献者，大家以分组的方式进行讨论，有的人干脆找个角落写代码。这次组织者非常用心，说不提供单一的 t-shirt，但找了一个打印 Logo 的机器，大家可以自己选择在衣服、背包、帽子上打印 Rust 相关的图案，我把自己的上衣上印了一个黄色的螃蟹。有的人把自己平时收集的一些笔记本贴纸分享出来，我第一次看到这么多 Geek 贴纸，选了好多。
会场提供了很多酒水和小吃，我不停地喝橙汁。期间碰到了在华为俄罗斯工作的 petrochenkov，他穿着一件 Rust 1.0 发布的纪念 t-shirt，年龄和我相仿却已在开源社区工作十多年。他之前帮我 Review 过不少 PR，以前在中国华为办公室工作过，这次终于见面聊了聊。我们俩一起打乒乓球，虽然两个人水平都不太行，但玩得很来劲。
这天下午用来庆祝 Rust 1.0 发布 10 周年，有一个小型 Party，并且用实时发布 1.87 版本的方式进行庆祝。Niko 上台演讲了 Rust turns 10，余教授代表华为作为赞助商演讲了，华为应该是中国企业中对 Rust 投入最多的，不管是国内的华为还是海外分部都有投入，而且也在通过其他组织赞助社区的一些资深维护者。这会儿我才知道发行一个 Rust 新版本的脚本要运行一个多小时多，最后发布倒计时那会儿气氛达到高潮，拍下了这张照片，我大概在右边第三排的位置，但是身高不够被淹没了：
5.16 和 5.17 是两天的 Rust all hands meeting，可以自由选择参加分组讨论也可以自己找个地方工作一会儿。我选择性参与听了一些，比如 Rust society、Let’s talk about Burnout、Infra、Rust Foundation 的 office hours 等，感觉这两天讨论比较多的几个主题是和 C++ 的互操作性。期间也有很多时间留给大家自由讨论，有人安利 jj这个工具，我试用了一下还没理解好在哪里。我比较多时间和 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 的作者，可以说是一个世界级的基础软件工程师，感兴趣的可以读读这篇 Twenty years of Valgrind。我的第一份工作写 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 社区的工作机会，说不定以后会用到。通过和不同的人聊天，我发现主要有以下一些机构：
如果是全职 Rust 开发的工作，欧洲应该是相对好找一些 (但需要签证)，国内据我所知除了华为、还有字节、小米、汽车公司会用到 Rust。现在 AI 很火，AI 的 infra 也会用到些 Rust，我了解到社区里一个非常资深的维护者去了 OpenAI，这次也碰到一个 OpenAI 的人说公司内部有些 Rust 项目。但整体来说，整个世界的大环境不好，工作机会相比往年少很多。
十年无疑个具有纪念意义的里程碑，就像 Niko 在Rust turns 10所说的：
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
Rust 目前的成功无法简单归功于个人和机构，无疑我们需要感谢项目发起人 Graydon Hoare 设置了宏大正确的愿景，而后 Rust 在开源社区自由生长，甚至完全不像是他所设想的编程语言了。现在几个 IT 巨头都有投入，但实际上也没有一个组织和个人能决定未来的发展，这既是社区的刻意设计，也是自然进化的结果。从我这种业余贡献者的角度来说，基金会虽然因为各种事饱受争议，但他们确实做了很好的幕后工作，比如这次参会的社区成员基本都能报销费用，甚至我的费用超过了计划申明的额度，基金会也直接说别担心，我们会如实报销所有费用。
总的来说，这次参会经历拓宽了我的视野。大家都因为对 Rust 和编程的激情和追求聚到了一起，交流起来非常有趣。十年前，我在 2015 年偶然发现了 Rust，当时并不知道它会塑造我的职业生涯，在我迷茫的时候重新捡起了 Rust，如今成为全职的 Rust 开发和社区贡献者。最近一年育儿和工作占据了我的大部分时间和精力，所以在 Rust 社区没那么活跃，我渴望通过编程和写作继续投入其中。
顺便一提，Rust Week 这一周我都没吃中餐，回家一称瘦了三四斤，算是意外达成健身目标！我应该是无法在欧洲长待的那类人。
2025-06-09 02:20:12
区块链这行经常会和椭圆曲线密码算法打交道，我也在尝试理解这其中的数学原理，这里记录一下。
先想象一个普通的曲线，比如抛物线（抛个球的轨迹）。椭圆曲线不是椭圆（名字有点误导），而是一种长得像“对称小山丘”或者“歪歪扭扭的环”的数学图形。
椭圆曲线通常表示为：
$$ y^2 = x^3 + ax + b$$
通过这个方程我们可以看到椭圆曲线是上下对称的，其中 (a) 和 (b) 是曲线参数，比如下面这些曲线就是 b = 1 的情况下，a 从 2 变到 -3 的情况：
我们通常使用的椭圆曲线必须满足非奇异 的特征，这些参数必须满足判别式：
$$4a^3 + 27b^2 \neq 0$$
“非奇异”什么意思？在数学上，椭圆曲线要是“非奇异”（non-singular），就是说这条曲线长得“光滑正常”，没有奇怪的尖角、交叉点或者自己打结的地方。简单讲，就是曲线不能太“怪”，得是个平滑的、像个正常曲线的样子。
如果曲线“奇异”了，会出现两种毛病：
这些毛病会让“点加法”出问题，因为公式会算不下去，或者结果不唯一。关于点加法我们后面再谈，下面这两个椭圆曲线都是奇异的：
这名字来自数学家 Niels Henrik Abel，他研究了这种“顺序无所谓”的结构。
“群”（group）是数学里的一种概念，就像一个有规则的“俱乐部”。里面有一堆东西（叫元素），加上一个玩法（叫运算），得满足几个条件。阿贝尔群是群的一种特别类型，特点是这个玩法“顺序无所谓”。
简单说，阿贝尔群就是一个集合，里面有些元素，能用某种运算（比如加法）组合起来，满足以下条件，而且运算顺序随便换都没问题。
群的四个基本条件：
群变成“阿贝尔群”，还得多一条：
密码学里用阿贝尔群（像椭圆曲线），因为它简单又有规律，适合搞安全。
到了 1900 年代，椭圆曲线跟数论彻底绑定，而数论研究的是整数。
椭圆曲线方程
$$y^2 = x^3 + ax + b$$
通常是在普通实数（无限多的小数）上定义的，画出来是个连续的曲线。但安全领域说的椭圆曲线通常是说通过椭圆曲线定义出来的群，其范围定义在某个有限域 : $F_p$ 。
简单说，整数也是一个无限数字的世界，而有限域就是一个只有有限个数字的“数字世界”。这里的表示这个世界里只有 0, 1, 2, ..., p-1 这 (p) 个数，(p) 必须是个素数。为什么是素数？因为这样能保证这个小世界里的数学运算（加减乘除）不会出乱子，规则特别“干净”。
在这个有限域里，所有的计算结果都得落在这 (p) 个数里面。如果算出来超了 (p)，就“绕回去”，用模 (p) 的方式把结果限制住。比如在 $F_5$ 里：3+4=7，但 7 不在范围内，所以 $7mod 5=2$，所以结果是 2。
这个时候，曲线不再是连续的，而是变成了散落在 $F_p \times F_p$ 网格上的一堆离散的点。比如我这个程序打印出来这条曲线上的点，这里打印的时候 $y =0$ 是在中间，从中间看上下是对称的：
上面我们只是通过椭圆曲线找到了一组数字，但这些数字之间还需要一种操作，这种操作才能让这些离散的数字组成一个群的概念。这里就需要引入一个“点加法”的概念。
点加法就像一个魔法公式，告诉你怎么从一个点“跳”到另一个点，或者同一个点“跳”两次变成新点。想象椭圆曲线是一条弯弯曲曲的线，上面有很多点，在不断做点加法的过程中不断地移动点。
在椭圆曲线上，点加法有几何和代数两种解释：
几何解释：通过两个点画一条直线，与曲线的第三个交点取关于 x 轴的对称点。
代数公式：
离散对数问题是在一个有限的“数字圈”里玩，比如有限域 $F_p$ （( p ) 是素数）或者椭圆曲线的点群里。比如：
这里的 ( x ) 或 ( k ) 就是“离散对数”。这就是离散对数问题，数学家没找到一个快速方式能解决这个问题。
直观感受一下，我们修改上面那个程序，我定义一个起始点 P，然后不断通过 P + P 的方式进行 20 次，终点是黄色的，然后把中间通过的点用蓝色的线连接起来，可以看到我们经过的点是没有什么规律的。
反向破解就比如你拿到这幅图，如果不告诉你蓝色的连线，而只有那个黄色的终点，现在问你起点在哪里？这个问题是很难回答的。
19 世纪数学家就研究过椭圆曲线的性质，但到 20 世纪数学家发现椭圆曲线上的点能通过点加法这类操作组成一个阿贝尔群，这些点的数量和分布特别“诡异”——既有限，又乱得没规律。而点加法这种正向容易、逆向难的特征刚好就适用于密码学。
Neal Koblitz 是专攻数论的数学家，对椭圆曲线很熟。他当时在研究有限域上的数学问题，注意到椭圆曲线的点群和传统离散对数有点像，但更“紧凑”。他想：如果把 Diffie-Hellman 的思路搬到椭圆曲线上，会不会更高效。
Victor Miller 在 IBM 搞应用数学，也盯着椭圆曲线的群性质。他发现，椭圆曲线的离散对数问题（ECDLP）似乎比普通离散对数还难破解，而且需要的数字（密钥长度）小得多。他俩不谋而合，都觉得这玩意儿能干大事。
他们的想法不是凭空来的，有几个关键“火花”：
为什么不随便挑个别的曲线？因为椭圆曲线（三次方程）正好有“三个交点”的几何性质，点加法规则简单又优雅，其他高次曲线要么太复杂，要么安全性不够。加上数学家几百年的研究，椭圆曲线的性质已经摸得透透的，拿来用最保险。
椭圆曲线加密从 1985 年的“怪胎”到今天的核心技术，走过了从冷门到爆款的路。它的历史是个典型的“学术变实用”的故事：数学家玩了好多年的椭圆曲线，被 Koblitz 和 Miller 一挖掘成了安全的利器。
secp256k1 是一个特殊的椭圆曲线，名字听起来高大上，其实就是密码学里用的一条数学曲线，secp256k1 的名字可以分成几个部分：
它是比特币、以太坊这些区块链的“安全锁”的核心。简单说，它定义了一个“跳跃游戏”的规则，靠这个规则保护你的私钥和公钥。
secp256k1 是这么来的：
secp256k1 就像一个超级复杂的“跳格子游戏”：
类比一下，想象 secp256k1 是个巨大的迷宫，里面有 (p) 个格子（大概 $2^{256}$个，这个数字大到超乎想象，比宇宙里的原子、沙粒、甚至时间秒数都多得多。它不是“很大”，而是“大的离谱”）。迷宫的形状由上面的椭圆曲线决定，起点是 (P)。你拿着私钥 (k)，按迷宫的跳法（点加法）走 (k) 步，停在 (Q)。这个迷宫设计得太巧妙，别人站在 (Q) 看你走过的路，根本摸不着头脑，只能从 (P) 一步步试，试到宇宙爆炸也试不完，破解难度像“从银河系找一粒沙”。签名时，拿私钥和消息算出两个数（r, s），别人用公钥验证。
secp256k1 另外一个特点是计算快，主要来自它的特殊数学结构和参数选择。bitcoin-core/secp256k1 是高度优化过的 C 语言实现，用了预存表、内敛汇编等各种优化手段来提高效率。通常我们在 Rust 程序上用的也是这个库的 binding。
本来想查找更多资料来写得更详细，但我发现如此太耗费时间，倒不如先把已经理解的部分写在这里，以后如果有新的理解再丰富。在尝试理解的过程中仍然会有这种感受：
更多的参考资料在这里：
2025-03-24 18:21:03
在 Rust 异步编程中，有一种观点认为：Future 的大小显著影响性能。你是否怀疑过这个说法的真实性？如果是真的，这种性能差异的根源又是什么？今天，我翻阅了一些源码，并编写实验代码来一探究竟。
为了验证“Future 大小影响性能”这一说法是否成立，我们先从一些简单代码入手。首要任务是弄清楚一个 Future 的大小是如何确定的。毕竟，在编译器眼里，Future 只是一个 trait：
pub trait Future { type Output; fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>;}那么，其大小取决于实现这个 trait 的具体结构体吗？我翻阅了 smol 的源码，发现在 spawn 一个 Future 时，相关代码是这样处理的：
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)}这里可以看到 mem::size_of::<Fut>() 是在计算这个 Future 的大小，我来写个简单的 Future 验证：
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);}在上面那个 async-task 的 spawn_unchecked 函数加上日志，打印出来的大小为 10256，刚好比这个 struct 的大小大 16，顺着代码往上可以看到这里在原始的 Future 上做了一个封装，这里的意思是如果这个 Future 以后执行完，需要从 runtime 里面删掉：
let future = AsyncCallOnDrop::new(future, move || drop(state.active().try_remove(index)));这解释了尺寸略有增加的原因。对于结构体的尺寸，我们不难理解，但对于 async 函数，其大小又是如何计算的呢？这就涉及 Rust 编译器对 async 的转换机制。
当你写下一个简单的 async fn 函数时，Rust 编译器在幕后悄然完成了一场复杂的转换：
async fn function() -> usize { let data = [0u8; 102400]; future::yield_now().await; data[0] as usize}这段代码会被编译器转化为一个庞大的状态机，负责追踪执行进度并保存所有跨越 .await 点的变量。转换后的结构体封装了状态切换的逻辑：
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") } } }}可以看到，Suspended 状态中包含了那个大数组。当状态从 Initial 切换到 Suspended 时，data 会被完整保留。
由此可知，对于一个 async 函数，若临时变量需跨越 await 存活，就会被纳入状态机，导致编译时生成的 Future 大小显著增加。
明确了 Future 大小的定义后，我们接着通过代码验证其对性能的影响。在之前的 mem::size_of::<Fut>() >= 2048 条件中可以看到，如果 Future 的大小过大，Box::pin(future) 会从堆上分配内存，理论上会带来额外开销。这种设计可能基于几点考量：小型 Future 直接嵌入任务结构体中，能提升缓存命中率；而大型 Future 若嵌入，会让任务结构体过于臃肿，占用过多栈空间，反而不利于性能。
我通过实验验证，若 async 函数中包含较大的结构体，确实会导致 Future 执行变慢（即便计算逻辑相同）：
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 slowerLarge Future (3KB): 3.41x slowerVery Large Future (10KB): 8.88x slowerHuge Large Future (100KB): 191.44x slower在微调这个 async 函数时，我发现了一些微妙的现象。为了让 data 跨越 await 存活，我特意在最后引用了它，以防编译器优化掉：
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}理论上，若改成下面这样，由于 len 在 await 前已计算完成，后面又没用引用到，生成的 Future 大小应该很小：
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);}然而，我发现 data 仍被保留在状态机中，即便 len 未被后续使用。这涉及到编译器如何判断变量是否跨越 await 存活的问题。当然，若显式限定 data 的生命周期在 await 之前，它就不会被纳入状态机：
async fn huge_large_future() -> u64 { { let data = [1u8; 102400]; // 10KB * 10 let len = data.len(); } future::yield_now().await; 0}我查阅了 Rust 编译器的源码，发现变量是否跨越 await 存活由 locals_live_across_suspend_points 函数 决定：
/// 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.在我们的代码中，let len = data.len() 构成了对 data 的借用，因此 data 被保留在状态机中。或许这里仍有优化的空间？我去社区问问看。
所有实验代码均可在以下链接找到：async-executor-examples。
在 Rust 异步编程中，代码的细微调整可能引发性能的显著波动。深入理解状态机生成的内在机制，能助你打造更高效的异步代码。下次编写 async fn 时，不妨自问：这个状态机究竟有多大？
2025-03-16 16:53:04
最近一年我在做 Fiber Network 这个新的开源项目，上个月底刚好主网第一个版本发布：
这个项目的挑战还是挺大的，上主网只是一个新的开始。我在开发过程中学到了很多东西，这是我前段时间写的一篇关于 Fiber 的大致介绍。
Fiber 是基于 CKB 构建的闪电网络协议，旨在实现快速、安全且高效的链下支付解决方案。借鉴了比特币闪电网络的核心理念，Fiber 针对 CKB 的独特架构进行了深度优化，提供低延迟、高吞吐量的支付通道，适用于微支付和高频交易等场景。与传统的闪电网络不同，Fiber 拥有多项关键特性：
在这篇文章中，我们将从源码层面介绍 Fiber 的整体架构和主要模块，以及项目的后续展望和规划。
我们从最高纬度去看一个 Fiber Node，主要包含下面几个主要模块：
其中：
Channel 的管理是闪电网络中非常重要、也是异常复杂的部分。其中的复杂性主要来自于 Channel 内部数据和状态的改变来自于网络上 peer 之间的交互，事件的处理可能存在并发上的问题，一个 Channel 的双边可能同时都有 TLC 的操作。
闪电网络本质上是一个 P2P 系统，节点之间通过网络消息相互通信进而改变内部的数据状态，我们发现 Actor Model 非常适合这种场景：
Actor Model 极大地简化了代码实现的复杂度，使用 Actor model 后我们不需要使用锁来保护数据的更新，当一个 Message handle 结束的时候，我们会把 channel state 的数据更新写入 db。而像 rust lightning 如果没用使用 actor model，就可能会涉及到非常复杂的锁相关的操作。
我们的所有的重要模块都采用了 Actor Model，Network Actor负责节点内外的消息通信，比如一个节点要给另外一个节点发送 Open channel 的消息，这个消息首先会通过 Fiber node A 的 channel actor 发送到 network actor，node A 的 network actor 通过更底层的网络层 tentacle 发送到 node B 的 network actor，然后 network actor 再发给 node B 里面的所对应的 channel actor。
在一个 Fiber Node 内部，每一个新的 Channel 我们都会建立一个对应的 ChannelActor，而这个 ChannelActorState 里面包含了这个 Channel 所需要持久化的所有的数据。采用 Actor Model 的另外一个好处就是我们能够在代码实现过程中直观地把 HTLC 网络协议相关的操作映射到一个函数里，比如下图中展示了 HTLC 在多个节点之间的流转过程，对于 A 到 B 之间的 AddTlc 操作，节点 A 里的 actor 0 所应对的代码实现就是 handle_add_tlc_command，而节点 B 里的 actor 1 所对应的代码实现是 handle_add_tlc_peer_message。
Channel 之间的 TLC 操作是复杂度非常高的部分，我们在实现上延用了 rust-lightning 的方式，使用状态机来表示 TLC 的状态，根据 actor 之间的 commitment_sign 和 revoke_ack 的消息来改变状态机，总的来说 AddTlc 的操作流程和两个 Peer TLC 状态的改变过程如下：
每个 Fiber 节点都通过 Network graph 保存了自己对于整个网络的了解情况，本质上这是一个双向有向图，每一个 Fiber 节点对应于 Graph 里面的一个 vertex，每一个 Channel 对应于 Graph 里面的一个 edge，出于隐私保护的需求，Channel 的真实 balance 不会广播到网络中，所有 edge 的大小是 Channel 的 capacity。
在支付开始前，发起者会通过路径规划找到一条通往收款者的路径，如果有多条路径就需要找到各方面综合考虑最优的路径，而在信息缺失的图中找到最优路径是一个在工程上非常具有挑战性的问题，Mastering Lightning Network 对这个问题有很详细的介绍：
在 Fiber 中，支付动作由用户向 Fiber Node 通过 RPC 发起请求，节点收到请求后会创建对应的 PaymentSession 来追踪支付的生命周期。
目前我们的路径规划的算法是一个变形的 Dijkstra 算法，这个算法是通过 target 往 source 方向扩展的，搜索路径的过程中通过折算支付成功的概率、fee、TLC 的 lock time 这些因素到一个 weight 来进行排序。其中的概率估算来自于每次支付的结果记录和分析，实现在 eval_probability。路径的选择质量好坏对于整个网络的效率和支付的成功率非常重要，这部分我们今后将会继续改进，Multipart payments (MPP) 也是一个今后可能要实现的功能。
路径规划完成后下一步就是构建 Onion Packet，然后给通过 source node 发起 AddTlcCommand。后续如果 TLC 失败或者成功会通过事件通知的方式处理。
整个支付的过程可能会发生多次的重试，一个常见的场景就是我们使用 capacity 作为 Graph 里边的容量，可能路径规划出来的路线无法真实满足支付的大小，所以我们需要返回错误并更新 Graph，然后再继续自动发起下一次路径规划尝试进行支付。
Fiber 的节点之间的通过相互发送广播消息交换新的 Node 和 Channel 信息，Fiber 中的 Gossip 模块实现了 Botls 7 定义的 routing gossip。在实现过程中我们的主要技术决策在这个 PR: Refactor gossip protocol里面有描述。
当一个 Node 节点第一次启动的时候，会通过配置文件里的 bootnode_addrs来的连接第一批 peers，广播消息的类型有三类：NodeAnnouncement 、ChannelAnnouncement 、ChannelUpdate 。
Fiber 会把收到的广播的原始数据保存下来，这样方便通过 timestamp + message_id 组合的 cursor 来对广播消息进行检索，以方便来自 peer node 的 query 请求。
当一个节点启动的时候，Graph 模块会通过 load_from_store来读取所有的 messages，重新构建自己的 network graph。
我们采用基于订阅的方式在网络中传播消息。一个节点需要主动向另一个节点发送广播消息过滤器（BroadcastMessagesFilter），另一个节点收到了该消息之后会为其创建对应的 PeerFilterActor，在构造函数里创建 Gossip 消息订阅。通过基于订阅的模型这种方式，我们可以让其他节点接收在特定的 cursor 之后接收到新保存的 Gossip 消息。
处于隐私保护的需求，payment 的 TLC 在多个节点之间传播的时候，每个节点只能知道自己所需要的信息，比如当前节点接收的 TLC 的 amount、expiry、下一个传播的节点等信息，而无法获得其他不必要的信息，而且每个 hop 在发送 TLC 给下一个节点的时候也需要做相应的混淆。
类似的，如果 payment 在某个节点传播的过程中发生了错误，这个节点也可能返回一个错误信息，而这个错误信息会通过 payment 的 route 反向传递给 payment 的发起节点。这个错误信息也是需要 Onion 加密的，这样确保中间节点无法理解错误的具体内容，而只有发送者能够获得错误内容。
我们参考了 rust-lightning 在 onion packet 的实现，发现其实现方式还是不够通用 (会绑定于其项目的具体数据结构)，所以我们自己从头开始实现了 fiber-sphinx，更详细的内容请参考项目的 spec。
涉及到 Onion 加解密的几个关键节点在这三个地方：
Watchtower 是闪电网络中的重要安全机制，主要用于帮助离线用户防止资金被盗。它通过实时监测链上交易，并在发现违规行为时执行惩罚交易，从而维护闪电网络的公平性和安全性。
Fiber 的 watchtower 实现在 WatchtowerActor里，这个 actor 会监听 Fiber 节点中发生的关键事件，比如一个新的 Channel 创建成功时将会收到 RemoteTxComplete，watchtower 就在数据库里插入一条对应的记录来开始监听这个通道，Channel 双方协商成功关闭时会收到 ChannelClosed，watchtower 从数据库中移除对应的记录。
在 Channel 中 TLC 交互时候，watchertower 将会收到 RemoteCommitmentSigned 和 RevokeAndAckReceived，分别去更新数据库中存储的 revocation_data 和 settlement_data，这些字段将会在后续创建 revocation transaction 和 settlement trasaction 的时候用到。
Watchtower 的惩罚机制是通过比较 commitment_number 来判断 CKB 的链上交易是否使用了老的 commitment transaction，如果发现违规则构建一个 revocation transaction 提交到链上进行惩罚，否则就构建发送一个 settlement transaction 提交到链上。
目前 Fiber 还处于前期活跃开发阶段，后续我们可能将继续做以下几个方面的改进：
Let’s scale P2P finance together! 🩵
