本文只涉及ckb上Dapp开发，含Script和客户端操作。但是不涉及矿池等应用场景。
本文中的代码仅为示例代码，未考虑太多异常情况，不要用于生产环境。
最近半年一直在做ckb上编程模型的研究。尝试并思考了很多有趣的点。
主网上线在即，做一个简短的总结，方便有需要的小伙伴查找。
第一次尝试，参见 GitHub - rink1969/ckb-generator 。
在该项目的README中，介绍了cell编程模型的一些基本情况。
期间着重思考了cell model和account model的区别和关系。
https://rink1969.github.io/Account-Model-VS-UTXO-Model-0
https://rink1969.github.io/Account-Model-VS-UTXO-Model-1
https://rink1969.github.io/Account-Model-VS-UTXO-Model-2
https://rink1969.github.io/Account-Model-VS-UTXO-Model-3
ckb-generator当时的目标太大了，想用一个DSL同时表达合约和客户端的逻辑。后来发现这一点很难做到。
但是这个项目有两点收获：
- 梳理了客户端对sdk的一些高级的接口需求。后续拆分出了 GitHub - rink1969/ckb-rpc-wrapper
- 提出合约组件化的思路。
之后梳理出了一个大概的Dapp开发软件栈。
- 合约采用组件的方式。有利于代码复用；分解功能保证每个组件足够简单可靠。
- 高级的链信息查询缓存服务。参见 GitHub - rink1969/ckb-rpc-wrapper 封装了一些高级的接口，并使用jsonrpc的形式，方便跨语言的调用。同时增加了一个同步live cells到sqlite数据库的功能，可以进行更复杂的查询，同时降低对节点rpc接口的压力。
- 中间是一个资源管理层。使用HD技术，将不同类型的livecells分到不同的账户里面，避免不同类型的livecell混在一起，影响查询操作。使用logic programming给用户提供一种智能的，声明式的编程接口。
- view层。Dapp的业务流程中，会大量涉及到用户的输入，选择等操作，图形化的界面会更加友好。
当前的一些进展：
合约组件部分 ckb-generator/contract/header/components at master · rink1969/ckb-generator · GitHub 有一些简单的示例。
sdk封装部分目前就是 ckb-rpc-wrapper。
view层，为了跨平台，主要考虑基于web的技术。尝试了很多前端的技术框架，受限于本人在这个领域经验太少，没有找到合适的方案，放弃。
资源管理层。尝试了自己设计logic programming框架，技术太小众，参考资料比较少，工作量也太大，放弃；后续尝试了Datalog结合数据库的方式，也碰到了一些问题，目前没有实质性进展。
最新的项目是 GitHub - rink1969/ckb-notebook
使用jupyter lab，可以同时看到代码以及对应的输出。
可以使用基于python的各种库。
包括 datalog（目前碰到一些问题），z3，数据分析的（目前例子比较简单，还没用上），可视化（可以稍微弥补一下没有veiw层的缺憾，但是目前还没涉及）。
还有一些乱七八糟的脑洞，参考我的博客 https://rink1969.github.io/
欢迎有兴趣的小伙伴一起来讨论。