CN110222109A - 基于分布式账本技术的节点拼接系统、方法及区块链节点 - Google Patents

Abstract

本发明实施例涉及区块链技术领域，公开了一种基于分布式账本技术的节点拼接系统、方法及区块链节点。其中所述的节点拼接方法，包括：获取至少一个区块链节点的API接口定义，所述API接口定义包括：商业命令定义、询问方法定义以及订阅方法定义；将自身的API接口定义与所述至少一个区块链节点的API接口定义进行拼接，生成全景API接口定义；基于所述全景API接口定义，生成全景API接口；通过所述全景API接口，向所述至少一个区块链节点发送商业命令。通过上述方式，本发明实施例解决了传统的分布式账本技术存在去中心化不足的问题，提高DLT生态圈的去中心化程度。

Description

基于分布式账本技术的节点拼接系统、方法及区块链节点

技术领域

本发明涉及区块链技术领域，特别是涉及一种基于分布式账本技术的节点拼接系统、方法及区块链节点。

背景技术

在如今的互联一体化世界中，经济活动都是在跨越国家、地理和司法边界的业务网络中进行的。业务网络通常汇聚在参与者(比如生产者、消费者、供应商、合作伙伴、造市者/推动者和其他项目干系人)云集的市场中，这些项目干系人能够拥有、控制并行使他们在价值对象(也称为资产)上的权力、特权和权利。

资产可以是有形的物理资产(比如汽车、住房或草莓)，也可以是无形的虚拟资产(比如契约、专利和证券)。资产的所有权和转移会在业务网络中创造价值，这个过程被称为交易(transaction)。

交易通常涉及不同参与方，比如买家、卖家和中介(比如银行、审计员或司法人员)，他们的商业协议和合约记录在账本(ledger)中。一个企业通常使用多个账本来跟踪资产的所有权，以及在其各种业务中的参与者之间的资产转移。账本是企业的经济活动和利益的记录系统(System of Record，SOR)。

区块链(Blockchain)是一个由不同节点共同参与的分布式数据库系统，是开放式的账簿系统；它是由一串按照密码学方法产生的数据块或数据包组成，即区块(block)，对每一个区块数据信息都自动加盖时间戳，从而计算出一个数据加密数值，即哈希值(hash)。每一个区块都包含上一个区块的哈希值，从创始区块(genesis block)开始链接(chain)到当前区域，从而形成区块链。在区块链的世界中，世界各地的节点们共同参与了这个网络的记账。例如：比特币通过工作量证明机制，矿工对打包生成的区块求解哈希谜题，并将结果提交至网络，等待其他节点验证并确认区块。

分布式账本技术，是一种在网络成员之间共享、复制和同步的数据库。分布式账本记录网络参与者之间的交易，比如资产或数据的交换。这种共享账本消除了调解不同账本的时间和开支。网络中的参与者根据共识原则来制约和协商对账本中的记录的更新。没有中间的第三方仲裁机构(比如金融机构或票据交换所)的参与。分布式账本中的每条记录都有一个时间戳和唯一的密码签名，这使得账本成为网络中所有交易的可审计历史记录。

目前，在建立跨境跨企业生态圈，企业们期望开发和提供产品和服务，并把交易信息记账到DLT(Distributed Ledger Technology，DLT)。一般专注于数据层去中心化，花大量精力研究DLT底层技术，而忽略了中层平台以及应用层的过度中心化所带来的问题。吸取过去多个DLT项目的经验，并且发现他们犯着类似毛病，专注于初级去中心化。不久，他们慢慢发现搭建跨境或跨企业生态圈所面对的问题，并未解决。例如，搭建DLT平台后期，营运者才发现并未满足本地法规需求。同样，他们也不了解外地司法区的法规需求，将来要跟外地的其他生态圈对接，变得不可能。DLT生态圈营运者过分依赖项目管理办公室(ProjectManagement Office)来处理纠纷。而普遍地，企业之间难以达到共识，造成去中心化不足。由于企业之间建立的生态圈去中心化不足，往往只能提供单一及简单产品，或是依从单一及简单商业流程。

发明人在实现本发明实施例的过程中，发现相关技术至少存在以下问题：传统的分布式账本技术存在去中心化不足的问题。

发明内容

本发明实施例旨在提供一种基于分布式账本技术的节点拼接系统、方法及区块链节点，其解决了传统的分布式账本技术存在去中心化不足的问题。

为解决上述技术问题，本发明实施例提供以下技术方案：

第一方面，本发明实施例提供一种基于分布式账本技术的节点拼接系统，所述系统包括至少两个区块链节点，每一区块链节点包括：

应用层，所述应用层包括API接口以及高反应性中间件，其中，

所述API接口用于拼接至少一个区块链节点的API接口，生成全景API接口；

所述高反应性中间件用于对接应用层和DLT数据层，单向传送所述区块链节点的链上数据和/或链下数据；

商业事件询问数据库，用于所述应用层询问商业事件；

实体投射数据库，用于保存实体的最新状态；

DLT数据层，所述DLT数据层包括链上数据库，用于存储实体的链上数据，其中，所述系统的每一区块链节点共享所述DLT数据层；

链下数据库，用于保存所述实体的链下数据。

在一些实施例中，所述应用层通过智能合约将商业事件写入DLT数据层，或者，通过智能合约询问所述DLT数据层中的商业事件。

在一些实施例中，所述高反应性中间件用于建立实体库，其中，所述实体库包括：

只写不读的实体库，用于写入链上数据；

只读不写的实体库，用于读出链上数据；

可读可写的实体库，用于写入或读出链下数据。

在一些实施例中，每一所述区块链节点安装至少一个应用程序，每一所述应用程序配置不同的用户认证方法，所述区块链节点通过所述应用程序的API接口，调用其他区块链节点的API接口命令，实现对其他区块链节点的链上数据和链下数据的调用；

当所述区块链节点成功写入商业事件后，智能合约对其他区块链节点进行通知。

在一些实施例中，所述API接口嵌入商业领域模型，所述商业领域模型包括：实体的定义、商业命令、发送商业命令的权限、商业事件的定义，其中，每一所述商业命令对应至少一个商业事件，每一所述商业事件包括：商业事件类别、实体类型、实体版本号、实体标识以及负载数据。

在一些实施例中，所述实体对应至少一个还原器，所述还原器用于读取所述实体的历史商业事件，并还原所述实体的最新状态。

在一些实施例中，所述应用层通过智能合约将商业事件写入DLT数据层，若所述商业事件成功写入区块链，则所述DLT数据层生成一成功写入识别码，并将所述成功写入识别码返回应用层。

第二方面，本发明实施例提供一种基于分布式账本技术的节点拼接方法，应用于上述的基于分布式账本技术的节点拼接系统，所述方法包括：

获取至少一个区块链节点的API接口定义，所述API接口定义包括：商业命令定义、询问方法定义以及订阅方法定义；

将自身的API接口定义与所述至少一个区块链节点的API接口定义进行拼接，生成全景API接口定义；

基于所述全景API接口定义，生成全景API接口；

通过所述全景API接口，向所述至少一个区块链节点发送商业命令。

在一些实施例中，所述商业命令包括单一商业命令和复合商业命令，其中，

所述单一商业命令用于将商业事件写入自身的链上数据库，或者，读取自身的实体的最新状态，或者，订阅自身获取的商业事件；

所述复合商业命令用于将商业事件写入自身的链上数据库和链下数据库，或者，从自身的链上数据库和链下数据库获取链上数据和链下数据。

在一些实施例中，所述方法还包括：

所述API接口定义嵌入商业领域模型，生成嵌入模型；

若更新所述商业领域模型，则所述API接口定义对应更新，以更新所述嵌入模型。

在一些实施例中，所述获取至少一个区块链节点的API接口定义，包括：

对所述至少一个区块链节点进行实时模型检查，获取所述至少一个区块链节点的商业命令定义、询问方法定义以及订阅方法定义。

在一些实施例中，所述向所述至少一个区块链节点发送商业命令之前，所述方法还包括：

获取所述至少一个区块链节点的用户访问权限，根据所述用户访问权限，获取所述至少一个区块链节点的链上数据和链下数据。

在一些实施例中，所述获取所述至少一个区块链节点的用户访问权限，根据所述用户访问权限，获取所述至少一个区块链节点的链上数据和链下数据，包括：

获取自身的用户访问权限以及至少一个其他区块链节点的用户访问权限；

通过转发商业命令，处理所述至少一个其他区块链节点的链上数据和链下数据。

在一些实施例中，所述方法还包括：

通过第三方认证方法，以使所述至少一个区块链节点获取其他区块链节点的指定数据。

第三方面，本发明实施例提供一种区块链节点，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述的基于分布式账本技术的节点拼接方法。

第四方面，本发明实施例还提供了一种非易失性计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使区块链节点能够执行如上所述的基于分布式账本技术的节点拼接方法。

第五方面，本发明实施例还提供一种区块链系统，应用上述的节点拼接方法，所述系统包括甲方企业以及乙方企业，所述甲方企业和乙方企业均包括至少一个上述的区块链节点，并且，所述甲方企业和乙方企业的区块链节点布置于跨境的服务器上。

在一些实施例中，所述甲方企业包括：甲方第一节点和甲方第二节点，所述乙方企业包括：乙方第一节点和乙方第二节点，其中，所述甲方第一节点拼接所述甲方第二节点以及所述乙方第一节点，所述乙方第一节点拼接所述甲方第一节点。

在一些实施例中，所述甲方第一节点以及所述乙方第一节点均包括用户实体库以及真姓名实体库，所述用户实体库为链上数据库，所述真姓名实体库为链下数据库。

本发明实施例的有益效果是：区别于现有技术的情况下，本发明实施例提供的一种基于分布式账本技术的节点拼接方法，所述方法包括：获取至少一个区块链节点的API接口定义，所述API接口定义包括：商业命令定义、询问方法定义以及订阅方法定义；将自身的API接口定义与所述至少一个区块链节点的API接口定义进行拼接，生成全景API接口定义；基于所述全景API接口定义，生成全景API接口；通过所述全景API接口，向所述至少一个区块链节点发送商业命令。通过上述方式，本发明实施例解决了传统的分布式账本技术存在去中心化不足的问题，提高DLT生态圈的去中心化程度。

附图说明

一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定，附图中具有相同参考数字标号的组件表示为类似的组件，除非有特别申明，附图中的图不构成比例限制。

图1是本发明实施例提供的现有技术中的依赖关系的示意图；

图2是本发明实施例提供的现有技术中的链上数据的存储示意图；

图3是本发明实施例提供的DLT生态圈的对接示意图；

图4是本发明实施例提供的一种向DLT数据层写入商业事件的示意图；

图5是本发明实施例提供的生成成功写入识别码的示意图；

图6是本发明实施例提供的将商业事件送出到商业事件询问数据库的示意图；

图7是本发明实施例提供的复制商业事件日志的示意图；

图8是本发明实施例提供的更新实体投射数据库以及商业事件询问数据库的示意图；

图9是本发明实施例提供的读出未经运算的商业事件的示意图；

图10是本发明实施例提供的读取实体的最新状态的示意图；

图11是本发明实施例提供的询问实体的最新状态的示意图；

图12是本发明实施例提供的商业命令转化为商业事件的示意图；

图13是本发明实施例提供的还原实体的最新状态的示意图；

图14是本发明实施例提供的嵌入模型的示意图；

图15是本发明实施例提供的简单商业命令的处理示意图；

图16是本发明实施例提供的复合商业命令的处理示意图；

图17是本发明实施例提供的读取乙方商业事件的示意图；

图18是本发明实施例提供的节点拼接的示意图；

图19是本发明实施例提供的一种基于分布式账本技术的节点拼接方法的流程示意图；

图20是本发明实施例提供的第一种应用场景的架构示意图；

图21是本发明实施例提供的第一种应用场景的商业事件写入读出的示意图；

图22是本发明实施例提供的第一种应用场景的商业流程的示意图；

图23是本发明实施例提供的第二种应用场景的架构示意图；

图24是本发明实施例提供的第二种应用场景的用户注册的示意图；

图25是本发明实施例提供的第二种应用场景的建立资产注册处的示意图；

图26是本发明实施例提供的第二种应用场景的建立资产的示意图；

图27是本发明实施例提供的一种区块链节点的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。

区块链技术，也被称之为分布式账本技术，是一种由若干台计算设备共同参与“记账”，共同维护一份完整的分布式数据库的新兴技术。由于区块链技术具有去中心化、公开透明、每台计算设备可以参与数据库记录、并且各计算设备之间可以快速的进行数据同步的特性，使得区块链技术已在众多的领域中广泛的进行应用。

智能合约是指为了方便、验证或者强制执行而将合同变成代码的形式并在约定的条件下自动执行计算机协议。第二代分布式账本技术的出现为智能合约提供了运行的基础。通过智能合约，用户可以创建自己的账本，降低了用户使用分布式账本技术的门槛。通过这个账本，用户可以用于去中心化自治组织的管理，或发行其数字资产，将现实中的资产代币化，例如：黄金代币。

在建立跨境跨企业生态圈，企业们期望开发和提供产品和服务，并把交易信息记账到DLT。由于企业一般专注于数据层去中心化，花大量精力研究DLT底层技术，而忽略了中层平台以及应用层的过度中心化所带来的问题。由于专注于初级去中心化，企业们慢慢发现并未解决搭建跨境或跨企业生态圈所面对的问题，例如：搭建DLT平台后期，营运者才发现并未满足本地法规需求。同样，他们也不了解外地司法区的法规需求，将来要跟外地的其他生态圈对接，变得不可能。

而且，由于DLT生态圈营运者过分依赖项目管理办公室(Project ManagementOffice)来处理纠纷。而普遍地，企业之间难以达到共识，也是去中心化不足的体现。企业们都希望提供独特的产品。通过以财团Consortium形式建立的生态圈，因为去中心化不足，往往只能提供单一及简单产品，或是依从单一及简单商业流程。

传统分布式分类账技术只是专注与把DLT数据层去中心化，而忽略了应用层依然高度中心化的毛病。而深度去中心化(Deep Decentralization)需要同时考虑到用户层和应用层，臻境到全面去中心化。

由于传统分布式分类账技术缺乏深度去中心化，企业搭建的DLT生态圈存在各种问题，例如：演变(Evolution)问题、API方案的问题、数据驻留(Data Residency)问题、信息隐私问题、依赖关系(Dependency)问题、链下数据存储问题等。

演变(Evolution)问题：由于各企业的软件各有不同的版本和更新，当DLT生态圈参与企业越多，架在DLT层以上的应用层，必然碰到演变的需求。在生态圈建立初期，为了尽快投入服务，企业们共同提供单一产品/服务。第一迭代产品采取简单工作流程。一般以最小可行产品发布，并投入服务。不久，个别企业提出要求，追加更多新功能：不光开发共同产品/服务，还需要按个别企业需求，开发独一无异的产品/服务，而每一件追加产品/服务，工作流程不一。因此使得搭建在第一迭代的应用层，便得无法使用。一些企业要求更新至第二迭代，而另一些企业要求不变，停留在第一迭代。并且，企业们都不希望其他企业模仿，希望独立和秘密地追加新功能。新功能若涉及API接口，数据标准或数据模型的变更，便不能避免提出变更请求。而在交易速度上，DLT比较传统交易慢。第一迭代应用层，为了节省开发时间，多数采用旧式网络应用的架构方法，大大影响用户体验。

另外，进入第二迭代或以后，也涉及系统向外对接的需求。有两种向外对接需求，包括：甲方DLT生态圈和乙方DLT生态圈向外对接、甲方DLT生态圈和乙方非DLT生态圈向外对接。

API方案的问题:因为不同品牌的DLT引擎都不兼容，开发人员都避免DLT数据层之间作直接对接，因此均采用传统API层对接。但是这样产生颇多不良影响，包括：API层对接多数以REST来进行。而用户间的协商，必然在API层浮现。两个DLT生态圈，各自有不同的应用程序，不同的DLT技术，不同的管理办法。轻微API改变务必造成大量修改。而且，API之间常常制造出不兼容问题。普遍地，轻微的数据模型改变，便花上数周，甚至数月完成。并且，还存在错误扩散的问题，例如：当一方API接口出现故障，或者，发现安全漏洞时，也为另一方带来同样问题。

数据驻留(Data Residency)问题：目前，企业都需要保护数据免受不必要的访问，无论其地理位置如何。企业一般采取加密方法。跨境跨企业大都通过互联网上的加密信道，把数据或信息从一端传送到另一端。经传送后，双方同样获得相同数据，两个位置存储数据。数据或信息的物理或地理位置变得模糊，造成数据驻留问题。用户不知道他们的数据应该符合发送方或接受方的法律和法规。有不少地区，实施数据或信息不离境政策。企业面临的主要问题之一是确保遵守数据所在地的法律和标准，它带来了许多实施上的困难。企业而言，同一间企业，可能因不同位置的相同数据，而有着不同的数据存储、访问和提供的方式。

信息隐私(Privacy)问题：针对个人信息隐私问题，企业都通过隐私政策声明书，要求客户确认隐私政策。可是，对于跨企业的数据或信息处理手法，隐私政策大多不能防止个人信息隐私泄漏。在传统系统设计，个人信息数据并没有独立处理。根据欧洲订立的通用数据保护规定(General Data Protection Regulation，GDPR)，对个人信息数据管理，有严格要求。若果违反有关规定，将面对严重法律后果。本发明涉及如何处理个人信息，以导致跨企业数据处理手法，同时满足GDPR。我们进行数据匿名化。光是从链上数据，不可能从匿名化的链上数据识别特定个人身分。

请参阅图1，图1是本发明实施例提供的现有技术中的依赖关系的示意图；

依赖关系(Dependency)问题：如图1所示，甲方企业和乙方企业依赖项目管理办公室进行API接口定义、数据标准以及数据模型之间的对接。如用传统API方式,需要长时间的协商,而且方案也不完美。目前，企业之间都必须共同建立单一数据标准(Data Standard)，才能进行信息交换或交易。随着业务需求，这套共同的数据标准和API接口定义也同样更新。企业之间一般花大量人力资源订定，开发，测试，更新，维护和部署。一般做法，他们会组织项目管理办公室(PMO)，制定项目治理办法(Project Governance Rulebook)，数据标准，处理企业之间的矛盾。可是，在典型DLT生态圈，企业之间是合作关系，也同时竞争对手。主要有这些考虑：企业希望制定对自己有利的单一数据标准，同时阻止其他不利改变。企业一般通过投票和协商来解决纠纷，一般不希望分享过多信息，一般不希望投入过多资源。因此，数据标准和API接口的定义便制造了大量的依赖关系。一方企业，对数据标准和数据模型的轻微改变，便需要DLT网络上的每个节点上的用户接口，API接口，应用层，和DLT数据层提出修改。结果，这些变更所带来的影响，快速传递到其他企业。不难看见，一个变更请求便花上数周或数月完成。不同企业的开发人员投入大量资源去协调。

请参阅图2，图2是本发明实施例提供的现有技术中的链上数据的存储示意图；

链下数据存储问题：如图2所示，甲方的链下私有数据和乙方的链下私有数据均保存在共享链下数据库中，目前主流方向，大多数已投产的DLT生态圈，把所有结构性数据存放在DLT数据层。原因在于他们模仿传统RDBMS设计数据模型(Data Model)的设计方法，同样定义数据模型在DLT数据层内，而链下数据以非结构性数据为主，如图片，MSOffice文档，PDF文档，等等。这样安排的好处是开发难度比较低。可是，这办法带来许多副作用。由于所有链上数据，同时传送到所有节点。如甲方节点和乙方节点，各自摆放在属于不同司法区，数据被看待成存储在两个物理位置，导致了前文所述的数据驻留问题。如果这些数据包含了企业私有数据，一方企业不希望分享到其他企业。或者，这些数据包含了个人隐私信息，这便违反了像GDPR之类的法规。并且，无法处理链下结构性数据，同时链下非结构性数据无法通过DLT网络传送。

有一些DLT设计者，尝试把同一数据模型内，把非结构性数据摆放在DLT以外的公共库存(Shared Storage)，通过公共库存，例如共享链下数据库的方式，能够实现容易管理链下的非结构性数据，但是，公共库存是一个高度中心化方法，无法解决数据驻留问题。如此，数据模型，一部分定义在链上，另一部分定义在链下，制造更多更复杂的依赖关系问题(用户间的协商)。

针对企业私有数据(Private Data)，跟GDPR无关。企业交易信息一般只允许摆放在DLT数据层，定义为链上数据(On-chain data)。考虑到DLT网络的交易速度，可扩展性能力和隐私原因，普遍地，DLT设计师也同时，就同一交易的次要内容摆放在DLT以外的数据库，链下数据(Off-chain data)。这样，在企业之间，因为隐私原因，甲方企业便无法获得乙方企业的链下私有数据。

请参阅图3，图3是本发明实施例提供的DLT生态圈的对接示意图；

如图3所示，本发明的设计思路是：在两个DLT生态圈之间，架设一个以DLT为主的抽象层，通过抽象层去除依赖关系，同时阻止错误扩散。在共享同一DLT数据层时，好让个别企业选择独立地开发应用层，或者，共享部分应用层。本发明将目前普遍使用的DLT核心引擎，例如Hyperledger Fabric和Enterprise Ethereum，提升DLT核心引擎去中心化的能力，以应付跨境跨企业的DLT生态圈，在投产上的真正挑战。

通过节点拼接技术，让企业之间在维护隐私前提下，通过单一访问，同时获得甲方的链上数据和乙方的链下数据。通过多种创新的办法，移除这些依赖关系，大大缩减数据变更所需时间，同时，解决了频繁变更而产生的版本管理问题。结合节点拼接技术，把双方企业的摆放数据的物理或地理位置变得清晰明确，企业们可以按当地法规需求进行管理。当要进行跨境读写数据时，节点拼接为他们提供全景数据服务。

本发明通过改良分布式账本技术，来处理跨境跨企业的数据或信息处理手法。这是针对企业级区块链(Enterprise-graded Blockchain)分布式账本技术(DistributedLedger Technology，DLT)的去中心化不足的问题。本发明从不同的技术层面对DLT进行改进或重新设计，下面详细说明本发明的技术方案：

首先对本发明中提及的技术名词进行定义：

商业领域模型(Business Domain Model),类以商业模型/数学模型等，所述商业领域模型基于以实体(Entity)为主的模型。所述商业领域模型包含Entity的定义，商业命令，发出商业命令的权限，商业事件的定义，以及它们的数据类型。

商业事件(Business Event)，当用户层对应用层发出商业命令后，生产出记载负载数据(Payload Data)的商业事件。其中，Payload Data是任何描述Entity状态的数据，没有数据格式限制。

商业事件询问数据库(Business Event Query Database)，是应用层高速缓存(Cache)机制。每当收到实体(Entity)询问时，应用层才运算出Entity的最新状态。所述商业事件询问数据库位于区块链节点的内存。

智能合约(Chaincode)，或称链码，用于执行DLT数据层写入或读出商业事件。当成功写入后，智能合约通知，节点上已订阅的应用程序。

嵌入模型(Decorated Model)，是商业领域模型和API接口的合并，通过延伸商业领域模型，让API接口能直接发布商业领域模型，而无须格式变换。

实体(Entity)，在商业领域模型中，Entity代表着一个独特而独立存在的东西，代表了用户在DLT网络中的一个角色，即身份，所述实体包括：用户类型、用户的商业事件历史、API等具体内容。每个Entity必须配置一个或多个还原器(Reducer)。所述还原器用于把商业事件历史，还原至Entity的最新状态。

实体投射数据库(Entity Projection Database)，是应用层内高速缓存(Cache)机制。每当收到新商业事件写入时，Entity自动地运算出它的最新状态，并写入实体投射数据库。应用层若要查询Entity时，直接从所述实体投射数据库获取，而无须重新运算。

实体库(Entity Repository)，并不是物理数据库，它是由高反应性中间件提供的一个抽象层。应用层只会对着实体库写入或读出商业事件，而完全不知道实体库的物理数据库，通过此方式去掉依赖关系。实体库背后的真实体现，如果是DLT数据层，则称为链上实体库(On-chain Entity Repository)，如果是非DLT数据层，称为链下实体库(Off-chainEntity Repository)。

通用数据保护条例(General Data Protection Regulation)，是欧盟法律中关于欧盟和欧洲经济区内所有人的数据保护和隐私的法规。

链上数据(On-chain Data)，摆放在DLT数据层内的数据，其属于公共数据(PublicData)。目前，Hyperledger Fabric提供链上私密数据On-chain Private Data的概念。为了能让节点拼接同时支持Hyperledger Fabric和Enterprise Ethereum，本发明没有使用链上私有数据。开发者可自由追加链上私有数据的功能。

链下数据，链下数据(Off-chain Data)，摆放在DLT数据层以外的数据。其属于个别企业不会通过DLT分享的结构性数据，属于私有数据(Private Data)。所述链下数据存放在企业的节点上的非DLT数据库，所述链下数据用于储存原始商业事件日志。

高反应性中间件(Reactivity Middleware)，是应用层内的重要零件，负责生成不同类型的实体库，例如：只读不写的实体库、只写不读的实体库以及可读可写的实体库。

还原器(Reducer)，用于运算出实体(Entity)的最新状态。

普遍DLT技术一直沿用的办法是数据模型(Data Model)的设计，传统数据模型是直接编写到智能合约中，让智能合约直接调用数据模型，这种设计方式容易导致很多问题，特别是依赖关系问题。并且，在发生一些改变时，容易导致智能合约修改，并重新部署，例如：用户界面改变，导致数据模型改变，或者，API接口定义改变，导致数据模型改变，数据模型改变，从而导致智能合约改变。

本发明以商业领域模型(Business Domain Model)代替数据模型；并且智能合约并不会依从商业领域模型来编写，本发明把智能合约重新改造，包括：智能合约不包含商业领域模型、智能合约改造成以处理商业事件为主、智能合约只提供写入和询问商业事件功能、在同一个实体(Entity)，追加的商业事件，不会变更从前的商业事件、不断迭加的商业事件，按照时间顺序，建立商业事件日志(或商业事件历史)、每次追加商业事件，Entity版本号码同时增加，每一条商业事件成功写入，智能合约对每一个区块链节点，发出通知，同时包含商业事件的公共数据。

本发明实施例提供一种基于分布式账本技术的节点拼接系统，所述系统包括至少两个区块链节点，每一区块链节点包括：

应用层，所述应用层包括API接口以及高反应性中间件，其中，

所述API接口用于拼接至少一个区块链节点的API接口，生成全景API接口；

所述高反应性中间件用于对接应用层和DLT数据层，单向传送所述区块链节点的链上数据和/或链下数据；

商业事件询问数据库，用于所述应用层询问商业事件；

实体投射数据库，用于保存实体的最新状态；

DLT数据层，所述DLT数据层包括链上数据库，用于存储实体的链上数据，其中，所述系统的每一区块链节点共享所述DLT数据层；

链下数据库，用于保存所述实体的链下数据。

在本发明实施例中，所述应用层通过智能合约将商业事件写入DLT数据层，或者，通过智能合约询问所述DLT数据层中的商业事件。

具体的，所述应用层通过智能合约把商业事件，一个一个按时间顺序，写到DLT数据层。随后的写入请求，将是使用增量后的Entity版本号码，并直接把新的写入请求迭加在同一Entity上。在成功写到区块链上的商业事件，产出一组成功写入识别码(commitID)，送回应用层。通过智能合约将商业事件写入DLT数据层，从而完成写入功能。

所述智能合约可按成功写入识别码(commitID)或实体标识(EntityIdentitier)，询问商业事件日志内的写入请求，智能合约向DLT数据层执行查询，将所有与所述实体相关的商业事件送出到应用层的商业事件询问数据库，例如：所述实体相关的商业事件包括：商业事件1、商业事件2、商业事件3，通过智能合约将商业事件日志写入商业事件询问数据库，从而使应用层能够访问DLT数据层的商业事件。

在本发明实施例中，所述高反应性中间件用于建立实体库，其中，所述实体库包括：

只写不读的实体库，用于写入链上数据；

只读不写的实体库，用于读出链上数据；

可读可写的实体库，用于写入或读出链下数据。

在本发明实施例中，每一所述区块链节点安装至少一个应用程序，每一所述应用程序配置不同的用户认证方法，所述区块链节点通过所述应用程序的API接口，调用其他区块链节点的API接口命令，实现对其他区块链节点的链上数据和链下数据的调用；

当所述区块链节点成功写入商业事件后，智能合约对其他区块链节点进行通知。

在本发明实施例中，所述API接口嵌入商业领域模型，所述商业领域模型包括：实体的定义、商业命令、发送商业命令的权限、商业事件的定义，其中，每一所述商业命令对应至少一个商业事件，每一所述商业事件包括：商业事件类别、实体类型、实体版本号、实体标识以及负载数据。

在本发明实施例中，所述实体对应至少一个还原器，所述还原器用于读取所述实体的历史商业事件，并还原所述实体的最新状态。

在本发明实施例中，所述应用层通过智能合约将商业事件写入DLT数据层，若所述商业事件成功写入区块链，则所述DLT数据层生成一成功写入识别码，并将所述成功写入识别码返回应用层。

请参阅图4，图4是本发明实施例提供的一种向DLT数据层写入商业事件的示意图；

企业级DLT一般分为用户层、API接口、应用层以及DLT数据层，如图4所示，应用层包括应用程序，所述应用程序包括API接口，本发明将API接口和应用层合而为一，所述应用层还包括高反应性中间件，甲方用户层向甲方应用层发送商业命令，所述甲方应用层通过高反应性中间件将所述商业命令中的商业事件写入DLT网络，即DLT数据层，同理，乙方用户层向乙方应用层发送商业命令，所述乙方应用层通过高反应性中间件将所述商业命令中的商业事件写入DLT网络，即DLT数据层。

请参阅图5，图5是本发明实施例提供的生成成功写入识别码的示意图；

如图5所示，应用层把包含商业事件的写入请求(就是商业命令)，送到DLT数据层，其中，每一写入请求包含一个或多个商业事件、商业事件分类、实体类型(Entity类型)、实体版本号(Entity版本号)、实体标识(EntityID)、用户身份号码。

具体的，通过智能合约把商业事件，按时间顺序，逐个写入DLT数据层。随后的写入请求，将是使用增量后的Entity版本号码，并直接把新的写入请求迭加在同一Entity上。在成功写到区块链上的商业事件，产出一组成功写入识别码(commitID)，送回应用层。通过智能合约将商业事件写入DLT数据层，从而完成写入功能。

请参阅图6，图6是本发明实施例提供的将商业事件送出到商业事件询问数据库的示意图；

如图6所示，智能合约可按成功写入识别码(commitID)或实体标识(EntityIdentifier)，询问商业事件日志内的写入请求，智能合约向DLT数据层执行查询，将所有与所述实体相关的商业事件送出到应用层的商业事件询问数据库，例如：所述实体相关的商业事件包括：商业事件1、商业事件2、商业事件3。

与传统DLT平台不同的是，本发明提供的应用层的日常的数据查询是不会直接执行这询问功能。本发明只是在应用层初始设定时，负责把整套DLT商业事件日志，复制到DLT外的商业事件询问数据库(Query Database)，是一次性动作。DLT数据层并没有像RDBMS一般查询功能。

在本发明中，DLT数据层只是负责在DLT网络上，以写入为主的数据库(WriteDatabase)，用于记载商业事件，是一个公共商业事件日志。因为DLT数据层采用了区块链技术，能确保商业事件日志的数据一致性。

需要注意的是，如果要计算实体(Entity)的最新状态(Final State)，则需要了解商业领域模型。为了把依赖关系从DLT数据层中移除，本发明中智能合约并没有计算实体(Entity)的最新状态的功能，也即，本发明中的还原器不会摆放在智能合约内，因此智能合约便无需理会商业领域模型的变化，从而能够把DLT数据层和其他组件的依赖关系移除。

就上文所述在演变问题上，当新产品开发时，不同企业的设计者就不必理会DLT数据层。一方企业可定义跟其他企业不一样的商业领域模型，而且他们可以共享同一DLT数据层。在系统维护，发布和部署新应用层时，DLT数据层甚至无须停顿。

本发明提供高反应中间件(Reactivity Middleware)，用于对接应用层和DLT数据层，高反应性中间件是本发明的核心技术之一，它协助解决传统DLT平台的技术瓶颈，例如：可扩展性的瓶颈和错误扩散等问题。

具体的，所述高反应性中间件是应用层的其中一个部分，所述高反应性中间件同样不含有商业领域模型。所述高反应性中间件用于将DLT数据层抽象化后，生产出实体库(Entity Repository)。在每一个DLT节点上的应用层，利用该高反应性中间件，可以建立：

一个只写不读的实体库。应用层对它发出包含商业事件的写入请求(WriteRequest)，而且该只写不读的实体库基于DLT数据层的数据，负责写入链上数据。

一个只读不写的实体库。应用层对它发出询问请求(Query Request)。所述只读不写的实体库基于区块链节点的内存内的数据库，负责读出链上数据。

一个能读能写的实体库。所述能读能写的实体库负责链下数据，应用层对它发出写入请求或者询问请求，从而写入或读出链下数据。其中，所述能读能写的实体库保存在所述区块链节点的本地位置，例如：硬盘。

在本发明实施例中，所述高反应性中间件通过串流技术处理每个写入读出请求。所述串流技术指的是：采用发后不理(Fire-and-forget)的策略，确保用户层得到较佳反应，而且采用单向数据流向(Unidirectional Data Flow)，即通过所述高反应性中间件的数据，是不可变更的，从而消除不确定性(Non-Deterministic)。

即使DLT数据层能提供区块链独有的数据一致性(Blockchain Consistency)，摆放在它上面的中间层或应用层却不保障数据一致性。

不少DLT设计者采用Java等语言开发中层，并使用面向对象编程(ObjectOriented Programming，OOP)，从而导致在中间层或应用层的内存内，存放大量有状态的对象(Stateful Object)，或内部状态(Internal State)。在DLT网络内，在不同节点的应用层内，如果出现大量有状态的对象(Stateful Object)，便会出现节点的应用层内的数据不一致性的问题。

本发明提供的高反应性中间将通过单向传送没有状态的商业事件(StatelessBusiness Event)，让中间层或应用层达到最终一致Eventual Consistency的效果。同时，在使用串流技术时，采用没有状态的函数式编程(Functional Programming)，取代持有状态的面向对象编程(Object Oriented Programming，OOP)，从而实现整个应用层都是没有状态的设计。

在本发明实施例中，所述高反应性中间件架设在应用层和DLT数据层之间，通过串流技术对链上数据(On-chain Data)、链下数据(Off-chain Data)的处理，实现链上数据和链下数据的去中心化问题。

具体的，所述高反应性中间件对链上数据的处理方式，包括：

(1)复制商业事件日志。

请参阅图7，图7是本发明实施例提供的复制商业事件日志的示意图；

如图7所示，应用层在每次开始时，需要同步DLT数据层和商业事件询问数据库中的商业事件日志，具体的，按应用层所涉及的实体类型(Entity类型)，通过发动智能合约，将DLT数据层内与所述实体类型相关的实体(Entity)的商业事件日志，复制到商业事件询问数据库，并且，应用层在每次开始时，注入一个或多个还原器，用于还原所述实体类型对应的实体的最新状态。通过依赖注入的编程手法，将所述DLT数据层中的商业事件日志复制到商业事件询问数据库中，实现类似将DLT数据层注入所述高反应性中间件。

(2)写入商业事件。

具体的，请参阅图8，图8是本发明实施例提供的更新实体投射数据库以及商业事件询问数据库的示意图；

如图8所示，就每一个实体(Entity)，应用层对区块链节点的API接口发出商业命令，所述API接口向所述高反应性中间件发出包含商业事件的命令，所述高反应性中间件向智能合约发出包含商业事件的命令，以使所述智能合约对所述DLT数据层写入商业事件。

由于所述高反应性中间件采用串流技术，而串流技术可以调节写入速度和次数。当所述DLT数据层出现超负荷，所述高反应性中间件可减低速度，或是停止写入。当DLT数据层恢复正常负荷时，所述高反应性中间件回复正常速度对所述DLT数据层进行写入。

其中，当商业事件成功写入所述DLT数据层，智能合约立刻通知所述高反应性中间件把这商业事件内的公共数据，分别送到商业事件询问数据库(Business Event QueryDatabase)以及实体投射数据库(Entity Projection Database)，从而更新所述商业事件询问数据库以及所述实体投射数据库。

(3)读取未经运算的原始商业事件。

请参阅图9，图9是本发明实施例提供的读出未经运算的商业事件的示意图；

如图9所示，就一个实体(Entity)，应用层对所述高反应性中间件发出读出命令，所述高反应性中间件从商业事件询问数据库，按照时间顺序，将所述商业事件询问数据库中的商业事件，不经任何运算，送回应用层。

(4)读取实体的最新状态。

请参阅图10，图10是本发明实施例提供的读取实体的最新状态的示意图；

如图10所示，针对一个实体(Entity)，应用层对所述高反应性中间件发出读出命令，所述高反应性中间件从商业事件询问数据库，把上述实体(Entity)的所有商业事件日志(商业事件历史)，送到所述实体对应的还原器，通过所述还原器运算该实体(Entity)的最新状态，所述还原器将所述实体的最新状态送回应用层，而不送回所有的商业事件历史。可以理解的是，所述实体的最新状态为集合了所有的商业事件历史的最新状态。

(5)读取实体投射数据库的最新状态。

请参阅图11，图11是本发明实施例提供的询问实体的最新状态的示意图；

如图11所示，针对一个实体(Entity)，应用层对所述高反应性中间件发出读出命令，其中，所述读出命令包括搜索条件，所述实体投射数据库保存有所有实体的最新状态，所述高反应性中间件根据所述搜索条件，从所述实体投射数据库，把实体(Entity)的最新状态，送回应用层，从而实现在新的商业事件写入DLT数据层时，应用层能够直接查询实体的最新状态，而无须重新运算。

在本发明实施例中，所述应用层不会直接到DLT数据层，读取/询问商业事件日志，而是按需要选择。为提升速度，所述商业事件询问数据库以及所述实体投射数据库都是以内存储存的数据库，即所述商业事件询问数据库以及所述实体投射数据库均采用高速缓存机制，能够提供系统的反应速度。本发明提供的高反应特性中间件，能按DLT数据层的负载能力调整写入速度，以使所述DLT数据层发挥最高效率，同时又防止DLT数据层大大超载。由于应用层不会直接读取DLT数据层的数据，从而阻止了DLT节点之间的错误扩散，能防止DLT数据层的不正常反应，扩散到应用层，从而能够实现双方企业的应用互不干扰。

具体的，所述链下数据库同样用于存储原始商业事件日志，与链上数据库不同的是，所述链下数据库是单一的，可读可写的，所述高反应性中间件对链下数据的处理方式，包括：

(1)写入链下数据；

由于所述链下数据为私有数据，其写入不需借助智能合约即可完成。

(2)读取链下数据；

具体的，当成功对链下数据的写入和变更后，应用层将对建立在链上数据的实体库，发出一个商业事件写入命令【PrivateDataSaved】，所述商业事件写入命令的负载数据(Payload Data)包含上述写入链下数据库的实体标识(EntityID)。由于链下数据为私有数据，不能独立还原。要想得到所述链下数据，必须把结合链上数据和链下数据一并运算或还原，其运算或还原方式与链上数据的运算或还原方式相似。从此，每个DLT节点拥有独立的链下数据，解决了链下数据中心化问题。

在本发明中，每个区块链节点，即DLT节点的应用层进行了重新改造，例如：每个DLT节点安装一个应用程序，每个应用程序不必相同；每个应用程序可配置不同的用户认证方法；每个应用程序由包含了高反应性中间件的应用层组成；每个应用程序必须有一个默认的还原器；甲方应用程序和乙方应用程序不存在依赖关系；就同一实体类型，甲方和乙方的应用程序内的还原器，不必相同；甲方应用程序可以通过API接口，调用乙方API接口命令；甲方或乙方通过单一API访问，便能同时调用甲方乙方API接口；甲方或乙方通过单一API访问，便能同时调用链上和链下数据。甲方应用程序成功写入商业事件后，智能合约负责通知乙方，而无须依赖消息传递软件。甲方乙方企业可自由选择共享，不共享，或部分采纳对方的商业领域模型。高反应性中间件，因为没有商业领域模型，所以是一模一样。并且，甲方应用程序和乙方应用程序的开关状态，互相不影响。应用程序和DLT数据层的开关状态，互相不影响。

具体的，本发明实施例中的应用层新增以下关键概念：

(1)商业领域模型(Business Domain Model)

其中，所述商业领域模型包括：命令处理程序(Command Handler)、实体模型(Entity Model)、商业事件(Business Event)以及还原器(Reducer)。

具体的，所述命令处理程序(Command Handler)，用于根据每个实体，提供一系列商业命令，每一所述商业命令包括至少一个商业事件。

请参阅图12，图12是本发明实施例提供的商业命令转化为商业事件的示意图；

如图12所示，API接口接收到用户层发送的商业命令，所述API接口发出写入商业事件命令到所述命令处理程序，所述命令处理程序将所述商业命令写入与DLT数据相关的实体库，具体的，在发出命令前，首先查询自身的实体(Entity)，或其他实体的最新状态。如果无法得到最新状态，所述API接口将发出错误信息，并停止发送命令。可以理解的是，所述API接口在发出命令前，还必须取得用户授权许可以及命令发送许可，并将所述写入商业事件命令写入高反应性中间件所提供的实体库。

在本发明实施例中，此为第一种商业逻辑，即从商业命令转化为商业事件，此商业逻辑是模型设计者在应用层编程是定义的，为静态的。

具体的，所述实体模型，包括：每个实体的商业领域定义及其属性，与传统的数据模型不同的是，本发明提供的实体模型只专注于商业领域，而无需定义系统模型(SystemModel)。其中，所述实体模型还包括：使用许可及权限(Permission&Privilege)。

具体的，所述商业事件包括：商业事件类型、负载数据(Payload Data)，其中，传统的数据模型内的数据，被转移至所述负载数据内，由于传统的数据模型内的数据与用户界面、API接口、应用层逻辑、数据库等存在双向依赖关系，当传统的数据模型发生改变时，所述用户界面、API接口、应用层逻辑、数据库等必然会受到影响，而且，当甲方企业变动数据模型时，乙方企业也必须适应性地调整，所以，本发明实施例提出的将传统的数据模型内的数据转移至负载数据，由于负载数据与上述的用户界面、API接口、应用层逻辑、数据库之间并无关联，因此能够解决依赖关系的问题。

具体的，所述还原器，用于读取每一实体的商业事件历史，并运算得出所述实体的最新状态，每一应用层至少包括一个还原器，或者，每一实体对应至少一个还原器，所述还原器运算所述实体的最新状态，例如：

例子一：计数器(Counter Reducer)有以下按时序的5次商业事件：

商业事件1：RESET COUNTER TO ZERO；

商业事件2：ADD ONE；

商业事件3：MINUS ONE；

商业事件4：ADD ONE；

商业事件4：ADD ONE；

计数器实体(CounterEntity)通过还原器的运算结果是：0+1-1+1+1＝2。

例子二：用户还原器(User Reducer)有以下按时序的3次商业事件：

商业事件1：CreateNewUser,name＝“Bob”

商业事件2：UpdateEmail,“bob@example.com”

商业事件3：UpdateTel,“12345678”

用户实体(UserEntity)通过还原器的运算结果是:name＝”Bob’,email＝”bob@example.com”,tel＝”1234578”。

在本发明实施例中，此为第二种商业逻辑：即从商业事件日志或商业事件历史，转化成为实体(Entity)的最新状态。这是动态的，可以是开发者追加的功能。

请参阅图13，图13是本发明实施例提供的还原实体的最新状态的示意图；

如图13所示，甲方和乙方分别通过甲方还原器和乙方还原器，对所述高反应性中间件读出的商业事件历史进行还原，运算出甲方Entity的最新状态和乙方Entity的最新状态。具体的，针对一个实体(Entity)，甲方的高反应性中间件将DLT数据层中的商业事件日志或商业事件历史，复制到甲方的商业事件询问数据库，所述高反应性中间件从商业事件询问数据库，把上述实体(Entity)的所有商业事件日志(商业事件历史)，送到所述实体对应的还原器，通过所述还原器运算该实体(Entity)的最新状态，所述还原器将所述实体的最新状态送回应用层。

就上述演变问题，基于一模一样的商业事件历史，甲方和乙方，通过不同的还原器，运算出不同的最新状态。甲方还可以自由变更挂在甲方应用层的还原器。也即，双方企业对同一实体(Entity)，有着不同理解。通过各自开发不同的还原器，和追加的特性，双方企业便能独立演变，还原器内的商业逻辑不必分享，所以不增加依赖关系。

(2)嵌入模型(Decorated Model)

本发明摆脱传统数据模型的设计方法，将商业领域模型从DLT数据层，转移至API接口处。并且，本发明把API接口定义(API Specification)和商业领域模型，合二为一，变成了嵌入模型(Decorated Model)。

请参阅图14，图14是本发明实施例提供的嵌入模型的示意图；

如图14所示，每一实体模型(Entity模型)对应API接口的类型信息，在定义商业领域模型时，本发明就每个实体(Entity)每条属性，直接镶嵌入专门为API接口而设的类型信息(Type Information)和标签。因此，无须重新定义API接口，从而节省了大量编程工作。根据之前的实验结果，一个多月的API定义工作，可减至数天完成。

并且，传统的API接口和数据模型的格式和调用方法是不同，需要在它们之间摆放转换器，如对象关系映射转换器(Object Relationship Mapper，ORM)之类的工具，本发明将API接口和商业领域模型合并，从而节省转换器。

传统的API接口多是没有强烈类型信息(Strong Type Information)。接收数据时，无法知道接收的数据类型，因此需要Validator，Convertor，Parser之类的工具。嵌入模型后的API接口，能够直接确定接收的数据的数据类型。

由于商业领域模型和API接口合二为一，因此去掉了商业领域模型和API接口之间的依赖关系，当商业领域模型改变，API接口定义自动地作出一模一样的改变。

(3)实时模型检查(Realtime Model Inspection)

传统的REST为主的API接口，开发人员必须检查以静态文件，如Swagger之类的API定义规格(API Specification)。但是，在多个企业的生态圈，一方企业多不会为其他企业提供可靠准确的API定义规格。因此本发明通过实时模型检查技术，实现不必依赖API定义规格。也不会出现API定义规格不准确的毛病。

具体的，凭借嵌入模型技术，DLT节点之间可以提出实时模型检查(RealtimeModel Inspection)。传统以REST为主的API接口都不具备这独特功能。实时模型检查是让区块链节点上的API接口，提供写入商业命令的调用方法，读出Entity最新状态的方法，和订阅商业事件的方法。

在多个企业的生态圈，例如：甲方企业和乙方企业，有可能需要访问乙方企业的应用层，可是他们的开发过程是不会同步进行。比如，当甲方开发人员开发应用层时，乙方可能正在进行测试。而且，互相不会通知不协调。尝试想象，多方企业的开发人员可达到数百人以上。当每家企业，都提供实时模型检查时，开发人员们就不须理会同步的问题。任何开发人员，在软件封装时，对着实时模型检查发动自动化的模型比较，能够立刻知道甲方乙方的应用层是否冲突，并且知道冲突的源代码的位置，从而大大提升了生产力，并且同样能够解决依赖关系问题和演变问题。

回到上述演变的问题，要实现个别企业独立演变，除去依赖关系问题是第一步。并且，本发明能够让企业之间展开合作而不失去独特性和保密性，同时符合网络安全法规。比如说，在一个深度去中心化的生态圈内，一方企业的用户层只会对同一企业的应用层发出商业命令。相反，它对其他企业的应用层，是没有访问权限，甚至它不知道其他企业的应用层存在。每家企业拥有独立独特的应用。传统技术也许使用代理服务器。这样只达到转发目的，但引发新问题：甲方API接口同时公开两个接口。有很大机会，这两个接口提供相似或相同API定义和商业命令。但是，由于它们由不同企业开发，而不同企业对API的定义是不一样。甲方的用户层，必须在开发时，预先协议使用哪一个接口为主。并且，不能够动态地更改。如果乙方API定义变更，架在甲方应用层上的代理服务器的API定义可能还停留在旧版本，可能导致甲方的用户层出现故障。更普遍地，乙方的静态Swagger档案，没有跟动态API接口同步更新。因为乙方是没有责任去确保甲方不出现故障，所以只有出现故障后，才慢慢作出矫正。

基于上述问题，本发明提出一种节点拼接技术，运用上述关键概念或手段，所述节点拼接类似相片拼接，拼接多幅在同一环境拍的照片。拼接后，生产出全景照片(PanoramaPicture)。从物理层，全景照片以多幅照片作为原材料，从外表看，它是单一广角照片。例如：从每家企业的应用的角度，需要单一广角的节点功能，而不须理会原材料(链上链下数据及其物理位置)，因此本发明提出的节点拼接技术，实际上是让每个企业节点能够实现如下功能：

(1)甲方应用层能接受简单商业命令，请参阅图15，图15是本发明实施例提供的简单商业命令的处理示意图；

其中，所述简单商业命令单纯针对甲方链上数据。通过甲方应用层，转化成商业事件，写入甲方链上数据库，或者，通过在甲方应用层，订阅甲方节点所获取到的商业事件，或者，通过在甲方应用层，从甲方商业事件询问数据库，读出实体(Entity)的商业事件历史，并运算出实体的最新状态。

(2)甲方应用层发出复合商业命令，请参阅图16，图16是本发明实施例提供的复合商业命令的处理示意图；

其中，所述复合商业命令针对甲方链上数据和链下数据。通过甲方应用层，转化成商业事件，同时送到甲方的链上数据库和链下数据库。或者，通过在甲方应用层，同时获得链上数据和链下数据，并合并输出，例如：从甲方的商业事件询问数据库，获取实体(Entity)的商业事件历史，并对所述商业事件历史进行运算，读出所述实体的最新状态，或者，从甲方的链下数据库，读出链下数据。

(3)甲方应用层转发简单商业命令或复合商业命令。请参阅图17，图17是本发明实施例提供的读取乙方商业事件的示意图；

其中，所述转发简单商业命令针对乙方链上数据，当甲方应用层选择不对甲方节点发送商业命令，而转发到乙方节点。甲方送出的命令必须同时拥有甲方和乙方的用户权限。通过乙方应用层，转化成商业事件，写入乙方的链上数据库，或者，通过在乙方应用层，从乙方的商业事件询问数据库，基于乙方还原器，读出实体(Entity)的最新状态。

其中，所述甲方应用层转发复合商业命令，所述转发复合商业命令针对乙方链下数据和链上数据，同理，甲方送出的命令必须同时拥有甲方和乙方的用户权限，通过乙方应用层，转化成商业事件，同时送到乙方的链上数据库和链下数据库。或者，通过在乙方应用层，同时获得链上数据和链下数据，并合并输出，例如：从乙方的商业事件询问数据库，获取实体(Entity)的商业事件历史，并对所述商业事件历史进行运算，读出所述实体的最新状态，或者，从乙方的链下数据库，读出链下数据。

可以理解的是，所述甲方应用层按个转发商业命令，每条商业命令需要同时得到甲方和乙方的用户授权，因此，甲方应用层需要采用第三方认证方法，例如：OAuth2，其中，所述第三方认证方法，包括：甲指示第三认证方发出一个令牌给甲,甲再将其交给乙，乙便可在某特定时间内有权存取甲方的某指定数据，所述第三方认证方法为双方同意的机制。

请参阅图18，图18是本发明实施例提供的节点拼接的示意图；

如图18所示，甲方节点API定义和乙方节点API定义进行拼接，生成全景节点API定义。

请参阅图19，图19是本发明实施例提供的一种基于分布式账本技术的节点拼接方法的流程示意图；

如图19所示，所述节点拼接方法，应用于基于分布式账本技术的节点拼接系统，所述系统包括至少两个区块链节点，所述方法包括：

步骤S10：获取至少一个区块链节点的API接口定义，所述API接口定义包括：商业命令定义、询问方法定义以及订阅方法定义；

具体的，所述节点拼接系统中的每一区块链节点均对应一API接口，所述系统包括至少两个区块链节点，例如：所述系统包括甲方节点和乙方节点，所述甲方节点获取所述乙方节点的API接口定义，所述API接口定义包括：商业命令定义、询问方法定义以及订阅方法定义。

其中，所述获取至少一个区块链节点的API接口定义，包括：对所述至少一个区块链节点进行实时模型检查，获取所述至少一个区块链节点的商业命令定义、询问方法定义以及订阅方法定义。

具体的，所述实时模型检查，包括：向所述至少一个区块链节点上的API接口，请求提供写入商业命令的调用方法、读取实体(Entity)最新状态的方法以及订阅商业事件的方法。

在本发明实施例中，所述向所述至少一个区块链节点发送商业命令之前，所述方法还包括：

获取所述至少一个区块链节点的用户访问权限，根据所述用户访问权限，获取所述至少一个区块链节点的链上数据和链下数据。

具体的，区块链节点在与其他区块链节点进行API接口拼接之后，在向其他区块链节点发送商业命令之前，必须获取其他区块链节点的用户访问权限，所述用户访问权限包括：用户授权许可以及命令发送许可，根据所述用户访问权限的具体内容，所述区块链节点可以部分获取或全部获取其他区块链节点的链上数据和链下数据。

步骤S20：将自身的API接口定义与所述至少一个区块链节点的API接口定义进行拼接，生成全景API接口定义；

具体的，所述区块链节点将自身的API接口定义与至少一个其他区块链节点的API接口定义进行拼接，所述区块链节点可以部分采纳或全部采纳所述至少一个其他区块链节点的商业命令定义、询问方法定义以及订阅方法定义。例如：甲方节点与乙方节点进行节点拼接，所述甲方节点可以局部或全部采纳乙方节点的商业命令定义、询问方法定义以及订阅方法定义。可以理解的是，所述区块链节点可以拼接一个或多个区块链节点，没有数量上的限制。

步骤S30：基于所述全景API接口定义，生成全景API接口；

具体的，所述区块链节点基于所述全景API接口定义，将自身的API接口确定为全景API接口，其中，当所述区块链节点与其拼接的其他区块链节点之间有重复的商业命令定义时，将进行优先级的排序，例如：甲方节点与乙方节点进行拼接，若甲方节点和乙方节点的商业命令定义重复，则甲方节点可以选择甲方优先或乙方优先的策略。

可以理解的是，本发明实施例的节点拼接技术不存在循环依赖的情况，因此，当一方区块链节点拼接另一方区块链节点后，另一方可以拼接对方区块链节点。

在本发明实施例中，所述方法还包括：所述API接口定义嵌入商业领域模型，生成嵌入模型；若更新所述商业领域模型，则所述API接口定义对应更新，以更新所述嵌入模型。由于所述API接口定义嵌入商业领域模型，若生成所述全景API接口，则相当于同时是全景商业领域模型。

步骤S40：通过所述全景API接口，向所述至少一个区块链节点发送商业命令。

由于所述全景API接口是对与其拼接的区块链节点的全景拼接，因此，所述区块链节点可以通过所述全景API接口，向与其拼接的至少一个区块链节点发送商业命令，订阅与其拼接的至少一个区块链节点获取的商业事件，向与其拼接的至少一个区块链节点写入或者读取链上数据和/或链下数据。

可以理解的是，通过所述全景API接口，任何企业的用户层，可以对己方节点发出对整个DLT网络的商业命令、访问或者订阅。其中，节点拼接是按个别企业，自由选择参与。

在本发明实施例中，所述商业命令包括：单一商业命令和复合商业命令，其中，所述单一商业命令用于将商业事件写入自身的链上数据库，或者，读取自身的实体的最新状态，或者，订阅自身获取的商业事件；

在所述商业事件写入链上数据库之后，所述方法还包括：若所述商业事件成功写入所述DLT数据层，所述高反应性中间件将所述商业事件中的公开数据发送到所述应用层的商业事件询问数据库以及实体投射数据库。

所述复合商业命令用于将商业事件写入自身的链上数据库和链下数据库，或者，从自身的链上数据库和链下数据库获取链上数据和链下数据。

在本发明实施例中，所述获取所述至少一个区块链节点的用户访问权限，根据所述用户访问权限，获取所述至少一个区块链节点的链上数据和链下数据，包括：

获取自身的用户访问权限以及至少一个其他区块链节点的用户访问权限；

通过转发商业命令，处理所述至少一个其他区块链节点的链上数据和链下数据。

在本发明实施例中，所述方法还包括：通过第三方认证方法，以使所述至少一个区块链节点获取其他区块链节点的指定数据。

具体的，所述区块链节点的应用层采用第三方认证方法，例如：OAuth2，其中，所述第三方认证方法，包括：甲指示第三认证方发出一个令牌给甲,甲再将其交给乙，乙便可在某特定时间内有权存取甲方的指定数据，所述第三方认证方法为双方同意的机制。

在本发明实施例中，所述API接口接收应用层发送的商业命令，并发出写入商业事件命令，将所述商业命令对应的商业事件发送到高反应性中间件提供的实体库。其中，所述API接口在发出写入商业事件命令前，所述方法还包括：查询自身的实体以及其他实体的最新状态，若查询失败，发出错误信息，并停止发送命令。

请再参阅图20，图20是本发明实施例提供的第一种应用场景的架构示意图；

如图20所示，该应用场景为一区块链系统，所述区块链系统包括：甲方企业(Org1)和乙方企业(Org2)，并且，所述甲方企业(Org1)和乙方企业(Org2)布置于跨境的服务器上，例如：所述甲方企业(Org1)布置于中国，所述乙方企业(Org2)布置于美国，所述甲方企业包括甲方第一节点(Org1Peer1)和甲方第二节点(Org1Peer2)，所述乙方企业包括乙方第一节点(Org2Peer1)和乙方第二节点(Org2Peer2)，所述甲方第一节点(Org1Peer1)拼接所述甲方第二节点(Org1Peer2)以及所述乙方第一节点(Org2Peer1)，所述甲方第一节点包括用户实体库和真姓名实体库，所述用户实体库为链上数据库，所述真姓名实体库为链下数据库。

具体的，所述甲方企业，搭建两个节点，分别为甲方第一节点(Org1Peer1)和甲方第二节点(Org1Peer2)，所述甲方第一节点用于用户身份鉴定，以及节点拼接，所述甲方第一节点不用于执行商业命令，如图20所示，甲方第一节点(Org1Peer1)的API接口拼接甲方第二节点(Org1Peer2)的API接口以及乙方第一节点(Org2Peer1)的API接口，生成拼接-全景接口，即全景API接口，所述甲方第一节点(Org1Peer1)通过所述拼接-全景接口拼接所述甲方第二节点(Org1Peer2)以及所述乙方第一节点(Org2Peer1)；

所述甲方第二节点用于提供API接口，供给甲方企业的商业命令，拼接所述甲方第一节点或所述乙方企业的节点；

所述乙方第一节点拼接所述甲方第一节点，所述乙方第一节点包括用户实体库和真姓名实体库，所述用户实体库为链上数据库，所述真姓名实体库为链下数据库；

在所述甲方第二节点的应用层准备时，根据甲方企业的商业领域模型的需求，选定和注入预设Org1-Entity实体库，之后，注入预设的Entity还原器，其中，所述甲方企业的商业领域模型同时包含真姓名和用户资料，作为用户身份鉴定。

其中，乙方企业，搭建两个节点，乙方第一节点(Org2Peer1)和乙方第二节点(Org2Peer2)，其中，所述乙方第一节点(Org2Peer1)用于用户身份鉴定和节点拼接，所述乙方第一节点(Org2Peer1)不执行商业命令，在所述乙方第一节点(Org2Peer1)，将用户实体库注入乙方第一节点(Org2Peer1)的API接口，其中，所述用户实体库为链上数据库。

在所述乙方第一节点(Org2Peer1)，将真姓名实体库注入乙方第一节点(Org2Peer1)的API接口，所述真姓名实体库为链下数据库，其中，所述乙方企业的商业领域模型同时包含真姓名和用户资料，作为用户身份鉴定。其中，所述乙方第二节点(Org2Peer2)应用层准备时，根据乙方企业的商业领域模型的需求，选定和注入预设Org2-Entity实体库，之后，注入预设的Entity还原器，其中，所述乙方企业的商业领域模型同时包含真姓名和用户资料，作为用户身份鉴定。

在本发明实施例中，所述甲方企业和乙方企业的真姓名实体库可以不同，其预设实体库也可以不同，预设还原器也可以不同。

当所述甲方企业和乙方企业同时搭建两层结构，所述甲方企业和乙方企业便能解决循环依赖问题，并且实现甲方企业和乙方企业可以互相拼接。

请参阅图21，图21是本发明实施例提供的第一种应用场景的商业事件写入读出的示意图；

其中，所述应用场景为企业之间的物品采购，甲方企业和乙方企业的节点位于不同地理位置。甲方希望把一份购物订单(Purchase Order，PO)，送到乙方手里。该购物订单包含采购物品的非保密数据，如交易概况和物品数据，同时该购物订单包含买卖双方的企业数据，是保密数据，乙方必须确认所述购物订单。甲方应用(采购软件)在甲方节点上。乙方应用(销售软件)在乙方节点上，甲方应用程序和乙方应用程序，均具有节点拼接功能。通过节点拼接的方式，乙方节点拥有访问甲方节点的用户权限。

通过甲方用户界面，输入甲方买家购物订单的所有数据，其中，甲方应用(采购软件)把保密数据，写入甲方链下数据库，甲方应用层对实体库，发出Create的商业命令，甲方应用把包含非保密数据的商业事件，POCreated，写入链上，甲方应用把包含保密数据的商业事件，POCreated，写入链下；同时生产出商业事件，PrivateDataSaved，写入链下。

其中，甲方可追加修改，发出Update的商业命令，把包含非保密资料商业事件，POUpdated，写入链上。

期间，乙方应用(销售软件)可通过订阅，获得POCreated和POUpdated等商业事件，当甲方确认完成所有修改后，利用链下数据的标识符和地址等数据，生产出POSent的商业事件，写入链上。

乙方应用通知卖家，卖家利用乙方应用(销售软件)从乙方节点获得链上的商业事件日志或商业事件历史，包括，POCreated，POUpdated和POSent。并且利用乙方节点上的还原器，得到该购物订单PO的最新状态。

同时，乙方节点利用节点拼接技术获取甲方节点的部分链下数据。可以理解的是，甲方应用依然控制所有访问权限，它可以检查链上商业事件，当POSent真实存在时，才让乙方读取链下数据。当乙方了解交易内容后，发出Sign-Confirm的商业命令，送出包含电子签名的POConfirmed的商业事件，写入链上，交易完成。

其中，采购软件和销售软件有着不同功能，由甲方和乙方各自开发，商业事件代表企业之间的日常交往。所述商业事件写入链上后，不能更改，成为可追溯源头的事实。可以理解的是，甲方乙方，对已发生的商业事件，没有修改权限，只能对所述商业事件进行迭加。

甲方节点没有通过DLT数据层直接分享链下私有数据。甲方节点的链下私有数据依然驻留在甲方节点的物理位置，并且甲方节点对其链下私有数据，依然实时控制所有访问权限。乙方卖家要通过甲方节点，才能短暂获得甲方的链下数据。乙方卖家签名后，同时成为商业事实，并且整个商业行为都记载在DLT数据层内。节点拼接技术让乙方应用，能调用甲方节点的非DLT相关功能。

请参阅图23，图23是本发明实施例提供的第二种应用场景的架构示意图；

如图23所示，该应用场景用于资产注册处(Asset Registry)和资产(Assets)生态圈，该应用场景为一区块链系统，所述区块链系统包括：甲方企业(Org1)和乙方企业(Org2)，其中，所述甲方企业(Org1)和乙方企业(Org2)布置于跨境的服务器上，例如：所述甲方企业(Org1)布置于中国，所述乙方企业(Org2)布置于美国，所述甲方企业(Org1)和乙方企业(Org2)均架设两个区块链节点，则所述DLT网络一共架设有4个节点，分别为第一节点(Org1Peer1)，第二节点(Org1Peer2)，第三节点(Org2Peer1)以及第四节点(Org2Peer2)，其中，所述Org1是由生态圈营运者管理，同时定义User的商业领域模型，所述Org2是由资产注册处和资产管理，同时定义Registry和Asset的商业领域模型。

具体的，Org1Peer1节点用于节点拼接和用户注册/登陆，所述Org1Peer1拼接所有其他节点，并且，所述Org1Peer1拥有链下私有数据，存放真实用户数据。

其中，所述Org1Peer2是主要负责User实体库，写入链上的用户数据库。所述Org1Peer1利用节点拼接，结合Org1Peer1链下真实用户数据和Org1Peer2的链上用户数据。

其中，所述Org2Peer1是资产注册处节点，负责Registry实体库，所述Registry实体库为写入链上的注册处数据库。

其中，所述Org2Peer2是资产节点，负责Asset实体库，所述Asset实体库为写入链上的资产数据库。

在本发明实施例中，Org2Peer1和Org2Peer2对应链上数据，所述Org2Peer1和Org2Peer2均没有私有数据。

如图23所示，Org1Peer1节点的全景-拼接接口拼接Org1Peer2节点、Org2Peer1节点以及Org1Peer2节点，Org1Peer1节点发出写入商业命令，当成功写入商业命令后，所述DLT数据层送回订阅通知。

请再参阅图24，图24是本发明实施例提供的第二种应用场景的用户注册的示意图；

如图24所示，资产注册处通过Org1Peer1节点的用户界面进行用户注册，成为资产注册处管理员。

Org1Peer1节点将其真实用户数据，写入链下真实用户实体库，是私有数据。利用Org1Peer1节点把他的公共用户数据，发出CreateUser的商业命令，转发至Org1Peer2节点，所述Org1Peer2节点应用把包含公共用户数据的商业事件，UserCreated，写入链上的User实体库。

请再参阅图25，图25是本发明实施例提供的第二种应用场景的建立资产注册处的示意图；

如图25所示，资产注册处通过Org1Peer1节点的用户界面，利用新注册账号登入，并发出CreateRegistry的商业命令，转发至Org2Peer1节点，所述Org2Peer1节点应用准备商业事件，从Org2Peer1节点，读出链上用户公共数据，基于所述用户公共数据，决定Registry的权限(Privilege)。通过单一写入命令，把RegistryCreated，OwnerDefined以及PrivilegeDefined商业事件，写入链上的Registry实体库，成功写入后，智能合约同时送出商业事件的通知，发至所有节点，各节点的应用层可以自由选择订阅商业事件。

请再参阅图26，图26是本发明实施例提供的第二种应用场景的建立资产的示意图；

如图26所示，如果资产拥有者(Asset Owner)尚未注册，资产拥有者重复第一步进行用户注册。资产拥有者通过Org1Peer1用户界面，利用新注册账号登入。所述资产拥有者通过Org1Peer1用户界面，输入建立资产的Asset资料，发出CreateAsset的商业命令，转发至Org2Peer2节点。Org2Peer2应用准备商业事件，从Org2Peer2节点读出链上用户公共数据，从Org2Peer2节点读出链上Registry数据，包括权限等数据。通过单一写入命令，把AssetCreated，AssetOwnerDefined,PrivilegeDefined,ContentDefined以及TitleDefined商业事件写入链上的Asset实体库。当所述商业事件均成功写入后，智能合约同时送出商业事件的通知，发至所有节点，各节点的应用层可以自由选择订阅商业事件。

由于每个节点有着不同功能，不同商业领域模型，各自开发，并且Org1Peer1节点没有通过DLT数据层直接分享真实用户数据，Org1Peer1节点的链下私有数据依然驻留在其物理位置，并且所述Org1Peer1节点对链下私有数据，依然实时控制所有访问权限，智能合约同时送出商业事件的通知，使得整个商业行为都记载在DLT数据层内。通过节点拼接技术让生态圈营运者，资产注册处和资产安置不同节点上。不同节点接收不同的商业命令，也使用不同的还原器，因此，解决了演变问题和依赖关系问题。

在本发明实施例中，通过提供一种节点拼接方法，应用于基于分布式账本技术的节点拼接系统，所述系统包括至少两个区块链节点，每一区块链节点包括：应用层，所述应用层包括API接口以及高反应性中间件，其中，所述API接口用于拼接至少一个区块链节点的API接口，生成全景API接口；所述高反应性中间件用于对接应用层和DLT数据层，单向传送所述区块链节点的链上数据和/或链下数据；商业事件询问数据库，用于所述应用层询问商业事件；实体投射数据库，用于保存实体的最新状态；DLT数据层，所述DLT数据层包括链上数据库，用于存储实体的链上数据，其中，所述系统的每一区块链节点共享所述DLT数据层；链下数据库，用于保存所述实体的链下数据，所述方法包括：获取至少一个区块链节点的API接口定义，所述API接口定义包括：商业命令定义、询问方法定义以及订阅方法定义；将自身的API接口定义与所述至少一个区块链节点的API接口定义进行拼接，生成全景API接口定义；基于所述全景API接口定义，生成全景API接口；通过所述全景API接口，向所述至少一个区块链节点发送商业命令。通过上述方式，本发明实施例解决了传统的分布式账本技术存在去中心化不足的问题，提高DLT生态圈的去中心化程度。

请参阅图27，图27是本发明实施例提供一种区块链节点的结构示意图。其中，该区块链节点可以是个人计算机、企业级计算机、服务器等能发送商业命令的电子设备。

如图27所示，该区块链节点270包括一个或多个处理器271以及存储器272。其中，图27中以一个处理器271为例。

处理器271和存储器272可以通过总线或者其他方式连接，图27中以通过总线连接为例。

存储器272作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。处理器271通过运行存储在存储器272中的非易失性软件程序、指令以及模块，从而执行基于分布式账本技术的节点拼接方法的各种功能应用以及数据处理，即实现上述方法实施例基于分布式账本技术的节点拼接方法以及上述装置实施例的各个模块和单元的功能。

存储器272可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器272可选包括相对于处理器271远程设置的存储器，这些远程存储器可以通过网络连接至处理器271。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

所述模块存储在所述存储器272中，当被所述一个或者多个处理器271执行时，执行上述任意方法实施例中的基于分布式账本技术的节点拼接方法。

本发明实施例还提供了一种非易失性计算机存储介质，所述计算机存储介质存储有计算机可执行指令，该计算机可执行指令被一个或多个处理器执行，例如图27中的一个处理器271，可使得上述一个或多个处理器可执行上述任意方法实施例中的基于分布式账本技术的节点拼接方法。

以上所描述的装置或设备实施例仅仅是示意性的，其中所述作为分离部件说明的单元模块可以是或者也可以不是物理上分开的，作为模块单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络模块单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁盘、光盘等，包括若干指令用直至得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；在本发明的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本发明的不同方面的许多其它变化，为了简明，它们没有在细节中提供；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (19)

1.一种基于分布式账本技术的节点拼接系统，其特征在于，所述系统包括至少两个区块链节点，每一区块链节点包括：

应用层，所述应用层包括API接口以及高反应性中间件，其中，

所述API接口用于拼接至少一个区块链节点的API接口，生成全景API接口；

所述高反应性中间件用于对接应用层和DLT数据层，单向传送所述区块链节点的链上数据和/或链下数据；

商业事件询问数据库，用于所述应用层询问商业事件；

实体投射数据库，用于保存实体的最新状态；

DLT数据层，所述DLT数据层包括链上数据库，用于存储实体的链上数据，其中，所述系统的每一区块链节点共享所述DLT数据层；

链下数据库，用于保存所述实体的链下数据。

2.根据权利要求1所述的系统，其特征在于，所述应用层通过智能合约将商业事件写入DLT数据层，或者，通过智能合约询问所述DLT数据层中的商业事件。

3.根据权利要求2所述的系统，其特征在于，所述商业事件询问数据库存储商业事件日志，所述应用层在开始时，同步所述DLT数据层和商业事件询问数据库中的商业事件日志。

4.根据权利要求1所述的系统，其特征在于，所述高反应性中间件用于建立实体库，其中，所述实体库包括：

只写不读的实体库，用于写入链上数据；

只读不写的实体库，用于读出链上数据；

可读可写的实体库，用于写入或读出链下数据。

5.根据权利要求1所述的系统，其特征在于，每一所述区块链节点安装至少一个应用程序，每一所述应用程序配置不同的用户认证方法，所述区块链节点通过所述应用程序的API接口，调用其他区块链节点的API接口命令，实现对其他区块链节点的链上数据和链下数据的调用；

当所述区块链节点成功写入商业事件后，智能合约对其他区块链节点进行通知。

6.根据权利要求1所述的系统，其特征在于，所述API接口嵌入商业领域模型，所述商业领域模型包括：实体的定义、商业命令、发送商业命令的权限、商业事件的定义，其中，每一所述商业命令对应至少一个商业事件，每一所述商业事件包括：商业事件类别、实体类型、实体版本号、实体标识以及负载数据。

7.根据权利要求1所述的系统，其特征在于，所述实体对应至少一个还原器，所述还原器用于读取所述实体的历史商业事件，并还原所述实体的最新状态。

8.根据权利要求1所述的系统，其特征在于，所述应用层通过智能合约将商业事件写入DLT数据层，若所述商业事件成功写入区块链，则所述DLT数据层生成一成功写入识别码，并将所述成功写入识别码返回应用层。

9.一种基于分布式账本技术的节点拼接方法，其特征在于，应用于如权利要求1-8任一项所述的基于分布式账本技术的节点拼接系统，所述方法包括：

获取至少一个区块链节点的API接口定义，所述API接口定义包括：商业命令定义、询问方法定义以及订阅方法定义；

将自身的API接口定义与所述至少一个区块链节点的API接口定义进行拼接，生成全景API接口定义；

基于所述全景API接口定义，生成全景API接口；

通过所述全景API接口，向所述至少一个区块链节点发送商业命令。

10.根据权利要求9所述的方法，其特征在于，所述商业命令包括单一商业命令和复合商业命令，其中，

所述单一商业命令用于将商业事件写入自身的链上数据库，或者，读取自身的实体的最新状态，或者，订阅自身获取的商业事件；

所述复合商业命令用于将商业事件写入自身的链上数据库和链下数据库，或者，从自身的链上数据库和链下数据库获取链上数据和链下数据。

11.根据权利要求9所述的方法，其特征在于，所述方法还包括：

所述API接口定义嵌入商业领域模型，生成嵌入模型；

若更新所述商业领域模型，则所述API接口定义对应更新，以更新所述嵌入模型。

12.根据权利要求9或10所述的方法，其特征在于，所述获取至少一个区块链节点的API接口定义，包括：

对所述至少一个区块链节点进行实时模型检查，获取所述至少一个区块链节点的商业命令定义、询问方法定义以及订阅方法定义。

13.根据权利要求9所述的方法，其特征在于，所述向所述至少一个区块链节点发送商业命令之前，所述方法还包括：

获取所述至少一个区块链节点的用户访问权限，根据所述用户访问权限，获取所述至少一个区块链节点的链上数据和链下数据。

14.根据权利要求13所述的方法，其特征在于，所述获取所述至少一个区块链节点的用户访问权限，根据所述用户访问权限，获取所述至少一个区块链节点的链上数据和链下数据，包括：

获取自身的用户访问权限以及至少一个其他区块链节点的用户访问权限；

通过转发商业命令，处理所述至少一个其他区块链节点的链上数据和链下数据。

15.根据权利要求14所述的方法，其特征在于，所述方法还包括：

通过第三方认证方法，以使所述至少一个区块链节点获取其他区块链节点的指定数据。

16.一种区块链节点，其特征在于，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求9-15任一项所述的方法。

17.一种区块链系统，其特征在于，应用如权利要求9-15任一项所述的节点拼接方法，所述系统包括：甲方企业以及乙方企业，所述甲方企业和乙方企业均包括至少一个如权利要求16所述的区块链节点，并且，所述甲方企业和乙方企业的区块链节点布置于跨境的服务器上。

18.根据权利要求17所述的系统，其特征在于，所述甲方企业包括：甲方第一节点和甲方第二节点，所述乙方企业包括：乙方第一节点和乙方第二节点，其中，所述甲方第一节点拼接所述甲方第二节点以及所述乙方第一节点，所述乙方第一节点拼接所述甲方第一节点。

19.根据权利要求18所述的系统，其特征在于，所述甲方第一节点以及所述乙方第一节点均包括用户实体库以及真姓名实体库，所述用户实体库为链上数据库，所述真姓名实体库为链下数据库。