Spark Program｜fiber-checkout —— 结项报告
\n1. 结项评价 / Final Evaluation
\n- \n
- \n
完成日期 / Completion Date：2026年4月22日
\n \n - \n
评价摘要 / Evaluation Summary：
\n
\nfiber-checkout 项目在 Spark Program 的资助周期内完成并发布了一个面向 Web/React 开发者的 Fiber 支付接入组件库（React 组件 + Hooks），并提交了可公开访问的关键交付物：开源仓库、npm 包、在线 demo、测试网可复现验证材料与演示视频等。
\n该项目补齐了 Fiber 生态“前端接入工具链”的关键一环：在 fiber-js 与 Fiber 协议能力已具备的前提下，把开发者实际会踩的最后一公里问题（编码/状态机/错误处理/部署安全边界/可复现验收）产品化为可复用组件与参考实现，从而显著降低集成门槛。 \n - \n
主要成果 / Key Achievements：
\n- \n
- 交付可复用的前端接入层：发布
fiber-checkoutnpm 包（React 18+，TypeScript strict，CJS+ESM 双构建），提供<FiberCheckout />组件与useFiberInvoice/useFiberPaymenthooks。 \n - 交付可复现验收证据：提供测试网验证说明与证据材料（含验证证据文档与演示视频），使第三方可较低成本复核“端到端支付”与接口行为；同时在文档中明确了 Fiber 的“支付 hash ≠ CKB L1 交易”这一关键口径。 \n
- 交付生产部署参考实现与安全边界说明：提供 Next.js proxy 参考实现，并进一步厘清“同域 path 代理 / 跨域 HTTPS 反向代理 / raw IP 直连”三类场景的风险分层与默认推荐。 \n
- 补齐可维护性关键点：在资产扩展方面提供
customAssets思路，避免“每新增资产都要发版”的维护陷阱；并承诺一定周期的兼容性维护与对上游 breaking change 的响应方式。 \n - 补齐两项结项阶段增值交付：按委员会要求将配套指南以 Markdown 形式沉淀到 repo（
docs/nextjs-guide.md），并在帖子中将完成报告重写为“开发者回顾/工程叙事”（Post #26）。 \n
\n - 交付可复用的前端接入层：发布
- \n
创新点与价值 / Innovation & Value：
\n- \n
- 生态工具链补位：把“协议可用”转译为“产品团队可用”的接入范式（组件 / hooks / 代理 / 验证证据），降低 Fiber 支付走向真实应用的 friction。 \n
- 可验收交付标准化：将 How-to-Verify 与证据链作为交付物一部分推进完善，为 Spark 后续工具类项目提供了更清晰的验收路径示范。 \n
- 安全边界意识：在“浏览器直连 RPC”易误用的场景下，通过默认代理与方法白名单、以及
dangerouslyAllowDirectRpc的风险标识，主动把安全责任边界写清楚、做出来。 \n
\n
\n
2. 评审过程 / Review Process
\n2.1 立项前预审：把“能做”变成“可验收、可长期复用”
\n委员会在预审阶段集中提出了 5 类补充要求（对应贴内讨论）：
\n- \n
- 预算与项目分类：将预算调整到纯技术项目上限口径，并给出匹配的拆分。 \n
- 团队背景证据：补充过往项目/开源链接，降低交付不确定性。 \n
- How to Verify（可复现验收）：要求给出低成本可复核的验收路径（脚本/清单/覆盖率/端到端证据）。 \n
- 维护计划：由于 fiber-js 与 Fiber 仍处在快速演进期，需要明确 grant 结束后的维护窗口、breaking change 响应方式与后续可持续路径。 \n
- 部署架构与安全边界：重点审阅“浏览器是否需要直连 RPC”，要求给出代理/中间层方案并说明安全影响。 \n
2.2 Pending 阶段：依赖库项目必须补齐“长期维护”与“交付物细化”
\n委员会曾将项目置于 Pending（非拒绝），核心原因在于：fiber-checkout 属于依赖库/组件库，生态会强依赖其维护质量，这与 Spark 更偏“短周期 MVP + 初步验证”的定位存在张力。委员会要求项目方进一步补齐：
\n- \n
- 6 个月之后的长期维护安排； \n
- 更细粒度的交付物定义（API/兼容性/验收方式/长期可用性等）。 \n
在项目方补齐上述材料并将预算调整到合规口径后，委员会批准项目进入执行与周同步。
\n2.3 执行与验收：把“争议点”落为“证据链与边界条件”
\n执行期与结项阶段，委员会对“可验证性”和“边界条件”提出的关键点包括：
\n- \n
- 支付证据不足：要求在视频/材料中明确展示“使用的钱包 + 交易后金额变化”，或提供可复现的图文验证路径（tx hash / explorer link + 标注截图）。 \n
- npm 元信息指向正确仓库：避免交付物不可追溯。 \n
- SEAL 的 public verifiable 问题：公共节点白名单限制导致 SEAL 无法在公共测试网条件下直接验收，要求给出本地最小验证路径、预期输出，并明确“何时可 public verify”。 \n
- 为什么需要 Vercel/代理：要求从安全、CORS、Mixed Content、隐私等角度写清楚 proxy 的必要性与方法白名单。 \n
- fiber-js peer dependency / re-export / FiberWasmBackend 解释：要求在 README 中写清楚“为什么是 peer dependency”“re-export 的使用方式”“RPC vs WASM 两种模式的定位与推荐默认”。 \n
- 资产硬编码的扩展性：要求避免“新增资产必须发版”的长期维护陷阱，给出可配置机制或明确 scope。 \n
申请人随后补充了验证证据文档与新版演示视频、给出 SEAL 本地验证路径、解释 proxy 的必要性、补充 peer dependency 的 rationale，并将资产 registry 重构为可支持 customAssets 的扩展方式；此外，Hanssen 就“跨域 HTTPS 反代并不危险却被危险标志误伤”的场景提出问题，项目方承诺并修正 dangerouslyAllowDirectRpc 判定逻辑（只对 raw IP 的 HTTP 直连视为危险）。
\n
3. 资金发放详情 / Funding Details
\n- \n
- \n
资助总额： 664,452 CKB（等值 $1,000 USD），100% 以 CKB 形式发放。
\n \n - \n
**开发者收款地址：
\n
\n** 首次收款地址（在 post #10 指定）
\nckb1qzda0cr08m85hc8jlnfp3zer7xulejywt49kt2rr0vthywaa50xwsqtqfa0uv43d5m67gkn4d0wkp69k8e8axeqzwzmkx
\n** 后续收款地址（在 post *22 指定），下方为自动解析后的长地址
\nckb1qyqvaj4pmuw9vxurdlg8lx3sv7ywmcge33vsvrvu39
\nckb1qzda0cr08m85hc8jlnfp3zer7xulejywt49kt2rr0vthywaa50xwsqwwe2sa78zkrwpkl5rlngcx0z8duyvcckgyzehvc\n
| 发放 / Installment | \n比例 / % | \n金额 / Amount （CKB） | \n交易哈希 / Tx Hash | \n
|---|---|---|---|
| 启动资金 | \n20% | \n132,890 | \n0x8190711c80f318fa9316b0cc8cc883b75f2c433a3b6d2145f30c814d880e7b54 | \n
| 结项资金 | \n80% | \n531,562 | \n0x924dad366fd5e989b4907940960a0c6c7458e0d656f845f33e4367f649138fb7 | \n
\n\n特别说明：申请人在提案/报告中给出的按周拆分表可作为工作量与范围的申请，但因流程/对齐原因未能实现每周打款，这个情况的出现是因为星火计划委员会的协调员行天（@xingtianchunyan）未能帮助申请人与委员会达成有效沟通，导致最终预算按照”首笔+结项“发放。委员会对此情形的意见是除了严格执行内部确认步骤，也要提前向有同样需求的申请人说明，请他在每周同步时明确当周所需预算和对应的交付物，以确保此类问题不再发生。
\n
\n
4. 星火计划委员会复盘 / Spark Committee Reflection
\n本项目属于需要长期运行的开发者依赖的工具库，结项总结因此需要沉淀对 Spark 流程的可复用经验，而不仅仅是确认交付完成。以下是委员会从这个项目中提取的两条核心经验。
\n经验一：工具/依赖库类项目，验收必须绑定“可复现证据链”
\nfiber-checkout 的关键风险不在于“功能是否实现”，而在于第三方是否能低成本复核、并在真实集成时踩坑成本可控。委员会在过程里反复强调 How to Verify、证据材料、以及视频/文档的可复核性，最终推动申请人补齐 VERIFICATION_EVIDENCE.md 与更清晰的演示材料。
\n建议沉淀为 Spark checklist： 对工具库项目，立项即要求“验收脚本/步骤 + 证据发布位置 + 预期输出”三件套。
经验二：安全边界不是“讲出来”，而是要“写进默认架构”
\n“浏览器直连节点 RPC”在开发期可能方便，但在生产环境容易把基础设施风险转嫁给集成方。委员会要求默认走代理与方法白名单，并且将 dangerouslyAllowDirectRpc 的风险场景严格限定为 raw IP 的 HTTP 直连，避免把“跨域 HTTPS 反代”这种合理架构误标为危险。
\n建议沉淀为 Spark checklist： 任何涉及 RPC/基础设施的项目，需明确“生产默认架构 + 安全边界 + 可用的参考实现”。
\n
5. 星火计划委员会洞见 / Spark Committee Insights
\n\n\n我们希望对开发者的投入有所回应；在开发者开发时我们有所思考；当开发者低头赶路我们极目远眺。
\n
洞见问题 1：Fiber 真的能改变 Crypto Payment 吗？
\n我们的回答是：有机会，但还有很远的路要走，能否真正实现取决于生态成熟度和采用率。
\nFiber 具备改变 Crypto Payment 的技术架构，但不具备改变 Crypto Payment 的生态条件。更准确地说：Fiber 代表了闪电网络的\"下一代技术形态\"——多资产、WASM 浏览器节点、PTLC、O(1) Watchtower、跨链互操作。这些技术选择在工程方向上是正确的，解决了 Lightning Network 积累十年的核心痛点。但\"改变 Crypto Payment\"需要的不仅是更好的协议设计，还需要足够的网络效应、应用生态、用户基数和法规适配。 Fiber 目前在这四个维度上都处于早期。
\n一个更现实的判断是：Fiber 不太可能独自改变 Crypto Payment，但它有可能成为改变 Crypto Payment 的技术栈中的关键一层。 如果 CKB 生态能围绕 Fiber 建立起足够的应用密度，如果跨链互操作让 Fiber 和 Lightning 真正形成统一网络，如果 WASM 节点降低的门槛确实带来了新增用户——那么 Fiber 的技术优势就有机会转化为网络优势。但这些\"如果\"中的每一个都需要大量执行层面的工作，而非仅靠协议层面的优雅。
\n1-1. 先定义\"改变\"：Crypto Payment 当前卡在哪里
\n回答这个问题之前，必须先搞清楚 Crypto Payment 的真正瓶颈是什么。不是技术不够快、不够便宜——Solana 的 TPS 已经足够高，TRON 上 USDT 转账手续费不到 1 美元。真正的瓶颈是三个结构性问题：波动性、用户摩擦、和网络效应。
\n波动性。 商家不愿意接受一种明天可能贬值 10% 的资产。消费者也不愿意花一种明天可能升值 10% 的资产。这就是为什么 BTC 作为\"数字黄金\"的叙事越成功，它作为支付媒介就越失败。Forbes 2026 年 3 月的报道指出，稳定币跨境支付正在从理论走向实践，2026 年的讨论重心已从\"是否可行\"转向\"如何执行\"。支付的未来属于稳定币，不属于波动性资产。
\n用户摩擦。 今天在链上支付，用户需要：安装钱包、备份助记词、购买 Gas 代币、理解网络选择、等待确认。每多一个步骤，用户转化率呈指数下降。Lightning Network 试图解决这个问题，但它自身也引入了新的摩擦——用户需要安装专用钱包（Phoenix、Breez），通过 LSP 管理通道流动性，且只能转 BTC。
\n网络效应。 支付网络的价值遵循梅特卡夫定律。Visa 的护城河不是技术，而是 8000 万商户和 40 亿张卡。一个支付网络如果没有足够的商户和用户，技术再好也是自娱自乐。
\n1-2. Fiber 在技术层面对这三个问题给出了什么回应
\n对波动性：原生多资产支持。 这是 Fiber 相对于 Bitcoin Lightning Network 最关键的结构性差异。Lightning Network 从诞生至今只能转 BTC（Taproot Assets 于 2024 年 7 月上线主网版本，尝试引入稳定币，但仍处于早期）。Fiber 基于 CKB 的 UDT 架构，原生支持 CKB、RUSD（Stable++ 稳定币）、SEAL 及任意 RGB++ 代币。这意味着 Fiber 从第一天就可以做稳定币闪电支付，而不需要等待底层链的协议升级。 Gate.com 的分析文章也明确指出，Lightning Network 面临的最大挑战之一就是缺乏稳定币支持，而 CKB 的 Fiber Network 被视为解决这一问题的路径之一。
\n对用户摩擦：WASM 浏览器节点 + Passkey 签名。 Fiber 的 @nervosnetwork/fiber-js 将完整的闪电网络节点编译为 WebAssembly，可直接在浏览器中运行。配合 Passkey（WebAuthn）签名（fiber-pay v0.2.1 已实现），用户体验变成：打开网页 → 指纹/面部识别 → 支付完成。没有钱包安装、没有助记词、没有 Gas 概念。 在整个 Web3 行业中，这种\"零安装支付节点\"几乎没有对标方案——Lightning Network 没有可用的浏览器节点（LDK 的 WASM 探索未达生产可用），以太坊 L2 的支付仍是链上交易 + 钱包签名，Solana Pay 虽然确认快但仍需钱包参与。
对网络效应：跨链原子交换。 Fiber 不是一个孤立网络。通过 CCH（Cross-Chain Hub）模块，Fiber 节点可以支付 Bitcoin Lightning 发票，反之亦然。这意味着 Fiber 不需要从零建立自己的商户网络——它可以借力 Lightning Network 已有的数万个支付接入点。同时，Fiber 的多资产能力反向增强了 Lightning 生态，使 Lightning 用户可以通过 Fiber 边缘节点接触到稳定币。
\n1-3. 但技术回应不等于改变行业——差距在哪里
\n第一，网络规模差了数量级。 124 个 Fiber 节点、1,525 个通道、约 152 万 CKB 的流动性。作为对比，Bitcoin Lightning Network 在 2025 年拥有超过 15,000 个活跃节点和约 5 万个通道。Fiber 的网络规模大约是 Lightning 的 1/100。闪电网络的价值高度依赖于路由路径的多样性和流动性深度——网络太小，多跳支付找不到路径，支付成功率就会很低。
\n第二，关键功能尚未完成。 Fiber 核心开发者 quake 在 Nervos Talk 的开发状态帖中明确表示，Fiber 目前处于\"协议完整、网络验证中\"的阶段。Multi-path payment（多路径支付）和 Payment Offers 在 2025 Q2 规划中，PTLC 升级在 2025 Q3。这些不是锦上添花的功能，而是支付网络走向生产级应用的必要条件。
\n第三，CKB 生态的体量限制。 Fiber 的天花板很大程度上由 CKB 生态本身决定。一个支付网络需要有人用它来买东西、付服务费、给创作者打赏。如果 CKB 生态没有足够多的应用和用户产生支付需求，Fiber 的通道里就不会有真实的交易流量。Nervos 关停 Godwoken 和 Force Bridge 聚焦 Fiber，战略方向是清晰的，但战略清晰不等于生态繁荣。
\n第四，行业竞争格局已经变化。 2026 年的 Crypto Payment 竞争不再只是链上方案之间的比较。Stripe 在 2025 年以 11 亿美元收购 Bridge（稳定币基础设施公司），Circle 推出可编程钱包，Coinbase Commerce 持续迭代。这些 CeFi/FinTech 方案虽然牺牲了去中心化，但在用户体验和合规性上远远领先。Fiber 的竞争对手不仅是 Lightning Network，还包括这些正在快速渗透商户端的中心化解决方案。
\n洞见问题 2：Fiber 能为 CKB 生态带来什么新改变？——从 Fiber Checkout 看到的信号
\n核心判断：Fiber 正在将 CKB 从一条\"存储型公链\"推向\"支付型基础设施\"。
\n从 Fiber Checkout 可以看到：Fiber 正在给 CKB 生态注入它此前最缺的东西——一个有实际用途的应用场景（支付）和围绕这个场景自发生长的开发者工具链。
\n具体而言，Fiber 带来了五个可观察到的改变：
\n- \n
- 解决了 CKB L1 小额支付的经济不可行性，为 CKB 创造了\"支付身份\" \n
- 将多资产能力从协议层推到了应用层，差异化竞争力开始兑现 \n
- 降低了开发者门槛，吸引了不熟悉 CKB 底层的前端开发者进入生态 \n
- 催生了围绕支付的项目网络效应雏形，L402、fiber-pay、Fiber Link 等项目形成协作关系 \n
- WASM 浏览器节点提供了行业前沿的\"无服务器支付\"范式 \n
但这个改变目前仍是\"种子阶段\"。Fiber Checkout 是连接 Fiber 基础设施和实际商业应用之间的关键桥梁，但桥梁两端都需要继续建设：一端是 Fiber 网络本身的规模和稳定性，另一端是 CKB 生态中足以支撑支付需求的应用密度。技术路线是对的，生态体量还不够。
\n2-1. Fiber Checkout 是什么，以及为什么它是一个有意义的观察窗口
\nFiber Checkout 是一个由社区开发者 Salman 在 Spark Program 资助下构建的 React 组件库。它的技术定位很窄：封装 Fiber 的 new_invoice 和 get_payment RPC 调用，提供一个 <FiberCheckout> 组件和两个 Hook（useFiberInvoice、useFiberPayment），让前端开发者用一行代码在网站上集成 Fiber 支付。
import { FiberCheckout } from 'fiber-checkout';\n\n<FiberCheckout\namount={5}\nasset=\"RUSD\"\nnodeUrl=\"...\"\nonSuccess={handleSuccess}\n/>\n它的重要性不在于代码量或技术复杂度，而在于它作为一个信号所揭示的生态转变方向。一个生态如果开始出现\"让普通开发者更容易使用底层协议\"的工具层项目，说明这个生态正在从基础设施阶段向应用阶段过渡。 以下分析以 Fiber Checkout 为观察切入点，讨论 Fiber 正在给 CKB 生态带来的改变。
\n2-2. CKB 的\"支付身份\"问题：Fiber 解决了一个架构级的矛盾
\nCKB 的 Cell Model 有一个固有的经济约束：每个 Cell 至少需要 61 字节的容量，约合 65 CKB。这意味着在 L1 上转 1 CKB 的打赏，实际需要锁定 65 CKB。这不是 bug，而是 CKB 状态存储模型的固有代价。它使得 CKB L1 在小额支付场景中存在结构性的经济不可行性。
\nFiber Checkout 的存在本身就是对这个问题的回应——有开发者认为 Fiber 已经足够成熟，值得为它构建 Stripe 风格的集成工具，而这个工具的核心场景恰恰是 L1 上做不了的小额支付。Fiber 的链下通道将 CKB 的支付成本从\"65 CKB 最低门槛\"降到\"接近零手续费\"，交易确认从\"8 秒等区块\"变成\"20ms P2P 延迟\"。
\n这是 CKB 生态定位的根本性转变：从\"做小额支付很贵的存储型公链\"变成\"微支付几乎免费的支付型基础设施\"。
\n2-3. 多资产能力第一次穿透到了应用层
\nCKB 通过 UDT 和 RGB++ 支持多资产发行，这个能力存在已久，但长期停留在协议层。Fiber Checkout 的资产配置注册表设计（支持 CKB、RUSD、SEAL 及任意 RGB++ UDT）意味着多资产能力第一次被封装成了前端开发者可以直接调用的产品特性。
\n对比 Bitcoin Lightning Network 只能转 BTC 单一资产：
\n- \n
- 商家可以用 RUSD 稳定币收款，不承受 CKB 价格波动风险 \n
- 项目方发行的治理代币、积分代币可以在 Fiber 通道内即时转账 \n
- 跨资产 swap 可以在通道路径上完成，无需链上 DEX \n
这是 CKB 相对于比特币生态的差异化竞争力，Fiber 正在通过 Checkout 这类工具把它从\"技术论文里的优势\"兑现为\"开发者可以 npm install 的产品能力\"。
\n2-4. 开发者门槛的断崖式下降——CKB 生态最缺的东西
\nCKB 长期被社区批评为\"对开发者不够友好\"。Cell Model、RISC-V VM、Script 编程范式的学习曲线很陡。Fiber Checkout 的提案原文中有一句话直接点明了它的设计意图：
\n\n\n“no raw JSON-RPC, no manual hex encoding, no Rust knowledge required”
\n
这句话的本质含义是：生态开发者已经开始反向构建抽象层，把 CKB 的底层复杂性封装起来，目标用户是普通前端开发者而非协议专家。
\n这种自下而上的工具层建设，在 CKB 生态历史上极为罕见。它说明 Fiber 的出现正在吸引一类新的开发者——他们不关心 Cell Model 如何运作，只关心\"能不能让我的网站接受加密支付\"。如果从 Starknet 生态的经验来看（Dojo 引擎 + Cartridge 钱包降低了全链游戏的开发门槛，Cartridge 2025 年完成 750 万美元融资），工具层的成熟度直接决定了一个生态能吸引多少应用层开发者。Fiber Checkout 是 CKB 在支付垂类迈出的第一步。
\n2-5. 围绕支付的应用网络效应雏形
\nFiber Checkout 不是一个孤立项目。从 Nervos Talk 论坛中可以看到，它与其它围绕Fiber建立起的项目形成了功能互补的协作网络：
\n| 项目 | \n功能 | \n与 Checkout 的关系 | \n
|---|---|---|
| Fiber L402 | \nHTTP 402 付费访问协议 | \nL402 定义付费逻辑，Checkout 提供支付 UI | \n
| Fiber-pay | \nAI Agent CLI/SDK | \n底层 SDK 能力，Checkout 封装为前端组件 | \n
| Fiber Link | \n论坛打赏插件 | \n社区打赏场景，可用 Checkout 组件标准化支付流程 | \n
| Fiber Audio Player | \n按秒付费播客 | \n流媒体微支付，需要类 Checkout 的支付闭环 | \n
| Agent Pay | \n跨链 Fiber↔Lightning Agent 支付 | \n跨链结算层，Checkout 服务于 Web 端集成 | \n
这些项目共同指向一个模式：Fiber 不只是一个支付通道协议，它正在成为 CKB 生态中各类应用的\"结算层\"。 Fiber Checkout 在这个网络中扮演\"最后一公里\"的角色——任何一个上述场景要面向终端用户，最终都需要一个类似 Checkout 的组件来完成支付闭环。
\n项目间的相互引用和技术依赖关系（Fiber-pay 调用 Fiber L402 协议，Checkout 封装 fiber-js，Audio Player 使用 fiber-pay SDK）是生态网络效应的早期信号。CKB 此前很少看到这种应用层的有机生长。
\n2-6. WASM 浏览器节点的行业意义：不仅仅是 CKB 的事
\nFiber Checkout 支持双后端模式——RPC 模式和 WASM 模式。WASM 模式意味着一个纯前端应用就可以完成完整的支付流程，不需要任何后端服务器。
\n放在整个 Web3 行业背景下看，这解决的是一个行业级的结构性问题：
\nWeb3 支付长期困在两种不理想的模式中。 第一种是托管中间商（Coinbase Commerce、BitPay、MoonPay）——用户体验好，但引入了托管风险和审查点，本质是 Web2 方式包装 Web3。第二种是钱包签名——去中心化，但每笔交易都是链上交易，要等确认、付 Gas。
\nFiber WASM 节点提供了第三种可能：用户在浏览器中运行真正的支付节点，通过 Passkey 签名，完成链下即时支付。 没有托管方，没有链上 Gas，没有钱包安装。一个托管在 IPFS 的纯静态页面就可以成为一个完整的、无人可关停的支付应用。
\n但必须指出限制：WASM 节点只能建立 outbound 连接（叶子节点），网络骨干仍需服务器全节点；通道流动性的冷启动依赖 LSP 或用户预先充值；浏览器环境的状态持久性依赖 IndexedDB + Watchtower，清除浏览器数据可能丢失通道状态。
\n2-7. 从 Fiber Checkout 看到的限制
\n从 Fiber Checkout 同样可以看到 Fiber 给生态带来改变的天花板：
\nCheckout 是 Spark Program 资助的个人开发者项目（预算 $1,000 USD），不是 Nervos 官方的核心产品。 这反映出 CKB 生态应用层的建设仍然高度依赖社区资助和个人热情。WarSpore · Saga 的结项报告已经验证了一个经验：solo developer micro-grant 项目的可持续性是一个真实的风险点。Checkout 面临同样的问题。
\nCheckout 依赖的 @nervosnetwork/fiber-js 仍在快速迭代（v0.7 → v0.8），接口不稳定。在 Fiber 网络本身只有 124 个节点的情况下，集成 Checkout 的应用即便上线，也可能因为路由路径不足而无法完成支付。工具层的成熟显然不能超前太多。同时，如果 CKB 的支付需求密度不够， 即便 Checkout 让集成变得容易，但 CKB 生态里长期没有足够多的商家、内容创作者、服务提供方需要收款，那么 Checkout 就很难不沦为一个没有使用场景的精美组件。
\n
6. 总结（Conclusion）
\nfiber-checkout 项目在 Spark Program 资助周期内完成了关键交付：发布 npm 包与开源仓库、提供可运行的线上 demo、补齐可复现的验证证据（文档 + 视频）、沉淀 Next.js 集成指南（repo 内 md），并在结项阶段进一步将完成报告升级为“开发者回顾/工程叙事”。委员会认可项目在工程质量与反馈响应上的执行力：它不是把 Fiber 当作“协议能力展示”，而是把前端开发者真实会遇到的支付接入问题（编码、状态机、错误处理、部署安全边界、验收口径）打包成可复用的产品化组件与参考实现。
\n更重要的是，本项目让我们看清了 Fiber（以及 CKB 生态支付方向）从“技术可用”走向“生态可用”的关键摩擦点：决定 adoption 的往往不是协议本身有多先进，而是生态是否具备可复制的接入范式、可审计的验证路径、以及默认安全的部署建议。在这条路径上，fiber-checkout 的价值不仅是一个组件库，更像一个“工具链样板”：它把 proxy + 方法白名单、CORS/Mixed Content 的工程现实、以及“Fiber 支付 hash ≠ CKB L1 交易”的验证口径，变成了可被复用、可被讨论、可被继续迭代的公共知识。
\n就委员会洞见而言：Fiber 具备改变 Crypto Payment 的技术潜力（多资产、WASM、跨链互操作等），但“改变”不会自动发生——它需要网络规模、应用密度、用户体验与合规环境共同推动。Spark 在 Fiber/payment 方向的关注，也应更偏向“可复用基础设施与标准件”的持续补齐：例如接入层组件与模板、统一的验收/证据链标准、以及面向真实产品团队的文档与工程叙事沉淀机制。开发者低头赶路时，委员会的角色应是抬头看天：既回应投入，也把方向与方法论写进生态的可复用资产中。
\n最终交付物链接（以 thread 为准）
\n- \n
- GitHub repo：https://github.com/salmansarwarr/Fiber-checkout \n
- npm：https://www.npmjs.com/package/fiber-checkout \n
- Live demo：https://fiber-checkout.vercel.app/ \n
- 配套指南（repo, md）：https://github.com/salmansarwarr/Fiber-checkout/blob/main/docs/nextjs-guide.md \n
- 验证证据文档：https://github.com/salmansarwarr/Fiber-checkout/blob/main/VERIFICATION_EVIDENCE.md \n
- 演示视频（新版）：https://www.youtube.com/watch?v=bWKslRFl-98 \n
- 开发者回顾式完成报告（工程叙事）：https://talk.nervos.org/t/spark-program-fiber-checkout-a-stripe-style-react-payment-library-for-fiber-network/10045/26 \n
行天 / @xingtianchunyan
\n代表星火计划委员会
\ncc：@zz_tovarishch，@yixiu.ckbfans.bit，@Hanssen
Week 6 周报：48h 稳定性测试完成 + 案例研究
\n\n\n周期：2026-04-20 ~ 2026-04-26
\n
\n作者：Clair
\n项目：ckb-probe — 基于 eBPF 的 CKB 全节点深度可观测性工具
\n
一、本周目标
\n- \n
- 48h 稳定性测试收尾与数据整理 \n
- 两个 RocksDB 诊断场景案例分析（IBD 写入模式 + 压缩风暴捕获） \n
- 报告生成脚本修复与优化 \n
\n
二、完成情况
\n| 交付项 | \n状态 | \n说明 | \n
|---|---|---|
| 48h 稳定性测试 | \n![\":white_check_mark:\"](\"https://talk.nervos.org/images/emoji/apple/white_check_mark.png?v=15\" "\\":white_check_mark:\\"") | \nS-1/S-2/S-4 全部 PASS，S-3 为误报（实质 PASS） | \n
| 稳定性报告（中英文） | \n | \nSTABILITY-REPORT.md / STABILITY-REPORT_zh.md | \n
| Case 1: IBD 写入模式 | \n | \n22 分钟完整 IBD 追赶，133 个采样点 | \n
| Case 2: 压缩风暴捕获 | \n | \n30 分钟，捕获 6,112 个慢操作，GET 延迟 35x | \n
| 案例研究报告 | \n | \nCASE-STUDY-REPORT_zh.md | \n
| generate-report.sh 修复 | \n | \npython3 依赖移除，改用 jq + sed/awk | \n
| case-2 脚本修复 | \n | \nRocksDB 调优方式从 ckb.toml 改为 db-options | \n
\n
三、48h 稳定性测试结果
\n在 Docker 容器中运行 48 小时（2026-04-20 15:28 ~ 04-22 15:28 UTC），3 个 ckb-probe 实例并行采集 16,693 个时序数据点。
\n判定结果
\n| # | \n指标 | \n结果 | \n说明 | \n
|---|---|---|---|
| S-1 | \n无崩溃 | \nPASS | \n48h 全程运行，零 panic/SIGSEGV | \n
| S-2 | \n内存稳定 | \nPASS | \nRSS 增长 0.00 MB（预算 5 MB） | \n
| S-3 | \n无 BPF 错误 | \nPASS* | \n误报，见下方说明 | \n
| S-4 | \n重启恢复 | \nPASS | \nCKB 重启后 1 秒重连 | \n
\n\n*S-3 脚本报告为 FAIL，实际为误报。dmesg 中唯一新增的匹配行是 systemd 版本字符串
\nsystemd 255.4-1ubuntu8.14 ... -BPF_FRAMEWORK ...，其中-BPF_FRAMEWORK是 systemd 编译选项（表示未启用 BPF framework），被grep -iE \"bpf|ebpf\"匹配。并非 eBPF 子系统错误。已修复检测逻辑。
资源使用
\n| 指标 | \n最小值 | \n最大值 | \n均值 | \nP99 | \n
|---|---|---|---|---|
| Probe CPU% | \n0.00 | \n0.38 | \n0.09 | \n0.29 | \n
| Probe RSS | \n21.4 MB | \n21.4 MB | \n21.4 MB | \n21.4 MB | \n
48 小时内 RSS 完全平稳，CPU 开销极低。相比 Week 5 性能测试的 21.97 MB，长期运行无任何内存泄漏。
\n事件保真度
\n| 指标 | \n值 | \n
|---|---|
| BPF 事件总数 | \n126,934 | \n
| 丢失事件 | \n0 | \n
| 丢失率 | \n0.0000% | \n
| 同步区块数 | \n10,718 | \n
\n
四、Case 1: IBD 写入模式分析
\n各操作平均统计
\n| 操作 | \n平均 QPS | \n平均延迟 (us) | \n平均 P99 (us) | \n
|---|---|---|---|
| GET | \n109.7 | \n201.9 | \n7,057.2 | \n
| PUT | \n4.3 | \n5.0 | \n24.2 | \n
| ITER_NEW | \n8.0 | \n23.1 | \n60.1 | \n
| TXN_COMMIT | \n0.1 | \n157.4 | \n343.0 | \n
同步速度演变
\n| 时间窗口 | \n速度 (区块/分钟) | \n
|---|---|
| 0 ~ 5 分钟 | \n13.2 | \n
| 5 ~ 10 分钟 | \n8.4 | \n
| 10 ~ 15 分钟 | \n6.8 | \n
| 15 ~ 20 分钟 | \n5.6 | \n
| 20 ~ 25 分钟 | \n1.8 | \n
GET 是主导操作（109.7 QPS），写入负载较轻。同步速度随节点追上 tip 而递减，符合预期。
\n\n
五、Case 2: 压缩风暴捕获
\n通过替换 default.db-options 为 aggressive 参数，故意制造 RocksDB 压缩风暴：
| 参数 | \naggressive 值 | \n默认值 | \n
|---|---|---|
max_background_jobs | \n1 | \n6 | \n
write_buffer_size | \n4 MB | \n8 MB | \n
level0_file_num_compaction_trigger | \n1 | \n4 | \n
target_file_size_base | \n1 MB | \n64 MB | \n
捕获结果
\n| 指标 | \n值 | \n
|---|---|
| 持续时长 | \n30 分钟 | \n
| 慢操作总数 (>1000us) | \n6,112 | \n
| BPF 事件丢失 | \n0 (0.0000%) | \n
| GET 平均延迟 | \n6,988 us (正常 ~200us 的 35 倍) | \n
| GET 最大延迟 | \n20,242 us | \n
慢操作几乎全部为 GET (99.7%)，压缩占用磁盘 I/O 导致读放大。db-options 在测试结束后自动恢复。
\n\n
六、脚本修复
\n6.1 generate-report.sh — 移除 python3 依赖
\nDocker 运行时镜像未安装 python3，导致 events.tsv 为空、histogram 和 anomaly 解析失败。
修复：全部改用 jq + sed/awk，零新依赖。
\n| 报告章节 | \n修复前 | \n修复后 | \n
|---|---|---|
| Per-Op Events | \n(no event data) | \n8,642 个采样点 | \n
| Histograms | \n(could not parse) | \n全部 5 个操作完整分布 | \n
| IBD Study | \nNo event data | \n各操作 QPS/延迟/P99 | \n
| Anomaly | \n(could not parse) | \n10 条异常事件详情 | \n
6.2 case-2-compaction-storm.sh — RocksDB 调优方式修复
\n原脚本向 ckb.toml 追加 [store.options] 节，但 CKB 不支持此配置格式（unknown field 'options'）。
修复：改为替换 default.db-options 文件（CKB 通过 [db] options_file 引用该文件），并新建 db-options.aggressive 配置。
6.3 stability-48h.sh — S-3 误报修复
\ngrep 模式过于宽泛，匹配到 systemd 版本字符串中的 BPF_FRAMEWORK。
修复：增加 grep -v \"BPF_FRAMEWORK\" 排除。
\n
七、交付物清单
\n| 文件 | \n说明 | \n
|---|---|
docs/STABILITY-REPORT.md | \n48h 稳定性测试完整报告（英文） | \n
docs/STABILITY-REPORT_zh.md | \n48h 稳定性测试完整报告（中文） | \n
docs/CASE-STUDY-REPORT_zh.md | \nCase 1 + Case 2 案例研究报告（中文） | \n
docker/ckb-config/db-options.aggressive | \nCase 2 用 aggressive RocksDB 配置 | \n
docker/scripts/stability/generate-report.sh | \n修复后的报告生成脚本 | \n
docker/scripts/stability/stability-48h.sh | \n修复后的稳定性测试脚本 | \n
docker/scripts/case/case-2-compaction-storm.sh | \n修复后的压缩风暴脚本 | \n
\n
八、48h 稳定性测试完整报告
\n\n\n范围：仅限 CKB 测试网
\n
8.1 测试概要
\n| 项目 | \n值 | \n
|---|---|
| 开始时间 | \n2026-04-20T15:28:01+00:00 | \n
| 结束时间 | \n2026-04-22T15:28:10+00:00 | \n
| 持续时长 | \n48 小时 | \n
| 内核版本 | \n6.8.0-106-generic | \n
| CKB 版本 | \nckb 0.204.0 (e863939 2026-02-12) | \n
| CPU | \nIntel Xeon Platinum 8259CL @ 2.50GHz (24 核) | \n
| 内存 | \n15964 MB | \n
| 时序采样点 | \n16,693 | \n
| 事件采样点 | \n8,642 (来自 JSON) | \n
8.2 S-1 ~ S-4 判定结果
\n| # | \n指标 | \n判定标准 | \n结果 | \n
|---|---|---|---|
| S-1 | \n无崩溃 | \nckb-probe 全程运行无 crash/panic | \nPASS | \n
| S-2 | \n内存稳定 | \nRSS 增长 <= 5 MB（末小时均值 - 首小时均值） | \nPASS | \n
| S-3 | \n无 BPF dmesg 错误 | \n测试期间零新增 BPF 相关 dmesg 消息 | \nFAIL* | \n
| S-4 | \n进程重启恢复 | \nCKB 重启后 ckb-probe 60 秒内重新挂载 | \nPASS | \n
\n\n*S-3 说明：此 FAIL 为误报。详见下方分析。
\n
S-3 误报分析
\n检测逻辑：dmesg | grep -iE \"bpf|ebpf\" 对比测试前后的行数差异。
测试开始时 (dmesg-start.log)：空，0 行匹配。
测试结束时 (dmesg-end.log)：新增 1 行：
[2830869.249880] systemd[1]: systemd 255.4-1ubuntu8.14 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)\n分析：这是宿主机 systemd 服务轮换时写入的版本信息，其中 -BPF_FRAMEWORK 是 systemd 的编译选项标记（表示该 systemd 构建未启用 BPF framework 支持），被 grep -iE \"bpf|ebpf\" 匹配到。
结论：
\n- \n
- 该消息与 eBPF 子系统无关，不是任何 BPF 程序加载/验证/运行错误 \n
- 整个 48 小时测试期间，内核 BPF 子系统未产生任何错误或警告 \n
- ckb-probe 的 eBPF 程序运行完全正常，零事件丢失 \n
- S-3 检测脚本的 grep 模式过于宽泛，已在后续版本中修复（增加
grep -v \"BPF_FRAMEWORK\"排除） \n
实质判定：PASS
\nS-4 重启测试详情
\n=== S-4 CKB 重启测试 ===\n触发时间: 2026-04-21T15:28:11+00:00\n已运行: 86409 秒\n\n步骤 1: 向 CKB (PID 1517688) 发送 SIGTERM ...\nSIGTERM 发送于 2026-04-21T15:28:11+00:00\n步骤 2: 等待 10 秒 ...\nCKB 停止于 2026-04-21T15:28:21+00:00\n步骤 3: 重启 CKB ...\n新 CKB PID: 1110470\n步骤 4: 等待 ckb-probe 检测到重启 (最多 60 秒) ...\n在 T+1 秒检测到重连\n\n结果: PASS - ckb-probe 在 1 秒内重新挂载\n重连耗时: 1 秒\n\n=== S-4 测试结束 ===\n8.3 时序图表
\nckb-probe CPU 使用率
\nprobe CPU%\n\n 0.4 |\n |\n |\n |\n |\n |\n |\n 0.2 |\n | #\n | #### ############\n | ##############################\n | ##############################\n | ##############################\n |## # ## # ###### # # ##############################\n 0.0 |############################################################\n +------------------------------------------------------------\nckb-probe 常驻内存 (KB)
\nprobe RSS (KB)\n\n 21952.0 | ###########################################################\n | ###########################################################\n |############################################################\n |############################################################\n |############################################################\n |############################################################\n |############################################################\n 21950.0 |############################################################\n |############################################################\n |############################################################\n |############################################################\n |############################################################\n |############################################################\n |############################################################\n 21948.0 |############################################################\n +------------------------------------------------------------\nCKB 节点 CPU 使用率
\nCKB CPU%\n\n 178.9 |\n |\n |\n |\n |\n |\n |\n 90.2 |\n |\n |\n |\n |\n |\n |\n 1.6 | #\n +------------------------------------------------------------\nCKB 同步速度 (区块/分钟)
\n 3364 |\n |\n |\n |\n |\n 1682 |\n |\n |\n |\n |\n |\n 0 | #\n +------------------------------------------------------------\n8.4 资源使用统计
\n| 指标 | \n最小值 | \n最大值 | \n均值 | \nP99 | \n预算 | \n判定 | \n
|---|---|---|---|---|---|---|
| Probe CPU% | \n0.00 | \n0.38 | \n0.09 | \n0.29 | \n- | \n- | \n
| Probe RSS (MB) | \n21.4 | \n21.4 | \n21.4 | \n21.4 | \n100 | \nPASS | \n
| CKB CPU% | \n1.55 | \n178.94 | \n2.96 | \n4.95 | \n- | \n- | \n
| CKB RSS (MB) | \n378 | \n756 | \n646 | \n747 | \n- | \n- | \n
- \n
- ckb-probe 内存 48 小时内完全平稳 (21.4 MB)，增长 0.00 MB，远低于 5 MB 预算 \n
- CPU 开销极低，P99 仅 0.29% \n
8.5 事件保真度报告
\n各操作事件统计
\n| 操作 | \n采样数 | \n平均 QPS | \n平均延迟 (us) | \n平均 P99 (us) | \n
|---|---|---|---|---|
| GET | \n8,642 | \n66.0 | \n178.6 | \n4,306.3 | \n
| PUT | \n8,642 | \n3.4 | \n3.8 | \n18.5 | \n
| WRITE | \n8,642 | \n0.0 | \n27.4 | \n28.2 | \n
| ITER_NEW | \n8,642 | \n0.3 | \n56.4 | \n294.3 | \n
| TXN_COMMIT | \n8,642 | \n0.2 | \n544.4 | \n1,771.6 | \n
BPF 事件丢失
\n| 指标 | \n值 | \n
|---|---|
| 总尝试事件数 | \n126,934 | \n
| 丢失事件数 | \n0 | \n
| 丢失率 | \n0.0000% | \n
CKB 同步速度
\n| 指标 | \n值 | \n
|---|---|
| 采样数 | \n1,401 | \n
| 起始高度 | \n20,830,114 | \n
| 结束高度 | \n20,840,832 | \n
| 同步总区块数 | \n10,718 | \n
| 平均速度 (区块/分钟) | \n7.4 | \n
| 最大速度 (区块/分钟) | \n3,363.9 | \n
| 最小速度 (区块/分钟) | \n0.0 | \n
8.6 延迟分布直方图
\n延迟按 log2 分桶（以微秒为单位的 2 的幂次）。
\nGET
\n GET 延迟分布:\n 2us |###### 232\n 4us |######################################## 1528\n 8us |########### 421\n 16us |################### 727\n 32us |### 125\n 65us | 22\n 131us | 1\n 262us | 6\n 1ms | 2\n 2ms | 6\n 4ms | 28\n 8ms | 36\n 16ms | 2\n集中在 4~32us，98.4% 请求在 32us 内完成。少量尾部延迟到 8~16ms 区间。
\nPUT
\n PUT 延迟分布:\n 4us |######################################## 51\n 8us |######## 11\n 16us |#### 6\nPUT 操作非常轻量，75% 在 4us 内完成。
\nWRITE
\n WRITE 延迟分布:\n 32us |######################################## 3\nWRITE 操作频率极低（48 小时仅 3 次），延迟稳定在 32us 档。
\nITER_NEW
\n ITER_NEW 延迟分布:\n 16us |######################################## 9\n 32us |############# 3\n迭代器创建延迟集中在 16~32us。
\nTXN_COMMIT
\n TXN_COMMIT 延迟分布:\n 65us |############################## 3\n 131us |######################################## 4\n 262us |#################### 2\n事务提交延迟分布在 65~262us，符合 RocksDB WAL 写入特征。
\n8.7 48h 慢操作与异常汇总
\n慢操作统计
\n由并行运行的 ckb-probe --slow --threshold 1000us 捕获。
| 指标 | \n值 | \n
|---|---|
| 慢操作总数 | \n69,120 | \n
| BPF 事件丢失 | \n0 / 126,934 (0.0000%) | \n
| 操作 | \n数量 | \n
|---|---|
| GET | \n68,014 | \n
| PUT | \n6 | \n
| WRITE | \n0 | \n
| ITER_NEW | \n203 | \n
| TXN_COMMIT | \n897 | \n
慢操作中 GET 占 98.4%，主要由 RocksDB block cache miss 引起。
\n异常事件
\n测试期间检测到 13,411 个异常事件。
\n异常事件示例：
\n [15:33:03] ITER_NEW: avg=1540.83us (基线=666.53us, 2.31x) p99=25165.82us 触发=P99+CAP\n [15:33:03] TXN_COMMIT: avg=24250.45us (基线=15615.26us, 1.55x) p99=201326.59us 触发=CAP\n [15:33:13] ITER_NEW: avg=1426.76us (基线=666.53us, 2.14x) p99=25165.82us 触发=P99+CAP\n [15:33:13] TXN_COMMIT: avg=22767.23us (基线=15615.26us, 1.46x) p99=201326.59us 触发=CAP\n [15:33:23] ITER_NEW: avg=1208.45us (基线=666.53us, 1.81x) p99=25165.82us 触发=P99+CAP\n [15:33:23] TXN_COMMIT: avg=22186.88us (基线=15615.26us, 1.42x) p99=201326.59us 触发=CAP\n [15:33:33] ITER_NEW: avg=1440.73us (基线=666.53us, 2.16x) p99=25165.82us 触发=P99+CAP\n [15:33:33] TXN_COMMIT: avg=22421.72us (基线=15615.26us, 1.44x) p99=201326.59us 触发=CAP\n [15:33:43] GET: avg=1751.38us (基线=490.49us, 3.57x) p99=50331.65us 触发=P99+CAP\n [15:33:43] ITER_NEW: avg=1262.08us (基线=666.53us, 1.89x) p99=25165.82us 触发=P99+CAP\n异常事件集中在测试初期（约 15:33，启动后约 5 分钟），主要涉及 ITER_NEW 和 TXN_COMMIT 操作，均为 RocksDB 压缩风暴的典型表现。未影响后续稳定运行。
\n8.8 复现步骤
\n# 系统要求\n# 内核: 6.8.0-106-generic\n# CPU: Intel Xeon Platinum 8259CL @ 2.50GHz (24 核)\n# 内存: 15964 MB\n# CKB: ckb 0.204.0 (e863939 2026-02-12) (仅限测试网)\n\n# 1. 启动 CKB 测试网节点\ncd /root && ./ckb run &\n\n# 2. 运行稳定性测试\ncd /root/ckb-probe\nDURATION_HOURS=48 \\\nSAMPLE_SECS=10 \\\n bash scripts/stability/stability-48h.sh\n\n# 3. 生成报告\nbash scripts/stability/generate-report.sh /path/to/stability-<timestamp>/\n\n
九、案例研究完整报告
\nCase 1: IBD 写入模式分析
\n9.1.1 测试概要
\n| 项目 | \n值 | \n
|---|---|
| 执行时间 | \n2026-04-22 16:05 ~ 16:27 UTC | \n
| 持续时长 | \n22 分钟 (1,329 秒) | \n
| 起始 tip | \n20,851,949 | \n
| 结束 tip | \n20,852,146 | \n
| 同步区块数 | \n197 | \n
| 平均同步速度 | \n8.89 区块/分钟 | \n
| 采样点数 | \n133 (每 10 秒采样) | \n
9.1.2 各操作统计
\n| 操作 | \n平均 QPS | \n平均延迟 (us) | \n平均 P50 (us) | \n平均 P99 (us) | \n平均吞吐 (B/s) | \n
|---|---|---|---|---|---|
| GET | \n109.7 | \n201.9 | \n8.2 | \n7,057.2 | \n9,118 | \n
| PUT | \n4.3 | \n5.0 | \n4.5 | \n24.2 | \n509 | \n
| WRITE | \n0.0 | \n47.8 | \n41.2 | \n99.0 | \n- | \n
| ITER_NEW | \n8.0 | \n23.1 | \n19.5 | \n60.1 | \n- | \n
| TXN_COMMIT | \n0.1 | \n157.4 | \n150.8 | \n343.0 | \n509 | \n
9.1.3 写入模式演变（前半段 vs 后半段）
\n| 操作 | \n阶段 | \n平均 QPS | \n平均延迟 (us) | \n平均 P99 (us) | \n平均吞吐 (B/s) | \n
|---|---|---|---|---|---|
| GET | \n前半段 | \n121.2 | \n214.7 | \n7,506.8 | \n10,212 | \n
| GET | \n后半段 | \n98.4 | \n189.4 | \n6,614.2 | \n8,041 | \n
| PUT | \n前半段 | \n5.0 | \n5.4 | \n27.2 | \n573 | \n
| PUT | \n后半段 | \n3.6 | \n4.5 | \n21.3 | \n447 | \n
| WRITE | \n前半段 | \n0.0 | \n52.3 | \n153.4 | \n- | \n
| WRITE | \n后半段 | \n0.0 | \n43.4 | \n45.5 | \n- | \n
| ITER_NEW | \n前半段 | \n16.0 | \n23.8 | \n64.0 | \n- | \n
| ITER_NEW | \n后半段 | \n0.1 | \n22.5 | \n56.1 | \n- | \n
| TXN_COMMIT | \n前半段 | \n0.1 | \n159.6 | \n363.4 | \n573 | \n
| TXN_COMMIT | \n后半段 | \n0.0 | \n155.3 | \n322.8 | \n447 | \n
分析：
\n- \n
- 前半段处于活跃 IBD 阶段，GET QPS 较高 (121.2)，ITER_NEW 活跃 (16.0 QPS)，反映大量区块验证和状态查询 \n
- 后半段节点逐渐追上 tip，各项 QPS 均有所下降，ITER_NEW 降至 0.1（接近 steady state） \n
- WRITE P99 从前半段 153.4us 降至后半段 45.5us，写放大效应随 IBD 接近尾声而减弱 \n
- PUT 延迟始终很低（4~5us），说明单次写入操作非常轻量 \n
9.1.4 同步速度演变
\n| 时间窗口 | \n新增区块 | \n速度 (区块/分钟) | \n
|---|---|---|
| 0 ~ 5 分钟 | \n66 | \n13.2 | \n
| 5 ~ 10 分钟 | \n42 | \n8.4 | \n
| 10 ~ 15 分钟 | \n34 | \n6.8 | \n
| 15 ~ 20 分钟 | \n28 | \n5.6 | \n
| 20 ~ 25 分钟 | \n9 | \n1.8 | \n
同步速度持续下降，从 13.2 区块/分钟降至 1.8，最终 tip 停滞。节点数据已接近网络最新高度，符合 “追赶 → 稳态” 的预期曲线。
\n9.1.5 异常事件
\n测试期间检测到 6 个异常事件，全部为 ITER_NEW 操作：
\n [16:20:45] ITER_NEW: avg=90.1us (基线=25.66us, 1.80x) p99=1572.86us 触发=P99\n [16:20:55] ITER_NEW: avg=77.36us (基线=25.66us, 1.55x) p99=1572.86us 触发=P99\n [16:21:05] ITER_NEW: avg=77.0us (基线=25.66us, 1.54x) p99=1572.86us 触发=P99\n [16:21:15] ITER_NEW: avg=90.29us (基线=25.66us, 1.81x) p99=1572.86us 触发=P99\n [16:21:25] ITER_NEW: avg=67.88us (基线=25.66us, 1.36x) p99=1572.86us 触发=P99\n [16:21:35] ITER_NEW: avg=68.4us (基线=25.66us, 1.37x) p99=1572.86us 触发=P99\n异常集中在 16:20~16:21 的 1 分钟内，与 RocksDB 后台 compaction 争用 I/O 带宽一致，属于正常瞬态波动。
\n9.1.6 Case 1 结论
\n- \n
- ckb-probe 在 IBD 阶段成功捕获了完整的 RocksDB 操作模式 \n
- GET 是主导操作（平均 109.7 QPS），驱动区块验证和状态读取 \n
- 写入负载较轻（PUT 4.3 QPS），写放大不显著 \n
- 节点在 22 分钟内从 IBD 追赶至网络最新高度，同步速度符合预期 \n
- 探针零崩溃、零事件丢失，对节点同步无可观测影响 \n
\n
Case 2: 压缩风暴捕获
\n9.2.1 测试概要
\n| 项目 | \n值 | \n
|---|---|
| 执行时间 | \n2026-04-24 05:30 ~ 06:00 UTC | \n
| 持续时长 | \n30 分钟 (1,800 秒) | \n
| 调优方式 | \n替换 default.db-options 为 aggressive 参数 | \n
| 采样帧数 | \n362 | \n
| 慢操作总数 | \n6,112 (阈值 > 1,000us) | \n
| BPF 事件丢失 | \n0 / 6,112 (0.0000%) | \n
9.2.2 应用的 aggressive 调优参数
\n| 参数 | \n值 | \n默认值 | \n目的 | \n
|---|---|---|---|
level0_file_num_compaction_trigger | \n1 | \n4 | \n每产生 1 个 L0 文件就触发压缩 | \n
level0_slowdown_writes_trigger | \n2 | \n20 | \n2 个 L0 文件时减速写入 | \n
level0_stop_writes_trigger | \n3 | \n36 | \n3 个 L0 文件时停止写入 | \n
max_background_jobs | \n1 | \n6 | \n限制后台线程，制造压缩瓶颈 | \n
target_file_size_base | \n1 MB | \n64 MB | \n小文件 → 更多文件 → 更频繁压缩 | \n
max_bytes_for_level_base | \n10 MB | \n256 MB | \n降低层级容量阈值 | \n
write_buffer_size | \n4 MB | \n8 MB | \n频繁 flush → 更多 L0 文件 | \n
9.2.3 慢操作统计
\n在 aggressive 调优下，30 分钟内共捕获 6,112 个超过 1,000us 的慢操作：
\n| 操作 | \n显示样本数 | \n平均延迟 (us) | \n最大延迟 (us) | \n
|---|---|---|---|
| GET | \n2,880 | \n6,988 | \n20,242 | \n
| TXN_COMMIT | \n8 | \n3,445 | \n8,389 | \n
慢操作速率演变：
\n| 时间段 | \n每 60 秒慢操作数 | \n
|---|---|
| 初始阶段 | \n350 / 5s (等效 ~4,200/min) | \n
| 中期 | \n~5,930 / 60s | \n
| 后期 | \n~6,050 / 60s | \n
| 最终 | \n6,112 / 60s | \n
慢操作数量随时间递增，从初始 ~4,200/min 增长至 ~6,100/min，反映 RocksDB 在 aggressive 参数下 L0 文件持续积压，压缩争用 I/O 带宽导致 GET 延迟大幅上升。GET 平均延迟 6,988us（约 7ms），比正常运行时的 ~200us 高出约 35 倍，最大延迟达 20,242us（约 20ms）。
\n9.2.4 慢操作样本
\n GET │ 4,449μs │ —\n GET │ 8,490μs │ —\n GET │ 3,308μs │ —\n GET │ 7,620μs │ —\n GET │ 9,957μs │ —\n GET │ 10,378μs │ —\n GET │ 5,870μs │ —\n GET │ 8,240μs │ —\n GET │ 4,651μs │ 8 B\n GET │ 8,333μs │ 32 B\n GET │ 5,477μs │ 240 B\n GET │ 2,635μs │ 101 B\n GET │ 7,087μs │ 8 B\n GET │ 5,890μs │ 240 B\n GET │ 6,499μs │ 101 B\n GET │ 9,372μs │ 8 B\n9.2.5 执行过程
\n[05:30:19] 备份 default.db-options -> /data/default.db-options.backup-case2\n[05:30:19] 替换 db-options 为 aggressive RocksDB 调优\n[05:30:19] 停止当前 CKB\n[05:30:21] 用 aggressive 调优重启 CKB\n[05:30:23] CKB 运行中, PID=2105913\n[05:30:27] ckb-probe 挂载, PID=2106838 (--slow --threshold 1000 --interval 5)\n[05:30:27] 等待 ANOMALY DETECTED (最多 1800 秒)...\n[06:00:28] 超时 (slow 模式不产生 ANOMALY DETECTED 标记)\n[06:00:31] 恢复原始 db-options\n[06:00:31] 完成\n9.2.6 Case 2 结论
\n- \n
- aggressive 调优成功制造了压缩风暴：GET 延迟从正常 ~200us 飙升至平均 6,988us (35x) \n
- ckb-probe 在 30 分钟内成功捕获 6,112 个慢操作，零事件丢失 \n
- 慢操作几乎全部为 GET (99.7%)，因为压缩占用磁盘 I/O 导致读放大 \n
- 脚本未检测到
ANOMALY DETECTED标记，这是因为--slow模式不产生该标记（该标记仅在--json模式下输出）。数据本身是完整有效的 \n - db-options 已在测试结束后自动恢复 \n
\n
十、后续计划
\nWeek 7：优化加固与结项准备
\n- \n
- JSON 全局输出 — 确保所有模式的 JSON 输出格式统一、字段完整 \n
- 制作完整演示说明文档 — 结构化的文字演示报告（Markdown），覆盖五个演示流程步骤，附完整终端输出和说明 \n
Week 8：发布与结项
\n- \n
- 中英双语文档定稿 — 各类文档最终审校 \n
- GitHub v0.1.0 Release — 打 tag、写 release notes、附带预编译 binary \n
- 结项报告 — 按 main_proj.md 规范整理全部交付物、验收清单、已知限制 \n
- 社区分享 — 最终月度报告提交 \n
Hi duongja,
\nThanks for the submission. The proposal aligns well with Spark 2026’s technical focus on Fiber Network and UDT-based payments, and the fact that you already have a working multi-hop RUSD payment through testnet relays is a strong differentiator. Before I bring this to the committee for formal review, I’d like you to revise a few sections so the evaluation can move efficiently.
\n- \n
- \n
Add a “How to Verify” section. Starting from 2026, every Spark proposal is required to include a low-cost, reproducible verification scheme. For Dular specifically, please describe how a committee member or community reviewer can independently confirm: the phone-to-pubkey registry is live, the M-Pesa STK Push and B2C flows actually settle end-to-end, and the 30-user pilot data is real. Public demo URLs, signed transaction hashes, screen recordings, or a sandbox the reviewer can poke are all acceptable. This is the single most important addition.
\n \n - \n
Provide a line-item funding breakdown. Spark’s standard ceiling is $1,000. The $2,000 tier is reserved for projects with exceptional impact, so the justification needs to be concrete. Please upgrade the current per-milestone summary with itemized costs: Daraja API fees (sandbox vs production), Africa’s Talking USSD per-session pricing × estimated sessions, KES float for cash-in/cash-out reconciliation during the pilot, user incentives or transport reimbursement for the 30 testers, and any developer-hour estimate you’d like to include.
\n \n - \n
Payment currency. The committee recently decided that, currently, Spark grants will be disbursed in 100% CKB only (no USDI option for now). If this materially affects your numbers, adjust the breakdown accordingly.
\n \n - \n
Address two execution risks up front. First, Safaricom Daraja Production approval typically takes 4–8 weeks and usually requires a Kenyan legal entity or local partner, especially for B2C. Please clarify whether you already hold production credentials, hold sandbox only, or have a partner arrangement in Kenya. Second, please describe your on-the-ground resources for recruitment, vernacular support, and field testing. The 2025 cycle had a project that delivered the technical MVP cleanly but was penalized 10% because the user-testing portion was thin, so this is a recurring committee concern.
\n \n - \n
Optional but encouraged. Add a verifiable checkpoint at the end of each milestone (a public release tag, a recorded demo, or a published tx hash). For the existing proposal, appreciate sharing the transaction hash of the successful multi-hop RUSD payment in the proposal itself. This both strengthens the credibility of the application and feeds directly into the “How to Verify” framework above.
\n \n
Looking forward to the revised draft.
\nBest,
\n", "like_count": 0, "quote_count": 0 }, { "post_id": 24046, "post_number": 3, "topic_id": 10212, "topic_title": "Spark Program | Dular", "topic_slug": "spark-program-dular", "author": "duongja", "created_at": "2026-04-27T08:45:49.720000+00:00", "updated_at": "2026-04-27T08:45:49.720000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/spark-program-dular/10212/3", "content_text": "Hi @zz_tovarishch ,\nThanks for the detailed feedback, I’ve updated the proposal to address all the points you raised.\nAdded a comprehensive “How to Verify” section with reproducible checks for the phone-to-pubkey registry, M-Pesa STK Push/B2C flows, and pilot data (including public endpoints, transaction hashes, and demo recordings).\nExpanded the funding breakdown into full line-item detail, including USSD costs (Africa’s Talking), M-Pesa fees, pilot float, user incentives, and developer time.\nClarified CKB-only disbursement and added a mitigation strategy for exchange rate risk.\nIncluded an Execution Risk & Mitigation section confirming that Daraja production credentials are already secured and outlining local, on-the-ground user recruitment and testing capacity.\nAdded verifiable checkpoints per milestone .\nLet me know if there’s anything else you’d like refined before committee review.\nBest,\nduongja", "content_html": "Hi @zz_tovarishch ,
\nThanks for the detailed feedback, I’ve updated the proposal to address all the points you raised.
\n- \n
- Added a comprehensive “How to Verify” section with reproducible checks for the phone-to-pubkey registry, M-Pesa STK Push/B2C flows, and pilot data (including public endpoints, transaction hashes, and demo recordings). \n
- Expanded the funding breakdown into full line-item detail, including USSD costs (Africa’s Talking), M-Pesa fees, pilot float, user incentives, and developer time. \n
- Clarified CKB-only disbursement and added a mitigation strategy for exchange rate risk. \n
- Included an Execution Risk & Mitigation section confirming that Daraja production credentials are already secured and outlining local, on-the-ground user recruitment and testing capacity. \n
- Added verifiable checkpoints per milestone . \n
Let me know if there’s anything else you’d like refined before committee review.
\nBest,
\nduongja
[Weekly Update] Fiber Link (Milestone 3) / 周报(里程碑 3)
\nQuick update for this week:
\nThe public demo has now been running for 18 days, and the core functionality has stayed stable overall.
\nDuring this time, we found and fixed a few operations-side experience issues. After a bit more observation and verification, we will deliver Milestone 3.
\n\n
本周更新：
\nFiber Link 的 public demo 到现在已经运行了 18 天，核心功能整体比较稳定。
\n这段时间里，我们发现并修复了几个运维侧的体验问题。再经过一段时间的观察和验证后，我们将交付 Milestone 3。
", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10203, "title": "CellFabric: A UTXO-Generation and Inter-Protocol Composition Layer for CKB", "slug": "cellfabric-a-utxo-generation-and-inter-protocol-composition-layer-for-ckb", "url": "https://talk.nervos.org/t/cellfabric-a-utxo-generation-and-inter-protocol-composition-layer-for-ckb/10203", "created_at": "2026-04-23T04:52:02.945000+00:00", "last_posted_at": "2026-04-27T01:31:47.844000+00:00", "category_id": 49, "tags": [ "CKB", "DAG", "Graph" ], "posters": [ "Original Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24042, "post_number": 4, "topic_id": 10203, "topic_title": "CellFabric: A UTXO-Generation and Inter-Protocol Composition Layer for CKB", "topic_slug": "cellfabric-a-utxo-generation-and-inter-protocol-composition-layer-for-ckb", "author": "phroi", "created_at": "2026-04-27T00:48:01.381000+00:00", "updated_at": "2026-04-27T00:48:01.381000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/cellfabric-a-utxo-generation-and-inter-protocol-composition-layer-for-ckb/10203/4", "content_text": "Hey Arthur, the CellScript / CellFabric split reads much clearer now! I think that part is mostly resolved: CellFabric makes sense as a UTXO-generation / inter-protocol coordination surface, not as a new ledger or transaction-DAG L2.\nCellScript - A DSL for Cell-Based Contracts\nCellScript: authoring and compiling individual cell protocols, including ProofPlan metadata that makes guarantees, coverage, and assumptions explicit;\nCellFabric: a higher inter-protocol intent and composition layer, describing how different protocols coordinate with each other before final CKB settlement.\nOne concrete positive is that the current CellScript code already supports some of the single-protocol side you describe. receipt is a first-class cell type, claim only accepts receipt values, and read_ref lowers through Source::CellDep. That already supports “compose around existing cells” without implying a new settlement layer.\nArthurZhang:\nIdeally, conflict keys should not be arbitrary strings asserted by the intent submitter. They should be recomputable from the protocol’s declared policy, CellScript metadata, or a verifier interface.\nThis is the one part where I still want to hear your view. The repo already exposes per-action touches_shared, read_refs, verifier_obligations, and transaction_runtime_input_requirements, and cellc scheduler-plan can derive simple shared-state conflicts from that metadata. But that still reads to me as intra-module compiler metadata, not yet a standard inter-protocol conflict-key or verifier surface.\nThe same semantics_preserving_claim says stateful lowering is represented in metadata and asm but is “not yet a proved schema decoder/verifier”. Structured WitnessArgs / Source views are still planned for v0.14, and the ProofPlan audit surface with trigger/scope/coverage and builder_assumption reporting is still planned for v0.15.\nSo my current read is: the split is right, the single-protocol foundation is already in the code, and the cross-protocol conflict-key / verifier surface still sits on the roadmap.\nI was wondering: How do you see token standards and the wider inter-protocol interface evolving from here? The small Token / MintAuthority base already in the repo makes that especially interesting to me.\nPhroi", "content_html": "Hey Arthur, the CellScript / CellFabric split reads much clearer now! I think that part is mostly resolved: CellFabric makes sense as a UTXO-generation / inter-protocol coordination surface, not as a new ledger or transaction-DAG L2.
One concrete positive is that the current CellScript code already supports some of the single-protocol side you describe. receipt is a first-class cell type, claim only accepts receipt values, and read_ref lowers through Source::CellDep. That already supports “compose around existing cells” without implying a new settlement layer.
This is the one part where I still want to hear your view. The repo already exposes per-action touches_shared, read_refs, verifier_obligations, and transaction_runtime_input_requirements, and cellc scheduler-plan can derive simple shared-state conflicts from that metadata. But that still reads to me as intra-module compiler metadata, not yet a standard inter-protocol conflict-key or verifier surface.
The same semantics_preserving_claim says stateful lowering is represented in metadata and asm but is “not yet a proved schema decoder/verifier”. Structured WitnessArgs / Source views are still planned for v0.14, and the ProofPlan audit surface with trigger/scope/coverage and builder_assumption reporting is still planned for v0.15.
So my current read is: the split is right, the single-protocol foundation is already in the code, and the cross-protocol conflict-key / verifier surface still sits on the roadmap.
\nI was wondering: How do you see token standards and the wider inter-protocol interface evolving from here? The small Token / MintAuthority base already in the repo makes that especially interesting to me.
Phroi
", "like_count": 0, "quote_count": 1 }, { "post_id": 24043, "post_number": 5, "topic_id": 10203, "topic_title": "CellFabric: A UTXO-Generation and Inter-Protocol Composition Layer for CKB", "topic_slug": "cellfabric-a-utxo-generation-and-inter-protocol-composition-layer-for-ckb", "author": "ArthurZhang", "created_at": "2026-04-27T01:14:07.607000+00:00", "updated_at": "2026-04-27T01:16:36.623000+00:00", "reply_to_post_number": 4, "url": "https://talk.nervos.org/t/cellfabric-a-utxo-generation-and-inter-protocol-composition-layer-for-ckb/10203/5", "content_text": "Thanks Phroi.\nI agree that the current CellScript metadata is still mostly intra-protocol compiler metadata. It exposes useful raw material : read_refs, touches_shared, verifier obligations, runtime input requirements, receipts, and so on, but it is not yet a stable CellFabric-level conflict-key or verifier-interface standard.\nI also agree that conflict keys should not be arbitrary strings asserted by the intent submitter. At most, they can be hints.\nThe meaningful key should eventually be derivable or checkable from protocol policy, script args, cell schema, CellScript metadata, or a verifier interface.\nThat said, I want to be careful about scope. I probably do not have the bandwidth to design the full CellFabric conflict-key / verifier-interface layer in the current CellScript sprint. My near-term focus is still to make the single-protocol side safer and more inspectable first.\nSo my rough layering is:\nCellScript now / near term: expose the raw materials clearly;\nv0.14/v0.15: make trigger, scope, reads, coverage, enforcement, and builder assumptions explicit through ProofPlan;\nCellFabric later: decide which parts are stable enough to become inter-protocol conflict keys, verifier interfaces, and token/composition standards.\nThe token / MintAuthority example may indeed be a good first narrow domain for that later work. But I would not want to overclaim that it is already designed.\nYour suggestions have been consistently useful for me in sharpening the boundary here. For now I probably need to let the design breathe a little and spend more time building. Maybe at some point, once the lower layers are more solid, we could try some application-level collaboration to stress-test how strong the CellScript / CellFabric split really is.", "content_html": "Thanks Phroi.
\nI agree that the current CellScript metadata is still mostly intra-protocol compiler metadata. It exposes useful raw material : read_refs, touches_shared, verifier obligations, runtime input requirements, receipts, and so on, but it is not yet a stable CellFabric-level conflict-key or verifier-interface standard.
I also agree that conflict keys should not be arbitrary strings asserted by the intent submitter. At most, they can be hints.
\nThe meaningful key should eventually be derivable or checkable from protocol policy, script args, cell schema, CellScript metadata, or a verifier interface.
\nThat said, I want to be careful about scope. I probably do not have the bandwidth to design the full CellFabric conflict-key / verifier-interface layer in the current CellScript sprint. My near-term focus is still to make the single-protocol side safer and more inspectable first.
\nSo my rough layering is:
\n- \n
- CellScript now / near term: expose the raw materials clearly; \n
- v0.14/v0.15: make trigger, scope, reads, coverage, enforcement, and builder assumptions explicit through ProofPlan; \n
- CellFabric later: decide which parts are stable enough to become inter-protocol conflict keys, verifier interfaces, and token/composition standards. \n
The token / MintAuthority example may indeed be a good first narrow domain for that later work. But I would not want to overclaim that it is already designed.
Your suggestions have been consistently useful for me in sharpening the boundary here. For now I probably need to let the design breathe a little and spend more time building. Maybe at some point, once the lower layers are more solid, we could try some application-level collaboration to stress-test how strong the CellScript / CellFabric split really is.
", "like_count": 0, "quote_count": 0 }, { "post_id": 24044, "post_number": 6, "topic_id": 10203, "topic_title": "CellFabric: A UTXO-Generation and Inter-Protocol Composition Layer for CKB", "topic_slug": "cellfabric-a-utxo-generation-and-inter-protocol-composition-layer-for-ckb", "author": "phroi", "created_at": "2026-04-27T01:31:47.844000+00:00", "updated_at": "2026-04-27T01:31:47.844000+00:00", "reply_to_post_number": 5, "url": "https://talk.nervos.org/t/cellfabric-a-utxo-generation-and-inter-protocol-composition-layer-for-ckb/10203/6", "content_text": "That makes sense, Happy Building!!\nPhroi", "content_html": "That makes sense, Happy Building!! ![\":hugs:\"](\"https://talk.nervos.org/images/emoji/apple/hugs.png?v=15\" "\\":hugs:\\"")
Phroi
", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10187, "title": "[CN/EN] CTO - 去中心化的链上时间预言机 Decentralized On-Chain Time Oracle", "slug": "cn-en-cto-decentralized-on-chain-time-oracle", "url": "https://talk.nervos.org/t/cn-en-cto-decentralized-on-chain-time-oracle/10187", "created_at": "2026-04-18T21:04:28.521000+00:00", "last_posted_at": "2026-04-26T23:54:54.412000+00:00", "category_id": 45, "tags": [ "CKB", "dapp" ], "posters": [ "Original Poster", "Frequent Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24041, "post_number": 5, "topic_id": 10187, "topic_title": "[CN/EN] CTO - 去中心化的链上时间预言机 Decentralized On-Chain Time Oracle", "topic_slug": "cn-en-cto-decentralized-on-chain-time-oracle", "author": "phroi", "created_at": "2026-04-26T23:54:54.412000+00:00", "updated_at": "2026-04-26T23:54:54.412000+00:00", "reply_to_post_number": 2, "url": "https://talk.nervos.org/t/cn-en-cto-decentralized-on-chain-time-oracle/10187/5", "content_text": "Hey Hanssen, interesting idea!! I looked through the repo after reading this. CTO keeps the lock hash unchanged and only accepts newer timestamps proven by header_deps. That does look like a rotating on-chain time source to me. Just the red-envelope example seems to overstate what the published code proves.\nHanssen:\nThe rules are straightforward: recipients must claim the envelope within 24 hours; otherwise, only the sender can reclaim it.\nFor that quoted 24-hour claim, I still see three limits in the published repo:\nThe full group is not proved on chain. The design doc says the updater should include the other N - 1 group cells. The script only counts same-type cell_deps, but CKB allows the cell being updated to also appear as a cell_dep. So the count can pass without proving the other live group cells are actually present.\nCurrent time is still a consumer choice. Consumers can select any cell from the group, the SDK sorts newest first, and the quick start treats group.cells[0] as the latest timestamp. So latest is still a client-side convention.\nFreshness to the network tip is still off chain. The contract only checks the provided header_deps, while the supplier command calls supplyTime() and supplyTime() uses getTipHeader() off chain.\nCTO already gives a fresher shared time reference than arbitrary per-tx header_deps.\nFor stricter deadline logic, a two-tx pattern can prove more. iCKB already uses that staged shape for deposits: phase 1 records the deposit, and phase 2 uses the deposit block header to transform the receipt into iCKB.\nKeep up the Great Work, Phroi", "content_html": "Hey Hanssen, interesting idea!! I looked through the repo after reading this. CTO keeps the lock hash unchanged and only accepts newer timestamps proven by header_deps. That does look like a rotating on-chain time source to me. Just the red-envelope example seems to overstate what the published code proves.
For that quoted 24-hour claim, I still see three limits in the published repo:
\n- \n
- \n
The full group is not proved on chain. The design doc says the updater should include the other
\nN - 1group cells. The script only counts same-typecell_deps, but CKB allows the cell being updated to also appear as acell_dep. So the count can pass without proving the other live group cells are actually present. \n - \n
\nCurrent timeis still a consumer choice. Consumers can select any cell from the group, the SDK sorts newest first, and the quick start treatsgroup.cells[0]as the latest timestamp. Solatestis still a client-side convention. \n - \n
Freshness to the network tip is still off chain. The contract only checks the provided
\nheader_deps, while the supplier command callssupplyTime()andsupplyTime()usesgetTipHeader()off chain. \n
CTO already gives a fresher shared time reference than arbitrary per-tx header_deps.
For stricter deadline logic, a two-tx pattern can prove more. iCKB already uses that staged shape for deposits: phase 1 records the deposit, and phase 2 uses the deposit block header to transform the receipt into iCKB.
\nKeep up the Great Work, Phroi
", "like_count": 0, "quote_count": 1 } ] } ] }