《超话区块链 # 20200507》

本文出自微信群： 【【2020.2】FISCO BCOS官方技术交流】

每周弄懂一个区块链问题，《超话区块链》第50期欢迎大家，感谢一直以来的陪伴！

在日常开发中，相信大家都会遇到这些问题：什么是“上链”？什么数据和逻辑应该“上链”？文件能不能上链？链上能不能批量查数据？“链下”又是什么？


本次分享，FISCO BCOS首席架构师张开翔 将为大家厘清这些关于“链上”与“链下”的疑问。

分享大纲：

• 什么是“链上”和“链下”
• 交易之轻和“上链”之重
• 让“链上”归链上，“链下”归链下
• 如何做到“上”“下”自如

一、什么是“链上”和“链下”

在数据层面，区块链指的是链式数据结构的“数据链”，在网络层面区块链则是多个节点构成的“节点链”。


交易“上链“，即交易被共识确认，达成”分布式事务性“，相关数据在所有节点都被存储，冗余可用，难以篡改，可以追溯。
上链这事儿，”共识“和”存储“缺一不可。


与区块链不直接相关，没参与共识，也不改变链上数据，无需保存的操作，都属于“链下”逻辑。如查询一下链上状态，不叫“上链”。

二、交易之轻和“上链”之重

“上链”的整个过程存在共识算法开销、加解密和智能合约计算开销、网络广播开销、存储开销。
这些开销比中心化服务要大，是在分布式系统中形成“信任”的额外成本，不可或缺，
但作为设计者，正视“交易之轻和链上之重”，积极“上链”的同时减少不必要的开销，找到平衡之道，避免滥用链上资源，出现“公地悲剧”。

三、让“链上”归链上，“链下”归链下

除了考虑开销，本质上，开发者应该让区块链干自己最该干的事情。
链上聚焦多方协作，尽快达成共识，营造或传递信任，将好钢用到刀刃上。
那些非全局性的、无需多方共识的、数据量大的、计算繁杂的…通通放到链下实现，一个好汉三个帮。
这就要求开发者对业务和技术都有相当的把握。


为避免过于抽象，下面给出几个例子：

💡 文件能不能上链？

文件的尺寸较大，且通常是点对点或局部分享，如果在链上广播整个文件，会有不必要的网络传输和存储开销。
一般将文件的HASH和非敏感信息上链，而文件的明文采用私有存储、云存储、IPFS等方案存在链下。
在分享文件时，采用点对点通道传输，或者授权对方下载，获得明文的用户可以到链上校验文件的完整性和正确性。


需要注意的是，IPFS这种分布式文件系统，实际上已经使文件内容以分片形式离开了私有环境，如果文件内容私密级很高，慎用。



💡 怎么批量查询和分析数据

区块链底层存储采用k-v结构，不适合范围查询和复杂分析，而且查询和分析操作本身并不需要链上共识，任何一个拥有数据的节点都可以独立完成。
推荐从链上完整导出所有数据到链下的数据库（如MySQL）、大数据平台等，采用这些强大的引擎建立索引、进行复杂查询、交叉分析。
区块链数据本身只增不减，且具有可自校验的特征，只要导出完整，在链上链下处理都是没有区别的。


区块链浏览器、运营管理台、运维监控、审计分析等系统，都是用的这种策略。

💡 复杂逻辑和计算

复杂业务逻辑指交易流程中关系复杂、流程繁杂的部分，如果智能合约里包含了不必要的复杂逻辑，会拖慢整条链的速度，甚至拖垮。
我们推荐编写尽量精简的、“小而美”的智能合约，将每个接口控制在百行规模，合约只包含牵涉多方协作、需要共识、共享和公示的部分流程和数据，将遍历、排序、统计等逻辑，以及密集计算的模块放到链下去实现。


开发者拿出计算和存储成本最小的合约，有着“如无必要勿增实体”的奥卡姆剃刀式美感，是对链上所有参与者的尊重和负责。

💡 即时消息：快速协商和响应

“上链”的响应时间取决于共识算法和系统负载，在10分钟到秒级不等，一般达不到毫秒级。
那么对于频繁交互且要求快速响应的场景，通常是采用类似“闪电网络”这样的链外点对点通道，在通道中频繁交互，最后和链上结合统一记账，既保证用户体验，又保证账务安全。


在我们的开源区块链底层平台中，提供了AMOP（链上信使协议），利用已经搭建起来的区块链网络，实现跨节点的实时、安全、点对点通信，可以实现即时消息、快速协商、事件通知、交换秘密、构建私有交易等一系列功能，推荐。


AMOP可参考：https://fisco-bcos-documentation.readthedocs.io/zh_CN/latest/docs/manual/amop_protocol.html

💡 链下信息如何可信上链

先看第一种情况，如果要用到不可能在链上原生的信息，诸如赛事结果、天气、汇率等，那么可以采用**“预言机”**（Oracle）机制,
其基本思路是由一个或多个链下可信机构将信息写到链上的公共合约，链上其他业务合约统一使用这一份信息，不会出现歧义。
考虑到安全和效率，预言机（Oracle）会有多种具体做法，实现起来相当有趣。




更进一步的灵魂拷问是：“如何保证上链的数据是真实的？”


其实，区块链并不能从根本上保证链下数据的可信性，只能保证信息一旦上链，就是全网一致且难以篡改的。
区块链要跟实体经济结合，现实世界里的“信息流、商流、物流、资金流”要可信上链，就会用到
物联网（传感器、摄像头）、人工智能（模式识别、联邦学习）、大数据分析、可信机构背书等多种技术和方式，
这已经远远超出了区块链的范围。
所以本节的命题其实是：区块链如何和数字世界里的技术广泛结合，更好的发挥自身多方协作、营造信任的作用。

随着数字世界的发展、以及“新基建”的强力推动，信息采集和校验的成本将会降低，在保护隐私的前提下，采集的数据会越来越丰富。如实体物资在使用、转移、回收时，都进行及时采集监测，交叉验证，并上链共识，这样就可以逐渐逼近“物理世界可信上链”的效果。

💡 "链上"还是“链下"治理

区块链治理，指制定行业联盟和业务运作规则，确保规则的执行，处理异常事件，奖励和惩戒参与者等。
完备的链上治理过于复杂，难以实现，尤其在需要达成现实世界法律法规的执行力时，纯链上的实现往往力不从心。
再考虑代码的BUG和升级流程，“Code is Law”还是个理想化的目标，链下治理不可或缺。


链上预置权限控制、冲正补账等控制接口，联盟链管理委员会在链下多方协商、共同决策，将治理指令上链，可全网生效、公开透明。
链上数据具备身份可知、难以篡改、无法否认且可全程追溯等特点，可为链下治理提供完备的数据分析基础。

四、如何做到“上”“下”自如

或许有人会说：“这链上链下什么的太复杂了，我就想用区块链！”


我认为这个说法很对，说到底，用户就想要一条趁手的“链”。作为开发者，实际上要是提供“围绕着区块链的一系列能力”，并按需打包，开箱即用。最终呈现的“链”，除了节点上的底层平台之外，还会有区块链浏览器、管理台、监控和审计系统、业务模板、APP/小程序等一系列交互入口，用户只需动动鼠标，点点页面，调调接口，就可以一站式体验完整的区块链应用，不用分什么“链上”和“链下”，浑然一体。


DID的规范 以及 WeIdendity 的实现是很好的链上链下结合例子，链上实现分布式协作，数据存在链下，很好地实现了个人隐私保护和多中心的平衡，规范优雅，逻辑自洽，推荐。

结语

区块链其修远兮，吾将“上下”而求索。在未来，“可信的”区块链将越来越多地和人们日常生活、实体经济联动，步入寻常百姓家。
作为从业者，保持开放的心态，积极而创新的将区块链与更多技术结合，无论作用于链上还是链下，只要能解决问题，创造价值，就是一条好链。