江苏龙网

  1. 首页 > 资讯 > 科技 > >

中年|火龙果财经：什么是“链上”和“链下”( 三 )


于是 ， 我们可以将数据完整地从链上导出 ， 包括从创世块开始到最新的所有区块、所有交易流水和回执、所有交易产生的事件、状态数据等 ， 通通写入链外的关系型数据库（如MySQL）或大数据平台 ， 构建链上数据的“镜像” ， 然后可以采用这些引擎强大的索引模型、关联分析、建模训练、并行任务能力 ， 灵活全面地对数据进行查询分析 。
区块链浏览器、运营管理平台、监控平台、监管审计等系统 ， 都会采用这种策略 ， 链上出块 ， 链下及时ETL入库 ， 进行本地化地分析处理后 ， 如需要和链上进行交互 ， 再通过接口发送交易上链即可 。
复杂逻辑和计算
中年|火龙果财经：什么是“链上”和“链下”
本文插图

和复杂查询略有不同 ， 复杂逻辑指交易流程中关系复杂、流程繁杂的部分 。

如上所述 ， 链上的智能合约会在所有节点上运行 ， 如果智能合约写得过于复杂 ， 或者包含其实不需要全网共识的多余逻辑 ， 全网就会承担不必要的开销 。 极端的例子是 ， 合约里写了个超级大的数据遍历逻辑（甚至是死循环） ， 那么全网所有节点都会陷入这个遍历中 ， 吭哧吭哧跑半天 ， 甚至被拖死 。
除了用类似GAS机制来控制逻辑的长度外 ， 在允许的GAS范围内 ， 我们推荐智能合约的设计尽量精简 ， 单个合约接口里包含的代码在百行以上就算是比较复杂的了 ， 可以考虑是否将一部分拆解出去 。
拆解的边界因不同业务而异 ， 颇为考验对业务的熟悉程度 。 开发者要对业务进行庖丁解牛式地分层分模块解耦 ， 仅将业务流程中牵涉多方协作、需要共识、共享和公示的部分放到链上 ， 使得合约只包含“必须”“铁定”要在链上运行的逻辑 ， 合约逻辑“小而美” 。
一般来说 ， 多方见证的线上协同、公共账本管理、一定要分享给全体的关键数据（或数据的HASH）都是可以放到链上的 ， 但相关的一些前置或后续的检验、核算、对账等逻辑可以适当拆解到链下 。

一些和密集计算有关的逻辑 ， 宜尽量将其在链下实现 ， 如复杂的加解密算法 ， 可以设计成链下生成证明链上快速验证的逻辑；如果业务流程中牵涉对各种数据的遍历、排序和统计 ， 则在链下建立索引 ， 链上仅进行Key-Value的精准读写 。
其实 ， 现在但凡看到合约里有用到mapping或array ， 我都会强迫症地想想能不能把这部分放链下服务去 ， 个人比较欣赏“胖链下”和“瘦链上”的设计取向 。
强调一下 ， 精简链上合约逻辑 ， 并不全是因为合约引擎的效率问题 ， 合约引擎已经越来越快了 。 核心原因还是在发挥区块链最大功效的同时 ， 避免“公地悲剧” 。 开发者拿出计算和存储成本最小的合约 ， 有着“如无必要勿增实体”的奥卡姆剃刀式美感 ， 更是对链上所有参与者表达尊重和负责任的态度 。
即时消息：快速协商和响应
中年|火龙果财经：什么是“链上”和“链下”
本文插图

受队列调度、共识算法、网络广播等因素约束 ， “上链”的过程多少都会有一点延时 。 采用工作量证明共识的链 ， 时延在十几秒到10分钟 ， 采用DPOS、PBFT的共识 ， 时延可缩短到秒级 ， 此外 ， 如果遇到网络波动、交易拥挤等特殊情况 ， 时延表现会有抖动 。

总的来说 ， 对照毫秒或百毫秒级响应的瞬时交互 ， “上链”会显得些许“迟钝” 。 比如去超市买瓶水 ， 支付后肯定不能站在那里等十几秒到十分钟 ， 链出块确认后才走吧（略尴尬） 。
对类似场景 ， 宜结合链上预存和链外支付 ， 在链下的点对点通道实现高频、快速、低延时的交易 ， 链下确保收妥和响应 ， 最后将双方的账户余额、交易凭据汇总到链上 ， 在链上完成妥善记账 。 著名的“闪电网络”就类似这种模式 。


推荐阅读


上一篇：青年|网络文明，始于你我！

下一篇：互联网|未成年人网络直播“隐秘的角落”：超四成App存少儿不宜内容