{ "base_url": "https://talk.nervos.org", "generated_at": "2026-05-08T18:09:07.592897+00:00", "since": "2026-05-07T18:09:03.170012+00:00", "until": "2026-05-08T18:09:03.170012+00:00", "window_hours": 24, "topics": [ { "topic_id": 10229, "title": "A Paid AI Agent Calling Experiment via Fiber", "slug": "a-paid-ai-agent-calling-experiment-via-fiber", "url": "https://talk.nervos.org/t/a-paid-ai-agent-calling-experiment-via-fiber/10229", "created_at": "2026-05-06T04:13:14.026000+00:00", "last_posted_at": "2026-05-08T09:27:31.708000+00:00", "category_id": 64, "tags": [], "posters": [ "Original Poster, Most Recent Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster" ], "recent_posts": [ { "post_id": 24170, "post_number": 6, "topic_id": 10229, "topic_title": "A Paid AI Agent Calling Experiment via Fiber", "topic_slug": "a-paid-ai-agent-calling-experiment-via-fiber", "author": "Thinker", "created_at": "2026-05-08T08:15:11.896000+00:00", "updated_at": "2026-05-08T08:15:11.896000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/a-paid-ai-agent-calling-experiment-via-fiber/10229/6", "content_text": "感觉挺有意思，但我还是不太确定我理解是否完全正确。这是想做个开放平台，开放给配置好的如Codex OpenClaw Hermes等这些Agent上架，它们是较强大脑（GPT5.5 Opus4.7 ）或独特技能突出的Agent（如爬虫Skill…），帮助那些没有资源或不想麻烦使用者直接使用？\n就现阶段来说感觉是个不错的方向定位，现在有不少尝鲜者优化配置了不错的Agent，但也有不少无法充分利用其价值 资源浪费，还有不少因渠道或精力问题而没法使用到。甚至为后期agnet学习技能A2A做准备。\n但同时对此也有些疑问，不知道是如何解决的，一个agent对应多个用户，是如何解决会话记忆污染问题的，如不做隔离会不会体验很不好呢？如果当调用者通过 Fiber 接入时，根据 Fiber通道 为其建立个专属ID及目录文件，进行个用户隔离及记忆储存 ，会不会体验更好些呢？但又考虑到户用隐私泄露问题，把ID及对应的记忆文件存到存入 IPFS/Arweave等第三方，然后只把该数据的哈希值和访问权限存入 CKB 的 Cell里。每次根据 Fiber 接入 ，直接关联其ID然后导入读取记忆储存文件，完成持续会话，这样是否行的通？ 这相对于户用了有一套线上的memory和prompts\n用户建立连接 → 宿主机拉起环境并下载（如果有历史 Hash）-> 用户持续交互（期间不更新存储，只保持容器运行） → 用户点击“结束会话” → 宿主机自动执行：加密打包 → 上传 IPFS/Arweave → 更新 CKB Cell Hash → 销毁本地容器。", "content_html": "

感觉挺有意思，但我还是不太确定我理解是否完全正确。这是想做个开放平台，开放给配置好的如Codex OpenClaw Hermes等这些Agent上架，它们是较强大脑（GPT5.5 Opus4.7 ）或独特技能突出的Agent（如爬虫Skill…），帮助那些没有资源或不想麻烦使用者直接使用？

\n

就现阶段来说感觉是个不错的方向定位，现在有不少尝鲜者优化配置了不错的Agent，但也有不少无法充分利用其价值 资源浪费，还有不少因渠道或精力问题而没法使用到。甚至为后期agnet学习技能A2A做准备。

\n

但同时对此也有些疑问，不知道是如何解决的，一个agent对应多个用户，是如何解决会话记忆污染问题的，如不做隔离会不会体验很不好呢？如果当调用者通过 Fiber 接入时，根据 Fiber通道 为其建立个专属ID及目录文件，进行个用户隔离及记忆储存 ，会不会体验更好些呢？但又考虑到户用隐私泄露问题，把ID及对应的记忆文件存到存入 IPFS/Arweave等第三方，然后只把该数据的哈希值和访问权限存入 CKB 的 Cell里。每次根据 Fiber 接入 ，直接关联其ID然后导入读取记忆储存文件，完成持续会话，这样是否行的通？ 这相对于户用了有一套线上的memory和prompts

\n

用户建立连接 → 宿主机拉起环境并下载（如果有历史 Hash）-> 用户持续交互（期间不更新存储，只保持容器运行） → 用户点击“结束会话” → 宿主机自动执行：加密打包 → 上传 IPFS/Arweave → 更新 CKB Cell Hash → 销毁本地容器。

", "like_count": 0, "quote_count": 0 }, { "post_id": 24171, "post_number": 7, "topic_id": 10229, "topic_title": "A Paid AI Agent Calling Experiment via Fiber", "topic_slug": "a-paid-ai-agent-calling-experiment-via-fiber", "author": "RetricSu", "created_at": "2026-05-08T09:27:31.708000+00:00", "updated_at": "2026-05-08T09:27:31.708000+00:00", "reply_to_post_number": 6, "url": "https://talk.nervos.org/t/a-paid-ai-agent-calling-experiment-via-fiber/10229/7", "content_text": "你理解得没错。最简单的动机可以认为，很多人用不了 claude code，通过这个平台可以去付费使用。当然你说的更精细化的agent/独特技能的 agent 我觉得也是个方向，甚至后面 agent 去调用 agent 的协作，也可以通过这套方式去做，无外乎是把人的聊天界面换成更适合机器的交互而已。\n至于你后面聊的这块，先说说现在已经做的：\n目前做法比较简单，就是每次用户开一个对话的时候，会拉起一个新的容器环境，让用户跟它交互，存放一些生成的产物，等等。当用户明确结束对话、开启一个新对话时，这个旧的环境就会被销毁。如果用户没有明确结束对话，这个环境会被保留一段时间。如果超过一定时间没有交互，也会自动销毁，避免宿主机器一直占用资源。所以当前多个用户对应一个 agent 是隔离开的，不会污染，同时我们不保留/不关联任何的用户身份数据，只是付费而已，隐私性可以认为是最好的。\n你提到的ID/记忆这些我还没想太远，我觉得你说的是可行的，核心是怎么平衡好用户体验和去中心化/不侵犯隐私这块。这里我相信 crypto 能发挥更大的作用，类似于你说的这种上链/授权的方式，细节还没想，大方向应该没错。这个方向后面 fiber 还可以通过保留容器环境的时间来收费，类似于一个租赁时间产生的费用来收费，跟现在的云服务器的模式也挺像的，但是是完全社会化、开放的平台，任何人都能拿着闲置资源加入进来。", "content_html": "

你理解得没错。最简单的动机可以认为，很多人用不了 claude code，通过这个平台可以去付费使用。当然你说的更精细化的agent/独特技能的 agent 我觉得也是个方向，甚至后面 agent 去调用 agent 的协作，也可以通过这套方式去做，无外乎是把人的聊天界面换成更适合机器的交互而已。

\n

至于你后面聊的这块，先说说现在已经做的：

\n

目前做法比较简单，就是每次用户开一个对话的时候，会拉起一个新的容器环境，让用户跟它交互，存放一些生成的产物，等等。当用户明确结束对话、开启一个新对话时，这个旧的环境就会被销毁。如果用户没有明确结束对话，这个环境会被保留一段时间。如果超过一定时间没有交互，也会自动销毁，避免宿主机器一直占用资源。所以当前多个用户对应一个 agent 是隔离开的，不会污染，同时我们不保留/不关联任何的用户身份数据，只是付费而已，隐私性可以认为是最好的。

\n

你提到的ID/记忆这些我还没想太远，我觉得你说的是可行的，核心是怎么平衡好用户体验和去中心化/不侵犯隐私这块。这里我相信 crypto 能发挥更大的作用，类似于你说的这种上链/授权的方式，细节还没想，大方向应该没错。这个方向后面 fiber 还可以通过保留容器环境的时间来收费，类似于一个租赁时间产生的费用来收费，跟现在的云服务器的模式也挺像的，但是是完全社会化、开放的平台，任何人都能拿着闲置资源加入进来。

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10230, "title": "基于 fiber-js 的 Demo 开发", "slug": "fiber-js-demo", "url": "https://talk.nervos.org/t/fiber-js-demo/10230", "created_at": "2026-05-06T06:45:31.692000+00:00", "last_posted_at": "2026-05-08T07:47:37.060000+00:00", "category_id": 36, "tags": [], "posters": [ "Original Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24169, "post_number": 3, "topic_id": 10230, "topic_title": "基于 fiber-js 的 Demo 开发", "topic_slug": "fiber-js-demo", "author": "RetricSu", "created_at": "2026-05-08T07:47:37.060000+00:00", "updated_at": "2026-05-08T07:47:37.060000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/fiber-js-demo/10230/3", "content_text": "官方文档中缺少对 fiber-js 的相关介绍和引导，可能会导致一些开发者都不知道其存在的问题。\nYes we should add this part in docs", "content_html": "
\n

官方文档中缺少对 fiber-js 的相关介绍和引导，可能会导致一些开发者都不知道其存在的问题。

\n
\n

Yes we should add this part in docs

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10218, "title": "[DIS] Quantir Risk Intelligence for CKB Ecosystem and Cross-Chain Monitoring", "slug": "dis-quantir-risk-intelligence-for-ckb-ecosystem-and-cross-chain-monitoring", "url": "https://talk.nervos.org/t/dis-quantir-risk-intelligence-for-ckb-ecosystem-and-cross-chain-monitoring/10218", "created_at": "2026-04-30T15:40:30.553000+00:00", "last_posted_at": "2026-05-08T06:15:15.393000+00:00", "category_id": 65, "tags": [ "grant-RFC", "grants" ], "posters": [ "Original Poster, Most Recent Poster", "Frequent Poster", "Frequent Poster" ], "recent_posts": [ { "post_id": 24168, "post_number": 7, "topic_id": 10218, "topic_title": "[DIS] Quantir Risk Intelligence for CKB Ecosystem and Cross-Chain Monitoring", "topic_slug": "dis-quantir-risk-intelligence-for-ckb-ecosystem-and-cross-chain-monitoring", "author": "Quantir", "created_at": "2026-05-08T06:15:15.393000+00:00", "updated_at": "2026-05-08T06:15:15.393000+00:00", "reply_to_post_number": 6, "url": "https://talk.nervos.org/t/dis-quantir-risk-intelligence-for-ckb-ecosystem-and-cross-chain-monitoring/10218/7", "content_text": "On CKB we’re mostly interested in behavioral and flow-based monitoring rather than only simple address tracking.\nFor xUDT specifically, suspicious activity can be detected through several layers:\nabnormal mint/burn patterns;\nsudden liquidity migration between RGB++ / DEX environments;\nlarge holder concentration shifts;\ncoordinated transfer bursts across newly created addresses;\nbridge-related anomalies between EVM / CKB environments;\nrepeated cell fragmentation/consolidation behavior that differs from normal user activity.\nWe also analyze:\ntransaction graph structure;\nvelocity changes;\nwallet clustering;\nadmin/operator activity;\nliquidity shock events;\nabnormal approval or settlement flows.\nSince CKB uses a cell-based architecture, monitoring logic differs significantly from standard EVM event indexing.\nWe’re currently adapting our risk-engine architecture to support:\ncell-level state interpretation;\nxUDT movement analysis;\nintent/solver routing flows;\ncross-chain liquidity intelligence.\nThe goal is not only alerting, but predictive risk scoring and behavioral anomaly detection across the ecosystem.", "content_html": "

On CKB we’re mostly interested in behavioral and flow-based monitoring rather than only simple address tracking.

\n

For xUDT specifically, suspicious activity can be detected through several layers:

\n

abnormal mint/burn patterns;
\nsudden liquidity migration between RGB++ / DEX environments;
\nlarge holder concentration shifts;
\ncoordinated transfer bursts across newly created addresses;
\nbridge-related anomalies between EVM / CKB environments;
\nrepeated cell fragmentation/consolidation behavior that differs from normal user activity.

\n

We also analyze:

\n

transaction graph structure;
\nvelocity changes;
\nwallet clustering;
\nadmin/operator activity;
\nliquidity shock events;
\nabnormal approval or settlement flows.

\n

Since CKB uses a cell-based architecture, monitoring logic differs significantly from standard EVM event indexing.
\nWe’re currently adapting our risk-engine architecture to support:

\n

cell-level state interpretation;
\nxUDT movement analysis;
\nintent/solver routing flows;
\ncross-chain liquidity intelligence.

\n

The goal is not only alerting, but predictive risk scoring and behavioral anomaly detection across the ecosystem.

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10238, "title": "[RFC] CellScript 的包管理：一个 Go 语言风格的、基于 GitHub 的 CKB 合约包管理注册表", "slug": "rfc-cellscript-go-github-ckb", "url": "https://talk.nervos.org/t/rfc-cellscript-go-github-ckb/10238", "created_at": "2026-05-08T03:31:06.806000+00:00", "last_posted_at": "2026-05-08T03:31:06.870000+00:00", "category_id": 45, "tags": [ "CKB", "CKB-VM", "CellScript" ], "posters": [ "Original Poster, Most Recent Poster" ], "recent_posts": [ { "post_id": 24167, "post_number": 1, "topic_id": 10238, "topic_title": "[RFC] CellScript 的包管理：一个 Go 语言风格的、基于 GitHub 的 CKB 合约包管理注册表", "topic_slug": "rfc-cellscript-go-github-ckb", "author": "ArthurZhang", "created_at": "2026-05-08T03:31:06.870000+00:00", "updated_at": "2026-05-08T03:39:43.185000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/rfc-cellscript-go-github-ckb/10238/1", "content_text": "Hi，社区\n上个月我发布了CellScript的早期预览版，得到了英语社区的一些建设性和温暖的反馈，现在我想用中文来和大家讨论一下未来的包管理的方向。\n我在CellScript的后续开发路线 (大约在接下来一两个月) 中做了一个更去中心化也更解决成本的设计，因为我谨慎地认为这个阶段，可能发布和引用智能合约库，不应该需要搭建自定义 API 服务器、维护专门的数据库，或者为仅开发者需要的源代码支付链上存储费用。\nCellScript 的第一阶段注册表将采取一种刻意极简的方案：一切都是 Git，一切都在 GitHub 上，而链上只记录那些在运行时真正重要的信息。\n本文将介绍整个设计，解释我选择这个模型的原因，并展示如何端到端地使用它。\n问题所在\n大多数我们用过的包管理注册表：如 crates.io、npm、PyPI, 都采用中心化服务器模式。你向服务器发布，服务器存储你的包，消费者从服务器下载。这对应用开发来说非常有效。但智能合约不同。\nCKB 智能合约的依赖不仅仅是下载和编译的源代码。在生产环境中，构建者或钱包需要知道具体的链上事实：该引用哪个 CellDep，data_hash 是什么，该指向哪个 OutPoint，该部署是活跃的还是已弃用的。源码包回答的是 “写了什么代码”，而生产部署回答的是 “你应该实际使用链上的哪个Cell” 。这两个层面都很重要，在新的设计中，它们通过加密哈希绑定在一起，而不是通过命名约定。\n同时，CKB 生态系统仍然相对很小。运行一个专门的注册表服务，如果带有 API 端点、存储后端、可用性保证和身份验证，在这个阶段我忖度，暂时属于过度工程。我们更需要一种今天就能工作、且零基础设施的方案，但又能随着生态系统的需求增长而变得更加严谨。\n核心理念：两层架构，零服务器\nCellScript 的注册表首先会有两个层级，都由 GitHub 上的 Git 仓库提供支持。\n第一层级是一个发现索引：一个单一的、轻量级 Git 仓库，将 namespace/name 映射到源码仓库的 URL。把它想象成一本电话黄页。只有当有人注册一个全新的包时，它才会更新。如果你正在发布一个已有包的 1.3.0 版本，发现索引完全不会改变。\n第二层级是每个包的版本索引，称为 registry.json，它位于每个源码仓库内部，紧挨着 Cell.toml。当你运行 cellc publish 时，它会计算源码哈希，读取你的构建产物，并将一个新的版本条目追加到这个文件中。然后你提交、打标签、推送。就这样。不需要向任何外部索引提 PR，不需要调用 API，不需要维护服务器。\n关键的洞察是 Go 风格的约定：如果没有显式的发现条目，cellscript/amm 会自动解析为 github.com/cellscript/amm。你不需要注册任何东西。你只需要把仓库推送到约定位置，它就能工作。发现索引只存在于打破约定的情况，托管在其他地方的仓库，或者仓库名称与包名不匹配的情况等（暂定）。\nimage952×272 14.4 KB\nimage944×502 27.9 KB\n为什么这对智能合约有效\n这里有一个容易被忽略的微妙之处。在传统的包管理注册表中，包就是身份标识的单元。你安装了 lodash@4.17.21，故事就结束了。但对于智能合约，包只是第一层。\nCellScript 使用我们称之为三层身份模型的机制。一个包存在于三个不同的身份范围内，每个范围回答一个不同的问题：\n包身份（Package Identity） 回答\"写了什么源代码？\"它由 Cell.toml 和注册表索引承载，在编译时验证。关键字段包括命名空间（namespace）、名称（name）、版本（version）和源码哈希（source_hash）。\n构建身份（Build Identity） 回答\"编译器产生了什么？\"它由 Cell.lock 承载，在构建时验证。关键字段包括 compiler_version、artifact_hash、metadata_hash、schema_hash、abi_hash 和 constraints_hash。\n部署身份（Deployment Identity） 回答\"在哪条链上的哪个Cell？\"它由 Deployed.toml 承载，在运行时验证。关键字段包括 network、chain_id、tx_hash、output_index、code_hash、hash_type、data_hash、out_point、dep_type、type_id 和 script_role。\ndiagram-4x (7)4800×3200 458 KB\n每一层都有独立的意义，但通过锁定文件（lockfile）与上下层进行加密绑定。如果有人在发布后篡改了源代码，source_hash 将不匹配。如果有人调换了构建产物，artifact_hash 将不匹配。如果有人指向了错误的链上Cell，data_hash 将与链上事实不匹配。系统会失败关闭（fail closed）。\n这就是为什么我们可以使用基于 Git 的注册表。注册表不需要成为信任锚点。信任锚点是加密哈希，它们在每一层都被独立验证。注册表只是一个发现机制——一种找到源代码的方式。一旦找到，你就验证它。\n三个文件\nCellScript 使用三个文件来分离关注点。这受到了 Move/Sui 的 Move.toml / Move.lock / Published.toml 分离方式的启发，但针对 CKB 的 CellDep 和 OutPoint 模型进行了适配，而非 Sui 的原生包对象模型。\nCell.toml — 部署意图\nCell.toml 是源码包声明。它描述的是开发者打算部署什么，而不是实际部署了什么。针对注册表的关键新增字段是 namespace：\n[package]\nname = \"amm_pool\"\nversion = \"1.2.0\"\nnamespace = \"cellscript\"\n[dependencies]\ntoken = { version = \"0.3.0\", namespace = \"cellscript\" }\n[build]\ntarget_profile = \"ckb\"\n依赖可以从注册表（通过命名空间和版本）、本地路径或 Git URL 解析。解析优先级是 路径 > Git > 注册表，这意味着你总可以用本地检出覆盖注册表依赖以进行开发，而无需更改任何配置。\nCell.lock — 构建身份\nCell.lock 是源码与部署之间的加密绑定点。它记录精确的依赖版本、Git 修订版本、源码哈希和构建哈希。它对重新验证是自包含的——url 和 revision 字段让你无需重新查询发现索引就能重新克隆精确的源码提交。\nversion = 1\n[package]\nname = \"amm_pool\"\nversion = \"1.2.0\"\nnamespace = \"cellscript\"\nsource_hash = \"blake2b:0xabcd...\"\n[package.build]\ncompiler_version = \"0.19.0\"\ntarget_profile = \"ckb\"\nartifact_hash = \"blake2b:0x1234...\"\n[dependencies.token]\nversion = \"0.3.2\"\nnamespace = \"cellscript\"\nsource = { registry = \"cellscript/token\", url = \"https://github.com/cellscript/token\", revision = \"f7e8d9c0...\" }\nsource_hash = \"blake2b:0x2222...\"\n[deployment.ckb.aggron4]\nstatus = \"deployed\"\nrecord = \"ckb-testnet:0xaaaa...\"\n这类似于 go.sum——它用哈希值固定精确版本，使构建可独立复现。\nDeployed.toml — 部署事实\nDeployed.toml 记录从链上推导出的不可变的部署事实。它在部署交易确认后自动生成，且不得手动编辑。\nversion = 1\n[package]\nname = \"amm_pool\"\nversion = \"1.2.0\"\nsource_hash = \"blake2b:0xabcd...\"\n[build]\ncompiler_version = \"0.19.0\"\nartifact_hash = \"blake2b:0x1234...\"\n[[deployments]]\nnetwork = \"aggron4\"\nchain_id = \"ckb-testnet\"\nscript_role = \"type\"\ntx_hash = \"0xaaaa...\"\noutput_index = 0\ncode_hash = \"0xbbbb...\"\nhash_type = \"data1\"\ndep_type = \"code\"\nout_point = \"0xaaaa...:0\"\ndata_hash = \"0xcccc...\"\ntype_id = \"0xdddd...\"\n这种分离很重要。Cell.toml 说\"我想要 hash_type = data1\"。Deployed.toml 说\"位于 0xaaaa…:0 的Cell实际上有 hash_type = data1，这是链上证明\"。一个是意图，另一个是事实。混淆这两者会导致正是智能合约系统应该避免的那种供应链漏洞。\n教程：端到端流程\n让我们走一遍一个包的完整生命周期，从编写到经过验证的链上部署。\n第一步：创建包\ncellc init amm_pool --namespace cellscript\n这会生成一个带有 namespace = \"cellscript\" 的 Cell.toml 和一个起始源文件。此时，没有 Cell.lock，没有 registry.json，没有 Deployed.toml。这个包纯粹是本地的。\n第二步：添加依赖\n编辑 Cell.toml 以添加注册表依赖：\n[dependencies]\ntoken = { version = \"0.3.0\", namespace = \"cellscript\" }\n当你构建时，解析器开始工作：\nimage1745×185 8.08 KB\n发现索引告诉解析器在哪里找到源码。源码仓库内的 registry.json 提供版本元数据。该元数据中的 source_hash 会针对实际源码树进行验证。如果有任何内容被篡改，构建将失败。\n第三步：发布\ncellc publish\n这会从你当前的源码树计算源码哈希，读取构建产物的哈希，并将一个新的版本条目追加到 registry.json。然后你提交并推送：\ngit add registry.json\ngit commit -m \"publish v1.2.0\"\ngit tag v1.2.0\ngit push --tags\n注意没有发生什么：你没有向发现索引提 PR，你没有调用 API，你没有向服务器上传任何东西。版本元数据存在于你的源码仓库中。发现索引只需要更新一次，就是当包首次注册时。\n第四步：部署到 CKB\n这是工具链变得真正严肃的地方。我们不只是把数据推送到链上，我们要经过一个验证过的流水线。\nimage321×877 15.2 KB\n构建步骤产生一个真正的 RISC-V ELF 二进制文件。cellc ckb-hash 计算该二进制文件的 CKB Blake2b 哈希。cellc deploy-plan 生成一个部署计划。cellc verify-deploy 验证该计划。然后，cellscript-ckb-adapter crate 中的 build_deploy_transaction() 构建一个带有 TYPE_ID、占用容量计算和找零输出的正规 CKB 交易——所有这些都在无头（headless）模式下计算，无需 RPC 连接即可构建交易本身。\n交易提交并确认后，Deployed.toml 从本地计算的证据加上链上的 tx_hash 生成。生成过程不需要链上重新推导——适配器已经知道所有哈希字段。验证（一个单独的步骤）才是发生链上读取的地方。\n第五步：交叉验证所有三层\n部署后，你可以验证完整的身份链：\ncellc package verify # source_hash 匹配\ncellc verify-artifact # artifact_hash 匹配真实二进制文件\ncellc registry verify # data_hash 匹配链上Cell\n或者以编程方式，如我会在端到端测试所做的：\n// 包身份：source_hash\nlet computed = compute_source_hash(&pkg_dir).unwrap();\nassert_eq!(computed, read_lock.package.source_hash.as_deref().unwrap());\n// 构建身份：artifact_hash\nlet lock_artifact = read_lock.package_build.as_ref().unwrap().artifact_hash.as_ref().unwrap();\nlet deployed_artifact = read_deployed.build.as_ref().unwrap().artifact_hash.as_ref().unwrap();\nassert_eq!(lock_artifact, deployed_artifact);\n// 部署身份：链上 data_hash\nlet on_chain_data_hash = live_cell[\"cell\"][\"data\"][\"hash\"].as_str().unwrap();\nlet computed_data_hash = format!(\"0x{}\", hex::encode(ckb_data_hash(&artifact_binary)));\nassert_eq!(on_chain_data_hash, computed_data_hash);\n这三个断言验证了三个不同的事情：自发布以来源码没有改变，构建产物与编译结果匹配，链上Cell包含部署时的确切二进制文件。这个链条中的任何断裂都意味着出了问题，系统会失败关闭，而不是默默接受不匹配。\n设计原理：为什么用 Git，为什么用 GitHub，为什么是现在\n有几个设计决策值得更多解释。\n为什么用 Git，而不用自定义 API？ 因为 Git 已经解决了我们需要解决的问题：内容寻址存储、通过提交哈希实现的加密完整性、通过本地克隆实现的离线缓存，以及每个开发者都已经熟悉的工作流。构建自定义 API 服务器会解决同样的问题，但会增加运营负担、认证复杂性和单点故障，而所有这些都是为了一个目前服务CKB社区较小生态系统的注册表。\n为什么用两层模型，而不是单一的单仓库索引？ 因为发布新版本应该是向你自己的仓库执行 git push，而不是向别人的仓库提 PR。单仓库索引（如 crates.io 的索引仓库）要求每次版本发布都更新一个共享仓库。这会产生摩擦：CI 冲突、合并竞争、权限管理。我们的模型让版本元数据随源码一起传播，就像 Go 的 go.mod。发现索引只在新包注册时才会改变，这是一个罕见事件。\n为什么专门用 GitHub？ 我们并不锁定在 GitHub。发现索引映射到源码 URL，而这些 URL 可以指向任何 Git 托管服务。但 GitHub 正是 CKB 生态系统开发已经在进行的地方，它提供免费的仓库托管、可靠的可用性和熟悉的工作流。如果有人想自托管他们的源码，发现索引只需要一个 git clone 能访问到的 URL。\n为什么用链下部署记录，而不用链上？ CKB 的容量成本使得大多数全量的链上源码包存储不具吸引力。在链上存储版本元数据、模式清单和 ABI 索引会成倍增加成本，却没有共识层面的收益。这些是开发者产物，不是运行时状态。链上应该记录紧凑的部署事实（CellDep、OutPoint、data_hash），而不是取代整个源码分发系统。\n代理怎么办？ 第三阶段可以添加一个可选的缓存层，如 proxy.cellscript.xyz，但基于 Git 的路径是永久的规范机制，不是临时占位符。代理将是一个透明缓存，用于更快的安装和可用性保证，而不是替代品。如果代理宕机，cellc install 会回退到直接 Git 克隆。\n接下来的计划\n第一阶段是刻意保持极简的。我将交付两层 Git 注册表、三文件分离和三层身份模型。以下是我尚未严密计划的内容，以及原因：\n链上类型脚本索引（第二阶段）：一个通过 code_hash 或 TYPE_ID 索引部署的链上脚本。对于希望无需读取链下文件即可发现部署的钱包和构建者来说很有用。但 CKB 生态系统尚未证明对此有需求，而且容量成本是真实的。有需要时我们会构建它。\n注册表代理（第三阶段）：一个像 proxy.golang.org 那样的缓存层，用于更快的安装和可用性保证。基于 Git 的路径始终是主要的解析机制。代理是透明缓存，不是替代品。\n审计签名和发布者身份（第二阶段）：以后包或许可以携带可选的审计报告哈希和准入门槛状态（但是这里有安全性和去中心化的trade-off，可能需要一个利维坦和风险之间的折中。）。要求审计员在将部署标记为生产就绪之前提供加密签名是一个自然的扩展，但这首先需要一套密钥管理方案。\n撤回和替代：yanked 标志已经在 registry.json 的模式中。第一阶段记录它；第二阶段在解析器层面强制执行。\n重要的是，这些未来的补充都不需要改变基本架构。添加代理不会改变发现索引的模式。添加链上索引不会改变 Deployed.toml 的生成方式。两层 Git 模型是永久的规范路径，其他一切都分层在其上。\nCellScript 是 Nervos CKB 智能合约的领域特定语言。实现仓库位于GitHub - a19q3/CellScript: Domain-specific language for the Cell model. · GitHub", "content_html": "

Hi，社区

\n

上个月我发布了CellScript的早期预览版，得到了英语社区的一些建设性和温暖的反馈，现在我想用中文来和大家讨论一下未来的包管理的方向。

\n

我在CellScript的后续开发路线 (大约在接下来一两个月) 中做了一个更去中心化也更解决成本的设计，因为我谨慎地认为这个阶段，可能发布和引用智能合约库，不应该需要搭建自定义 API 服务器、维护专门的数据库，或者为仅开发者需要的源代码支付链上存储费用。

\n

CellScript 的第一阶段注册表将采取一种刻意极简的方案：一切都是 Git，一切都在 GitHub 上，而链上只记录那些在运行时真正重要的信息。

\n

本文将介绍整个设计，解释我选择这个模型的原因，并展示如何端到端地使用它。

\n

问题所在

\n

大多数我们用过的包管理注册表：如 crates.io、npm、PyPI, 都采用中心化服务器模式。你向服务器发布，服务器存储你的包，消费者从服务器下载。这对应用开发来说非常有效。但智能合约不同。

\n

CKB 智能合约的依赖不仅仅是下载和编译的源代码。在生产环境中，构建者或钱包需要知道具体的链上事实：该引用哪个 CellDep，data_hash 是什么，该指向哪个 OutPoint，该部署是活跃的还是已弃用的。源码包回答的是 “写了什么代码”，而生产部署回答的是 “你应该实际使用链上的哪个Cell” 。这两个层面都很重要，在新的设计中，它们通过加密哈希绑定在一起，而不是通过命名约定。

\n

同时，CKB 生态系统仍然相对很小。运行一个专门的注册表服务，如果带有 API 端点、存储后端、可用性保证和身份验证，在这个阶段我忖度，暂时属于过度工程。我们更需要一种今天就能工作、且零基础设施的方案，但又能随着生态系统的需求增长而变得更加严谨。

\n

核心理念：两层架构，零服务器

\n

CellScript 的注册表首先会有两个层级，都由 GitHub 上的 Git 仓库提供支持。

\n

第一层级是一个发现索引：一个单一的、轻量级 Git 仓库，将 namespace/name 映射到源码仓库的 URL。把它想象成一本电话黄页。只有当有人注册一个全新的包时，它才会更新。如果你正在发布一个已有包的 1.3.0 版本，发现索引完全不会改变。

\n

第二层级是每个包的版本索引，称为 registry.json，它位于每个源码仓库内部，紧挨着 Cell.toml。当你运行 cellc publish 时，它会计算源码哈希，读取你的构建产物，并将一个新的版本条目追加到这个文件中。然后你提交、打标签、推送。就这样。不需要向任何外部索引提 PR，不需要调用 API，不需要维护服务器。

\n

关键的洞察是 Go 风格的约定：如果没有显式的发现条目，cellscript/amm 会自动解析为 github.com/cellscript/amm。你不需要注册任何东西。你只需要把仓库推送到约定位置，它就能工作。发现索引只存在于打破约定的情况，托管在其他地方的仓库，或者仓库名称与包名不匹配的情况等（暂定）。
\n

\"image\"
image952×272 14.4 KB

\n

\"image\"
image944×502 27.9 KB

\n

为什么这对智能合约有效

\n

这里有一个容易被忽略的微妙之处。在传统的包管理注册表中，包就是身份标识的单元。你安装了 lodash@4.17.21，故事就结束了。但对于智能合约，包只是第一层。

\n

CellScript 使用我们称之为三层身份模型的机制。一个包存在于三个不同的身份范围内，每个范围回答一个不同的问题：

\n

包身份（Package Identity） 回答\"写了什么源代码？\"它由 Cell.toml 和注册表索引承载，在编译时验证。关键字段包括命名空间（namespace）、名称（name）、版本（version）和源码哈希（source_hash）。

\n

构建身份（Build Identity） 回答\"编译器产生了什么？\"它由 Cell.lock 承载，在构建时验证。关键字段包括 compiler_version、artifact_hash、metadata_hash、schema_hash、abi_hash 和 constraints_hash。

\n

部署身份（Deployment Identity） 回答\"在哪条链上的哪个Cell？\"它由 Deployed.toml 承载，在运行时验证。关键字段包括 network、chain_id、tx_hash、output_index、code_hash、hash_type、data_hash、out_point、dep_type、type_id 和 script_role。
\n

\"diagram-4x
diagram-4x (7)4800×3200 458 KB

\n

每一层都有独立的意义，但通过锁定文件（lockfile）与上下层进行加密绑定。如果有人在发布后篡改了源代码，source_hash 将不匹配。如果有人调换了构建产物，artifact_hash 将不匹配。如果有人指向了错误的链上Cell，data_hash 将与链上事实不匹配。系统会失败关闭（fail closed）。

\n

这就是为什么我们可以使用基于 Git 的注册表。注册表不需要成为信任锚点。信任锚点是加密哈希，它们在每一层都被独立验证。注册表只是一个发现机制——一种找到源代码的方式。一旦找到，你就验证它。

\n

三个文件

\n

CellScript 使用三个文件来分离关注点。这受到了 Move/Sui 的 Move.toml / Move.lock / Published.toml 分离方式的启发，但针对 CKB 的 CellDep 和 OutPoint 模型进行了适配，而非 Sui 的原生包对象模型。

\n

Cell.toml — 部署意图

\n

Cell.toml 是源码包声明。它描述的是开发者打算部署什么，而不是实际部署了什么。针对注册表的关键新增字段是 namespace：

\n
[package]\nname = \"amm_pool\"\nversion = \"1.2.0\"\nnamespace = \"cellscript\"\n\n[dependencies]\ntoken = { version = \"0.3.0\", namespace = \"cellscript\" }\n\n[build]\ntarget_profile = \"ckb\"\n
\n

依赖可以从注册表（通过命名空间和版本）、本地路径或 Git URL 解析。解析优先级是 路径 > Git > 注册表，这意味着你总可以用本地检出覆盖注册表依赖以进行开发，而无需更改任何配置。

\n

Cell.lock — 构建身份

\n

Cell.lock 是源码与部署之间的加密绑定点。它记录精确的依赖版本、Git 修订版本、源码哈希和构建哈希。它对重新验证是自包含的——url 和 revision 字段让你无需重新查询发现索引就能重新克隆精确的源码提交。

\n
version = 1\n\n[package]\nname = \"amm_pool\"\nversion = \"1.2.0\"\nnamespace = \"cellscript\"\nsource_hash = \"blake2b:0xabcd...\"\n\n[package.build]\ncompiler_version = \"0.19.0\"\ntarget_profile = \"ckb\"\nartifact_hash = \"blake2b:0x1234...\"\n\n[dependencies.token]\nversion = \"0.3.2\"\nnamespace = \"cellscript\"\nsource = { registry = \"cellscript/token\", url = \"https://github.com/cellscript/token\", revision = \"f7e8d9c0...\" }\nsource_hash = \"blake2b:0x2222...\"\n\n[deployment.ckb.aggron4]\nstatus = \"deployed\"\nrecord = \"ckb-testnet:0xaaaa...\"\n
\n

这类似于 go.sum——它用哈希值固定精确版本，使构建可独立复现。

\n

Deployed.toml — 部署事实

\n

Deployed.toml 记录从链上推导出的不可变的部署事实。它在部署交易确认后自动生成，且不得手动编辑。

\n
version = 1\n\n[package]\nname = \"amm_pool\"\nversion = \"1.2.0\"\nsource_hash = \"blake2b:0xabcd...\"\n\n[build]\ncompiler_version = \"0.19.0\"\nartifact_hash = \"blake2b:0x1234...\"\n\n[[deployments]]\nnetwork = \"aggron4\"\nchain_id = \"ckb-testnet\"\nscript_role = \"type\"\ntx_hash = \"0xaaaa...\"\noutput_index = 0\ncode_hash = \"0xbbbb...\"\nhash_type = \"data1\"\ndep_type = \"code\"\nout_point = \"0xaaaa...:0\"\ndata_hash = \"0xcccc...\"\ntype_id = \"0xdddd...\"\n
\n

这种分离很重要。Cell.toml 说\"我想要 hash_type = data1\"。Deployed.toml 说\"位于 0xaaaa…:0 的Cell实际上有 hash_type = data1，这是链上证明\"。一个是意图，另一个是事实。混淆这两者会导致正是智能合约系统应该避免的那种供应链漏洞。

\n

教程：端到端流程

\n

让我们走一遍一个包的完整生命周期，从编写到经过验证的链上部署。

\n

第一步：创建包

\n
cellc init amm_pool --namespace cellscript\n
\n

这会生成一个带有 namespace = \"cellscript\" 的 Cell.toml 和一个起始源文件。此时，没有 Cell.lock，没有 registry.json，没有 Deployed.toml。这个包纯粹是本地的。

\n

第二步：添加依赖

\n

编辑 Cell.toml 以添加注册表依赖：

\n
[dependencies]\ntoken = { version = \"0.3.0\", namespace = \"cellscript\" }\n
\n

当你构建时，解析器开始工作：
\n

\"image\"
image1745×185 8.08 KB

\n

发现索引告诉解析器在哪里找到源码。源码仓库内的 registry.json 提供版本元数据。该元数据中的 source_hash 会针对实际源码树进行验证。如果有任何内容被篡改，构建将失败。

\n

第三步：发布

\n
cellc publish\n
\n

这会从你当前的源码树计算源码哈希，读取构建产物的哈希，并将一个新的版本条目追加到 registry.json。然后你提交并推送：

\n
git add registry.json\ngit commit -m \"publish v1.2.0\"\ngit tag v1.2.0\ngit push --tags\n
\n

注意没有发生什么：你没有向发现索引提 PR，你没有调用 API，你没有向服务器上传任何东西。版本元数据存在于你的源码仓库中。发现索引只需要更新一次，就是当包首次注册时。

\n

第四步：部署到 CKB

\n

这是工具链变得真正严肃的地方。我们不只是把数据推送到链上，我们要经过一个验证过的流水线。

\n

\"image\"
image321×877 15.2 KB

\n

构建步骤产生一个真正的 RISC-V ELF 二进制文件。cellc ckb-hash 计算该二进制文件的 CKB Blake2b 哈希。cellc deploy-plan 生成一个部署计划。cellc verify-deploy 验证该计划。然后，cellscript-ckb-adapter crate 中的 build_deploy_transaction() 构建一个带有 TYPE_ID、占用容量计算和找零输出的正规 CKB 交易——所有这些都在无头（headless）模式下计算，无需 RPC 连接即可构建交易本身。

\n

交易提交并确认后，Deployed.toml 从本地计算的证据加上链上的 tx_hash 生成。生成过程不需要链上重新推导——适配器已经知道所有哈希字段。验证（一个单独的步骤）才是发生链上读取的地方。

\n

第五步：交叉验证所有三层

\n

部署后，你可以验证完整的身份链：

\n
cellc package verify   # source_hash 匹配\ncellc verify-artifact  # artifact_hash 匹配真实二进制文件\ncellc registry verify  # data_hash 匹配链上Cell\n
\n

或者以编程方式，如我会在端到端测试所做的：

\n
// 包身份：source_hash\nlet computed = compute_source_hash(&pkg_dir).unwrap();\nassert_eq!(computed, read_lock.package.source_hash.as_deref().unwrap());\n\n// 构建身份：artifact_hash\nlet lock_artifact = read_lock.package_build.as_ref().unwrap().artifact_hash.as_ref().unwrap();\nlet deployed_artifact = read_deployed.build.as_ref().unwrap().artifact_hash.as_ref().unwrap();\nassert_eq!(lock_artifact, deployed_artifact);\n\n// 部署身份：链上 data_hash\nlet on_chain_data_hash = live_cell[\"cell\"][\"data\"][\"hash\"].as_str().unwrap();\nlet computed_data_hash = format!(\"0x{}\", hex::encode(ckb_data_hash(&artifact_binary)));\nassert_eq!(on_chain_data_hash, computed_data_hash);\n
\n

这三个断言验证了三个不同的事情：自发布以来源码没有改变，构建产物与编译结果匹配，链上Cell包含部署时的确切二进制文件。这个链条中的任何断裂都意味着出了问题，系统会失败关闭，而不是默默接受不匹配。

\n

设计原理：为什么用 Git，为什么用 GitHub，为什么是现在

\n

有几个设计决策值得更多解释。

\n

为什么用 Git，而不用自定义 API？ 因为 Git 已经解决了我们需要解决的问题：内容寻址存储、通过提交哈希实现的加密完整性、通过本地克隆实现的离线缓存，以及每个开发者都已经熟悉的工作流。构建自定义 API 服务器会解决同样的问题，但会增加运营负担、认证复杂性和单点故障，而所有这些都是为了一个目前服务CKB社区较小生态系统的注册表。

\n

为什么用两层模型，而不是单一的单仓库索引？ 因为发布新版本应该是向你自己的仓库执行 git push，而不是向别人的仓库提 PR。单仓库索引（如 crates.io 的索引仓库）要求每次版本发布都更新一个共享仓库。这会产生摩擦：CI 冲突、合并竞争、权限管理。我们的模型让版本元数据随源码一起传播，就像 Go 的 go.mod。发现索引只在新包注册时才会改变，这是一个罕见事件。

\n

为什么专门用 GitHub？ 我们并不锁定在 GitHub。发现索引映射到源码 URL，而这些 URL 可以指向任何 Git 托管服务。但 GitHub 正是 CKB 生态系统开发已经在进行的地方，它提供免费的仓库托管、可靠的可用性和熟悉的工作流。如果有人想自托管他们的源码，发现索引只需要一个 git clone 能访问到的 URL。

\n

为什么用链下部署记录，而不用链上？ CKB 的容量成本使得大多数全量的链上源码包存储不具吸引力。在链上存储版本元数据、模式清单和 ABI 索引会成倍增加成本，却没有共识层面的收益。这些是开发者产物，不是运行时状态。链上应该记录紧凑的部署事实（CellDep、OutPoint、data_hash），而不是取代整个源码分发系统。

\n

代理怎么办？ 第三阶段可以添加一个可选的缓存层，如 proxy.cellscript.xyz，但基于 Git 的路径是永久的规范机制，不是临时占位符。代理将是一个透明缓存，用于更快的安装和可用性保证，而不是替代品。如果代理宕机，cellc install 会回退到直接 Git 克隆。

\n

接下来的计划

\n

第一阶段是刻意保持极简的。我将交付两层 Git 注册表、三文件分离和三层身份模型。以下是我尚未严密计划的内容，以及原因：

\n

链上类型脚本索引（第二阶段）：一个通过 code_hash 或 TYPE_ID 索引部署的链上脚本。对于希望无需读取链下文件即可发现部署的钱包和构建者来说很有用。但 CKB 生态系统尚未证明对此有需求，而且容量成本是真实的。有需要时我们会构建它。

\n

注册表代理（第三阶段）：一个像 proxy.golang.org 那样的缓存层，用于更快的安装和可用性保证。基于 Git 的路径始终是主要的解析机制。代理是透明缓存，不是替代品。

\n

审计签名和发布者身份（第二阶段）：以后包或许可以携带可选的审计报告哈希和准入门槛状态（但是这里有安全性和去中心化的trade-off，可能需要一个利维坦和风险之间的折中。）。要求审计员在将部署标记为生产就绪之前提供加密签名是一个自然的扩展，但这首先需要一套密钥管理方案。

\n

撤回和替代：yanked 标志已经在 registry.json 的模式中。第一阶段记录它；第二阶段在解析器层面强制执行。

\n

重要的是，这些未来的补充都不需要改变基本架构。添加代理不会改变发现索引的模式。添加链上索引不会改变 Deployed.toml 的生成方式。两层 Git 模型是永久的规范路径，其他一切都分层在其上。

\n
\n

CellScript 是 Nervos CKB 智能合约的领域特定语言。实现仓库位于GitHub - a19q3/CellScript: Domain-specific language for the Cell model. · GitHub

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10237, "title": "一点关于隐私保护的看法:所有Utxo系公链都原生具备的能力", "slug": "utxo", "url": "https://talk.nervos.org/t/utxo/10237", "created_at": "2026-05-08T02:20:33.880000+00:00", "last_posted_at": "2026-05-08T03:17:26.138000+00:00", "category_id": 49, "tags": [], "posters": [ "Original Poster, Most Recent Poster" ], "recent_posts": [ { "post_id": 24165, "post_number": 1, "topic_id": 10237, "topic_title": "一点关于隐私保护的看法:所有Utxo系公链都原生具备的能力", "topic_slug": "utxo", "author": "yifenzi", "created_at": "2026-05-08T02:20:33.922000+00:00", "updated_at": "2026-05-08T02:20:33.922000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/utxo/10237/1", "content_text": "加密货币中关于隐私保护的讨论设计和实现一直在发生和推进，对不同潜在保护对象的底层认知的不同自然演进出不同的呈现路径\n我的观点是隐私保护的对象应该是不作恶也没能力作恶的绝大多数的普通人，而不是在链上盗取勒索别人谋取不义之财的极少数作恶之人\n基于这样的尺度，我提出一点关于隐私保护的看法，这个实现方式原生支持所有Utxo系公链，且实现不触及任何底层协议的变动只需要在钱包应用端即可做到，同时隐私保护的成本可调可控\n这就是在工程上已经实现的主子私钥钱包，即用一个主私钥生成无数个子私钥，一笔隐私转账只需要把交易的输入方和输出方数量上增加即可，比如设置成一百个输入和一百个输出，只需要在一百个输出中其中一个是真正的收款方地址即可，其他199个地址都由付款方控制(即都是自己生成的子私钥钱包)这样对收款方是无感的，对付款方参与行为混淆的地址越多其隐私保护越高，当然对应的交互成本也越高，这个由自己选择\n一句话总结:所有Utxo系公链都原生具备这样一个隐私功能，给所有用户提供了面具，至于这个面具用不用什么时候用以及用到什么程度，完全由用户自己决定\n这样的隐私保护实现的对象，技术难度和用户成本才是对的方向", "content_html": "

加密货币中关于隐私保护的讨论设计和实现一直在发生和推进，对不同潜在保护对象的底层认知的不同自然演进出不同的呈现路径

\n

我的观点是隐私保护的对象应该是不作恶也没能力作恶的绝大多数的普通人，而不是在链上盗取勒索别人谋取不义之财的极少数作恶之人

\n

基于这样的尺度，我提出一点关于隐私保护的看法，这个实现方式原生支持所有Utxo系公链，且实现不触及任何底层协议的变动只需要在钱包应用端即可做到，同时隐私保护的成本可调可控

\n

这就是在工程上已经实现的主子私钥钱包，即用一个主私钥生成无数个子私钥，一笔隐私转账只需要把交易的输入方和输出方数量上增加即可，比如设置成一百个输入和一百个输出，只需要在一百个输出中其中一个是真正的收款方地址即可，其他199个地址都由付款方控制(即都是自己生成的子私钥钱包)这样对收款方是无感的，对付款方参与行为混淆的地址越多其隐私保护越高，当然对应的交互成本也越高，这个由自己选择

\n

一句话总结:所有Utxo系公链都原生具备这样一个隐私功能，给所有用户提供了面具，至于这个面具用不用什么时候用以及用到什么程度，完全由用户自己决定

\n

这样的隐私保护实现的对象，技术难度和用户成本才是对的方向

", "like_count": 0, "quote_count": 0 }, { "post_id": 24166, "post_number": 2, "topic_id": 10237, "topic_title": "一点关于隐私保护的看法:所有Utxo系公链都原生具备的能力", "topic_slug": "utxo", "author": "yifenzi", "created_at": "2026-05-08T03:17:26.138000+00:00", "updated_at": "2026-05-08T03:17:26.138000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/utxo/10237/2", "content_text": "不管是所谓的独立隐私公链还是比特币网络上的一些项目，追求对付款地址收款地址以及交易金额这三要素的绝对隐藏的大方向可能就错了，其潜在服务对象，潜在技术漏洞和被接受的容易程度都是问题\n利用无限子私钥地址以及一个地址只收一次只付一次的原则，让所有人都能在现在的基础上容易的用起来，且普通交易和隐私交易随时可以无缝切换\n就像我们出去旅游住宿，绝大多数时候都只需要一间房间就够了，但如果有必要，也可以把整层楼甚至整个酒店包下，作为服务方，提供可选性然后让用户自己选择就行了，而在多个提供可选性的服务商家中，那个最能综合安全方便价格等各个因素的商家一定是胜出者", "content_html": "

不管是所谓的独立隐私公链还是比特币网络上的一些项目，追求对付款地址收款地址以及交易金额这三要素的绝对隐藏的大方向可能就错了，其潜在服务对象，潜在技术漏洞和被接受的容易程度都是问题

\n

利用无限子私钥地址以及一个地址只收一次只付一次的原则，让所有人都能在现在的基础上容易的用起来，且普通交易和隐私交易随时可以无缝切换

\n

就像我们出去旅游住宿，绝大多数时候都只需要一间房间就够了，但如果有必要，也可以把整层楼甚至整个酒店包下，作为服务方，提供可选性然后让用户自己选择就行了，而在多个提供可选性的服务商家中，那个最能综合安全方便价格等各个因素的商家一定是胜出者

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10143, "title": "Pre-RFC Discussion: Activating the Nervos DAO Treasury", "slug": "pre-rfc-discussion-activating-the-nervos-dao-treasury", "url": "https://talk.nervos.org/t/pre-rfc-discussion-activating-the-nervos-dao-treasury/10143", "created_at": "2026-03-31T03:10:02.859000+00:00", "last_posted_at": "2026-05-08T01:10:57.283000+00:00", "category_id": 31, "tags": [ "CKB" ], "posters": [ "Original Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24163, "post_number": 13, "topic_id": 10143, "topic_title": "Pre-RFC Discussion: Activating the Nervos DAO Treasury", "topic_slug": "pre-rfc-discussion-activating-the-nervos-dao-treasury", "author": "jimi-winehouse", "created_at": "2026-05-07T23:16:34.543000+00:00", "updated_at": "2026-05-07T23:16:34.543000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/pre-rfc-discussion-activating-the-nervos-dao-treasury/10143/13", "content_text": "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. Ethereum’s ecosystem is 1000x bigger and they still have the foundation basically using the equivalent of this treasury with ICO tokens. We could just use similar design and the day where the ecosystem is mature enough we go back to a burn model with the ecosystem acting as a treasury. Transparency matters more than decentralization IMO.", "content_html": "

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. Ethereum’s ecosystem is 1000x bigger and they still have the foundation basically using the equivalent of this treasury with ICO tokens. We could just use similar design and the day where the ecosystem is mature enough we go back to a burn model with the ecosystem acting as a treasury. Transparency matters more than decentralization IMO.

", "like_count": 0, "quote_count": 0 }, { "post_id": 24164, "post_number": 14, "topic_id": 10143, "topic_title": "Pre-RFC Discussion: Activating the Nervos DAO Treasury", "topic_slug": "pre-rfc-discussion-activating-the-nervos-dao-treasury", "author": "Yeti", "created_at": "2026-05-08T01:10:57.283000+00:00", "updated_at": "2026-05-08T01:10:57.283000+00:00", "reply_to_post_number": 13, "url": "https://talk.nervos.org/t/pre-rfc-discussion-activating-the-nervos-dao-treasury/10143/14", "content_text": "jimi-winehouse:\nEthereum’s ecosystem is 1000x bigger and they still have the foundation basically using the equivalent of this treasury with ICO tokens\nThat’s the current system we have, but I think there would be some pretty complex regulatory issues with the Secondary Issuance being used in the same way as the ICO tokens, controlled by the Foundation or any other organisation.\nI agree though, that it would be way easier and probably even way more productive to just let the Foundation manage the secondary issuance in the beginning and distribute funding to the DAO/s, but I just don’t think that’s possible.", "content_html": "\n

That’s the current system we have, but I think there would be some pretty complex regulatory issues with the Secondary Issuance being used in the same way as the ICO tokens, controlled by the Foundation or any other organisation.

\n

I agree though, that it would be way easier and probably even way more productive to just let the Foundation manage the secondary issuance in the beginning and distribute funding to the DAO/s, but I just don’t think that’s possible.

", "like_count": 0, "quote_count": 1 } ] }, { "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-05-07T19:41:42.315000+00:00", "category_id": 49, "tags": [ "Pending", "Spark-Program" ], "posters": [ "Original Poster, Most Recent Poster", "Frequent Poster", "Frequent Poster" ], "recent_posts": [ { "post_id": 24161, "post_number": 5, "topic_id": 10212, "topic_title": "Spark Program | Dular", "topic_slug": "spark-program-dular", "author": "duongja", "created_at": "2026-05-07T19:41:42.315000+00:00", "updated_at": "2026-05-07T19:41:42.315000+00:00", "reply_to_post_number": 4, "url": "https://talk.nervos.org/t/spark-program-dular/10212/5", "content_text": "Updated @xingtianchunyan\nI have updated the following sections of the main post:\nExisting Progress\nclarified that the prototype has a public testnet multi-hop RUSD payment\nproof\nPublic Testnet Multi-Hop RUSD Proof (new subsection added)\nadded the completed Fiber payment hash\nadded the route / hop pubkeys\nadded the delivered amount and routing fee\nadded the relevant channel funding tx hashes + output indexes\nadded a short explanation clarifying the relationship between the Fiber\npayment hash and CKB L1 explorer records\nCKB Disbursement & Exchange Rate Risk\ncorrected the disbursement language to match Spark’s standard procedure\nLinks / evidence added to the main post:\nFiber payment hash:\n0x20fd6c4a9d9e207420b4f55b4ae095eee9840fca1678afc89f9065298fe4a9e2\nChannel funding tx hash:\n0xefdb791ac44ba1af435ae2b22f5572862519865990185d3c0d0cd5bd068e9e39 (output\nindex 0x0)\nRelay channel funding tx hash:\n0x6156f3a8f46063d529f74df2a40407fc79ac70322615d2e862875eedf2b6a79c (output\nindex 0x0)\nAlso Sent you the Visual evidence of Daraja environment credentials via DM.", "content_html": "

Updated @xingtianchunyan

\n

I have updated the following sections of the main post:

\n\n

Links / evidence added to the main post:

\n\n

Also Sent you the Visual evidence of Daraja environment credentials via DM.

", "like_count": 0, "quote_count": 0 } ] } ] }