作者：张开翔｜FISCO BCOS 首席架构师

什么是“上链”？什么数据和逻辑应该“上链”？文件能不能上链？链上能不能批量查数据？“链下”又是什么？“链上”、“链下”诸多问题，一文说清。

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


区块“链”的链，蕴含“数据链”和“节点链”。数据链指用链式构造组织区块数据，形成数据校验和追溯的链条；“节点链”指多个节点通过网络连接在一起，相互共享信息，其中的共识节点则联结执行共识算法，产生并确认区块。

交易“上链”的简要过程如下：

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，能够反对即时消息、疾速协商、事件告诉、替换机密、构建公有交易等，举荐。

*注：【AMOP】详情可参考：https://fisco-bcos-documentat...链下信息如何可信上链？

先看一个典型问题：“智能合约运行中要应用链外信息，怎么办？” 比方，链上有个世界杯决赛竞猜游戏，但世界杯不可能在链上踢吧；或者须要参考明天的天气，天气显然不是链上原生信息，应该从气象局获取；在跨境业务中，可能用到法定汇率，而汇率肯定是来自权威机构的，不能在链上凭空生成。这时候就要用到“预言机(Oracle)”，由一个或多个链下可信机构将球赛、天气、汇率等信息写到链上的公共合约，其余合约对立应用这份通过共识确认的可信信息，不会呈现歧义。思考到平安和效率，预言机（Oracle）会有多种具体做法，实现起来相当乏味。

更进一步的灵魂拷问是：“如何保障上链的数据是实在的？”**坦率地说，区块链并不能从根本上保障链下数据的可信性，只能保障信息一旦上链，就是全网统一且难以篡改的。而区块链跟实体经济联合时，势必要面对“如何可信上链”这个问题。如资产相干利用，除了进行人员治理之外，还要“四流合一”，即“信息流、商流、物流、资金流”相互匹配和穿插印证，会使业务流程更加可信。这些“流”经常产生在链下事实世界，要把控它们，可能会用到物联网（传感器、摄像头等）、人工智能（模式识别、联邦学习等）、大数据分析、可信机构背书等多种技术和形式，这曾经远远超出了区块链的范畴。

所以，本节的命题其实是：区块链如何和数字世界里的技术宽泛联合，更好地施展本身多方合作、营造信赖的作用。随着数字世界的倒退、尤其“新基建”的强力推动，咱们置信宽泛的数字化能在爱护隐衷的前提下，升高信息采集和校验的老本，采集的数据会越来越丰盛。如在应用、转移、回收实体物资时，及时采集监测，甚至是多方、多路、多维度立体化的采集监控，并上链进行共识、公示、锚定，链上链下穿插验证，这样就能够逐步迫近“物理世界可信上链”的成果，逻辑会更紧密，更具备公信力，数据和价值流通会更牢靠，合作的摩擦更低。

“链上”还是“链下”治理？

“治理”即制订行业联盟和业务运作规定，确保规定的执行，解决异样事件，处分和惩戒参与者等。以理想化的规范，仿佛应该实现链上治理，通过代码决策、制订和执行规定，出错时零碎具备“自修复”的“超能力”。实际上，齐备的链上治理过于简单，实现起来很有挑战性，尤其在须要达成事实世界法律法规的执行力时，纯链上的治理往往力不从心。再多想一步：如齐全依赖代码，万一代码自身有BUG、或者要“改需要”呢？链下的决策者、开发者如何发现和染指？所以，“Code is Law”还是个理想化的指标，链下治理不可或缺。

联盟链参与者们组成治理委员会，在事实世界里进行民主集中制的探讨和决策，独特制订规定，采纳多签、工作流的形式一起发动治理动作，调用区块链接口上链。在链上，包含区块链底层平台和智能合约在内，都会内置一系列的决策和控制点，如反对多方投票决策，具备从业务层穿透到底层的准入和权限控制能力，可批改业务和节点的参数，能应答异常情况的重置账户，对错账进行冲正调账等等。治理动作和后果通过共识确认，在链上全网失效，公开通明，承受宽泛监督，彰显其合理性和公正性。必要时还能够引入监管方和司法仲裁。反过来，联盟链上的数据，具备身份可知、难以篡改、无奈否定且可全程追溯等特点，可为链下治理决策提供齐备的数据根底，也便于为链下理论执行提供可信的凭据。所以，链上和链下有机联合，有助于设计齐备、可控、可继续的治理机制。

如何做到“上” “下”自若

或者有人会说：“这链上链下什么的太简单了，我就想用区块链！” 我认为这个说法很对。说到底，用户就想要一条趁手的“链”。作为开发者，咱们要打造灵便的、插件化的零碎架构，实现各种能力，什么数据导出、文件存储和传输、密集计算、数据采集和异步上链、治理监管、一键部署……按需取舍后，打包起来开箱即用，实际上提供了“基于区块链的一系列能力”。最终出现的“链”，除了节点之外，还有区块链浏览器、治理台、监控和审计零碎、业务模板、APP/小程序等一系列交互入口，用户只需动动鼠标，点点页面，调调接口，一站式体验到一个残缺的区块链利用。用户会感觉：“这就是区块链”，无需再分“链上”和“链下”，浑然一体。

说到这里，举荐一个我认为十分棒的设计：分布式身份标识（DID）。DID是一套涵盖了分布式身份治理、可信数据交换的标准。权威机构为用户实现KYC，颁发凭据。用户将身份标识的摘要颁布到链上，而将本人隐衷数据存在链下（这一点十分重要）。应用时，用户采纳“明确受权”和“选择性披露”的策略，仅需出示大量的信息或加密证实，与链上数据进行对照校验，即可证实用户凭据和数据可信性，达成了“数据多跑路，用户少跑腿”、爱护了用户隐衷的可喜成果。这种设计很好地将链上链下联合起来，逻辑闭环自洽，并不因为数据存在链下，就减弱了链上的效用，反而使得链的授信模型更为重要。DID标准定义了语义清晰、层次分明的数据结构，以及通用的交互协定。开源我的项目WeIdentity残缺地实现了DID协定，并提供丰盛的周边撑持工具和服务，值得参考。
*注：【WeIdentity】详情可见：https://fintech.webank.com/we...

结语

“链漫漫其修远兮，吾将上下而求索”在将来，“可信的”区块链将越来越多地和人们日常生活、实体经济联动，步入寻常百姓家。作为从业者，放弃凋谢的心态，踊跃而翻新地将区块链与更多技术联合，无论运作于链上还是链下，只有能解决问题、发明价值，就是一条好链。

文章起源：FISCO BCOS开源社区
文章原题目：《一文说清“链上”和“链下”》
如有侵权请与咱们分割删除。