什么是“链上”？哪些数据和逻辑应该“上链”？文件可以上链吗？什么是“链下”？很多关于“链上”和“链下”的问题，一篇文章就可以搞清楚。什么是“链上”和“链下”区块“链”链，包括“数据链”和“节点链”。数据上链是指采用链式结构，将区块数据组织起来，形成数据验证、溯源的链条；“节点链”是指多个节点通过网络连接在一起，相互共享信息，共识节点共同执行共识算法，生成并确认区块。交易“上链”的简要过程如下：簿记员记录交易，并按照链上数据结构将其打包成“块”。共识算法驱动大家对新区块中的交易进行验证，保证计算结果一致。数据广播到所有节点并安全存储，每个节点将存储数据的完整副本。一旦交易“上链”，就意味着它已经完全执行，实现了“分布式交易性”。简单的说，就像是一段话，经过集体的认可，发布在了布告栏上。文字不错，而且永久可见，不可更改。“链上”意味着“共识”和“存储”，两者缺一不可。如果交易不经过共识，则无法保证一致性和正确性，也无法被链上所有参与者接受；共识后的数据不由多方存储，这意味着数据可能会丢失或被一方篡改，更不用说冗余可用性了。另外，如果只是调用接口查询，不改变链上的任何数据，不需要确认共识，也不算“上链”。或者，一个业务服务本身与区块链没有直接关系，或者其业务流程不需要参与共识，产生的数据也不写入节点存储，那么这个业务服务就称为“链下服务”》，无论是否与区块链节点共同部署在同一台服务器上，甚至与节点进程一起编译。当该业务服务调用区块链接口发送交易，交易完成“共识”和“存储”时，称为“上链”；如果交易没有按预期打包处理，可以称为“链上失败”。”。事实上，几乎所有的区块链系统，尤其是与实体经济和现实世界相结合的区块链应用，都需要链上和链下协同，并以“混合架构”实现。系统本身包含丰富的技术生态.注1：交易是区块链中的一个总称，泛指发送到区块链的一段指令和数据，会改变链上的数据和状态注2：本节描述一个简要的模型，在多层链，在分片模型中，流程会更复杂，交易划分会更细，但“共识”和“存储”是on-chain的基本原则。随着它的成熟，性能和成本不再是大问题，但由于“分布式多方协作”，固有的开销如下：oS（ProofofEquity）需要抵押资产获得记账权；PBFT（联盟链常用的拜占庭容错算法）记账人要完成多次往返投票，流程步骤复杂。计算开销：除了加解密、协议解析等计算外，在支持智能合约的区块链上，为了验证合约的执行结果，所有节点都会胡乱执行合约代码，影响了全身。网络开销：与节点数成指数关系。节点越多，网络传输次数越多，带宽和流量开销就越大。如果数据包太大，那就更糟了。存储开销：与节点数量成正比，链上所有数据都会写入所有节点的硬盘。在有100个节点的链上，它会变成100个副本。如果有1000个节点，就是1000份。也许有人会说：“这就是‘信任’的代价，值得！”我同意。只是理想不能脱离现实，毕竟硬件资源总是有限的。想象一下，如果每笔交易都是复杂的科学计算任务，那么每个节点的CPU和内存都会爆满；如果每笔交易都包含很大的图片或视频，那么整个网络的带宽和每个节点的存储都会非常大。它即将被淹没；如果每个人都对滥用“链上”资源持开放态度，“公地悲剧”将不可避免。调用API发送交易非常容易，链上的开销就像房间里的大象，很难忽视。作为开发者，需要正视“交易之轻，链上之重”，在减少不必要开销的同时积极“上链”，找到平衡的方法。注1：常规联盟链节点参考配置：8核/16G内存/10M外网带宽/4T硬盘，不考虑“矿机”等特殊配置。土豪是自由的，俗话说“钱能解决的问题不是问题，问题是……”注2：本节不讨论“本地/分片共识”，也不讨论情况“平行扩张”。默认情况下，假设所有Network参与共识和存储，允许“on-chain”在链上，“off-chain”在链下。成本只是成本问题，但本质上应该让区块链做它最应该做的事情。注重链上多方协作，尽快达成共识，建立或传递信任，把好钢用到刀刃上；那些不是全局的，不需要多方共识，数据量大，计算复杂……都把他们链下实现了，一雄三帮。怎么剪？在业务层面，找准多方协同交易和数据共享的“最大公约数”，抓住重点痛点，有所作为；在技??术上，合理设计多层结构，扬长避短，因地制宜使用各种技术，避免采取一锤子一锤定音，一招制天下的思想。为避免过于抽象，下面举几个例子。注意：每个例子其实都有很多细节。考虑到篇幅，这里简单介绍一下，重点介绍链上链下的区别和有机结合。文件可以上传到链上吗？这是一个非常常见的问题，经常被问到。这里的文件一般是指图片、视频、PDF等，也可以指大规模的数据集。链上可信共享的目的是让接收者能够验证文件的完整性和正确性。在常见的场景下，文件共享一般是本地化和点对点的，而不是广播给所有人。把海量数据胡乱存储在区块链上会很吃力。因此，计算文件的数字指纹（MD5或HASH），连同一些其他可选信息，如作者、持有人签名、访问地址等上传到链上是合理的。没有太多单链上的信息。文件本身存储在私有文件服务器、云文件存储或IPFS系统中。这些专业的解决方案更适合维护海量文件和超大文件，容量更高，成本更低。注意，如果文件的安全级别达到“一个字节不能泄露给无关人员”的级别，那么就要慎用IPFS等分布式存储方案，优先采用私有存储方式。当您需要与指定好友共享文件时，您可以通过专用传输通道点对点发送文件，或授权您的好友到指定网址下载，可与对方的P2P网络隔离区块链，不占用区块链带宽。好友获取文件后，计算文件的MD5和HASH，与链上对应信息进行比对，验证数字签名，确保接收到正确完整的文件。在该方案中，文件在链上“确认”、“锚定”、“寻址”，明文在链下传输，与链上相互验证，在成本、效率和隐私方面取得了平衡安全。如何批量查询和分析数据？在区块链上分析数据是很自然的需求，比如“某个账户参与了哪些业务流程，完成了多少笔交易，成功率如何？”你参加过多少次区块记账，是否及时，有没有作弊。”这些逻辑会涉及时间范围、区块高度、交易发送方和发送方、合约地址、事件日志、状态数据等维度。目前区块链底层平台普遍采用“键值对”存储结构，具有读写效率极高的优势，但难以支持复杂的查询。其次，复杂的查询逻辑一般在区块生成后进行，时效性稍差，不需要多方共识，具有一定的“离线”性。最后，数据一旦“上链”，就不会改变，只会增加不会减少。数据本身具有明显的特征（如区块高度、相互关联的HASH值、数字签名等）来验证数据的完整性和正确性，没有链上或链下处理的区别，任何节点具有完整的数据可以支持独立的复杂查询。因此，我们可以完全从链上导出数据，包括从创世块到最新的所有区块，所有交易记录和收据，所有交易产生的事件，状态数据等，全部写入关系数据库（如MySQL)或大数据平台构建链上数据的“镜像”，然后利用这些引擎强大的索引模型、关联分析、建模训练、并行任务能力，灵活、全面地查询和分析数据。区块链浏览器、运营管理平台、监控平台、监管审计等系统都会采用这种策略。链上会产生区块，链下会及时存储ETL。进行交互，然后通过接口将交易发送到链上。复杂逻辑与计算和复杂查询略有不同。复杂逻辑是指交易过程中关系复杂、流程复杂的部分。如上所述，链上智能合约会在所有节点上运行。如果智能合约写的过于复杂，或者包含不需要全网共识的冗余逻辑，全网都会承担不必要的开销。一个极端的例子是，如果在合约中写了一个超大数据的遍历逻辑（甚至是死循环），那么全网所有节点都会陷入到这个遍历中，跑来跑去很久，甚至被拖到死亡。除了使用类似GAS的机制来控制逻辑长度，在允许的GAS范围内，我们建议智能合约的设计尽可能简单。单个合约界面包含的代码一百多行，即使比较复杂，也可以考虑是否使用A部分进行反汇编。拆解的边界随着业务的不同而不同，相当考验对业务的熟悉程度。开发者需要对业务进行分层、分模块的解耦，只将涉及多方协作、共识、共享、公示的业务流程部分上链，让合约只包含“必须”而“铁定”要跑在链上的逻辑，合约逻辑“小而美”。一般来说，多方见证的在线协作、公共账本管理、必须与所有人共享的关键数据（或数据HASH）都可以上链，但一些相关的事前或事后的检查和记账、对账和其他逻辑可以适当分解到链下。一些与密集计算相关的逻辑应该尽可能在链下实现。例如，可以设计复杂的加解密算法，生成链下证明，快速验证链上逻辑；如果业务流程涉及到各种数据的遍历，为了排序和统计，在链下建立索引，在链上只做键值对的精准读写。事实上，每当我看到合约中使用映射或数组时，我都会执着地思考是否可以将这部分放在链下服务中。我个人比较欣赏“胖链下”和“瘦链上”的设计取向。强调一下，链上合约逻辑的精简，不全是合约引擎的效率。合约引擎越来越快。核心原因是为了避免“公地悲剧”，同时最大化区块链的有效性。开发者拿出计算和存储成本最低的合约，以“非必要不添加实体”的奥卡姆剃刀般的美感，表达对链上所有参与者的尊重和负责的态度。即时通讯：快速协商和响应受队列调度、共识算法、网络广播等因素制约。“上行”的过程会有些延迟。使用工作量证明共识的链有十几秒到十分钟的延迟。利用DPOS和PBFT的共识，延迟可以缩短到秒级。另外，遇到网络波动、交易拥堵等特殊情况，时延性能会出现抖动。总的来说，与几毫秒或几百毫秒的瞬间交互相比，“缠绕”会显得有些“呆滞”。比如你去超市买一瓶水，付款后一定不能站在那里等十几秒到十几分钟，确认挡块后再走（略尴尬）。对于类似场景，建议将链上预存和链下支付相结合，实现链下点对点通道的高频、快速、低延迟交易，保证链下接收和响应。链，最后将交易双方的账户余额和交易凭证汇总到链上，完成链上的妥善记账。大名鼎鼎的“闪电网络”与此模型类似。此外，在某些业务场景中，会先进行多轮订单撮合、竞价拍卖或议价。一般来说，这些操作发生在本地交易对手之间，并不一定需要全网达成共识，因此也可以通过链下渠道完成，最后是双方的指令（包括协商结果、数字签名、等）发送到链上，完成交易。举个下快棋的例子，棋手的每一步棋都不需要实时上链。将百手的战绩与输赢结果汇总链接在一起，从而记录战绩和发放奖金。如果想回顾棋局的细节（比如视频），可以参考前面提到的链下文件存储方式，用专用服务器或者分布式存储来实现。针对类似需求，FISCOBCOS底层平台提供了AMOP（On-ChainMessengerProtocol），利用已建立的区块链网络实现全网点对点、实时、安全的通信。基于AMOP，可以支持即时通讯、快速协商、事件通知、秘密交换、构建隐私交易等，推荐。链下信息如何可信上传到链上？我们来看一个典型的问题：“智能合约使用链下信息怎么办？”比如世界杯决赛圈竞猜比赛是上链的，但是世界杯不能上链是吧？;或者你需要参考今天的天气。天气明显不是链上的原始信息，应该从气象局获取；这时候就用到了“Oracle甲骨文”。链下一个或多个可信机构将球赛、天气、汇率等信息写入链上公共合约，其他合约使用这一共识确认的可信信息，无歧义。考虑到安全性和效率，预言机会有多种具体的方法，实现起来还是蛮有意思的。灵魂的进一步问题是：“如何保证链上数据的真实性？”坦白说，区块链并不能从根本上保证链下数据的可信度，它只能保证信息一旦上链，就完全网内一致，难以篡改。当区块链与实体经济相结合，势必面临“链上如何可信”的问题。例如，在资产相关的应用中，除了人员管理，“四流合一”，即“信息流、业务流、物流、资金流”进行匹配和交叉验证，将使业务过程更可信。这些“流量”通常发生在链下现实世界中。为了控制它们，可能会使用物联网（传感器、摄像头等）、人工智能（模式识别、联邦学习等）、大数据分析、可信机构背书等。各种各样的技术和方法，已经远远超出了区块链的范畴。因此，本节的命题实际上是：区块链如何与数字世界的技术广泛融合，更好地发挥其在多方协作和建立信任方面的作用。随着数字世界的发展，特别是“新基建”的大力推进，我们相信广泛的数字化可以在保护隐私的前提下降低信息收集和验证的成本，收集的数据会越来越丰富。例如，在使用、流转、回收实物资料时，及时收集和监控，甚至多方、多渠道、多维度的立体收集和监控，并在链上进行共识、公示、锚定，跨-链上和链下验证，使其逐渐接近“物理世界可信链上”的效果，逻辑更严谨，更可信，数据和价值流通更可靠，并且协作的摩擦力会更低。“链上”还是“链下”治理？“治理”就是制定产业联盟和业务运营规则，保证规则的执行，处理异常事件，奖惩参与者等。在理想化的标准下，似乎应该实现链上治理。通过代码的决策、规则的制定和执行，系统在出现问题时具有“自愈”的“超能力”。事实上，完整的链上治理过于复杂和难以实施，尤其是在需要实现现实世界法律法规的执行时，单纯的链上治理往往是不够的。再想想：如果完全依赖代码，如果代码本身有错误，或者需要“required”怎么办？链下的决策者和开发者将如何发现和干预？因此，“CodeisLaw”仍然是一个理想化的目标，链下治理不可或缺。联盟链参与者组成管理委员会，在现实世界民主集中制下进行讨论和决策，共同制定规则，以多重签名和工作流的形式共同发起治理动作，调用区块链接口上链。在链上，包括底层的区块链平台和智能合约，都会内置一系列的决策和控制点，比如支持多方投票决策，从业务层到底层的访问和权限控制能力层，并可以修改业务和节点的参数，可以针对异常情况重置账户，对错误账户进行逆向调整账户等。治理行为和结果通过共识确认，并在链上全网生效。公开透明，接受广泛监督，彰显其合理性和公平性。必要时还可以引入监管和司法仲裁。反过来，联盟链上的数据具有可识别、不可篡改、不可否认和完全可追溯的特点，可以为链下治理决策提供完整的数据基础，也便于为链下实际提供可信凭证。执行。因此，链上和链下的有机结合有助于设计一个完整的、可控的、可持续的治理机制。如何实现“上”“下”自如有人可能会说：“链上链下的东西太复杂了，我想用区块链！”我认为这个说法是非常正确的。说到底，用户想要的是一个触手可及的“链”。作为开发者，我们需要创建一个灵活的、插件化的系统架构来实现各种能力，比如数据导出、文件存储和传输、密集计算、数据收集和异步链接、治理监管、一键部署……。.根据需要选择和选择后，打包开箱即用，实际上提供了“基于区块链的一系列能力”。除了节点，最终呈现的“链”还有区块链浏览器、管理控制台、监控审计系统、业务模板、APP/小程序等一系列交互入口，用户只需移动鼠标，点击页面，调整界面，一站式体验完整的区块链应用。用户会觉得：“这就是区块链”，不需要分“链上”和“链下”，天衣无缝。话虽如此，我推荐一个我认为很棒的设计：分布式身份（DID）。DID是一套涵盖分布式身份管理和可信数据交换的规范。当局为用户完成KYC并颁发凭证。用户将身份摘要发布到链上，并将自己的隐私数据存储在链下（这一点很重要）。用户在使用时采用“明确授权”和“选择性公开”的策略，只需出示少量信息或加密证书，与链上数据进行核对即可证明用户凭证的可信度和数据。“数据走多了，用户跑腿少了”，保护用户隐私的效果可喜。这种设计很好地将链上和链下结合起来，逻辑闭环是自洽的。并不会因为数据存在链下就削弱了链的效能，反而让链的信用模型变得更加重要。DID规范定义了语义清晰、层次清晰的数据结构，以及通用的交互协议。开源项目WeIdentity全面实现了DID协议，提供了丰富的周边支持工具和服务，值得参考。结语链很长很长，我会“上下”搜索一下。未来，“可信”的区块链将越来越多地与人们的日常生活和实体经济联系在一起，走进寻常百姓家。作为从业者，保持开放的心态，积极创新地将区块链与更多技术相结合。不管是链上还是链下，只要能解决问题，创造价值，就是好链。
