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

什么是“链上”？哪些数据和逻辑应该“链上”？文件可以上传吗？是否可以在链上批量检查数据？什么是“链下”？

“链上”和“链下”问题在一篇文章中进行了解释。

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

区块“链”的链，包括“数据链”和“节点链”。数据链是指利用链式结构将区块数据组织起来，形成一条数据验证和溯源的链；“节点链”是指多个节点通过网络连接在一起，相互共享信息，它们之间的共识节点共同执行共识算法生成并确认区块。

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

一旦交易“上链”，就意味着它被完全执行，实现了“分布式交易性”。简单来说，它就像一个被集体批准并发布在公告板上的段落。好话很多，永久可见，不可更改。

“链上”意味着“共识”和“存储”，两者缺一不可。没有共识的交易不能保证一致性和正确性，不能被链上所有参与者接受；共识后的数据不会被多方存储，这意味着数据可能会丢失或单方面被篡改，更不用说冗余的可用性。

另外，如果只是调用接口查询，链上没有数据发生变化，也不需要共识确认，不认为是“链上”。

或者，一个业务服务本身和区块链没有直接关系，或者它的业务流程不需要参与共识，生成的数据也不写入节点存储，那么这个业务服务就叫做“链下服务”，不管是不是与区块链节点一起部署在服务器上，甚至与节点进程一起编译。

当业务服务调用区块链接口发送交易，交易完成“共识”和“入库”时，称为“链上”；如果交易没有按预期打包和处理，则可以称为“链上失败”。

事实上，几乎所有的区块链系统，尤其是结合实体经济和现实世界的区块链应用，都需要链上链下协同，并以“混合架构”来实现。系统本身包含丰富的技术生态系统。

*注1：交易是区块链中的总称，一般是指发送到区块链上的一段指令和数据，会改变链上的数据和状态。

*注 2：本节描述了一个简短的模型。在多层链和分片模型中，流程会更复杂，交易划分也会更细化，但“共识”和“存储”的基本原理与链是一样的。.

交易的轻量级和“链上”的重要性

目前，区块链底层平台逐渐成熟，性能和成本不再是大问题，但由于“分布式多方协作”，先天存在以下开销：

有人可能会说：“这就是‘信任’的代价，值得！” 我同意。只是理想离不开现实，毕竟硬件资源总是有限的。

想象一下，如果每笔交易都是复杂的科学计算任务，那么每个节点的 CPU 和内存都会被填满；如果每笔交易都包含一张大图片或视频，那么整个网络的带宽和每个节点的存储都会非常高。它即将被超越；如果每个人都对滥用“链上”资源持开放态度，那么“公地悲剧”是不可避免的。

调用API发送交易很容易，链上的开销就像房间里的大象，难以忽视。作为开发者，你需要正视“交易的轻量级和链上的重量”，积极“上链”，同时减少不必要的开销，找到平衡点。

*注1：常规联盟链节点参考配置：8核/16G内存/10m外网带宽/4T硬盘，不考虑“矿机”等特殊配置。土豪随随便便，俗话说“钱能解决的不是问题，问题是……”

*注2：本节不讨论“本地/分片共识”，也不讨论“并行扩展”。默认情况下，假设全网参与共识和存储。

让“链上”去链上，“链下”去链下

开销只是成本问题，本质上，让区块链做它最擅长的事情。专注链上多方协作，尽快达成共识，建立或转移信任，用好钢到边缘；非全局、不需要多方共识、数据量大、计算复杂……都是链下实现的，三帮英雄。

如何进行切割？业务层面，识别多方协同交易和数据共享的“最大公约数”，抓住关键痛点，下功夫；在技​​术上，合理设计多层结构，扬长避短，因地制宜运用多种技术，避免用锤子看什么都是钉子，一招制胜世界。

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

*注：每个示例实际上都有很多细节。考虑到篇幅，这里简单介绍一下，重点介绍链上和链下的区别和有机结合

文件可以上传吗？

这是一个非常高频的问题，经常被问到。这里的文件一般指图片、视频、PDF等，也可以指大规模数据集。链上可信共享的目的是让接收者能够验证文件的完整性和正确性。

在常见的场景中，文件共享一般是本地化的、点对点的，而不是广播给所有人，这样一来，区块链就会被无差别存储海量数据所淹没。因此，计算文件的数字指纹（MD5或HASH）并与其他一些可选信息一起上传是合理的，例如作者、持有人签名、访问地址等。单条链上的信息并不多。

文件本身存储在私有文件服务器、云文件存储或 IPFS 系统中。这些专业的解决方案更适合维护海量文件和超大文件，容量更高，成本更低。注意，如果文件的安全级别达到“不向无关人员泄露单个字节等”的级别，那么就要慎用IPFS等分布式存储方案，首选私有存储方式。

当您需要与指定好友共享文件时，可通过专用传输通道点对点发送文件，或授权好友从指定URL下载，可与用户的P2P网络隔离区块链，不占用区块链带宽。好友获取文件后，计算文件的MD5、HASH，与链上对应信息进行对比，验证数字签名one区块链浏览器，确保收到正确完整的文件。

在该方案中，文档在链上“确认”、“锚定”和“寻址”，明文在链下传输并与链上相互验证，实现了成本、效率和隐私的平衡和安全。

如何批量查询和分析数据？

对区块链上的数据进行分析是很自然的需求，比如“一个账户参与了哪些业务流程，完成了多少笔交易，成功率是多少”，“一个记账节点参与了多少次“区块记账、是否及时、是否有作弊”，这些逻辑会涉及时间范围、区块高度、交易发送方和接收方、合约地址、事件日志、状态数据等维度。

目前区块链底层平台普遍采用“Key-Value”存储结构，具有读写效率极高的优势，但难以支持复杂的查询。

其次，复杂的查询逻辑一般在出块后进行，时效性稍低，不需要多方共识，因此具有一定的“离线”性质。

最后，数据一旦“上链”，就不会改变，只会增加不会减少。数据本身具有明显的特征（如区块高度、相互关联的HASH值、数字签名等），可以验证数据的完整性和正确性。，没有链上或链下处理的区别，任何拥有完整数据的节点都可以支持独立的复杂查询。

因此，我们可以将链上的数据完全导出，包括从创世块到最新的所有区块、所有交易流和收据、所有交易产生的事件、状态数据等，并写入到链外的关系类型中。链。一个数据库（如MySQL）或大数据平台可以为链上数据建立一个“镜像”，然后可以利用这些引擎强大的索引模型、关联分析、建模训练、并行任务能力进行查询灵活全面地分析数据。

区块链浏览器、运营管理平台、监控平台、监管审计等系统都会采用这种策略。区块在链上生成，ETL 及时存储在链下。交互，然后通过接口将交易发送到链上。

复杂的逻辑和计算

与复杂查询略有不同，复杂逻辑是指事务过程中关系复杂、流程复杂的部分。

如上所述，链上的智能合约将在所有节点上运行。如果智能合约写得太复杂，或者包含不需要全网共识的冗余逻辑，全网将承担不必要的开销。一个极端的例子是，合约中写了一个超大数据遍历逻辑（甚至是无限循环），那么整个网络中的所有节点都会陷入这个遍历，运行很长时间，甚至被拖死。

除了使用类似于 GAS 的机制来控制逻辑的长度外，在允许的 GAS 范围内，我们建议智能合约的设计尽可能简单。单个合约接口中包含的代码复杂度超过 100 行。它的一部分被拆卸了。

拆解的界限因业务而异，这是对业务熟悉程度的考验。开发者需要将业务以分层、分模块的方式解耦，只将涉及多方协作且需要共识、共享和公示的部分业务流程上链，让合约只包含“必须”和“固定”。要在链上运行的逻辑，合约逻辑“小而美”。

一般来说，多方见证的在线协作、公共账本管理、必须与所有人共享的关键数据（或数据 HASH）都可以上链，但一些相关的事前或事后检查和记账、对账和其他逻辑可以适当地拆解到链下。

一些与密集计算相关的逻辑应该尽量在链下实现，比如复杂的加解密算法，可以设计生成链下逻辑，进行链上快速验证；如果业务流程涉及到各种数据的遍历，为了排序和统计，在链下建立索引，只在链上进行Key-Value的准确读写。

其实每当看到合约中使用映射或者数组的时候，我都会痴迷地思考是否可以把这部分放到链下服务中。个人比较欣赏“链下脂肪”和“链上”的设计导向。

需要强调的是，精简链上的合约逻辑并不全是因为合约引擎的效率。合约引擎越来越快。核心原因是在发挥区块链最大作用的同时避免“公地悲剧”。开发者拿出计算和存储成本最低的合约，以奥卡姆剃刀般的美学“无必要不加实体”，表达对链上所有参与者的尊重和责任。

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

受队列调度、共识算法、网络广播等因素的约束，“链上”的过程会有一点延迟。使用工作量证明共识链，延迟在十秒到十分钟的范围内。使用 DPOS 和 PBFT 的共识，可以将时延缩短到秒级。另外，如果出现网络波动、交易拥塞等特殊情况，延迟性能会有抖动。

一般来说，相比毫秒或 100 毫秒响应的瞬时交互one区块链浏览器，“上链”会显得有点“迟钝”。比如去超市买瓶水，付款后千万不要站在那里等十秒到十分钟。确认区块后我们再去（有点尴尬）。

对于类似的场景，建议将链上预存和链下支付结合起来，通过链下的点对点通道实现高频、快速、低延迟的交易，确保在链下的接收和响应。链，最后汇总双方的账户余额和交易凭证。到链上，并在链上完成适当的核算。著名的“闪电网络”与此模型类似。

此外，部分业务场景会先进行多轮订单撮合、竞价拍卖或议价。一般来说，这些操作发生在本地交易对手之间，不一定需要全网共识，因此也可以通过链下渠道完成。最后，将双方的订单（包括协商结果、数字签名等信息）发送到链上，即可完成交易交易。

举个快速下棋的例子，棋手的一举一动并不需要实时上链。百手牌记录与输赢结果汇总上传，记录记录，分配红利。如果想查看棋局的细节（比如视频），可以参考上面提到的链下文件存储方式，用专用服务器或者分布式存储来实现。

针对类似需求，FISCO BCOS底层平台提供AMOP（on-chain messenger protocol），利用已建立的区块链网络实现全网点对点、实时、安全的通信。基于AMOP，可支持即时通讯、快速协商、事件通知、交换秘密、构建私密交易等。推荐。

*注：【AMOP】详情请参考：

链下信息如何在链上被信任？

我们先来看一个典型的问题：“如果在智能合约的运行中使用链下信息，我该怎么办？”

例如，有世界杯决赛竞猜赛上链，但世界杯不能上链；或者你需要参考今天的天气，天气显然不是链上的原始信息，应该从气象局获得；在跨境业务中，可能习惯于法定汇率，汇率必须来自权威机构，不能在链上凭空产生。

此时使用“预言机”，链下一个或多个可信机构将足球比赛、天气、汇率等信息写入链上的公共合约，其他合约使用这个共识确认的合约。可靠的信息，没有歧义。考虑到安全性和效率，预言机会有各种具体的实践，实现起来相当有趣。

更进一步的灵魂拷问是：“如何保证链上数据的真实性？” 坦率地说，区块链并不能从根本上保证链下数据的可信度。网络是一致的，难以篡改。当区块链与实体经济结合时，必然会面临“如何信任链”的问题。

比如资产相关的应用，除了人事管理，还要“整合四流”，即“信息流、商流、物流、资金流”进行匹配和交叉验证，这将使业务流程更可信。这些“流动”经常发生在现实世界的链下。为了控制它们，可以使用物联网（传感器、摄像头等）、人工智能（模式识别、联邦学习等）、大数据分析、可信机构的认可等。多种技术和方式，这远远超出了区块链的范围。

因此，本节的命题实际上是：区块链如何与数字世界中的技术广泛融合，更好地发挥其在多方协作和信任建立中的作用。

随着数字世界的发展，特别是“新基建”的大力推进，我们认为广泛的数字化可以在保护隐私的前提下降低信息收集和验证的成本，收集到的数据会越来越丰富。

例如，在使用、转移、回收实物材料时，及时收集和监控，甚至多方、多渠道、多维度的三维收集和监控，以及链上共识、宣传、锚定等。 -链上和链下交叉验证，使其逐渐接近“物理世界可信上链”的效果，逻辑更严谨，更可信，数据和价值流通更可靠，合作摩擦会降低。

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

“治理”是指制定行业联盟和业务运行规则，保障规则的执行、异常事件的处理、参与者的奖惩等。

有了理想化的标准，似乎应该实施链上治理。通过代码决策、制定和执行规则，系统在出现问题时具有“自愈”的“超能力”。事实上，完整的链上治理过于复杂且难以实施，尤其是在需要实现现实世界法律法规的执行时，纯粹的链上治理往往是不够的。

再想一想：如果你完全依赖代码，如果代码本身有bug，或者你想“改变需求”怎么办？链下决策者和开发者如何发现和干预？

因此，“代码就是法律”仍然是一个理想的目标，链下治理必不可少。

联盟链参与者组成管理委员会，在现实世界中进行民主集中讨论和决策，共同制定规则，通过多重签名和工作流的方式共同发起治理行动，并调用区块链接口进行链接。

在链上，包括区块链底层平台和智能合约在内，内置了一系列决策和控制点，例如支持多方投票决策，具有从业务层到终端的访问和权限控制能力。底层，并且可以修改业务和节点的参数，可以用于应对异常情况的重置账户、纠正错误账户和调整账户等。

治理行动和治理结果由共识确认，并在链上全网生效。他们公开透明，接受广泛监督，表现出合理性和公平性。必要时还可以引入监管和司法仲裁。

反过来，联盟链上的数据具有身份已知、不易篡改、不可否认、全程可追溯等特点，可以为链下治理决策提供完整的数据依据，也便于提供可信的链下实际执行的凭据。因此，链上链下的有机结合，有助于设计一个完整、可控、可持续的治理机制。

如何自由地实现“上”和“下”

有人可能会说：“链上链下太复杂了，我就是想用区块链！”

我认为这个说法是正确的。毕竟，用户想要一个方便的“链”。作为开发者，我们需要创建一个灵活的、插件式的系统架构来实现数据导出、文件存储和传输、密集计算、数据采集和异步上传、治理监督、一键部署等各种能力……然后，它是开箱即用的，实际上提供了“基于区块链的一系列能力”。

除了节点，最终呈现的“链”还包括区块链浏览器、管理控制台、监控审计系统、业务模板、APP/小程序等一系列交互入口。用户只需移动鼠标点击页面即可。，调整界面，一站式体验完整的区块链应用。用户会觉得：“这就是区块链”，不需要区分“链上”和“链下”，它是一体的。

话虽如此，我推荐一个我认为非常好的设计：分布式身份（DID）。

DID 是一套涵盖分布式身份管理和可信数据交换的规范。当局为用户完成 KYC 并颁发凭证。用户将身份识别的摘要发布到链上，并将他的私有数据存储在链下（这很重要）。

使用时，用户采用“显式授权”和“选择性公开”的策略，只需出示少量信息或加密证明，与链上数据核对即可证明用户凭证的可信度和数据，实现“数据多出，用户少跑腿”，保护用户隐私的可喜效果。

这种设计很好地结合了链上和链下，逻辑闭环自洽。它并没有因为数据存在于链下而削弱链上的功效，而是使链的信用模型更加重要。

DID 规范定义了语义清晰的分层数据结构和通用交互协议。开源项目WeIdentity全面实现了DID协议，提供了丰富的外围支持工具和服务，值得参考。

*注：[WeIdentity] 详情可在以下网址找到：

结语

链条很长很长，我会“上下”寻找。未来，“可信”区块链将越来越多地与人们的日常生活和实体经济挂钩，走进寻常百姓家。作为从业者，保持开放的心态，积极创新地将区块链与更多技术相结合，无论是链上还是链下，只要能解决问题、创造价值，就是一条好链。

关于作者

FISCO BCOS首席架构师张凯祥。