https://chainte.github.io/ckb-talk-radar/ Daily Nervos Talk community briefing and latest active topics. zh-cn Fri, 08 May 2026 09:27:31 +0000 https://chainte.github.io/ckb-talk-radar/ tag:ckb-talk-radar,2026-05-08:daily-brief Fri, 08 May 2026 18:09:07 +0000 ## 今日发生了什么 Nervos论坛今天讨论活跃，围绕AI Agent支付实验、CellScript合约包管理和链上隐私方案展开了具体的技术讨论。[S01, S02, S05, S06] ArthurZhang发布了CellScript包管理的RFC，提出用GitHub作为极简注册表，避免开发者自建服务器和链上存储成本；同时关于UTXO隐私保护的新思路也引发了关注，强调不对底层协议做改动即可实现可切换的隐私层级。[S05, S06, S07] ## 重点话题 **AI Agent调用平台方向获确认**：Thinker和RetricSu就基于Fiber的付费AI Agent实验深入交流，RetricSu确认核心动机是让无法直接使用Claude Code等工具的用户能付费使用，并展望了Agent间协作调用的可能性。[S01, S02] **CellScript包管理走极简路线**：ArthurZhang提出第一阶段注册表完全基于Git和GitHub，不架设自定义API、不维护专门数据库、不为源代码付链上存储费，目标是在接下来一到两个月落地。[S05] **UTXO隐私保护的新思路**：yifenzi提出无需改动底层协议、仅需钱包端实现的隐私方案，利用无限子私钥地址和"一地址一收一付"原则，让普通交易与隐私交易可随时切换，成本可调可控。[S06, S07] **fiber-js文档缺口被承认**：RetricSu确认官方文档缺少fiber-js的介绍和引导，表示应该补充这部分内容。[S03]... https://talk.nervos.org/t/a-paid-ai-agent-calling-experiment-via-fiber/10229 https://talk.nervos.org/t/a-paid-ai-agent-calling-experiment-via-fiber/10229#recent-2 Fri, 08 May 2026 09:27:31 +0000 感觉挺有意思，但我还是不太确定我理解是否完全正确。这是想做个开放平台，开放给配置好的如Codex OpenClaw Hermes等这些Agent上架，它们是较强大脑（GPT5.5 Opus4.7 ）或独特技能突出的Agent（如爬虫Skill…），帮助那些没有资源或不想麻烦使用者直接使用？ 就现阶段来说感觉是个不错的方向定位，现在有不少尝鲜者优化配置了不错的Agent，但也有不少无法充分利用其价值 资源浪费，还有不少因渠道或精力问题而没法使用到。甚至为后期agnet学习技能A2A做准备。 但同时对此也有些疑问，不知道是如何解决的，一个agent对应多个用户，是如何解决会话记忆污染问题的，如不做隔离会不会体验很不好呢？如果当调用者通过 Fiber 接入时，根据 Fiber通道 为其建立个专属ID及目录文件，进行个用户隔离及记忆储存 ，会不会体验更好些呢？但又考虑到户用隐私泄露问题，把ID及对应的记忆文件存到存入 IPFS/Arweave等第三方，然后只把该数据的哈希值和访问权限存入 CKB 的 Cell里。每次根据 Fiber 接入 ，直接关联其ID然后导入读取记忆储存文件，完成持续会话，这样是否行的通？ 这相对于户用了有一套线上的memory和prompts 用户建立连接 → 宿主机拉起环境并下载（如果有历史 Hash）-> 用户持续交互（期间不更新存储，只保持容器运行） → 用户点击“结束会话” → 宿主机自动执行：加密打包 → 上传 IPFS/Arweave → 更新 CKB Cell Hash → 销毁本地容器。 你理解得没错。最简单的动机可以认为，很多人用不了... https://talk.nervos.org/t/fiber-js-demo/10230 https://talk.nervos.org/t/fiber-js-demo/10230#recent-1 Fri, 08 May 2026 07:47:37 +0000 官方文档中缺少对 fiber-js 的相关介绍和引导，可能会导致一些开发者都不知道其存在的问题。 Yes we should add this part in docs https://talk.nervos.org/t/dis-quantir-risk-intelligence-for-ckb-ecosystem-and-cross-chain-monitoring/10218 https://talk.nervos.org/t/dis-quantir-risk-intelligence-for-ckb-ecosystem-and-cross-chain-monitoring/10218#recent-1 Fri, 08 May 2026 06:15:15 +0000 On CKB we’re mostly interested in behavioral and flow-based monitoring rather than only simple address tracking. For xUDT specifically, suspicious activity can be detected through several layers: abnormal mint/burn patterns; sudden liquidity migration between RGB++ / DEX environments; large holder concentration shifts; coordinated transfer bursts across newly created addresses; bridge-related anomalies between EVM / CKB environments; repeated cell fragmentation/consolidation behavior that differs from normal user activity. We also analyze: transaction graph structure; velocity changes; wallet clustering; admin/operator activity; liquidity shock events; abnormal approval or settlement... https://talk.nervos.org/t/rfc-cellscript-go-github-ckb/10238 https://talk.nervos.org/t/rfc-cellscript-go-github-ckb/10238#recent-1 Fri, 08 May 2026 03:31:06 +0000 Hi，社区 上个月我发布了CellScript的早期预览版，得到了英语社区的一些建设性和温暖的反馈，现在我想用中文来和大家讨论一下未来的包管理的方向。 我在CellScript的后续开发路线 (大约在接下来一两个月) 中做了一个更去中心化也更解决成本的设计，因为我谨慎地认为这个阶段，可能发布和引用智能合约库，不应该需要搭建自定义 API 服务器、维护专门的数据库，或者为仅开发者需要的源代码支付链上存储费用。 CellScript 的第一阶段注册表将采取一种刻意极简的方案：一切都是 Git，一切都在 GitHub 上，而链上只记录那些在运行时真正重要的信息。 本文将介绍整个设计，解释我选择这个模型的原因，并展示如何端到端地使用它。 问题所在 大多数我们用过的包管理注册表：如 crates.io、npm、PyPI, 都采用中心化服务器模式。你向服务器发布，服务器存储你的包，消费者从服务器下载。这对应用开发来说非常有效。但智能合约不同。 CKB 智能合约的依赖不仅仅是下载和编译的源代码。在生产环境中，构建者或钱包需要知道具体的链上事实：该引用哪个 CellDep，data_hash 是什么，该指向哪个 OutPoint，该部署是活跃的还是已弃用的。源码包回答的是 “写了什么代码”，而生产部署回答的是 “你应该实际使用链上的哪个Cell” 。这两个层面都很重要，在新的设计中，它们通过加密哈希绑定在一起，而不是通过命名约定。 同时，CKB 生态系统仍然相对很小。运行一个专门的注册表服务，如果带有 API... https://talk.nervos.org/t/utxo/10237 https://talk.nervos.org/t/utxo/10237#recent-2 Fri, 08 May 2026 03:17:26 +0000 加密货币中关于隐私保护的讨论设计和实现一直在发生和推进，对不同潜在保护对象的底层认知的不同自然演进出不同的呈现路径 我的观点是隐私保护的对象应该是不作恶也没能力作恶的绝大多数的普通人，而不是在链上盗取勒索别人谋取不义之财的极少数作恶之人 基于这样的尺度，我提出一点关于隐私保护的看法，这个实现方式原生支持所有Utxo系公链，且实现不触及任何底层协议的变动只需要在钱包应用端即可做到，同时隐私保护的成本可调可控 这就是在工程上已经实现的主子私钥钱包，即用一个主私钥生成无数个子私钥，一笔隐私转账只需要把交易的输入方和输出方数量上增加即可，比如设置成一百个输入和一百个输出，只需要在一百个输出中其中一个是真正的收款方地址即可，其他199个地址都由付款方控制(即都是自己生成的子私钥钱包)这样对收款方是无感的，对付款方参与行为混淆的地址越多其隐私保护越高，当然对应的交互成本也越高，这个由自己选择 一句话总结:所有Utxo系公链都原生具备这样一个隐私功能，给所有用户提供了面具，至于这个面具用不用什么时候用以及用到什么程度，完全由用户自己决定 这样的隐私保护实现的对象，技术难度和用户成本才是对的方向 不管是所谓的独立隐私公链还是比特币网络上的一些项目，追求对付款地址收款地址以及交易金额这三要素的绝对隐藏的大方向可能就错了，其潜在服务对象，潜在技术漏洞和被接受的容易程度都是问题 利用无限子私钥地址以及一个地址只收一次只付一次的原则，让所有人都能在现在的基础上容易的用起来，且普通交易和隐私交易随时可以无缝切换... https://talk.nervos.org/t/pre-rfc-discussion-activating-the-nervos-dao-treasury/10143 https://talk.nervos.org/t/pre-rfc-discussion-activating-the-nervos-dao-treasury/10143#recent-2 Fri, 08 May 2026 01:10:57 +0000 I 100% encourage this initiative. We should definitely find a fast solution to having no financial incentives for builders in the ecosystem when every ecosystem is inflating non-stop, running low float/high FDV scams, and managing to suck up all the talent pool and attention. I think the elephant in the room is CKB price in and its volatility, we’re talking about an inflation which is equivalent to 5min implied volatility and doesn’t hurt decentralization from a node requirement POV. Tbh it feels like the whole discussion about decentralizing the treasury is premature optimization that’s more likely going to hurt than not and waste precious dev time that could be used elsewhere.... https://talk.nervos.org/t/spark-program-dular/10212 https://talk.nervos.org/t/spark-program-dular/10212#recent-1 Thu, 07 May 2026 19:41:42 +0000 Updated @xingtianchunyan I have updated the following sections of the main post: Existing Progress clarified that the prototype has a public testnet multi-hop RUSD payment proof Public Testnet Multi-Hop RUSD Proof (new subsection added) added the completed Fiber payment hash added the route / hop pubkeys added the delivered amount and routing fee added the relevant channel funding tx hashes + output indexes added a short explanation clarifying the relationship between the Fiber payment hash and CKB L1 explorer records CKB Disbursement & Exchange Rate Risk corrected the disbursement language to match Spark’s standard procedure Links / evidence added to the main post: Fiber payment hash:...