中年|火龙果财经：什么是“链上”和“链下”
什么是“链上”和“链下”
本文插图
区块“链”的链 ， 包含“数据链”和“节点链” 。 数据链指用链式结构组织区块数据 ， 构成数据校验和追溯的链条；“节点链”指多个节点通过网络连接在一起 ， 互相共享信息 ， 其中的共识节点则联合执行共识算法 ， 产生并确认区块 。
交易“上链”的简要过程如下：
1、记账者们收录交易 ， 按链式数据结构打包成“区块” 。
2、共识算法驱动大家验证新区块里的交易 ， 确保计算出一致的结果 。
3、数据被广播到所有节点 ， 稳妥存储下来 ， 每个节点都会存储一个完整的数据副本 。
交易一旦“上链” ， 则意味着得到完整执行 ， 达成了“分布式事务性” 。 简单地说 ， 就像一段话经过集体核准后在公告板上公示于众 ， 一字不错不少 ， 永久可见且无法涂改 。
“上链”意味着“共识”和“存储” ， 两者缺一不可 。 交易不经过共识 ， 则不能保证一致性和正确性 ， 无法被链上所有参与者接受；共识后的数据不被多方存储 ， 意味着数据有可能丢失或被单方篡改 ， 更谈不上冗余可用 。
除此之外 ， 如果仅仅是调用接口查询一下 ， 没有改变任何链上数据 ， 也不需要进行共识确认 ， 则不算“上链” 。
或者 ， 某个业务服务本身和区块链并不直接相关 ， 或其业务流程无需参与共识 ， 所生成的数据也不写入节点存储 ， 那么这个业务服务称为“链下服务” ， 无论它是否和区块链节点共同部署在一台服务器 ， 甚至和节点进程编译在一起 。
当这个业务服务调用区块链的接口发送交易 ， 且交易完成“共识”和“存储”后 ， 才称为“上链”；如果这个交易没有按预期被打包处理 ， 那么可以叫“上链失败” 。
事实上 ， 几乎所有的区块链系统 ， 尤其是和实体经济、现实世界结合的区块链应用 ， 都需要链上链下协同 ， 用“混合架构“来实现 ， 系统本身就包含丰富的技术生态 。
*注1：交易（transaction）是区块链里的通用术语 ， 泛指发往区块链 ， 会改动链上数据和状态的一段指令和数据
*注2：本节描述的是简要的模型 ， 在多层链、分片模型里 ， 流程会更加复杂 ， 事务划分更细 ， 但“共识”和“存储”才叫上链的基本原则不变
交易之轻和“上链”之重
目前区块链底层平台逐步趋于成熟 ， 性能和成本已经不是什么大问题 ， 只是以下几个开销是因“分布式多方协作”而先天存在的：
共识开销：主流共识算法里 ， PoW（工作量证明 ， 也就是挖矿）消耗电力；PoS（权益证明）要抵押资产获得记账权；PBFT（联盟链常用的拜占庭容错算法）记账者要完成多次往返投票 ， 流程步骤繁杂 。
计算开销：除了加解密、协议解析等计算之外 ， 在支持智能合约的区块链上 ， 为了验证合约的执行结果 ， 所有节点都会无差别地执行合约代码 ， 牵一发而动全身 。
网络开销：与节点数呈指数级比例 ， 节点越多 ， 网络传播次数越多 ， 带宽和流量开销越大 ， 如果数据包过大 ， 就更雪上加霜 。
存储开销：和节点数成正比 ， 所有的链上数据 ， 都会写入所有节点的硬盘 ， 在一个有100个节点的链上 ， 就变成了100份副本 ， 如果有1000个节点 ， 那就是1000份 。
也许有人会说：“这就是‘信任’的成本 ， 值得的！”我同意 。 只是理想无法脱离现实 ， 毕竟硬件资源总是有限的 。
想象一下 ， 如果每个交易都是一个复杂科学计算任务 ， 那么每个节点CPU和内存会跑满；如果每个交易都包含一个大大的图片或视频 ， 那么全网的带宽 ， 以及各节点存储很快被塞爆；如果大家都敞开来滥用“链上”资源 ， “公地悲剧”就不可避免 。
调用API发个交易是很容易的 ， 而链上的开销就像房间里的大象 ， 难以视而不见 。 作为开发者 ， 需要正视“交易之轻和链上之重” ， 积极“上链”的同时减少不必要的开销 ， 找到平衡之道 。
*注1：常规联盟链节点参考配置：8核/16G内存/10m外网带宽/4T硬盘 ， 不考虑“矿机”和其他特种配置 。 土豪随意 ， 俗话说“钱能解决的问题都不是问题 ， 问题是...”
*注2：本节暂未讨论“局部/分片共识” ， 也不探讨“平行扩容”的情况 ， 默认假定全网参与共识和存储
让“链上”归链上 ， “链下”归链下
开销只是成本问题 ， 而本质上 ， 应该让区块链干自己最该干的事情 。 链上聚焦多方协作 ， 尽快达成共识 ， 营造或传递信任 ， 将好钢用到刀刃上；那些非全局性的、无需多方共识的、数据量大的、计算繁杂的...通通放到链下实现 ， 一个好汉三个帮 。
如何进行切割？在业务层面 ， 识别多方协作事务和数据共享中“最大公约数” ， 抓住要点痛点 ， 四两拨千斤；在技术上 ， 合理设计多层架构 ， 扬长避短、因地制宜地运用多种技术 ， 避免拿着锤子看什么都是钉子、一招打天下的思维 。
为避免过于抽象 ， 下面给出几个例子 。
*注：每个例子其实都有大量的细节 ， 考虑篇幅 ， 这里做概要介绍 ， 聚焦链上链下的区别和有机结合
文件能不能上链？
本文插图
这是个非常高频的问题 ， 经常被问到 。 这里的文件一般指图像、视频、PDF等 ， 也可以泛指大体量的数据集 ， 上链可信分享的目的 ， 是使接受者可以验证文件的完整性、正确性 。
常见的场景里 ， 文件共享一般是局部的、点对点的 ， 而不是广播给所有人 ， 让区块链无差别地保存海量数据 ， 会不堪重负 。 所以 ， 合理的做法是计算文件的数字指纹（MD5或HASH） ， 并与其他一些可选信息一起上链 ， 如作者、持有人签名、访问地址等 ， 单个上链信息并不多 。
文件本身则保存在私有的文件服务器、云文件存储、或者IPFS系统里 ， 这些专业方案更适合维护海量文件和大尺寸文件 ， 容量更高、成本更低 。 注意 ， 如果文件的安全级别到了“一个字节都不能泄露给无关人等”的程度 ， 那么应慎用IPFS这种分布式存储的方案 ， 优选私有存储方式 。
需要分享文件给指定的朋友时 ， 可以走专用传输通道点对点的发送文件 ， 或者授权朋友到指定的URL下载 ， 可以和区块链的P2P网络隔离 ， 不占用区块链带宽 。 朋友获得文件后 ， 计算文件的MD5、HASH ， 和链上对应的信息进行比对 ， 验证数字签名 ， 确保收到了正确且完整的文件 。
这种方案 ， 文件在链上“确权”、“锚定”和“寻址” ， 明文在链下传输并与链上互验 ， 无论是成本、效率、还是隐私安全都取得了平衡 。
怎么批量查询和分析数据？
本文插图
对区块链上的数据进行分析是自然的需求 ， 比如“某个账户参与哪些业务流程、完成了多少笔交易、成功率如何” ， “某个记账节点在一段时间内参与了多少次区块记账、是否及时、有否作弊” ， 这些逻辑会牵涉到时间范围、区块高度、交易收发双方、合约地址、事件日志、状态数据等维度 。
目前区块链底层平台一般是采用“Key-Value”的存储结构 ， 其优势是读写效率极高 ， 但难以支持复杂查询 。
其次 ， 复杂查询逻辑一般是在区块生成后进行 ， 时效性略低 ， 且并不需要进行多方共识 ， 有一定的“离线”性 。
最后 ， 数据一旦“上链” ， 就不会改变 ， 且只增不减 ， 数据本身有明显特征（如区块高度、互相关联的HASH值、数字签名等）可以检验数据的完整性和正确性 ， 在链上还是链下处理并无区别 ， 任何拥有完整数据的节点都能支持独立的复杂查询 。
于是 ， 我们可以将数据完整地从链上导出 ， 包括从创世块开始到最新的所有区块、所有交易流水和回执、所有交易产生的事件、状态数据等 ， 通通写入链外的关系型数据库（如MySQL）或大数据平台 ， 构建链上数据的“镜像” ， 然后可以采用这些引擎强大的索引模型、关联分析、建模训练、并行任务能力 ， 灵活全面地对数据进行查询分析 。
区块链浏览器、运营管理平台、监控平台、监管审计等系统 ， 都会采用这种策略 ， 链上出块 ， 链下及时ETL入库 ， 进行本地化地分析处理后 ， 如需要和链上进行交互 ， 再通过接口发送交易上链即可 。
复杂逻辑和计算
本文插图
和复杂查询略有不同 ， 复杂逻辑指交易流程中关系复杂、流程繁杂的部分 。
如上所述 ， 链上的智能合约会在所有节点上运行 ， 如果智能合约写得过于复杂 ， 或者包含其实不需要全网共识的多余逻辑 ， 全网就会承担不必要的开销 。 极端的例子是 ， 合约里写了个超级大的数据遍历逻辑（甚至是死循环） ， 那么全网所有节点都会陷入这个遍历中 ， 吭哧吭哧跑半天 ， 甚至被拖死 。
除了用类似GAS机制来控制逻辑的长度外 ， 在允许的GAS范围内 ， 我们推荐智能合约的设计尽量精简 ， 单个合约接口里包含的代码在百行以上就算是比较复杂的了 ， 可以考虑是否将一部分拆解出去 。
拆解的边界因不同业务而异 ， 颇为考验对业务的熟悉程度 。 开发者要对业务进行庖丁解牛式地分层分模块解耦 ， 仅将业务流程中牵涉多方协作、需要共识、共享和公示的部分放到链上 ， 使得合约只包含“必须”“铁定”要在链上运行的逻辑 ， 合约逻辑“小而美” 。
一般来说 ， 多方见证的线上协同、公共账本管理、一定要分享给全体的关键数据（或数据的HASH）都是可以放到链上的 ， 但相关的一些前置或后续的检验、核算、对账等逻辑可以适当拆解到链下 。
一些和密集计算有关的逻辑 ， 宜尽量将其在链下实现 ， 如复杂的加解密算法 ， 可以设计成链下生成证明链上快速验证的逻辑；如果业务流程中牵涉对各种数据的遍历、排序和统计 ， 则在链下建立索引 ， 链上仅进行Key-Value的精准读写 。
其实 ， 现在但凡看到合约里有用到mapping或array ， 我都会强迫症地想想能不能把这部分放链下服务去 ， 个人比较欣赏“胖链下”和“瘦链上”的设计取向 。
强调一下 ， 精简链上合约逻辑 ， 并不全是因为合约引擎的效率问题 ， 合约引擎已经越来越快了 。 核心原因还是在发挥区块链最大功效的同时 ， 避免“公地悲剧” 。 开发者拿出计算和存储成本最小的合约 ， 有着“如无必要勿增实体”的奥卡姆剃刀式美感 ， 更是对链上所有参与者表达尊重和负责任的态度 。
即时消息：快速协商和响应
本文插图
受队列调度、共识算法、网络广播等因素约束 ， “上链”的过程多少都会有一点延时 。 采用工作量证明共识的链 ， 时延在十几秒到10分钟 ， 采用DPOS、PBFT的共识 ， 时延可缩短到秒级 ， 此外 ， 如果遇到网络波动、交易拥挤等特殊情况 ， 时延表现会有抖动 。
【中年|火龙果财经：什么是“链上”和“链下”】
总的来说 ， 对照毫秒或百毫秒级响应的瞬时交互 ， “上链”会显得些许“迟钝” 。 比如去超市买瓶水 ， 支付后肯定不能站在那里等十几秒到十分钟 ， 链出块确认后才走吧（略尴尬） 。
对类似场景 ， 宜结合链上预存和链外支付 ， 在链下的点对点通道实现高频、快速、低延时的交易 ， 链下确保收妥和响应 ， 最后将双方的账户余额、交易凭据汇总到链上 ， 在链上完成妥善记账 。 著名的“闪电网络”就类似这种模式 。
另外 ， 有些商业场景会先进行多轮的订单撮合、竞价拍卖或讨价还价 。 一般来说 ， 这些操作是发生在局部的交易对手方之间 ， 未必需要全网共识 ， 所以也可以通过链下通道完成 ， 最后将双方的订单（包含双方磋商结果、数字签名等信息）发送到链上 ， 完成交易事务即可 。
举个下快棋的例子 ， 棋手的每一步棋并不需要实时上链 ， 双方只管啪啪地下 ， 裁判和观众只管围观 ， 在棋局结束时 ， 比如总共下了一百手 ， 那么将这一百手的记录汇总起来 ， 连同输赢结果上链 ， 以便记录战绩分配奖金 。 如果要复盘棋局详情（如视频） ， 可以参考上文提及的链下文件存储模式 ， 用专用的服务器或分布式存储实现 。
针对类似需求 ， 在FISCO BCOS底层平台中 ， 提供了AMOP（链上信使协议） ， 利用已经搭建起来的区块链网络 ， 在全网范围实现点对点、实时、安全的通信 。 基于AMOP ， 可以支持即时消息、快速协商、事件通知、交换秘密、构建私有交易等 ， 推荐 。
推荐阅读
- | 万多福开心果开心补给站亮相上海外滩BFC创意集市
- 热点|因小孩玩火引燃，407岁梨树被烧空心仍能结果，靠树皮吸收养分
- 搜狐|92号加成了95号，汽车加油加错号了，有什么严重的后果吗？
- 终于|十四年后，那句“不是你撞的为什么要扶”, 终于酿成了恶果
- 国际社会|英国一甜品加工厂出现聚集性感染 72名工人新冠病毒检测结果呈阳性
- 男士补水面膜哪款效果好 男士控油补水面膜排行榜10强
- 减肥|JAMA：减肥要趁早，25岁就该开始预防中年期肥胖
- 人见人厌，国见国烦，蓬佩奥再访欧洲欲对抗中俄，结果却碰了壁
- 漏洞|华为称继续向预装Google Play手机提供更新；Mac纳入苹果独立维修商维修范围；三星智能手机生产
- 苹果|苹果将于8月28日终止Epic Games的开发者账号