<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
  <title>CKB Talk Radar Daily Brief</title>
  <link>https://chainte.github.io/ckb-talk-radar/</link>
  <description>Daily Nervos Talk community briefing and latest active topics.</description>
  <language>zh-cn</language>
  <lastBuildDate>Sat, 02 May 2026 15:44:55 +0000</lastBuildDate>
  <atom:link href="https://chainte.github.io/ckb-talk-radar/rss.xml" rel="self" type="application/rss+xml" />
  <item>
    <title>CKB Talk Daily Brief - 2026-05-03</title>
    <link>https://chainte.github.io/ckb-talk-radar/</link>
    <guid>tag:ckb-talk-radar,2026-05-02:daily-brief</guid>
    <pubDate>Sat, 02 May 2026 17:42:11 +0000</pubDate>
    <description>## 今日发生了什么 CellScript 作者 ArthurZhang 预告了 0.13.1 补丁计划，重点聚焦本地开发体验和语法治理 [S01]。与此同时，ckb-probe 项目提交了 Week 7 周报，交付了 JSON 全局输出优化和完整的演示说明文档 [S06]。iCKB 合约方面，phroi 发布了新版安全审计报告，并同步整理了 DAO、header、witness 等开发构件，方便 CellScript 团队将其作为成熟度基准进行测试 [S07, S11, S13]。 ## 重点话题 **CellScript 0.13.1 补丁预览**：ArthurZhang 透露下周发布的 0.13.0 将确立"Action Model"（交易提出 Cell 转换、Action 验证转换是否被允许），0.13.1 则聚焦本地人体工程学和语法治理 [S01]。 **ckb-probe 项目进展**：Clair 发布了覆盖五个核心演示步骤的完整文字报告，所有输出均来自 CKB v0.204.0 测试网节点真实运行数据；同时 Week 7 周报显示 `--json --histogram` 联用输出已统一完成 [S05, S06]。 **iCKB 合约审计与构件整理**：phroi 发布了截至 2026-05-01 的安全复审报告，包含 Token 通胀等攻击场景的案例追踪；为配合 CellScript 集成，合并了 contracts PR #19，补充了本地可执行审查和重放测试用例 [S07, S08, S11, S13]。 **CKB PoP...</description>
  </item>
  <item>
    <title>CellScript 0.13 Preview: The Action Model and Syntax (1 posts)</title>
    <link>https://talk.nervos.org/t/cellscript-0-13-preview-the-action-model-and-syntax/10224</link>
    <guid>https://talk.nervos.org/t/cellscript-0-13-preview-the-action-model-and-syntax/10224#recent-1</guid>
    <pubDate>Sat, 02 May 2026 15:44:55 +0000</pubDate>
    <description>0.13.1 Patch Plan Preview Local Ergonomics and Syntax Governance 1. Background CellScript 0.13.0 set to be released next week will establish the new action model: A transaction proposes a Cell transformation. An action verifies whether that transformation is allowed. In this model, an action is not a method call, not an account-storage mutation, and not a runtime constructor. It is a typed verifier case: it names the input evidence, names the proposed output evidence, and proves the relationship between them. The 0.13 tutorial already frames this explicitly: signature direction describes transaction topology, where scopes proof obligations, move declares a state edge, require states...</description>
  </item>
  <item>
    <title>Building CKB PoP: a reusable participation primitive on CKB (1 posts)</title>
    <link>https://talk.nervos.org/t/building-ckb-pop-a-reusable-participation-primitive-on-ckb/10136</link>
    <guid>https://talk.nervos.org/t/building-ckb-pop-a-reusable-participation-primitive-on-ckb/10136#recent-1</guid>
    <pubDate>Sat, 02 May 2026 12:43:18 +0000</pubDate>
    <description>Over the last few days, I have completed a thorough investigation and fix for several critical bugs across the ckb-pop and ckb-pop-cli repositories. I tried to ensure protocol consistency and restore core functionality that was previously broken. Key Bug Fixes &amp; Improvements Confirmed Bugs The dob-badge on-chain contract expects 60-byte script args (including a unique 20-byte Type ID), but the CLI was only providing 40 bytes. This caused all CLI-initiated mints to fail. The open-window command signed a window proof but never registered it with the backend. This meant HMACs generated by the CLI could never be verified by the backend when an attendee tried to claim a badge. The frontend...</description>
  </item>
  <item>
    <title>Multi-Model Allocation Guide for Complex Tasks (2 posts)</title>
    <link>https://talk.nervos.org/t/multi-model-allocation-guide-for-complex-tasks/10226</link>
    <guid>https://talk.nervos.org/t/multi-model-allocation-guide-for-complex-tasks/10226#recent-2</guid>
    <pubDate>Sat, 02 May 2026 12:34:46 +0000</pubDate>
    <description>For routing complex tasks across multiple AI models, I noticed that benchmark-based allocation (HLE, GPQA, IFBench, etc.) only explains part of the story. Each model defaults to a distinct cognitive register when handed the same task. Therefore, have this guide. Claude Opus 4.7 is the lead and coordinator. Highest non-hallucination rate and 1M context. Methodology judgment, long-document reading, integration, final draft. Codex (GPT-5.5) is the hard-reasoning specialist. Highest raw reasoning scores, most surgical precision in rewrites and cross-section consistency. Never let it independently produce factual claims. Gemini 3.1 Pro is the knowledge anchor. Highest Omniscience and IFBench....</description>
  </item>
  <item>
    <title>Spark Program | Ckb-probe: Deep Observability Tool for CKB Nodes Based on Aya Kernel eBPF/ckb-probe：基于 Aya 内核 eBPF 的 CKB 节点深度可观测性工具 (2 posts)</title>
    <link>https://talk.nervos.org/t/spark-program-ckb-probe-deep-observability-tool-for-ckb-nodes-based-on-aya-kernel-ebpf-ckb-probe-aya-ebpf-ckb/10008</link>
    <guid>https://talk.nervos.org/t/spark-program-ckb-probe-deep-observability-tool-for-ckb-nodes-based-on-aya-kernel-ebpf-ckb-probe-aya-ebpf-ckb/10008#recent-2</guid>
    <pubDate>Sat, 02 May 2026 08:19:48 +0000</pubDate>
    <description>CKB-Probe 演示流程说明 范围：仅限 CKB 测试网 本文档覆盖 ckb-probe 的五个核心演示步骤，每步附完整终端输出、关键命令说明和输出解读。 所有输出均为真实运行数据（2026-05-02，CKB v0.204.0 测试网节点）。 调整说明 本文档替代原计划的演示视频。文字报告在以下方面对评审者更为友好： 评审者可以直接复制报告中的命令进行复现，不需要反复拖动视频进度条 终端输出配合文字解读比视频旁白更容易精确定位到具体的输出字段和数值 报告本身可以作为项目文档的一部分长期保留，便于后续版本更新时同步修改 视频一旦录制后修改成本较高，而文档可以随项目迭代 前置条件 # 系统要求 # - Linux 内核 &gt;= 5.8 (BTF 支持) # - root 权限 (eBPF 需要 CAP_BPF + CAP_SYS_ADMIN) # - CKB 测试网节点运行中 # Docker 方式运行 (推荐) docker run --rm --privileged --pid host \ -v /sys/kernel/debug:/sys/kernel/debug:ro \ -v /sys/kernel/btf:/sys/kernel/btf:ro \ -v /path/to/ckb-testnet:/data \ -v /path/to/ckb:/usr/local/bin/ckb:ro \ ckb-probe:latest &lt;command&gt; # 或者直接在宿主机运行 (需要 root) sudo ckb-probe &lt;command&gt; 步骤 1: 环境检查与...</description>
  </item>
  <item>
    <title>iCKB Contracts Revisited: Old Code, New Audit (3 posts)</title>
    <link>https://talk.nervos.org/t/ickb-contracts-revisited-old-code-new-audit/10225</link>
    <guid>https://talk.nervos.org/t/ickb-contracts-revisited-old-code-new-audit/10225#recent-3</guid>
    <pubDate>Sat, 02 May 2026 01:33:02 +0000</pubDate>
    <description>This post mirrors the original security review report published in ickb/contracts: any question or feedback is more than welcomed Review completion date: 2026-05-01. Reviewed contracts commit: 454cfa9. This is the last commit that changed scripts/contracts/** or scripts/Cargo.toml. Executable test evidence: current scripts/tests/** suite in this repository state. Scope: iCKB Logic, Owned Owner, Limit Order, and the shared utils crate. Cross-references: the iCKB whitepaper and Nervos L1 reference implementations. Prior external audit: Scalebit (2024-09-10). That audit reported three issues: two informational and one minor. Executive Summary Under the current deployment assumptions, the...</description>
  </item>
  <item>
    <title>Cellora — designing a production indexing and query service for CKB (feedback welcome) (1 posts)</title>
    <link>https://talk.nervos.org/t/cellora-designing-a-production-indexing-and-query-service-for-ckb-feedback-welcome/10199</link>
    <guid>https://talk.nervos.org/t/cellora-designing-a-production-indexing-and-query-service-for-ckb-feedback-welcome/10199#recent-1</guid>
    <pubDate>Sat, 02 May 2026 01:21:16 +0000</pubDate>
    <description>matt_ckb: Without the Flyclient proof, I have trouble seeing how the client can verify that the block header returned from Cellora has been included in the chain. Am I missing something? Even if the returned header is anchored to consensus, there is still the harder question: how does the client prove that no matching cells or txs were omitted from the answer? If the client wants both consensus anchoring and query completeness for itself, it still needs its own light client or full node. The more interesting design space is not “one provider proves everything”, but “independent parties reproducing the same canonical view at the same tip”. Been chiseling away at a design in that direction:...</description>
  </item>
  <item>
    <title>CellScript - A DSL for Cell-Based Contracts (2 posts)</title>
    <link>https://talk.nervos.org/t/cellscript-a-dsl-for-cell-based-contracts/10193</link>
    <guid>https://talk.nervos.org/t/cellscript-a-dsl-for-cell-based-contracts/10193#recent-2</guid>
    <pubDate>Sat, 02 May 2026 01:12:37 +0000</pubDate>
    <description>Hey Arthur, you are very welcome to try iCKB in CellScript To make that easier, I tightened the iCKB artifacts around the relevant DAO, header, witness, and deployment details: ickb/contracts PR #19: merged. Adds the local executable review plus the expanded scripts/tests suites and replay-heavy cases. See also iCKB Contracts Revisited: Old Code, New Audit ickb/whitepaper PR #24: merged. Consolidates the protocol and deployment notes. nervosnetwork/rfcs PR #453: open. Notes the current DAO same-serialized-lock-size rule that nodes enforce for phase-1 withdrawals. So if you still want to use iCKB as a maturity benchmark, the code and docs should be a much cleaner starting point now. Happy...</description>
  </item>
  <item>
    <title>[DIS] iCKB &amp; dCKB Rescuer Funding Proposal (Non-Coding Expenses) (1 posts)</title>
    <link>https://talk.nervos.org/t/dis-ickb-dckb-rescuer-funding-proposal-non-coding-expenses/8369</link>
    <guid>https://talk.nervos.org/t/dis-ickb-dckb-rescuer-funding-proposal-non-coding-expenses/8369#recent-1</guid>
    <pubDate>Sat, 02 May 2026 00:45:39 +0000</pubDate>
    <description>Hey all, small update on the iCKB side I cleaned up a few iCKB artifacts around the DAO, headers, witnesses, and deployment notes: ickb/contracts PR #19: merged. Adds the local executable review plus the expanded scripts/tests suites and replay-heavy cases. See also iCKB Contracts Revisited: Old Code, New Audit ickb/whitepaper PR #24: merged. Consolidates the protocol and deployment notes. nervosnetwork/rfcs PR #453: open. Notes the current DAO same-serialized-lock-size rule that nodes enforce for phase-1 withdrawals. That last point is the same current node rule I mentioned earlier here for dCKB Rescuer, so at least that constraint is now written down more clearly. Love &amp; Peace, Phroi</description>
  </item>
  <item>
    <title>Revamping and Refactoring the CKB Wallet Connection Experience: A Modular Compound Component for React Developers (1 posts)</title>
    <link>https://talk.nervos.org/t/revamping-and-refactoring-the-ckb-wallet-connection-experience-a-modular-compound-component-for-react-developers/10221</link>
    <guid>https://talk.nervos.org/t/revamping-and-refactoring-the-ckb-wallet-connection-experience-a-modular-compound-component-for-react-developers/10221#recent-1</guid>
    <pubDate>Fri, 01 May 2026 19:35:13 +0000</pubDate>
    <description>This is awesome</description>
  </item>
</channel>
</rss>
