本文解释了区块链的“链上”和“链下”

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

“链上”和“链下”诸多问题，本文将一一厘清。

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

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

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

簿记员收集交易并根据链式数据结构将其打包成“块”。共识算法促使每个人验证新区块中的交易，以确保计算出一致的结果。数据广播到所有节点并安全存储，每个节点存储数据的完整副本。

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

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

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

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

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

事实上，几乎所有的区块链系统，尤其是与实体经济和现实世界相结合的区块链应用，都需要链上链下协同。蕴含丰富的技术生态。

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

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

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

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

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

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

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

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

为避免过于抽象，下面举几个例子。

文件可以上传吗？

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

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

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

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

在该方案中，文件在链上“确认”、“锚定”、“寻址”，明文在链下传输，与链上进行验证，无论是成本、效率还是隐私安全都是平衡的.

如何批量查询分析数据？

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

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

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

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

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

区块链浏览器、运营管理平台、监控平台、监管审计等系统都会采用这种策略。区块在链上生成，ETL 及时存储在链下。经过本地化分析处理后，如果需要与链交互，可以通过接口将交易发送到链。

复杂的逻辑和计算

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

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

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

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

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

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

实际上，每当我看到合约中使用的地图或数组时，我都会着迷地思考是否可以将这部分放在链下服务中。就个人而言，我很欣赏“fat off-chain”和“slim off-chain”。链上”的设计方向。

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

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

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

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

对于类似的场景，建议将链上预存和链下支付结合起来，在链下点对点渠道中实现高频、快速、低延迟的交易。账户余额和交易凭证汇总到链上，并在链上完成适当的记账。著名的“闪电网络”与此模型类似。

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

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

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

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

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

比如链上有个世界杯决赛问答游戏，但是不能上链玩世界杯；或者你需要参考今天的天气，天气显然不是链上的原始信息，应该从气象局获得；在跨境业务中，可以使用法定汇率，汇率必须来自权威机构，不能在链上凭空产生。

此时使用“预言机”，链下一个或多个可信机构将足球比赛、天气、汇率等信息写入链上公共合约，其他合约统一会有使用此经共识确认的可信信息时不要含糊不清。考虑到安全性和效率，预言机会有各种具体的实践，实施起来非常有趣。

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

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

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

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

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

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

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

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

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

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

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

p>

在链上，包括区块链底层平台和智能合约，都会有一系列的内置决策和控制点，比如支持多方投票决策，从业务层接入到底层可以修改服务和节点的参数，异常情况重置账户，纠正错误账户和调整账户等。

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

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

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

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

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

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

说到这里，我推荐一个我认为很棒的设计：分布式身份（DID）。

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

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

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

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

结束语

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