在 Chia 区块链里，一切都被称为 coin。每一次转账、锁仓或创建 DID 等操作，钱包都会先进行一次 coin selection（币选择） —— 由系统自动完成，用户无感。理解这一环节，能帮助我们避免余额“卡死”、减少费用，并提高链上效率。下文将从简单场景到进阶算法逐步拆解，带你彻底吃透 Chia 的 币选择策略。
当区块链只有一种资产：币模型初探
与账户余额模型不同，Chia 使用 coin set 模式。
简单来说，钱包里的余额并非一列数字，而是一张“硬币清单”。假设 Alice 钱包实际显示是 5 XCH，但底层可能由 1.2 + 3.8、0.5×10 或无数碎钻组成。任何操作都必须先“花费”一枚或几枚 coin，然后生成新 coin 给接收方和找零。
常见触发 coin selection 的操作：
- 发送 XCH
- 冻结 XCH 作为 Offer 保证金
- 创建 数字身份 DID
简单场景：一币搞定
最简单的情况：Alice 手中只有 1 枚 1 XCH 的大额单币。
她想给 Bob 转 0.5 XCH，此时做法显而易见：
- 花掉那一枚 1 XCH（销毁旧币）
生成两枚新币：
- 0.5 XCH → Bob
- 0.5 XCH → Alice（找零）
此时只有 1 input 2 outputs，逻辑一气呵成。
复杂场景：算法出马
示例背景
Alice 钱包现在有三枚币：
- 0.6 XCH
- 0.3 XCH
- 0.2 XCH
目标：给 Bob 转账 0.5 XCH（暂不考虑手续费）。
钱包有两条路径可行：
- 方案 A
用 0.6 XCH 单币，帮 Bob 创建 0.5 XCH，剩下的 0.1 XCH 找零。 - 方案 B
用 0.3 + 0.2 = 0.5 XCH，新币正好 0.5 XCH，无需找零。
两条方案在以往版本下的选择完全不同，答案藏在算法里。
旧算法：最大币优先（1.4 版本前）
早期之路极度粗暴：
挑最大的那一枚，再不够就依次往下补，直到凑够金额。
这样带来的副作用让人头大。设想：
- Alice 想买 0.0001 XCH 的 NFT
- 她钱包：一枚 0.0001 XCH 与一枚 10 XCH
旧算法会 锁定 10 XCH，而买家实际需要支付的仅是 0.0001 XCH！NFT 挂单期间，Alice 10 XCH 无法动弹，仅剩 0.0001 XCH 可用 —— 这种“杀鸡用牛刀”的体验对用户极不友好。
新算法：背包抽样（1.4 版本起）
为了根治上述痛点，Chia 参考 Bitcoin Core 的 背包算法（Knapsack Algorithm）：
- 精确匹配第一优先：找寻一枚与“支付额 + 手续费”分毫不差的小币。
- 碎币合拼：把小币全加一遍，看是否精确凑出所需金额。
- 找不到就升档：使用比目标还小的最小大中币。
- 背包抽样：在以上步骤未果时，随机抽样小币组合，最多迭代 1000 次，返回误差最小、输入硬币最少的那一组。
- 退而求其次：如果 1000 次仍无理想组合，再把所有小币全部纳入一次，二次迭代 1000 次后给出最佳可行方案。
通过该策略，手续费、找零碎片、UTXO 生命周期管理 都被极大优化。
5 组并行案例，看新版算法如何逆转乾坤
案例 1：第二次尝试 Alice 的例子（忽略手续费）
钱包拥有：0.6、0.3、0.2
目标：0.5 XCH
- 窗口 1：无单枚正巧 0.5
- 窗口 2：0.3 + 0.2 精确匹配 0.5 → 直接用
- 优化结果：2 input, 1 output，无找零，链上资源压到最低。
案例 2：加小额手续费 0.00001 XCH
目标额 0.50001 XCH
- 碎币总和 0.5 < 0.50001 → 步骤 2 失败
- 升档到 0.6 XCH，直接用它产生找零 0.09999 XCH → 1 input, 2 outputs，兼顾费用与简单性。
案例 3：多币随机组合
钱包硬币：0.6、0.5、0.4、0.3、0.2
目标：0.50001 XCH
- 无单枚精准匹配
- 碎币总和 1.4 > 0.50001，进入背包抽样
- 最终抽到 0.4 + 0.2 ≈ 0.60001 XCH，即可得一误差最小组合
- 注意：每次运行结果可能有差异，但都会在 1000 次内找到可接受解。
案例 4：大头妨碍小额支付的隐患被根除
经典场景回归：
钱包：0.0001、10 XCH
目标：0.0001 XCH
- 新算法 首选精确匹配，毫不犹豫锁定 0.0001 而非 10 XCH
- 十万级余额保持流动性，大额资产不会被异常占用。
案例 5：巨鲸冷钱包场景
假设冷钱包拥有 2000+ coin，平均面额 0.001 XCH。
背包算法在首轮 1000 次迭代即可挑出足够多 0.001 XCH 组合拼齐目标额，CPU 消耗可控，区块打包既不臃肿亦避免费用跳升。
FAQ：把烫手疑惑一次说清
问 1：我可以强制钱包使用“旧算法”吗？
答：官方参考钱包不再开放开关，若第三方钱包沿用旧逻辑，自行 fork 即可，但会复现大额锁死、费用偏高的问题，社区不建议继续使用。
问 2：手续费会影响背包策略吗？
答：会。步骤 1、2 均把“目标额 + 手续费”视为一次 整体需求；只有在无法满足时才会升档或抽样更大 coin。
问 3：有没有办法手动干预某个 coin 不要参与这次花费？
答：目前官方图形钱包不提供“自定义币”界面，CLI 及 SDK 支持通过 exclude_coin 字段实现，高阶开发者可调用 wallet RPC 实现。
问 4：如果钱包被垃圾 coin 填满，性能会崩？
答：1.4+ 版本对 >1000 枚 coin 的情形设有 二次抽样，CPU 不会无限增长；同时第三方冷钱包需定期 consolidate（归拢） 零币，保持输入集简洁。
问 5：Linux/Windows/Mac 下币选择逻辑一致吗？
答：完全一致。Chia 的 币选择策略 以 Python & Rust 跨平台实现，与系统无关。
尾声：为什么背包算法成为“最优解”？
- 准确性：动辄省下高至 30–40 % 链上输入
- 计算经济：最多 2000 次简单加权判断即可完成任务
- 可预测性：开发者可复刻同一输入数据，在多端复现相同随机种子结果 —— 便于调试与审计
- 前沿生态：👉 探索用 Chia 进行闪电转账与多签的更多玩法
关键词贯穿全文： Chia、币选择、coin set、背包算法、knapsack、手续费优化、数字身份 DID、交易效率、UX、冷热钱包、链上费用。