今天我推荐你读“链上”和“链下”

什么是“链上”？哪些数据和逻辑应该“链接”？文档可以链接吗？可以批量查询链上的数据吗？什么是“锁链下”？

“链上”和“链下”是许多问题。

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

区块链，包括数据链和节点链。数据链是指采用链结构组织块数据形成数据验证和可追溯性的链；“节点链”是指通过网络连接的多个节点，彼此共享信息，其**识节点共同实现共识算法生成和确认块。

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

一。簿记员收集交易，并根据链接的数据结构将其打包成“块”

二。一致性算法驱使您验证新块中的事务，以确保结果一致。

3数据被广播到所有节点并安全存储。每个节点将存储数据的完整副本。

一旦事务处于“链上”，就意味着它已经完全执行，并且已经实现了“分布式事务”简而言之，这就像一段经过集体批准后，在公告栏上公开展示的文章。这个词不错。它是**的，不能改变。

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

此外，如果您只调用接口进行查询，而不更改链上的任何数据或不需要一致确认，则它不是“链上”

或者，业务服务本身与区块链没有直接关系，或者其业务流程不需要参与共识，生成的数据也不写入节点存储，那么该业务服务称为“链下服务”，无论它是与区块链节点一起部署在服务器中，还是甚至与节点进程一起编译。

当业务服务调用区块链接口发送交易，交易完成“共识”和“存储”时，称为“上行”；如果交易未按预期打包，则称为“上行失败”

事实上，几乎所有的区块链系统，特别是与实体经济和现实世界相结合的区块链应用，都需要在链上和链下进行合作，采用“混合架构”来实现，系统本身蕴含着丰富的技术生态。

*注1：交易是区块链中的一个通用术语，通常是指发送到区块链的一段指令和数据，该指令和数据将改变链上的数据和状态

*注2：本节描述了一个简单的模。在多层链式和分片模中，流程将更加复杂，事务将更加仔细地划分。但是，“共识”和“储存”的基本原则是一样的

交易的轻与“上链”的重

目前，区块链的底层平台正逐步走向成熟。性能和成本不是大问题，但由于“分布式多方合作”，以下成本是固有的：

一致性代价：在主流一致性算法中，pow（workload proof，即挖矿）消耗能量；POS（equity proof）需要抵押资产才能获得记账权；pbft（Byzantine容错算法，常用于联盟链）需要完成多个往返投票，过程步骤复杂。

计算成本：除了加密解密、协议解析等计算外，在支持智能合约的区块链中，为了验证合约的执行结果，所有节点都会不分青红皂白地执行合约代码，逐一移动全身。

网络开销：它与节点数成指数比例。节点越多，网络传播时间越长，带宽和流量开销就越大。如果数据包太大，情况会更糟。

存储开销：与节点数成正比，链中的所有数据将写入所有节点的硬盘。在具有100个节点的链中，它将成为100个副本。如果有1000个节点，则为1000个副本。

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

想象一下，如果每个事务都是一个复杂的科学计算任务，那么每个节点的CPU和内存都会满负荷运行；如果每个事务都包含一幅大图片或视频，那么整个网络的带宽以及每个节点的存储都会很快被阻塞；如果每个人都公开滥用“链上”资源，“公地悲剧”将不可避免。

调用API发送事务很容易，链上的开销就像房间里的大象，很难忽略。作为开发者，我们需要正视“交易轻、链条重”，在减少不必要开支的同时，积极“上链”，找到平衡的方法。

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

*注2：本节不讨论“本地/分区一致性”或“并行扩展”默认情况下，假设整个网络参与一致性和存储

让“链上”上升，“链下”下降

管理费用只是一个成本问题。实际上，区块链应该做它应该做的事情。关注链条上的多方合作，尽快达成共识，建立或转移信任，用好刀刃上的钢；那些非全局、非多方共识、海量数据、复杂计算都是在链条下实现的，一个英雄、三个帮手。

如何切割？在业务层面，识别多方协同事务和数据共享中的“**公约数”，抓住关键点，朝着四两个方向努力；在技术上，合理设计多层架构，扬长避短，因地制宜地应用各种技术，避免拿锤子看什么是钉子，一招就赢世界。

为了避免过于抽象，这里有几个例子。

*注：事实上，每个例子都有很多细节。考虑到空间，这里有一个简短的介绍。焦点链的差异与有机结合

文档可以链接吗？

这是一个非常频繁的问题，经常被问到。这里的文件通常是指图像、视频、PDF等或大数据集。链上可信共享的目的是使接收方能够验证文件的完整性和正确性。

在常见的场景中，文件共享通常是本地和点对点的，而不是向所有人广播，这样区块链就可以不加选择地存储海量数据，这将不堪重负。因此，计算文件的数字指纹（MD5或hash）并将其与一些其他可选信息（如作者的签名、持有者、访问地址等）链接是合理的，单个链接上没有太多信息。

文件本身存储在私有文件服务器、云文件存储或IPFs系统中。这些专业解决方案更适合维护海量文件和大文件，容量更大，成本更低。需要注意的是，如果文件的安全级别达到“一个字节不能泄露给无关人员等”的级别，则应谨慎使用IPFs的分布式存储方案，优先采用私有存储方式。

当需要与指定朋友共享文件时，可以使用专用传输通道点对点发送文件，也可以授权朋友以指定的URL下载文件，该URL可以与区块链的P2P网络隔离，不占用区块链的带宽。朋友拿到文件后，计算文件的MD5和hash，与链上的相应信息进行比较，验证数字签名，确保收到正确完整的文件。

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

如何批量查询分析数据？

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

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

其次，复杂查询逻辑一般在块生成后执行，时效性稍差，不需要多方协商一致，具有一定的“离线”性质。

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

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

区块链浏览器、运营管理平台、监控平台、监督审计等系统将采用这一策略。当区块出链时，ETL将在链下及时入库。本地化分析处理后，如果需要与链交互，则通过接口将事务发送到链。

复杂逻辑和计算；

与复杂查询不同，复杂逻辑是指交易过程中复杂的部分。

如上所述，链上的智能合约将在所有节点上运行。如果智能合约过于复杂或包含冗余逻辑，不需要整个网络的一致同意，整个网络将承担不必要的开销。在极端情况下，如果契约中写入了一个超大数据遍历逻辑（甚至是一个死循环），那么整个网络中的所有节点都会陷入这种遍历，运行半天，甚至被拖死。

除了使用类似的燃气机制来控制逻辑长度外，我们建议在允许燃气的范围内，智能合约的设计应尽可能简单。如果单个契约接口中包含的代码比100行更复杂，我们可以考虑是否要反汇编其中的一部分。

拆卸的界限因企业而异，这就考验了人们对企业的熟悉程度。开发人员需要以分层和模块化的方式分离业务。只有业务流程中涉及多方协作、需要共识、共享和宣传的部分才放在链条上，使合同只包含“必须”和“必须”在链条上运行的逻辑，合同逻辑是“小而美”

一般来说，网上协作、公共账户管理以及必须共享给各方的关键数据（或散列数据）都可以放在链条上，但一些相关的事前或事后检查、核算、对账等逻辑可以适当分解到链条上。

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

事实上，当我看到契约可以用于映射或数组时，我将不得不考虑是否可以将这部分服务从链式服务中去掉。我很欣赏“脂肪链下”和“细链上”的设计方向。

需要注意的是，在这个链中精简契约逻辑并不完全是为了契约引擎的效率，它已经变得越来越快了。核心原因是在充分发挥区块链**效应的同时避免“公地悲剧”开发者提出了计算和存储成本**的合同，具有“不需要就不添加实体”的Okam剃刀般的美感，也表达了对链上所有参与者的尊重和负责态度。

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

受队列调度、一致性算法、网络广播等因素的制约，“上链”的进程会有一定的延迟。通过使用一致性的工作量证明链，可以将延迟降低到第二级，其范围为几十秒到10分钟。另外，在网络波动、事务拥塞等特殊情况下，延迟性能会有抖动。

一般来说，与毫秒或百毫秒响应的瞬时相互作用相比，“上行链路”会显得有点“慢”例如，如果你去超市买一瓶水，付款后10秒到10分钟内不能站在那里，而且在确认街区之前不能离开。

对于类似的场景，建议将链上预存和链下支付结合起来，实现链下点对点渠道的高频、快速、低延迟交易，确保链下的收货和响应，**汇总链下双方的账户余额和交易凭证，并在链条上做好适当的簿记。**的“闪电网络”与此模式类似。

此外，一些业务场景将从多轮订单匹配、拍卖或议价开始。一般来说，这些操作发生在本地交易对手之间，不需要整个网络的一致意见，因此也可以通过链下的渠道完成。**，将双方的订单（包括双方的咨询结果、数字签名等信息）发送到链上完成交易。

作为一个快速下棋的例子，棋手的每一个动作都不需要实时链接。双方只需破土动工，裁判和观众只需观看。例如，在下棋结束时，如果总共下棋100步，则将这100步的记录与输赢结果汇总在一起，以便记录成绩并分配奖金。如果要重放棋局的详细信息（如视频），可以参考上面提到的离线文件存储模式，用专用服务器或分布式存储实现。

为了满足类似的需求，在FISCO bcos的底层平台上提供了amop（on-chain messenger protocol）。所构建的区块链网络用于在整个网络中实现点对点、实时、安全的通信。基于amop，可以支持即时消息、快速协商、事件通知、秘密交换、私有事务构建等功能，并可推荐。

*注：【金额】详见：

HT年tps://fisco-bcos-documentation.readthedocs.io/zhCN/latest/docs/manual/amop_u协议。HT毫升

如何信任脱机信息？

我们先来看看一个典的问题：“如果我想在智能合约操作中使用链外信息，我应该怎么做？”

例如，有一场世界杯决赛猜谜赛在链条上，但世界杯不能在链条上进行；或者需要参考今天的天气。天气显然不是链条上的原始信息，应该从气象局获得；在跨境业务中，可以使用法定汇率，汇率必须来自一个权威机构，不能在没有基础的链条上产生。

此时，将使用“预言机”链下一个或多个值得信任的机构将把球赛、天气、汇率等信息写入链上的公共合同。其他合同将使用经协商一致确认的可信信息而不含糊。考虑到预言机的安全性和效率，预言机将有多种具体的实现方法，这是非常有意思的。

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

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

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

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

比如，在实物材料的使用、转移和回收方面，及时收集和监控，甚至多方、多维、多维的收集和监控，达成共识，进行宣传，在链条上下锚，在链条上下交叉验证，使“物质世界信任链”的效应能够逐步接近，逻辑会更加严谨，可信度会更高，数据和价值循环会更加可靠，协作摩擦会更少。

“链上”或“链下”治理？

“治理”是指制定行业联盟和企业经营规则，确保规则的实施，处理异常事件，奖惩参与者等。

按照理想的标准，似乎应该实现连锁治理。通过代码的决策、制定和执行规则，系统具有在出错时“自我修复”的“超能力”事实上，完整的连锁治理过于复杂，实现起来非常具有挑战性，特别是在需要实现现实世界法律法规的实施时，单纯的连锁治理往往是不够的。

再考虑一个步骤：如果代码是完全依赖的，那么如果代码本身有错误或者需要“修改”呢？链下的决策者和开发者如何发现和干预？

因此，“法典就是法律”是一个理想的目标，离线治理是不可或缺的。

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

在链中，包括区块链的底层平台和智能合约，有一系列内置的决策和控制点，如支持多方投票决策、具有从业务层到底层渗透的访问和权限控制能力、修改业务和节点，能够在异常情况下重置账户，抵销和调整错误账户等。

治理的行动和成果已得到共识的确认。它们是有效的、全链条的、公开透明的、接受广泛监督的，体现了它们的合理性和公平性。必要时，还可以引入监管机构和司法仲裁。

另一方面，联盟链中的数据具有已知身份、不易篡改、不可否认和全过程可追溯的特点，可以为联盟链下的治理决策提供完整的数据库，并为链下的实际实施提供可信的凭证。因此，链上与链下的有机结合有利于设计完整、可控、可持续的治理机制。

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

也许有人会说：“链太复杂了，我只想用区块链！”

我想那是对的。归根结底，用户想要一个“链”作为开发人员，我们需要构建一个灵活的插件系统架构来实现各种功能，如数据导出、文件存储和传输、密集计算、数据采集和异步链构建、治理和监督、一键部署。。。在按需取舍之后，我们需要将它们打包并使用，这实际上提供了一系列基于区块链的功能。

除了节点，最终的“链”还包括区块链浏览器、管理平台、监控审核系统、业务模板、APP/applet等一系列互动入口，用户只需移动鼠标、点击页面、调整界面，一站式体验完整的区块链应用。用户会觉得“这就是区块链”，没有必要把“链上”和“链下”一分为二。

在这一点上，我推荐一种我认为很好的设计：分布式身份（did）。

Did是一套规范，涵盖分布式身份管理和可信数据交换。该机构为用户完成KYC并颁发凭据。对于用户来说，将其身份摘要发布到链中并将其隐私数据存储在链下是非常重要的。

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

这种设计很好地结合了上链和下链。逻辑闭环的自一致性并不会因为数据存在于链下而削弱链的效率，而是使链的信用模更加重要。

did规范定义了一个具有清晰语义、清晰层和通用交互协议的数据结构。开源项目weidenty充分实现了did协议，提供了丰富的外围支持工具和服务，值得借鉴。

*注：有关【Weidenty】的详细信息，请参见：

HT年tps://fintech.webank.com/weidenty

后记

链子太长了，我要找“上下”未来，“可信”区块链将越来越多地与人们的日常生活和实体经济互动，走进普通百姓的家。作为一名实践者，要保持开放的心态，积极创新地将区块链与更多的技术进行整合。无论是上链还是下链，只要能解决问题，创造价值，就是一条好的链条。