Hi @xingtianchunyan, below you can find the progress report for Milestone 1, week 2
\nWeek 2 Milestone 1 Progress Report
\nStatus
\nMilestone 1 has been completed.
\nThis phase focused on finishing the remaining Milestone 1 onboarding documents, replacing placeholder-only setup sections with validated guidance, and extending the validation evidence behind the local CKB node and RPC flow. The work completed during this period strengthens the project goal of reducing beginner ambiguity and making the path to first successful RPC interaction more explicit and repeatable.
\nRepository And Publication Status
\nThe repository structure established in Week 1 remains in place, and the Week 2 work was completed in the local repository workspace.
\nDuring this run:
\n- \n
- \n
no GitHub push was performed
\n \n - \n
no pull request was opened
\n \n - \n
no git commit was created
\n \n - \n
no remote configuration was changed
\n \n
This is important because the Week 2 work was intended to refine Milestone 1 content locally before any later publication or review step.
\nWork Completed
\n1. Remaining Milestone 1 Setup Sections Completed
\nThe previously placeholder-only Milestone 1 setup sections were expanded into beginner-oriented, validation-first documentation.
\nCompleted or substantially completed sections include:
\n- \n
- \n
03 Quick Start
\n \n - \n
04 CKB Node Setup
\n \n - \n
05 RPC Setup
\n \n - \n
07 Configuration Setup
\n \n
These sections now provide:
\n- \n
- \n
a shortest validated path to first RPC success
\n \n - \n
explicit step-by-step node startup guidance
\n \n - \n
RPC request and response interpretation for beginners
\n \n - \n
minimal configuration awareness without speculative file-edit instructions
\n \n
This directly supports the Milestone 1 requirement to help a developer reach first successful RPC interaction through a documentation-first onboarding flow.
\n2. Milestone 1 Navigation And Scope Messaging Refined
\nThe top-level project messaging was updated so the repository no longer describes the completed Milestone 1 setup sections as placeholders.
\nUpdated files include:
\n- \n
- \n
README.md
\n \n - \n
00 Overview
\n \n - \n
02 Environment Setup
\n \n
These updates improved:
\n- \n
- \n
document sequencing
\n \n - \n
scope clarity
\n \n - \n
internal cross-references
\n \n - \n
the distinction between completed Milestone 1 content and later placeholder sections
\n \n
3. Validation-First Boundaries Strengthened
\nThe Week 2 documentation pass preserved the rule that the guide should not guess commands, paths, ports, or behaviors that were not validated locally.
\nAs part of this cleanup:
\n- \n
- \n
validated commands were kept explicit
\n \n - \n
speculative configuration editing was not introduced
\n \n - \n
endpoint ambiguity was documented instead of hidden
\n \n - \n
later scope was left as placeholders rather than filled with weak guidance
\n \n
This keeps the guide aligned with the project’s positioning as a complement to official Nervos documentation rather than a replacement for it.
\n4. Placeholder Milestone Labels Added
\nLater placeholder sections were updated so TODO: VALIDATE markers now include a milestone label where the planned sequencing is already clear.
Updated placeholder sections include:
\n- \n
- \n
06 Indexer Setup:
\nMilestone 2\n - \n
08 First Developer Workflow:
\nMilestone 2\n - \n
09 Common Errors and Remediation:
\nMilestone 2\n - \n
10 Troubleshooting Matrix:
\nMilestone 2\n - \n
11 AI-Assisted Debugging:
\nMilestone 3\n - \n
12 CKB Mental Model:
\nMilestone 3\n - \n
13 Common Misconceptions:
\nMilestone 3\n
This improves planning clarity by showing which unfinished sections belong to later milestones instead of leaving all later work under one undifferentiated validation marker.
\nValidation Work Completed
\n5. Environment Connectivity Validation Refined
\nThe Week 1 connectivity failure around https://example.com was revisited and clarified through a more meaningful real-URL test.
Published findings updated in Week 2 include:
\n- \n
- Environment Validation Findings \n
The updated validation now shows:
\n- \n
- \n
repeated
\nexample.comhostname resolution failure in the local environment \n - \n
successful HTTPS header retrieval from
\nhttps://google.com\n - \n
evidence that target selection matters when using a simple connectivity check
\n \n
This is useful because it prevents the guide from incorrectly treating one failed hostname test as proof that all network-dependent onboarding is blocked.
\n6. Node And RPC Validation Expanded Significantly
\nThe local CKB node and RPC evidence base was expanded through multiple additional validation passes.
\nPublished findings updated in Week 2 include:
\n- \n
- CKB Node And RPC Validation Findings \n
The expanded validation covered:
\n- \n
- \n
repeated
\noffckb nodestartup after initial installation \n - \n
repeated successful JSON-RPC responses from
\nlocalhost:8114\n - \n
successful JSON-RPC responses from
\n127.0.0.1:28114\n - \n
wrong-method behavior on both endpoints
\n \n - \n
HTTP
\n200 OKconfirmation for JSON-RPC POST requests \n - \n
local process inspection with
\nlsof\n - \n
custom
\n--binary-pathstartup using the discovered local CKB binary \n - \n
confirmation that the
\ndevnetpath exists after initialization \n
This strengthens confidence that the Milestone 1 onboarding path is not a one-off success case.
\n7. Local Endpoint Relationship Clarified
\nWeek 2 validation materially improved the explanation of local endpoint behavior.
\nThe observed local evidence now shows:
\n- \n
- \n
\nckblistening on port8114\n - \n
\nnodelistening on port28114\n - \n
valid JSON-RPC POST responses from both endpoints
\n \n
This does not fully document the internal implementation details, but it is strong enough for beginner-facing onboarding guidance. It supports the practical explanation that 28114 behaves like a Node.js / OffCKB proxy layer while 8114 behaves like the underlying ckb RPC listener.
8. Binary Path And Devnet Path Validation Added
\nWeek 2 also validated filesystem-level details that were previously only partially understood.
\nThe local validation now confirms:
\n- \n
- \n
the installed CKB binary can be discovered at runtime rather than guessed
\n \n - \n
the binary version can be checked directly from that path
\n \n - \n
\noffckb node -b <actual-binary-path>works on the validation machine \n - \n
the
\ndevnetdirectory appears after initialization and contains real configuration and data paths \n
This improves the quality of the configuration guidance while still avoiding unsafe or speculative edit instructions.
\n9. Milestone 1 Scope Boundaries Confirmed
\nWeek 2 also confirmed that some sections should remain intentionally incomplete at the end of Milestone 1.
\nThe validated scope decision is that Milestone 1 now covers:
\n- \n
- \n
prerequisites
\n \n - \n
environment setup
\n \n - \n
quick start
\n \n - \n
CKB node setup
\n \n - \n
RPC setup
\n \n - \n
minimal configuration awareness
\n \n
The following remain intentionally outside the completed Milestone 1 scope:
\n- \n
- \n
indexer setup details
\n \n - \n
first full developer workflow
\n \n - \n
remediation and troubleshooting matrix content
\n \n - \n
AI-assisted debugging guidance
\n \n - \n
broader conceptual materials such as mental models and misconceptions
\n \n
This keeps the milestone focused on onboarding and first success rather than expanding prematurely into later-phase documentation.
\nOutcome Against Week 2 Scope
\nWeek 2 successfully delivered:
\n- \n
- \n
completed Milestone 1 setup documents for quick start, node setup, RPC setup, and configuration setup
\n \n - \n
stronger internal consistency across the main onboarding docs
\n \n - \n
updated validation findings based on repeat local testing
\n \n - \n
clearer explanation of local RPC endpoint behavior
\n \n - \n
milestone labels for later placeholder sections
\n \n - \n
a stronger basis for declaring Milestone 1 substantially complete
\n \n
\n
第2周里程碑1进展报告
\n状态
\n里程碑1已完成。
\n本阶段重点是完成里程碑1剩余的入门文档，将仅占位的设置部分替换为经过验证的指导，并扩展本地 CKB 节点和 RPC 流程的验证依据。本阶段完成的工作进一步强化了项目目标，即减少新手的不确定性，使首次成功进行 RPC 交互的路径更加清晰和可复现。
\n仓库与发布状态
\n第1周建立的仓库结构保持不变，第2周的工作在本地仓库环境中完成。
\n在此期间：
\n- \n
- 未进行 GitHub 推送 \n
- 未创建 Pull Request \n
- 未创建 git 提交 \n
- 未更改远程配置 \n
这一点很重要，因为第2周的工作目标是在本地完善里程碑1内容，以便后续再进行发布或评审。
\n已完成工作
\n1. 完成里程碑1剩余设置部分
\n此前仅为占位的里程碑1设置部分已扩展为面向初学者、以验证为优先的文档。
\n已完成或基本完成的部分包括：
\n- \n
- 03 快速开始 \n
- 04 CKB 节点设置 \n
- 05 RPC 设置 \n
- 07 配置设置 \n
这些部分现在提供：
\n- \n
- 达到首次 RPC 成功的最短验证路径 \n
- 明确的逐步节点启动指导 \n
- 面向初学者的 RPC 请求与响应解释 \n
- 最小化配置认知（避免推测性文件修改指引） \n
这直接支持了里程碑1的目标，即通过以文档为核心的入门流程帮助开发者实现首次成功的 RPC 交互。
\n2. 优化里程碑1导航与范围说明
\n更新了顶层项目说明，使仓库不再将已完成的里程碑1部分描述为占位内容。
\n更新文件包括：
\n- \n
- README.md \n
- 00 概览 \n
- 02 环境设置 \n
这些更新提升了：
\n- \n
- 文档结构顺序 \n
- 范围清晰度 \n
- 内部交叉引用 \n
- 已完成内容与后续占位内容的区分 \n
3. 强化“验证优先”的边界
\n第2周的文档完善过程中，始终遵循不猜测未验证内容的原则。
\n具体包括：
\n- \n
- 保留明确验证过的命令 \n
- 不引入推测性的配置修改 \n
- 明确记录端点不确定性 \n
- 后续内容保持占位而非填充不可靠信息 \n
这使文档继续作为官方 Nervos 文档的补充，而非替代。
\n4. 添加里程碑标签到占位部分
\n后续占位部分新增了里程碑标签，用于明确规划顺序。
\n更新包括：
\n- \n
- 06 Indexer 设置：里程碑2 \n
- 08 首个开发工作流：里程碑2 \n
- 09 常见错误与修复：里程碑2 \n
- 10 故障排查矩阵：里程碑2 \n
- 11 AI 辅助调试：里程碑3 \n
- 12 CKB 心智模型：里程碑3 \n
- 13 常见误解：里程碑3 \n
这提升了规划清晰度。
\n验证工作
\n5. 优化环境连接验证
\n第1周中 https://example.com 的失败测试已被重新分析，并通过更有意义的真实 URL 测试进行验证。
更新结果包括：
\n- \n
- 本地环境中
example.com解析失败 \n - 成功获取
https://google.comHTTPS 响应头 \n - 证明测试目标选择会影响结果 \n
这避免了错误地将单一失败当作整体网络问题。
\n6. 扩展节点与 RPC 验证
\n对本地 CKB 节点与 RPC 进行了多轮验证。
\n新增验证包括：
\n- \n
- 多次执行
offckb node启动 \n - 从
localhost:8114获取成功响应 \n - 从
127.0.0.1:28114获取成功响应 \n - 错误方法测试行为 \n
- JSON-RPC POST 返回 HTTP 200 \n
- 使用
lsof检查进程 \n - 使用
--binary-path启动 \n - 验证
devnet路径存在 \n
增强了稳定性信心。
\n7. 明确本地端点关系
\n验证结果显示：
\n- \n
ckb监听端口 8114 \nnode监听端口 28114 \n- 两者均可返回有效 JSON-RPC \n
可解释为：
\n- \n
- 28114：Node.js / OffCKB 代理层 \n
- 8114：底层 CKB RPC \n
8. 验证二进制路径与 devnet
\n确认：
\n- \n
- 可动态发现 CKB 二进制路径 \n
- 可直接检查版本 \n
offckb node -b <路径>可用 \n- 初始化后生成
devnet目录 \n
9. 确认里程碑范围边界
\n里程碑1覆盖：
\n- \n
- 前置条件 \n
- 环境设置 \n
- 快速开始 \n
- 节点设置 \n
- RPC 设置 \n
- 基础配置 \n
不包含：
\n- \n
- Indexer 设置 \n
- 完整开发流程 \n
- 故障排查矩阵 \n
- AI 调试 \n
- 概念性内容 \n
第2周成果总结
\n成功交付：
\n- \n
- 完整的里程碑1核心文档 \n
- 更一致的文档结构 \n
- 更新的验证数据 \n
- 更清晰的 RPC 行为说明 \n
- 明确的后续里程碑规划 \n
Hey Arthur, thank you!! I appreciate you introducing CellScript publicly!
\nFrom what I understand, it gives CKB and other cell-based systems a higher-level language without abstracting away the cell model. Gotta love the honesty about what already works and what is still maturing!
\nLooking at the repo, CellScript compiles to ckb-vm-compatible RISC-V assembly or ELF. It also makes resources, shared state, receipts, and explicit Cell effects, plus typed metadata, explicit. That keeps the language tied to the same execution target and cell effects.
\nAs you put it:
\n\nSo I’d llike to understand where CellScript draws the composability boundary on CKB today.
\nIf protocol A already occupies a cell’s type script slot, what is the intended path for protocol B to build on top of it and add new behavior?
From the repo, I see three paths:
\n- \n
- Build around A with
receiptcells or read-onlyCellDepaccess viaread_ref. \n - Later compose multiple verification scripts, which the roadmap still lists under
v0.14. \n - Combine those two approaches. \n
Which of those best matches how you think about composability on CKB today? Over time, do you expect CellScript to lean toward composing around existing cells, first-class script-to-script composition, or something else?
\nSee also: [NIP] Allow some Output Lock Scripts to Validate.
\nPhroi
", "like_count": 0, "quote_count": 1 }, { "post_id": 24030, "post_number": 14, "topic_id": 10193, "topic_title": "CellScript - A DSL for Cell-Based Contracts", "topic_slug": "cellscript-a-dsl-for-cell-based-contracts", "author": "ArthurZhang", "created_at": "2026-04-25T23:03:17.117000+00:00", "updated_at": "2026-04-26T04:15:55.356000+00:00", "reply_to_post_number": 13, "url": "https://talk.nervos.org/t/cellscript-a-dsl-for-cell-based-contracts/10193/14", "content_text": "Thank you Phroi. This is a very sharp reading of the current design, and I think you are pointing at precisely the right boundary.\nReading the NIP again, I think it captures something quite fundamental about CKB composability. The problem is not merely “how do we add another script?” The deeper question is: where does a constraint live, when is it invoked, what surface of the transaction does it observe, which cells does it actually protect, and what is merely assumed by the surrounding builder or wallet?\nThat is the distinction I would like CellScript to preserve rather than smooth over.\nI would say the three paths you identified are all real, but they live at different levels of maturity.\nToday, the default and most honest path is to compose around existing cells.\nIf protocol A already occupies a cell’s type script slot, CellScript should not pretend that protocol B can simply attach another independent type rule to the same cell. Unless A was explicitly designed for that extension, B should usually build around A through receipts, proofs, companion cells, read-only CellDep / read_ref access, explicit witness requirements, and transaction-level constraints.\nThat is also how I read the NIP: not merely as a concrete mechanism proposal, but as a useful articulation of the slot and coverage problem in the CKB model.\nThis also matches some examples I have heard from @matt_ckb. Some developers seem to want lock scripts to assert conditions when they are attached to a cell. Others move authorization-like logic into the type script, as in rental-style designs. In UDT-like protocols, many state-transition assertions naturally live in the type script, while authorization stays in the lock; but there are also cases where people want the lock to act covenant-style and check transaction-wide output conditions.\nTo me, these are not isolated design oddities. They are all symptoms of the same deeper question: CKB protocols increasingly need a clearer vocabulary for different constraint categories — authorization constraints, attachment-time invariants, transaction-wide covenant constraints, type-local state-transition rules, and inter-protocol composition constraints.\nThe NIP’s output-lock-validation direction is highly relevant, but I would treat it with some care.\nIt may give us another place to express covenant-like constraints, especially where the type slot is already occupied. But I would be cautious about presenting this as if lock and type scripts were interchangeable. They are not. Their invocation conditions, coverage, and social meaning in the model are different.\nFor CellScript, the important thing is to make that difference inspectable:\nwhat is checked by the type script;\nwhat is checked by the lock script;\nwhether the check applies to inputs, outputs, or the whole transaction shape;\nwhich cells are actually protected;\nwhat remains only a builder, wallet, or protocol assumption.\nThis is exactly the kind of boundary I would like CellScript metadata and ProofPlan to surface. CellScript should first model those constraint categories explicitly, and only then lower them into lock scripts, type scripts, wrappers, receipts, companion cells, or future L1 mechanisms such as output-lock validation, depending on the target profile and the available semantics.\nOn the roadmap side, I should probably phrase the v0.14 “script composition” item more carefully.\nThe wording may have made it sound broader than I intended. Spawn/IPC is real and useful, but I do not see it as the default answer to protocol composability. It is better understood as bounded verifier composition: delegated verification, reusable verifier modules, and modular validation pipelines. It does not make a cell’s type script slot multi-tenant, and it should not be presented as doing so.\nThe more important semantic layer is really v0.15, where the roadmap moves into scoped invariants and Covenant ProofPlan. That is where CellScript should make trigger, scope, reads, coverage, on-chain enforcement, and builder assumptions explicit.\nSo the intended layering is:\nv0.14: low-level mechanism for bounded verifier composition;\nv0.15: semantic composability through scoped invariants and ProofPlan;\nlater: combine this with receipts, companion cells, read-only deps, and lock-side or output-lock validation patterns where the coverage is clear.\nThat distinction may not have been clear enough in the roadmap wording, so this is useful feedback.\nIn that sense, I see the NIP less as a separate concern and more as one of the clearest examples of why CellScript needs to exist. A good language layer should not make the underlying model disappear. It should give developers better instruments for seeing where the model’s real boundaries are.", "content_html": "Thank you Phroi. This is a very sharp reading of the current design, and I think you are pointing at precisely the right boundary.
\nReading the NIP again, I think it captures something quite fundamental about CKB composability. The problem is not merely “how do we add another script?” The deeper question is: where does a constraint live, when is it invoked, what surface of the transaction does it observe, which cells does it actually protect, and what is merely assumed by the surrounding builder or wallet?
\nThat is the distinction I would like CellScript to preserve rather than smooth over.
\nI would say the three paths you identified are all real, but they live at different levels of maturity.
\nToday, the default and most honest path is to compose around existing cells.
\nIf protocol A already occupies a cell’s type script slot, CellScript should not pretend that protocol B can simply attach another independent type rule to the same cell. Unless A was explicitly designed for that extension, B should usually build around A through receipts, proofs, companion cells, read-only CellDep / read_ref access, explicit witness requirements, and transaction-level constraints.
That is also how I read the NIP: not merely as a concrete mechanism proposal, but as a useful articulation of the slot and coverage problem in the CKB model.
\nThis also matches some examples I have heard from @matt_ckb. Some developers seem to want lock scripts to assert conditions when they are attached to a cell. Others move authorization-like logic into the type script, as in rental-style designs. In UDT-like protocols, many state-transition assertions naturally live in the type script, while authorization stays in the lock; but there are also cases where people want the lock to act covenant-style and check transaction-wide output conditions.
\nTo me, these are not isolated design oddities. They are all symptoms of the same deeper question: CKB protocols increasingly need a clearer vocabulary for different constraint categories — authorization constraints, attachment-time invariants, transaction-wide covenant constraints, type-local state-transition rules, and inter-protocol composition constraints.
\nThe NIP’s output-lock-validation direction is highly relevant, but I would treat it with some care.
\nIt may give us another place to express covenant-like constraints, especially where the type slot is already occupied. But I would be cautious about presenting this as if lock and type scripts were interchangeable. They are not. Their invocation conditions, coverage, and social meaning in the model are different.
\nFor CellScript, the important thing is to make that difference inspectable:
\n- \n
- what is checked by the type script; \n
- what is checked by the lock script; \n
- whether the check applies to inputs, outputs, or the whole transaction shape; \n
- which cells are actually protected; \n
- what remains only a builder, wallet, or protocol assumption. \n
This is exactly the kind of boundary I would like CellScript metadata and ProofPlan to surface. CellScript should first model those constraint categories explicitly, and only then lower them into lock scripts, type scripts, wrappers, receipts, companion cells, or future L1 mechanisms such as output-lock validation, depending on the target profile and the available semantics.
\nOn the roadmap side, I should probably phrase the v0.14 “script composition” item more carefully.
\nThe wording may have made it sound broader than I intended. Spawn/IPC is real and useful, but I do not see it as the default answer to protocol composability. It is better understood as bounded verifier composition: delegated verification, reusable verifier modules, and modular validation pipelines. It does not make a cell’s type script slot multi-tenant, and it should not be presented as doing so.
The more important semantic layer is really v0.15, where the roadmap moves into scoped invariants and Covenant ProofPlan. That is where CellScript should make trigger, scope, reads, coverage, on-chain enforcement, and builder assumptions explicit.
\nSo the intended layering is:
\n- \n
- v0.14: low-level mechanism for bounded verifier composition; \n
- v0.15: semantic composability through scoped invariants and ProofPlan; \n
- later: combine this with receipts, companion cells, read-only deps, and lock-side or output-lock validation patterns where the coverage is clear. \n
That distinction may not have been clear enough in the roadmap wording, so this is useful feedback.
\nIn that sense, I see the NIP less as a separate concern and more as one of the clearest examples of why CellScript needs to exist. A good language layer should not make the underlying model disappear. It should give developers better instruments for seeing where the model’s real boundaries are.
", "like_count": 0, "quote_count": 0 }, { "post_id": 24032, "post_number": 15, "topic_id": 10193, "topic_title": "CellScript - A DSL for Cell-Based Contracts", "topic_slug": "cellscript-a-dsl-for-cell-based-contracts", "author": "phroi", "created_at": "2026-04-26T02:24:54.605000+00:00", "updated_at": "2026-04-26T02:24:54.605000+00:00", "reply_to_post_number": 14, "url": "https://talk.nervos.org/t/cellscript-a-dsl-for-cell-based-contracts/10193/15", "content_text": "Gotcha!! CellScript is focused on making the current Cell model easier to work with.\nAs it stands, CellScript is already valuable for authors who want typed shared state, receipts, locks, and transaction-shaped effects without working directly with the raw format.\nBecause CellScript already explores composition between cells, I had unwittingly assumed you were exploring a bit further in that direction, toward inter-protocol composing standards. If you ever move in that direction, feel free to tag me!\nKeep up the Great Work, Phroi", "content_html": "Gotcha!! CellScript is focused on making the current Cell model easier to work with.
\nAs it stands, CellScript is already valuable for authors who want typed shared state, receipts, locks, and transaction-shaped effects without working directly with the raw format.
Because CellScript already explores composition between cells, I had unwittingly assumed you were exploring a bit further in that direction, toward inter-protocol composing standards. If you ever move in that direction, feel free to tag me! ![\":hugs:\"](\"https://talk.nervos.org/images/emoji/apple/hugs.png?v=15\" "\\":hugs:\\"")
Keep up the Great Work, Phroi
", "like_count": 0, "quote_count": 0 }, { "post_id": 24034, "post_number": 16, "topic_id": 10193, "topic_title": "CellScript - A DSL for Cell-Based Contracts", "topic_slug": "cellscript-a-dsl-for-cell-based-contracts", "author": "ArthurZhang", "created_at": "2026-04-26T02:48:14.663000+00:00", "updated_at": "2026-04-26T08:44:12.889000+00:00", "reply_to_post_number": 15, "url": "https://talk.nervos.org/t/cellscript-a-dsl-for-cell-based-contracts/10193/16", "content_text": "Thanks Phroi, really appreciate that.\nI do think inter-protocol composition standards are a very interesting longer-term direction. My current instinct is that this probably belongs more naturally at a CellFabric layer than inside the core CellScript language alone.\nThe way I currently separate the responsibilities is roughly:\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.\nSo CellScript should first make lock/type boundaries, receipts, read_ref, witnesses, builder assumptions, and ProofPlan coverage visible for individual protocols.\nA higher CellFabric layer could then describe how protocols expose intents, receipts, conflict keys, settlement plans, read/write boundaries, verifier interfaces, and ProofPlan coverage to one another.\nI would not frame CellFabric as a replacement for lower-level validation changes such as output-lock validation. That still seems like a separate L1 semantics question. But I do think the broader motivation is related: protocols need safer and more explicit composition surfaces.\nI had sketched a related direction here, and I suspect it may eventually be a better home for this kind of inter-protocol composition work, though it would need refinement if framed specifically around the NIP.\nI will definitely tag you if I start exploring this layer more seriously.", "content_html": "Thanks Phroi, really appreciate that.
\nI do think inter-protocol composition standards are a very interesting longer-term direction. My current instinct is that this probably belongs more naturally at a CellFabric layer than inside the core CellScript language alone.
\nThe way I currently separate the responsibilities is roughly:
\n- \n
- CellScript: authoring and compiling individual cell protocols, including ProofPlan metadata that makes guarantees, coverage, and assumptions explicit; \n
- CellFabric: a higher inter-protocol intent and composition layer, describing how different protocols coordinate with each other before final CKB settlement. \n
So CellScript should first make lock/type boundaries, receipts, read_ref, witnesses, builder assumptions, and ProofPlan coverage visible for individual protocols.
A higher CellFabric layer could then describe how protocols expose intents, receipts, conflict keys, settlement plans, read/write boundaries, verifier interfaces, and ProofPlan coverage to one another.
\nI would not frame CellFabric as a replacement for lower-level validation changes such as output-lock validation. That still seems like a separate L1 semantics question. But I do think the broader motivation is related: protocols need safer and more explicit composition surfaces.
\nI had sketched a related direction here, and I suspect it may eventually be a better home for this kind of inter-protocol composition work, though it would need refinement if framed specifically around the NIP.
\nI will definitely tag you if I start exploring this layer more seriously.
", "like_count": 0, "quote_count": 0 } ] } ] }