![\":white_check_mark:\"](\"https://talk.nervos.org/images/emoji/apple/white_check_mark.png?v=15\" "\\":white_check_mark:\\"")
Differential Testing Framework for ckb-vm
\nImplemented a differential test framework for ckb-vm. This provides a stronger foundation for validating optimizations and future architecture changes: GitHub - yuqiliu617/ckb-vm-contrib at differential-test · GitHub
\nCKB DAO Treasury Design & Voting Research
\nresearch on the CKB DAO Treasury design and voting settlement, with multiple directions under active discussion:
\nExplores a governance model where voting power is bound to Nervos DAO deposits, while proposal state, voting records, and tally data are maintained off-chain and committed on-chain through verifiable state roots.
\nThis direction focuses on improving scalability while keeping governance state verifiable.
\nBuilt an experimental MVP to validate core DAO Treasury workflows and voting-related transaction construction. Details see: ckb/dao-treasury at dao-treasury · chenyukang/ckb · GitHub
\nExplores a rollup-inspired approach for voting settlement, where voting data is batched and compressed into verifiable state updates.
\nThis direction focuses on improving settlement efficiency while preserving on-chain verifiability under CKB’s UTXO model.
\nKey Question Identified & Follow-Up Research
\nHow to handle on-chain settlement for the voting process. Continued follow-up research based on the design discussions:
\nCryptography & Performance
\nA series of optimizations were merged into ckb-vm to improve performance on ARM64-based hardware:
\nThis further prepares the network for post-quantum cryptographic standards: GitHub - XuJiandong/signatures at use-opt-shake128 · GitHub
\nInfra & Tooling
\nSKILL.md for AI agents in ckb-debugger, making it easier for agents to assist devs in debugging CKB scripts.: Add SKILL.md for AI agents ckb-standalone-debugger#202Networking & Connectivity
\nThe underlying P2P network Tentacle, is moving closer to full QUIC support. QUIC (built on UDP) provides faster handshake times and better resilience against connection migration compared to standard TCP.
\nCore Maintenance & Release Prep
\nNetworking
\nGovernance PoC
\nThis looks like a valuable direction. A further verified CKB-VM foundation would strengthen the whole CKB scripting stack. Proving instruction-level equivalence against the Sail RISC-V specification feels like the kind of deep infrastructure work that may not be immediately visible to application developers, but i reckon it compounds over time.
\nBest of luck.
", "like_count": 0, "quote_count": 0 }, { "post_id": 24062, "post_number": 4, "topic_id": 10214, "topic_title": "Spark Program | CKB-VM Sail Formal Verification — Proving CKB-VM RISC-V Instruction Equivalence via Sail Specification and Coq Theorem Prover / CKB-VM Sail 形式化验证 — 基于 Sail 规范与 Coq 定理证明器的 CKB-VM RISC-V 指令等价性证明", "topic_slug": "spark-program-ckb-vm-sail-formal-verification-proving-ckb-vm-risc-v-instruction-equivalence-via-sail-specification-and-coq-theorem-prover-ckb-vm-sail-sail-coq-ckb-vm-risc-v", "author": "xingtianchunyan", "created_at": "2026-04-29T02:00:41.314000+00:00", "updated_at": "2026-04-29T02:00:41.314000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/spark-program-ckb-vm-sail-formal-verification-proving-ckb-vm-risc-v-instruction-equivalence-via-sail-specification-and-coq-theorem-prover-ckb-vm-sail-sail-coq-ckb-vm-risc-v/10214/4", "content_text": "@TinyuengKwan 你好，感谢提交 ckb-vm-sail-verify 的提案。这个方向非常关键：CKB-VM 是 CKB 的执行层安全基石，而你提出的 “Sail（官方规范）+ Coq（形式化证明）+ 差分测试（工程验证）” 的双轨方案，也能看出你在 Sail/ACT 生态中有相对稀缺的一手经验与工程积累。\n需要说明的是，该项目已明显超出星火计划的支持范围（以 低门槛、快节奏 的方式帮助社区开发者启动小型原型项目）。如果你仍希望向委员会正式递交该项目，那么在提交委员会正式评审前，我个人建议你按 Spark 的预审要求补充/澄清以下几点信息，让评审能更快收敛到“本期资助是什么、怎么验收、验收失败影响什么”。\n1) 验证方案（How to Verify）——写成“可复现步骤 + 通过/失败标准 + 影响面（blast radius）”\n你在主贴里讲清楚了技术架构与实现设想，但仍缺少一段面向评审者/社区的 “低成本、可重复” 的验收章节。建议新增一个独立章节 How to Verify（或在 repo 内提供 VERIFICATION.md），至少包含：\n1.1 可复现步骤（评审者照着做即可）\n建议最少做到以下级别：\n环境一键化：提供 Docker/Nix/脚本，确保在干净 Linux 环境下可以复现（并 pin 关键依赖版本：Sail/Coq/OPAM/Rust 等）。\n生成与构建：从 sail-riscv 生成 Coq 产物的命令（以及预期输出在哪里）。\n证明检查：如何运行 Coq proof check（命令 + 预期输出）。\n差分测试：如何运行 diff-test（命令 + 测试集来源 + mismatch 报告格式）。\n证据发布位置：每个里程碑的证据放在哪里（release tag / CI artifact / 报告 / 日志）。\n1.2 通过/失败标准（必须可判定）\n形式化验证最大的风险，是“最后没有一个可客观判定的结果”。请明确写清：\n本期承诺证明/验证的指令子集是什么（例如 RV64I 的某些指令集合；或只覆盖 CKB-VM 的某个 VERSION 模式——你提到 VERSION2 only 的倾向，需要明确）。\n对 Coq 证明的要求：是否允许 admit？若允许，允许到什么边界（建议明确为“0 admitted”或“admitted 上限”）。\n差分测试的要求：覆盖哪些测试集（riscv-tests / riscv-arch-test / 自建 corpus），以及遇到 mismatch 的处理策略（“发现问题即成果” vs “必须修到一致才算通过”）。\n1.3 影响面（blast radius）与“保证边界”\n由于 CKB-VM 属于执行层安全边界，请你在文档中非常明确地写清：\n保证了什么：例如“对某版本/某子集/某模型假设下的语义等价”。\n没有保证什么：例如 MOP 扩展、cycle 计费、syscall/ECALL 语义差异、flat 4MB memory model 的限制、并发/原子指令的模型化边界等。\n如果外部误解为“全量等价/全链安全已证明”，可能造成的误用风险是什么，以及你准备如何在 README/报告中避免过度解读。\n2) 结项后的维护计划（持续有效性）\n形式化验证的成果很容易因上游演进而失效。建议你补充：\n你承诺维护的窗口（例如覆盖到 ckb-vm 的哪些版本线；以及 sail-riscv 更新后的跟进方式）。\nCI 策略：是否会把 proof check + diff-test 做成持续集成（例如 weekly/nightly），并在 README 放 badge。\n交接方案：如果你后续无法维护，社区如何接手（依赖锁定、脚本、文档、最小复现路径）。\n3) 部署架构与安全性（供应链 / 可信边界 / 结果可审计性）\n该项目不是线上服务，但仍然有“可信边界”与“供应链安全”需要写清：\n工具链与依赖如何 pin 版本（OPAM/Coq/Sail 等），避免“换个时间/换台机器就跑不出来”。\n是否提供可重复构建说明（reproducible build）与产物校验方式（hash / release artifact）。\n对外发布时的“声明口径”：建议在最终报告中用一段固定文本写清适用范围与非目标（避免被当作全量安全证明）。\n请在针对以上建议优化后 @ 我一下，我们再把更新版本提交委员会进入正式评审流程。", "content_html": "@TinyuengKwan 你好，感谢提交 ckb-vm-sail-verify 的提案。这个方向非常关键：CKB-VM 是 CKB 的执行层安全基石，而你提出的 “Sail（官方规范）+ Coq（形式化证明）+ 差分测试（工程验证）” 的双轨方案，也能看出你在 Sail/ACT 生态中有相对稀缺的一手经验与工程积累。
需要说明的是，该项目已明显超出星火计划的支持范围（以 低门槛、快节奏 的方式帮助社区开发者启动小型原型项目）。如果你仍希望向委员会正式递交该项目，那么在提交委员会正式评审前，我个人建议你按 Spark 的预审要求补充/澄清以下几点信息，让评审能更快收敛到“本期资助是什么、怎么验收、验收失败影响什么”。
\n你在主贴里讲清楚了技术架构与实现设想，但仍缺少一段面向评审者/社区的 “低成本、可重复” 的验收章节。建议新增一个独立章节 How to Verify（或在 repo 内提供 VERIFICATION.md），至少包含：
建议最少做到以下级别：
\n形式化验证最大的风险，是“最后没有一个可客观判定的结果”。请明确写清：
\nadmit？若允许，允许到什么边界（建议明确为“0 admitted”或“admitted 上限”）。由于 CKB-VM 属于执行层安全边界，请你在文档中非常明确地写清：
\n形式化验证的成果很容易因上游演进而失效。建议你补充：
\nckb-vm 的哪些版本线；以及 sail-riscv 更新后的跟进方式）。该项目不是线上服务，但仍然有“可信边界”与“供应链安全”需要写清：
\n请在针对以上建议优化后 @ 我一下，我们再把更新版本提交委员会进入正式评审流程。
", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10212, "title": "Spark Program | Dular", "slug": "spark-program-dular", "url": "https://talk.nervos.org/t/spark-program-dular/10212", "created_at": "2026-04-26T16:35:20.268000+00:00", "last_posted_at": "2026-04-29T01:49:03.597000+00:00", "category_id": 49, "tags": [ "Spark-Program", "Submitted" ], "posters": [ "Original Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24061, "post_number": 4, "topic_id": 10212, "topic_title": "Spark Program | Dular", "topic_slug": "spark-program-dular", "author": "xingtianchunyan", "created_at": "2026-04-29T01:49:03.597000+00:00", "updated_at": "2026-04-29T01:49:36.043000+00:00", "reply_to_post_number": 3, "url": "https://talk.nervos.org/t/spark-program-dular/10212/4", "content_text": "@duongja 你好，感谢你提交 Dular 项目提案，并根据预审建议补充了 How to Verify、预算拆分与风险说明等内容。整体方向（Fiber + RUSD/UDT + 真实在地试点）很契合 Spark 对“可落地、可验证”的资助导向。\n本项目当前状态暂定为 Pending，并非否定项目价值，而是表示：在进入下次正式评审/投票前，我们还需要你补齐两类“可验证凭据”，并纠正提案中关于 CKB 发放与汇率折算机制的表述，以避免后续沟通成本与验收争议。\n1) 请补充：Daraja 生产环境凭据的可视化证据。\n你已声明持有 STK Push + B2C 生产凭据，请通过私信发我一张 Daraja Developer Portal 的后台截图（API Key 字段可全部打码，但需保留 Production 环境标识、App 名称、创建时间）。这一步用于委员会内部尽调，不会公开。委员会在验证后，会在本帖中发布一条信息，说明已经核验。\n2) 请补充：现有 multi-hop RUSD payment 的可核验证据。\n为了让委员会/社区能低成本持续复核你的技术交付（而不是只在结项时“补材料”），请在主楼直接给出对应的 Fiber payment hash 或相关 CKB testnet tx hash，并简要说明 Fiber payment hash 与 CKB L1 explorer 的对应关系（避免读者误以为每笔 Fiber 支付都能在 CKB explorer 直查）。\n3) 关于 CKB 发放与汇率风险：请修正提案中的流程假设，并按 Spark 口径重写\n你在提案的 “CKB Disbursement & Exchange Rate Risk” 中写到：\n“The CKB amount per milestone will be calculated at the market rate on the day of disbursement, per standard Spark procedure.”\n这里需要更正：Spark 的标准口径不是“每次发放按当日汇率重新折算 CKB”。\nSpark 2026 资金口径：\n发放币种：当前周期 Spark 资助仅支持100% 以 CKB 形式发放。\n折算口径（锁定）：委员会通常以 USD 口径沟通资助额度以便横向对比；但若以 CKB 发放，则会在项目审批通过时点以当时参考汇率折算并确定该项目的 CKB 总额，并在对外决议/公告中公示。后续发放以约定的 CKB 数额为基准执行，不随每次发放当日价格重新折算。\n汇率风险：审批通过后至实际支出期间，CKB 价格波动导致的购买力变化风险由提案申请人/团队自行承担，这是CKB生态相关grants的惯例。对存在法币硬成本的项目，建议在收到款项后及时换汇/锁定硬成本，并在预算中清晰区分“硬成本 vs 人力成本”。\n下一步\n请根据上述内容优化提案后，在本帖回复“已更新”并@xingtianchunyan，并标明你更新了主楼的哪些小节/新增了哪些链接或附件。委员会会在信息齐备后尽快推进正式评审流程。\n祝好，\n行天\n代表星火计划委员会", "content_html": "@duongja 你好，感谢你提交 Dular 项目提案，并根据预审建议补充了 How to Verify、预算拆分与风险说明等内容。整体方向（Fiber + RUSD/UDT + 真实在地试点）很契合 Spark 对“可落地、可验证”的资助导向。
\n本项目当前状态暂定为 Pending，并非否定项目价值，而是表示：在进入下次正式评审/投票前，我们还需要你补齐两类“可验证凭据”，并纠正提案中关于 CKB 发放与汇率折算机制的表述，以避免后续沟通成本与验收争议。
\n你已声明持有 STK Push + B2C 生产凭据，请通过私信发我一张 Daraja Developer Portal 的后台截图（API Key 字段可全部打码，但需保留 Production 环境标识、App 名称、创建时间）。这一步用于委员会内部尽调，不会公开。委员会在验证后，会在本帖中发布一条信息，说明已经核验。
\n为了让委员会/社区能低成本持续复核你的技术交付（而不是只在结项时“补材料”），请在主楼直接给出对应的 Fiber payment hash 或相关 CKB testnet tx hash，并简要说明 Fiber payment hash 与 CKB L1 explorer 的对应关系（避免读者误以为每笔 Fiber 支付都能在 CKB explorer 直查）。
\n你在提案的 “CKB Disbursement & Exchange Rate Risk” 中写到：
\n\n\n“The CKB amount per milestone will be calculated at the market rate on the day of disbursement, per standard Spark procedure.”
\n
这里需要更正：Spark 的标准口径不是“每次发放按当日汇率重新折算 CKB”。
\nSpark 2026 资金口径：
\n请根据上述内容优化提案后，在本帖回复“已更新”并@xingtianchunyan，并标明你更新了主楼的哪些小节/新增了哪些链接或附件。委员会会在信息齐备后尽快推进正式评审流程。
\n祝好，
\n行天
\n代表星火计划委员会
Update: Automatic Finalization Bot live on testnet
Following up on the v1.1 update above: the bot is deployed and end-to-end verified on testnet as of yesterday (2026-04-27). The platform is now fully trustless on testnet, campaigns flow create → pledge → deadline → distribution with zero manual intervention from anyone (creator, backer, or platform operator).
What the bot does (each polling cycle, every 10s):
\nActive status → submits permissionless finalizeCampaign tx (Success if total pledged ≥ goal, Failed otherwise)permissionlessRelease tx (funds → creator)permissionlessRefund tx (funds → backer)Architecture:
\nFinalizationBot class integrated into the existing indexer process (no separate service)BOT_PRIVATE_KEY env var is unset, the indexer runs normally and users can still trigger finalize/release/refund manually from the UIE2E verification on testnet (2026-04-27):
\n| Path | \nGoal | \nPledged | \nOutcome | \n
|---|---|---|---|
| Success | \n200 CKB | \n250 CKB | \nBot auto-finalized as Success → auto-released to creator (release tx 0x564c6d7a...) | \n
| Failed | \n10,000 CKB | \n100 CKB | \nBot auto-finalized as Failed → auto-refunded to backer (refund tx 0x54fd7e40...) | \n
Total time from deadline to full distribution: ~30 seconds.
\nTry it yourself: https://decentralized-kickstarter-kappa.vercel.app/ create a campaign with a short deadline, pledge from a second JoyID account, and watch the bot do its thing.
\nWhat’s next:
\n本周承接第六周“多轮可持续交互”阶段的工作，重点从“机制已经具备”推进到“关键路径真正闭环、且后续可以被稳定评测”。核心目标有四个：
\ndiscourse_query / github_search 从协议层定义走到图执行主路径可调用。日志治理与诊断视图补齐
\n已对常见第三方库日志进行了统一降噪处理，补充了 quiet_loggers 与 third_party_level 控制项，降低了测试和运行期的无关日志干扰。同时把工具执行过程的摘要信息接入到图状态与 trace_summary 中，使得一次回答至少可以追踪到“执行了哪些 tool、各自成功/为空/失败”的最小诊断视图，而不再只能看到最终回答文本。
工具执行闭环推进到运行时主路径
\n本周把 discourse_query 与 github_search 从“schema 已存在但主路径未接通”的状态推进到了可被 RetrieverPlanner -> RetrievalExecutor -> ToolRuntime 实际调用的状态。具体包括：
RetrieverPlanner 归一化阶段已允许这两个 tool 保留，不再强制回退到 qdrant_search。ToolRuntime 为二者补齐了 handler。execute_tool，不再为新增 tool 走特殊旁路逻辑。回答链路的可解释性继续增强
\n在原有“回答生成稳态与兜底能力增强”的基础上，本周补充了 tool 级别的错误码与执行摘要，使回答不仅能在失败时兜底，也能在 trace 中解释失败原因。例如工具执行异常会落到统一错误结构中，而不是静默吞掉。这样后续排查时，可以区分“模型答错”“检索为空”“工具执行异常”“预算截断”等不同问题来源。
多轮评测集第一版落地
\n已新增 evaluation/week7_multiturn_eval.jsonl 作为第一版多轮 benchmark 输入集，并新增配套的 loader / validator，确保每条 case 至少满足：
case_id；success_criteria；expected_signals 用于后续自动比对。平台稳定性回归增强
\nTelegram / Discord 两端都补充了：
Week 7 相关回归验证通过
\n本周相关测试，结果为：
\n78 passed, 1 warning
\n覆盖范围包括 tool runtime、graph executor、logging system、Discord/TG runtime 以及 evaluation dataset 验证。
本周最重要的新工作，不是单纯“加了几条样例”，而是把后续多轮评测的基本方法论先定下来。这里单独展开说明。
\n当前项目虽然已经具备多轮补参、反思分流、回答兜底等机制，但如果没有稳定 benchmark，任何关于“效果更好了”的结论都只能靠主观感受。尤其是多轮系统，很容易出现下面几类错觉：
\n因此本周没有直接上“评分 dashboard”，而是先做 benchmark 输入层。原因很简单：没有稳定输入，就没有稳定指标；没有稳定 case，任何分数都不可复现。
\n本周设计 benchmark 时，刻意没有把重点放在开放式知识问答上，而是围绕 Nervos Brain 当前最关键的系统能力来建样例。也就是说，这份 benchmark 的目标不是测试“模型懂不懂 CKB”，而是测试下面这些系统行为是否发生：
\nqdrant_search。换句话说，这份 benchmark 更像是“系统工作流 benchmark”，而不是“百科知识 benchmark”。
\n本周评测集按三类任务拆分：
\nsolution_recommendation（方案推荐）development_guidance（开发指导）troubleshooting（排障定位）这样拆分的原因是，这三类任务对应了系统最典型、也最容易出错的三种工作模式。
\nsolution_recommendation 关注的是：
development_guidance 关注的是：
troubleshooting 关注的是：
这三类覆盖面并不等于项目全部任务，但已经足够形成一个可复用的最小 benchmark 骨架。
\n本周不是只记录“问题文本”，而是给每条 case 设计了完整结构。单条 case 至少包含以下字段：
\ncase_id
\n用于保证 case 可追踪、可比对、可回归。
category
\n明确任务类别，避免把推荐类、开发类、排障类混在一起统计，导致指标失真。
conversation
\n必须是多轮结构，而不是单句问答。因为我们本周的目标就是验证多轮补参与恢复，而不是单轮回答质量。
expected_signals
\n这是本周 benchmark 设计里最关键的一层。它不直接判断最终答案“好不好”，而是先判断系统行为“有没有发生”。例如：
sdk_language；github_search；discourse_query 与 qdrant_search；success_criteria
\n这里记录的是回答级别的成功标准，例如：
expected_signals 的区别在于：前者看流程动作，后者看回答结果。expected_signals 和 success_criteria如果只有 success_criteria，我们只能看最后回答像不像“还行”，但无法知道它是通过正确流程得到的，还是偶然答对的。
\n如果只有 expected_signals，我们又只能知道系统“做了动作”，但不能判断最终产出的答案是否真的可用。
所以本周采用“双层判定”思路：
\n第一层：流程层 benchmark
\n检查有没有正确 ask_user、有没有正确选 tool、有没有沿线程继续执行。
第二层：回答层 benchmark
\n检查最终回答是否引用充分、是否尊重约束、是否满足任务目标。
这两层拆开之后，后面出现 bad case 时就能更快定位：
\n本周这 6 条样例不是随机写出来的，而是围绕当前系统最值得验证的机制构造出来的：
\n推荐类样例
\n用来测试用户目标在第二轮收缩后，推荐路径是否跟着变化。
\n例如从“我想做 demo”进一步细化到“前端集成、JS/TS”。
开发指导类样例
\n用来测试系统是否会在缺语言/版本时追问，并在得到补参后输出更贴近实际工程的步骤或示例来源。
排障类样例
\n用来测试系统在日志不充分、版本冲突、文档与代码不一致时，是否会优先保守地继续收集证据，而不是直接“拍脑袋诊断”。
本质上，这些 case 优先覆盖的是“高频失败模式”，而不是“知识点覆盖率”。这也是第一版 benchmark 更适合工程迭代的原因。
\n虽然本周还没有把完整的自动评分 runner 做出来，但流程已经定型，后续可以直接接上：
\njsonl benchmark。conversation。ask_user_questiontrace_summaryexpected_signals 做流程级检查。success_criteria 做结果级检查。后续如果继续扩展，这个流程可以自然演进成：
\n这是一个取舍问题。当前最缺的是“统一输入格式”，不是“再写一个复杂脚本”。
\n如果没有先把 case 结构稳定下来，直接写 runner 很容易导致：
\n所以本周先完成的是：
\n这样下一周只需要在这个基础上补 runner 和聚合输出，而不需要推倒重来。
\n本周也明确看到了第一版评测集的边界：
\nexpected_signals 还需要进一步细化成更严格、可自动比对的字段。因此，本周的 benchmark 工作更准确地说是“评测基线搭建完成”，而不是“评测体系完成”。
\n本周完成后，系统进入了一个新的阶段：
\ndiscourse_query / github_search 不再停留在协议层，而是进入了主路径可执行状态。trace_summary 已能表达最小工具执行信息，但还没有形成更结构化的统一诊断报告。![\":star:\"](\"https://talk.nervos.org/images/emoji/apple/star.png?v=15\" "\\":star:\\"")
-3 对话的复盘优先级，为后续结项报告沉淀真实用户评估数据。This week focused on turning the newly-added multi-turn mechanisms into a more testable and operationally reliable system. The four core goals were:
\ndiscourse_query / github_search from protocol-only definitions into the real runtime path.Logging and observability cleanup
\nAdded logger quieting controls and surfaced per-tool execution summaries into graph state and final trace summaries.
Runtime tool-loop coverage expanded
\ndiscourse_query and github_search now survive planner normalization, have dedicated runtime handlers, and align with timeout / idempotency / normalized execution behavior.
Better answer-path explainability
\nTool-level execution failures now map into clearer traceable error states instead of disappearing behind generic failures.
First multi-turn benchmark dataset landed
\nAdded a structured jsonl evaluation set plus loader/validator utilities, covering recommendation, development-guidance, and troubleshooting tasks.
Platform stability regression improved
\nAdded Discord/Telegram fallback-path and long-message segmentation tests to protect key runtime edge cases.
Week 7 regression validation
\nIn the nervous-brain mamba environment, the Week 7 related suite passed:
\n78 passed, 1 warning.
The most important outcome this week was not just “adding several examples”, but defining the first benchmark methodology for multi-turn system evaluation.
\nThis benchmark is designed to test system behavior rather than generic knowledge recall. Its purpose is to verify whether the system:
\nThe dataset is divided into three task types:
\nsolution_recommendationdevelopment_guidancetroubleshootingEach case contains:
\ncase_id for stable tracking;category for split-level reporting;conversation with at least two turns;expected_signals for workflow-level expectations;success_criteria for answer-level expectations.This two-layer design is deliberate:
\nThis separation matters because it lets us diagnose whether a failure came from planning, retrieval execution, or answer composition instead of treating every bad answer as the same class of issue.
\nThe benchmark construction strategy this week prioritized failure modes over topic breadth. The six seed cases were manually designed around the most important multi-turn risks:
\nThe intended evaluation flow is now clear:
\njsonl;expected_signals;success_criteria;This week intentionally stopped at dataset + validator rather than overbuilding a scoring runner too early. The reasoning was simple: without a stable input format, any automated benchmark script would be fragile and constantly changing. By fixing the dataset contract first, future runner and dashboard work can build on a stable base.
\n感谢您的建议，
\n我上周对系统做了基础的评测，并计划在这周拉一个Telegram试用群，邀请委员会的成员提前体验。同时欢迎在体验中提出建议，来帮助我改善系统。
\nBest regards.
", "like_count": 0, "quote_count": 0 }, { "post_id": 24059, "post_number": 33, "topic_id": 9995, "topic_title": "Spark Program | Nervos Brain - A Global Developer Onboarding Engine and Cross-Language Hub Powered by Agentic RAG", "topic_slug": "spark-program-nervos-brain-a-global-developer-onboarding-engine-and-cross-language-hub-powered-by-agentic-rag", "author": "zz_tovarishch", "created_at": "2026-04-28T14:03:27.779000+00:00", "updated_at": "2026-04-28T14:03:27.779000+00:00", "reply_to_post_number": 32, "url": "https://talk.nervos.org/t/spark-program-nervos-brain-a-global-developer-onboarding-engine-and-cross-language-hub-powered-by-agentic-rag/9995/33", "content_text": "Hi IrisNeko, 目前论坛已经接入AI翻译工具，Spark不再强制要求项目在Talk上沉淀的内容需采用双语版本\n期待项目的持续发展！", "content_html": "Hi IrisNeko, 目前论坛已经接入AI翻译工具，Spark不再强制要求项目在Talk上沉淀的内容需采用双语版本
\n期待项目的持续发展！
", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10204, "title": "Discontinuation of the DAO v1.1 project", "slug": "discontinuation-of-the-dao-v1-1-project", "url": "https://talk.nervos.org/t/discontinuation-of-the-dao-v1-1-project/10204", "created_at": "2026-04-23T05:07:43.422000+00:00", "last_posted_at": "2026-04-28T11:56:27.570000+00:00", "category_id": 40, "tags": [], "posters": [ "Original Poster, Most Recent Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster" ], "recent_posts": [ { "post_id": 24057, "post_number": 11, "topic_id": 10204, "topic_title": "Discontinuation of the DAO v1.1 project", "topic_slug": "discontinuation-of-the-dao-v1-1-project", "author": "_magicsheep", "created_at": "2026-04-28T11:56:27.570000+00:00", "updated_at": "2026-04-28T11:56:27.570000+00:00", "reply_to_post_number": 7, "url": "https://talk.nervos.org/t/discontinuation-of-the-dao-v1-1-project/10204/11", "content_text": "In consideration of Terry’s advice, the following updates are provided regarding the closure of DAO v1.1:\nPayment: The proposal team will retain the payment corresponding to the already‑delivered Milestone 1.\nCode: The code will remain open source and is accessible at this repository. A total of eight repositories encompass all code for the DAO v1.1 platform (excluding Web5 services, which are available here). Additionally, the community may access the open‑source vote auditor tool here.\nContract: The voting contract deployed on the mainnet has been terminated, whereas the testnet voting contract continues to operate. The did:ckb contracts remain active on both the mainnet and the testnet.\nServer: Servers supporting the current DAO v1.1 platform will be decommissioned shortly. Following this action, services for both the mainnet and the testnet will be terminated.\nDomain name: Domain resolution for ccfdao.dev and ccfdao.org will be terminated in the near future. Consequently, the documentation website at https://docs.ccfdao.org/ will also be shut down. However, relevant documentation can be found within the source code repository accessible here.\nThis marks the official conclusion of the DAO v1.1 project. The proposal team wishes to once again express its gratitude to all those who provided constructive feedback and support. May the community identify a suitable governance model at a future date. Thank you", "content_html": "In consideration of Terry’s advice, the following updates are provided regarding the closure of DAO v1.1:
\nPayment: The proposal team will retain the payment corresponding to the already‑delivered Milestone 1.
\nCode: The code will remain open source and is accessible at this repository. A total of eight repositories encompass all code for the DAO v1.1 platform (excluding Web5 services, which are available here). Additionally, the community may access the open‑source vote auditor tool here.
\nContract: The voting contract deployed on the mainnet has been terminated, whereas the testnet voting contract continues to operate. The did:ckb contracts remain active on both the mainnet and the testnet.
Server: Servers supporting the current DAO v1.1 platform will be decommissioned shortly. Following this action, services for both the mainnet and the testnet will be terminated.
\nDomain name: Domain resolution for ccfdao.dev and ccfdao.org will be terminated in the near future. Consequently, the documentation website at https://docs.ccfdao.org/ will also be shut down. However, relevant documentation can be found within the source code repository accessible here.
This marks the official conclusion of the DAO v1.1 project. The proposal team wishes to once again express its gratitude to all those who provided constructive feedback and support. May the community identify a suitable governance model at a future date. Thank you ![\":slight_smile:\"](\"https://talk.nervos.org/images/emoji/apple/slight_smile.png?v=15\" "\\":slight_smile:\\"")
Just came across this thread and found it interesting, so I’ll try to offer a few suggestions. I think the honest answer is:
\nFor tx inclusion proofs, the practical first step is likely not Flyclient, but exposing CKB’s existing get_transaction_proof / verify_transaction_proof path through Cellora. That lets clients verify that a transaction is committed under a particular block header, rather than merely trusting Cellora’s indexed result. This easily moves Cellora from a purely trusted indexer toward an inclusion-verifiable indexer.
For full historical / chain-tip trust minimisation, my narrower point is that I’m not sure there is a canonical Rust/TS wallet-side verifier package that app developers can just plug into today. So for Cellora v1, I’d probably keep MMR/Flyclient-style support as a later integration layer, not a hard requirement.
", "like_count": 0, "quote_count": 0 } ] } ] }