基于区块链的多层级多系统泛中心合作平台系统和方法

摘要

一种基于区块链的多层级多系统泛中心合作平台系统和方法。该系统包括形成扁平化结构的多个层级节点，需求分配时，需求类型的节点可以在系统中发布需求请求消息，供应类型的节点根据需求请求消息中携带的需求的产品的信息与自身存储的供应方的产品的信息进行匹配，并在匹配到多个供应方的情况下，多个供应方通过博弈算法进行处理，得到分配结果，需求类型的节点选择合适的分配结果，完成了基于区块链的协作竞争的产品分配过程，该系统基于区块链建立，宏观上实现了反垄断，在底层供应方之间针对不同的产品确定微观规则，从而实现宏、微观调控，促进市场的活性与公平性，提高资源的周转率，降低协作成本，提高市场各层级各参与方的利益与积极性。

说明书

技术领域

本申请涉及区块链技术领域，具体涉及基于区块链的多层级多系统泛中心合作平台系统和方法。

背景技术

无论是市场经济或者社交网络等都可以逻辑抽象看作是一个多层级的图网状关联结构的系统，其中，系统中的每一类角色又可以由多个成员构成(形成同一类集合)。不同层级间的角色相互之间存在有方向的相互关系(例如：买卖关系、供需关系、发布/订阅关系)。另外，同一个角色集合内部的成员之间既存在相互合作也存在竞争关系。数字经济时代来临，更多相互之间的信息交易、交易往来都在以互联网为平台的计算机系统上完成，大大促进开放型经济的发展，形成分布式商业市场与社会化经济形态。

现有的电子商务、共享交易、服务供应平台等，大多都采用/依赖云计算为基础的中心化平台，从而撮合供需双方。平台既是市场的参与方、也是管理方，同时也构建了一个数字化市场本身。

然而，中心化平台执行规则缺乏透明度，容易形成平台的垄断。随着规模的过度集中化，会影响市场的公平性，从而影响市场各层级参与方的利益与积极性。

发明内容

本申请主要解决的技术问题是现有的中心化平台执行规则缺乏透明度，容易形成平台的垄断。随着规模的过度集中化，会影响市场的公平性，从而影响市场各层级参与方的利益与积极性。

根据第一方面，一种实施例中提供一种基于区块链的多层级多系统泛中心合作平台系统，其特征在于，包括：多个节点，其中，节点的类型包括：供应类型和需求类型；需求类型的节点是至少一个需求方在区块链中的代理节点；供应类型的节点是多个供应方在区块链中的代理节点，每个供应类型的节点中包含业务模块、权益模块、信息组织模块和通信模块；业务模块中存储供应方的产品的信息，产品的信息包括产品的关键词；权益模块用于存储权益分配条件；信息组织模块用于存储相关节点信息；通信模块用于完成与其他节点的通信，其他节点是除供应类型的节点以外的节点；

其中：

基于产品的信息中包含的关键词建立的名字空间，需求类型的节点以命名寻址的通信方式向基于区块链的多层级多系统泛中心合作平台系统发布需求请求消息，需求请求消息中包含需求的产品的信息和匹配类型，匹配类型为模糊匹配或精确匹配；

对于每一个接收到需求请求消息的供应类型的节点：将需求的产品的信息与自身所存储的供应方的产品的信息进行匹配，得到多个候选的供应方，候选的供应方的产品的信息中包含需求的产品的信息；基于智能合约，对多个候选的供应方基于博弈算法进行处理，直到达到纳什平衡，得到目标供应方以及需求的产品的信息在目标供应方中的分配结果；向需求类型的节点发送分配结果；

需求类型的节点显示所有的从供应类型的节点接收到的分配结果；

需求类型的节点基于接收到的选择指令，从所有的分配结果中选择一个分配结果为目标分配结果；

需求类型的节点向目标分配结果对应的供应类型的节点发送选中通知，选中通知用于指示目标分配结果对应的供应类型的节点发送的分配结果被选中；

目标分配结果对应的供应类型的节点存储需求的产品的信息和分配结果的对应关系。

根据第二方面，一种实施例中提供一种基于区块链的多层级多系统泛中心合作方法，应用于基于区块链的多层级多系统泛中心合作平台系统，系统包括多个节点，其中，每个节点的类型包括：供应类型和需求类型；需求类型的节点是至少一个需求方在区块链中的代理节点；供应类型的节点是多个供应方在区块链中的代理节点；方法包括：

供应类型的节点接收需求类型的节点发送的需求请求消息，需求请求消息中包含需求的产品的信息，产品的信息包括产品的关键词；

供应类型的节点根据需求的产品的信息和自身所存储的供应方的产品的信息，得到多个候选的供应方，供应类型的节点中存储的每个产品的信息有对应的供应方，每个候选的供应方的产品的信息中包含需求的产品的信息；

供应类型的节点基于智能合约，根据多个候选的供应方基于博弈算法进行处理，直到达到纳什平衡，得到目标供应方以及需求的产品的信息在目标供应方中的分配结果；

供应类型的节点向需求类型的节点发送分配结果。

根据第二方面，一种实施例中提供一种计算机可读存储介质，介质上存储有程序，程序能够被处理器执行以实现如上述第二方面中任一项的方法。

依据上述实施例的基于区块链的多层级多系统泛中心合作平台系统和方法，通过基于区块链的多层级多系统泛中心合作平台系统，基于区块链这种去中心化的系统，系统透明度高，不易形成垄断，实现宏观调控，在底层供应方之间针对不同的产品确定细微的微观规则，从而实现宏、微观调控，该系统包括多个层级(不同的节点)，多个节点形成扁平化的结构，需求分配时，需求类型的节点可以在系统中发布相应的需求请求消息，供应类型的节点根据需求请求消息中携带的需求的产品的信息与自身存储的供应方的产品的信息进行匹配，并在匹配到多个供应方的情况下，在多个供应方之间通过博弈算法进行分配，从而得到最终的分配结果，每个供应类型的节点将自身匹配得到的分配结果发送给需求类型的节点，以使需求类型的节点进行选择，从而完成了基于区块链的协作竞争的产品分配过程，促进市场的活性与公平性，提高资源与服务的周转效率，降低协作成本，提高市场各层级参与方的利益与积极性。

附图说明

图1为一种中心化交互模式示意图；

图2为本申请实施例提供的一种多层级交互模式示意图；

图3为本申请实施例提供的一种基于区块链的多层级多系统泛中心合作平台系统的架构示意图；

图4为本申请实施例提供的一种基于区块链的多层级多系统泛中心合作平台系统的结构示意图；

图5为本申请实施例提供的一种基于区块链的多层级多系统泛中心合作方法的交互示意图；

图6为本申请实施例提供的一种发布/订阅系统模型示意图；

图7为本申请实施例提供的一种单个网约房订单对应单个服务提供方的处理流程示意图；

图8为本申请实施例提供的一种单个网约房订单对应多个服务提供方的处理流程示意图；

图9为本申请实施例提供的一种多个网约房订单对应多个服务提供方的处理流程示意图。

具体实施方式

现有的电子商务、共享交易、服务供应平台，大多都采用/依赖云计算为基础的中心化平台，撮合供需双方。如图1所示的中心化交互模式示意图，该中心化平台既是市场的参与方、也是管理方，同时也构建了一个数字化市场本身。中心化平台执行规则缺乏透明度，容易形成平台的垄断。随着规模的过度集中化，会影响市场的公平性，从而影响市场各级层参与方的利益与积极性。对于服务、交易、供需的上下游相关方利益延伸关注不够，即不同网络平台之间缺乏互通性，服务链上的延伸方在不同平台之间存在断裂性。

示例性的，现有的在线旅游服务提供平台自身都是采用各自云计算资源所搭建的中心化平台，内部所有规则都有平台方单方面制定和更改，所有数据信息都为平台方所有；参与方只能遵循平台方制定的规则执行，从而容易导致降底参与方积极性与创造性；最后中心化平台规模过度集中容易导致对应行业市场垄断，无法实现对应行业市场的良性竞争。

中心化的交互平台(例如可以是电商平台、租赁平台、共享经济、交易平台等)一边连接多个需求方(本申请中也可以称为买方)，一边连接多个供应方(本申请中也可以称为卖方)，从而需求方与供应方需要通过集中式平台进行交互，使得这种交易不透明，决策易被操纵，容易形成垄断，双边信息不对称等。

请参见图2，图2为本申请实施例提供的一种多层级交互模式示意图，需求方可以与各个供应方交互，无需通过中心化平台。其中，带箭头的线条表示信息的流向，每个五边形表示一个需求方，每个三角形表示一个供应方，供应方可以由多个层级，图中示例性示出了n+k个层级。

因而，如果建立一个更大而全的多级买卖方联通、或者上下游级联长链条的买卖方平台，形成一个供需接力、业务打通的大平台，循序渐进的实现共同富裕，是实现社会化市场的大趋势。引入多层级、多方成员集合构建一个更加庞大的分布式商业市场之后，可能会导致一些新的问题，例如：

问题1：关联关系从中心化平台的(服务方/被服务方、供应方/需求方(双边中心化)合作关系演化到多层级迭代合作关系。如何有效协调统筹多层级相关方的权益竞争与协同分配？

问题2：对每层级的平行成员，微观相互之间的合作与竞争关系如何平衡？一个社会化良性市场的前提是保证宏观优化的大前提下，微观防止垄断的形成与有效的协同协作。简单说，就是宏观与微观的统筹规划与对立统一。

问题3：对于出现了宏观目标不一致或者出现偏差的情况下，如何进行监督与修正？基于事后的冲突处理方式，代价高、周期长、取证难，建立实时性高的干预、监督机制非常有必要性。

传统的商业模式由于时间与空间的间隔比较大，导致权益/利益/供需双方交互的边界有限；虽然基于互联网的电子商务等模式有效解决了空间间隔的问题，但大多基于集中式平台的交易方式，逻辑上依然限定在有限的局部双边/双方交互模式。区块链技术多方参与，共同记账、计算，共识维护、基于智能合约(程序规则)自动执行，可以进一步扩大时间、空间的多方交互边界，促进细粒度、精准化、长链条合作的颠覆式商业模式的形成。

实际生产、社会服务、社交关系中，从一个垂直的行业来看，每个组织/个人的角色都是多方面、而且相互转换的：对于上游而言，某个组织或者个人是供应方；但对于下游而言，该组织或者个人又变成的需求方，而且在对于多个细分垂直行业链条是举办交叉角色作用的，也就是链条中每个节点是存在交叉的，对于这种更加复杂、扩大、上下多元关系组成的分布式数字化商业组织形式，需要进一步解决好各相关方之间价值/权益联动的新型信息系统与统筹优化策略。

数字经济时代来临，泛中心化分布式商业将成为未来趋势，它是个多中心且中心动态均衡化的商业形态，在未来商业组织将需具备，独立(Independence)，代表着企业的数据主导权、以及在充分竞争市场环境中的长尾创新；融合(Integration)，指的是生产要素的连接、生产方式的协作、以及业务边界的淡化；智能(Intelligence)，数据思维在引爆智能革命，未来的商业都在朝智能化方向在进化，主要体现在决策智能和运营智能上。

本申请提供的多层级多方合作系统基于区块链作为底层技术而建立，可以实现去中心化、全网共识、数据透明和可追溯的特点。

目前区块链的大多数应用只关注数据信息流，点对点互联互通，对于实际的应用场景的价值流、层级关系、宏微观统筹权益分配方面的关注度不够，计算机系统与实际商务业务逻辑的拓扑一致性映射耦合度不明确，并不能发挥基于区块链构建分布式商业模式潜力。

区块链作为一种面向点对点去中心化交易而提出的工具，区块链以其账本多方同步存储、安全共识确认、智能合约可编程的自动化交互的特征，被认为是多/去中心场景下的信任构建、可信交互、分布式商业的有效工具。目前区块链的大多数应用只关注数据信息流，数据的互联互通，对于实际的应用场景的价值流、宏微观统筹权益分配方面的关注度不够，并不能发挥基于区块链构建分布式商业模式潜力。

区块链被认为是在跨域/开放网络中更好地构建信任、促进网络中众多“自私”的节点分享、交换与协作的有效方案：首先，区块链是为分布式架构而构建的，其机制中不含有中心权威节点，而跨域开放网络也存在大量归属于多域的分散节点；其次，区块链共识机制及加密货币可以成为一种促进各节点相互协作的有效激励手段，如进行存储交易、信息共享等等。而区块链的智能合约有助于构建信息相互分享交易的市场。更重要的是，依托区块链技术建立起的信息共享交换市场是安全可靠的，发生的交易经由全网/或者主要权威节点的验证与确认。

中心化平台不仅导致规则数据缺乏透明度，而且也容易形成信息孤岛。本发明面向分布式场景，提出了基于区块链的构建一个扁平化点对点的多层级、多成员集合/联盟的级联交互合作系统及经济效用宏微观统筹的权益分配架构及方法。系统不仅省去各平台上链问题，同时也打破各平台之间信息孤岛的情况。示例性的，在线旅游服务提供平台AA和在线旅游服务提供平台BB都可以提供网约房租赁服务业务，可将平台AA和平台BB的房源直接上链，保证房源信息透明性和真实性；通过区块链智能合约共识保障如房源价格不会受到单方面原因导致较大波动。参与方可以在该技术平台上提出需求，该技术平台通过匹配方式对已经对接上链的房源进行需求匹配，然后对匹配出来结果进行博弈算法得出最优结果反馈给参与方。

在本申请实施例提供一种基于区块链的多层级多系统泛中心合作平台系统和方法、可读存储介质，基于区块链的去中心化的性质构建多层级(本申请中的层级是指供应方平台)多方(本申请中的多方是指需求方、供应方平台以及供应方平台中包括的供应方)公平合作的系统，通过基于区块链思维与系统构建一个多层级、多成员集合构成扁平化级联松耦合、信息化、数字价值化、分布式组织架构，基于逐跳的、语义化(基于命名语义发布/订阅双向消息交互)供需消息点对点广播/组播/多播的方式在系统节点之间直接转发、路由和撮合供需，建立基于宏微观粗细粒度统筹协调市场动态博弈平衡的权益有限定的分配算法机制，从而建立一个有效、高参与度、共享共治的可编程的未来智能商务生态市场。

下面结合图3和图4介绍本申请实施例提供的区块链的多层级多方合作系统。

请参见图3，图3为本申请实施例提供的一种基于区块链的多层级多系统泛中心合作平台系统的架构示意图。本实施例提供的基于区块链的多层级多系统泛中心合作平台系统(以下简称“多方合作系统”或者“系统”)可以包括但不限于统筹层、协作层和源系统层。

系统主要是通过区块链建立起多层级(多方)的共享网络，本申请下面以系统中生成的需求为订单为例进行说明。

其中，源系统层是指系统中合作参与各方自有的自我生成、管理的IT系统，成为多方合作系统的组成基本单元。具有接收(上游)外部订单、完成订单、生成对外(下游)订单的功能。

例如，图3中示例性示出了3个节点(也就是3个层级)，分别为本级联盟链A、本级联盟链B和本级联盟链M，节点也可以不是联盟链的形式，可以为单独的供应方在系统中的区块链代理节点。每一级联盟链中可以包含多个供应方，例如，图1中示例性示出的在本级联盟链A中包含成员A

需要说明的是，源系统层可建立联盟区块链，也可以不建立联盟区块链。

其中，协作层是指根据业务上下游逻辑，分级关联相关联盟构成的联盟区块链、个人或者团队，根据链接协议对接完成点对点的信息组网以及需求(例如，可以是订单)的发布/承接服务的订阅消息格式等。协作层也可以称为中间件。协作层主要的功能可以包括但不限于：上下游关联、协议组网、消息的发布/订阅、命名寻址和/或供需匹配等。每个联盟区块链、个人或者团队可以向系统的网络中发送消息，协作层进行该消息的转发，从而根据匹配方式完成供应方和需求方各方的订单匹配，返回交互的双方，上报给统筹层，供需双方后续可以点对点直接完成产品交付。

进一步地，可以依据统筹层或者微观已共识、合规的、透明的分配方式完成最终的供应方之间的利益分配和获取，将利益分配结果上报统筹层进行记录和监督。进一步地，完成社区贡献与奖惩评价等。

其中，统筹层主要负责基于联盟共识的方式制定或修改系统的运行规则：管理和维护权益分配规则、监督与监控交易运行的状态、调整系统运行的参数、奖励或惩罚相关的违反规则的事件等。

系统基于上层(统筹层)和中间层(协作层)两层控制逻辑完成运行。

其中，上层(统筹层)基于区块链联盟方共识宏观调控，从而防止各个供应类型节点形成垄断，例如，供应类型的节点A和供应类型的节点B均含有X服务，那么在该两个节点接入到系统中(中间件)后，需要在区块链上与系统中的各个节点达成共识，从而后续的交易过程中将不会出现因为平台或者认为操作对X服务产生垄断。

中间层(协作层)各节点微观自主决策，即各个节点针对具体的不同的产品或者服务通过共识确定的分配规则，微观调控主要目的是非对称竞争协调。微观调控中间件底层比较细粒度的规则，示例性的，有三人在中间件中发布民宿预定需求并最终在A平台(A平台为一个供应类型的节点)上预定了三间民宿并入住时间均为同一个时间段；而这时三间民宿就会发布三个保洁订单，张三、李四为兼职保洁的人员将会抢这个订单，这时张三因为现场网络较好优先抢到三个订单，这时微观调控将会根据张三以往完成订单时间以及现手头上已有的订单数判断这个三个订单张三是否有能力完成，如果没有能力完成将会把不能完成的部分重新分配。这个例子即是在保洁订单分配过程中指定的分配规则，其可能并不适用于其他类型的产品和服务，因此为微观决策的规则。

从而，统筹层改变了单一中心化平台可能导致的不透明性以及垄断性，系统可以扩展交易的范围，形成多方合作长链条协同；另外，实现了市场与调控的剥离，即源系统层和协作层完成的微观市场交易的自主性、细粒度结算与统筹层完成的宏观社会化治理的解耦，促进市场的活性与公平性，提高资源与服务的周转效率，降低协作成本。

现有的供应链为自上而下的模式，自上而下的模式例如：需求方需要在某购物平台买一台智能锁或一个相关配件的相关供应方顺序可以为：通过某购物平台获取到店铺、获取方案商，获取电路板厂家，获取锁体厂家，获取五金厂家，同时获取上门服务方，可以理解现成现有的供应商模式过于繁琐，同时该供应链模式一旦形成将很难做出灵活改变。

本实施例提供的系统基于扁平化多层级多联盟的结构，行业内所有供应商以平行的形式接入到源系统层中，改变了供应链至上而下的模式。然后行业中所有供应商根据统筹层中宏微观规则达成共识，实现供应商所提供的商品或服务等费用达成一个共识的规则，进而打破了传统至上而下模式中价格不透明、价格不规律波动等风险，同时打消需求方在购买商品或服务中对价格方面的顾虑。由于是扁平化多层级的结构，接入源系统层所有供应商都可以通过联盟的方式或单独的方式通过协作层发布自由的产品和服务，也使得需求方在需求一件基础的商品或一件基础服务时可以直接找到源头供应商，同时对需求方的需求可由供应商联合形成联盟完成需求。

另外，系统作为一个可以接入各类平台/用户基于区块链的中间件平台，其顶层可以包含相应的交易规则，这个规程作用是在买卖交易的过程中防止某一个平台垄断某个业务，也就是在系统宏观层面实现反垄断。中间件平台的底层，对于不同的产品或者服务，其对应的供应方可以通过共识的方式制定出相应的该类型的产品或者服务的匹配方式，即为微观匹配方式。

可选的，本申请实施例提供的系统可应用于Web3.0模式的分布式商业。

下面结合另一种系统结构对本申请实施例提供的系统进行详细介绍。

请参见图4，图4为本申请实施例提供的一种基于区块链的多层级多系统泛中心合作平台系统的结构示意图，多方合作系统可以包括：多个节点。每个节点均是基于区块链建立的。节点的类型包括：供应类型和需求类型。

其中，需求类型的节点是至少一个需求方在区块链中的代理节点。

其中，供应类型的节点是多个供应方在区块链中的代理节点。

可以理解，节点的类型用于在区块链中区分节点在区块链中的角色，一个节点可以具有多种类型，节点的类型也可以转换，例如，X节点上作为一些供应方的代理节点，X节点的类型是供应类型，而X节点上的供应方需要通过系统采购产品，则可以在系统中发布产品需求，从而X节点的类型也是需求类型的。

其中，上述系统层对应存储在每个节点本地。每个供应类型的节点中可以包含但不限于以下模块：业务模块、权益模块、信息组织模块和通信模块等。

其中，业务模块中存储供应方的产品的信息，产品的信息包括产品的关键词。

可选的，业务模块用于：供需双方根据业务需求对已有产品与服务等资源进行关键词、详细描述、状态信息等业务规则参数设定。

可选的，业务模块可以包括关键词统一资源标志符(Uniform ResourceIdentifier,简称URI)数据库。关键词URI数据库可以存储产品与服务所标识的关键词。示例性的，该关键词可以为层级化词组或者字符串等多种形式。

可选的，业务模块可以包括产品/服务规格描述表。产品/服务规格描述表用于存储产品与服务的详细描述。示例性的，产品/服务规格描述表可以为XML等结构化数据格式。

可选的，业务模块可以包括本地产品/服务管理数据库。本地产品/服务管理数据库用于存储产品库存、服务容量和/或状态信息等参数。例如，产品与服务数量、价格、描述和状态等。

可选的，业务模块可以包括业务规则参数表。业务规则参数表用于根据业务需求请求给对应产品与服务设定规则参数。

其中，权益模块用于存储权益分配条件。

可选的，权益模块用于存储供需双方共识制定权益分配、计算和统计等规则。

可选的，权益模块可以包括规则数据库。规则数据库用于存储供需双方制定的权益规则。

可选的，权益模块可以包括权益数据库。权益数据库用于存储供需双方所获取的权益。

可选的，权益模块可以包括权益计算引擎。权益计算引擎用于根据共识规则计算业务权益。

可选的，权益模块可以包括统计分析引擎。统计分析引擎用于对所产生的业务进行统计分析。其中，信息组织模块用于存储相关节点信息。

其中，通信模块用于完成与其他节点的通信，其他节点是除供应类型的节点自身以外的节点。通信模块也可以称为网络处理相关组件。

可选的，网络处理相关组件用于在区块链模块内对网络软硬件接口进行管理，对信息和不同协议进行处理。

可选的，网络处理相关组件可以包括网络接口管理。网络接口管理用于管理所有参与方已有软硬件平台所对接的接口。

可选的，网络处理相关组件可以包括网络信息处理。网络信息处理用于发布/订阅、交易撮合、传播等信息处理。

可选的，网络处理相关组件可以包括网络协议处理。网络协议处理用于多播或广播协议之间的处理。

可选的，网络处理相关组件可以包括区块链模块。区块链模块用于存储信息。

可选的，网络处理相关组件可以包括性能管理。性能管理用于监测整个系统层中性能情况。

在一些实施例中，每个供应类型的节点还可以包括信息组织模块，信息组织模块也可以称为信息组织相关数据结构。信息组织模块用于供需双方根据自身情况填写相关数据，并根据所填数据与相识方形成联盟。

可选的，信息组织模块可以包括联盟黑白名单表。联盟黑白名单表用于存储联盟中所有成员及所标注的黑白名单。

在一些实施例中，对于每个供应类型的节点其提供的供应方的产品或服务可以是供应链中的一环，该产品或服务在供应链中可以有上游的产品或服务，也可以有下游的产品或服务。

可选的，信息组织模块可以包括上游服务客户表。上游服务客户表用于存储供需双方对应上游客户表单。该上游服务客户表可以是通过系统匹配得到的。

可选的，信息组织模块可以包括下游供应商家表。下游供应商家表用于存储供需双方对应下游供应商表单。该下游服务客户表可以是通过系统匹配得到的。

可选的，信息组织模块可以包括待匹配交易表。待匹配交易表是所发布供需双方需求正在撮合匹配的表单。

在另外一些实施例中，系统还可以包括：互联网交互层。互联网交互层可以包括点对点根据业务属性进行供需消息传播、快速交易撮合、供需交易上下游链条沿路径逐级语义分解、转换、迭代转发，进行分布式订单撮合、匹配，包括订单沿着上下游路径拆分迭代传播，从而拉动整个供应/服务链条。

可选的，互联网交互层可以包括拓扑路由模块。拓扑路由模块用于各业务各层级中关键词、名字语义定义和路由转发策略。

示例性的，拓扑路由模块可以包括以下至少一种功能：业务分类/域及层级管理、关键词词义拓扑结构管理、基于名字的语义路由和语义转发策略。

可选的，互联网交互层还可以包括微观交互模块。微观交互模块用于宏观共识规则下，供需双方关键词信息传播匹配。

示例性的，微观交互模块可以包括以下至少一种功能：消息组播/多播/广播分发模块、需求消息正向路径传播、供应消息逆向路径传播和消息分布式汇聚处理。

可选的，互联网交互层还可以包括分布式交易处理模块。分布式交易处理模块用于处理分散式节点或分散式不同域中信息传播和供需双方匹配撮合。

示例性的，分布式交易处理模块可以包括以下至少一种功能：分散式交易撮合、订单匹配/订单拆分、订单-需求的转义、沿路径逐级上下游迭代传播

可选的，互联网交互层还可以包括搜索及匹配、权益交割、支付管理、第三方财务系统等的分布式商业运行计算相关的系统模块。交互层做微观管理，功能上尽可能实时性完成在业务规则允许下的订单链条完成。

在另外一些实施例中，系统还可以包括分布式控制层。分布式控制层是根据业务整体情况进行联盟统筹管理的系统功能模块。相应的每个模块也可以根据地域、业务、周期进行多实例部署，从而避免单点失效以及加强负载均衡。

可选的，分布式控制层可以包括宏观控制模块。宏观控制模块基于区块链联盟管理和维护权益分配规则、监督与监控交易运行的状态、调整系统运行的参数、奖励或惩罚相关的违反规则的事件等。

示例性的，宏观控制模块用于实现分布式控制宏观上层对于微观分布式交互层的控制与反馈协议、宏观规则参数的监控与调节和宏观总账区块链系统中的至少一种功能。

可选的，分布式控制层可以包括语义管理模块。语义管理模块用于管理系统中各行业层级中所有关键词、命名语义总表。

示例性的，语义管理模块可以包括但不限于以下至少一种：行业域名结构化层级图谱、业务关键词关联图谱和领域知识图谱。

可选的，分布式控制层可以包括规则共识模块。规则共识模块基于区块链联盟下对共识规则管理以及供需双方交易完成后智能合约将凭证上报到区块链作为后续分配决策依据。

示例性的，规则共识模块可以包括但不限于以下至少一种：基于区块链共识机制的规则制定、各类规则的生成与管理器、区块链智能合约编辑器和规则的运行与管理执行器。

可以理解，分布式控制层主要负责整体业务链条的数据上总账区块链、观测宏观层的业务运行状态、通过联盟共识机制制定新的规则及权益分配比例、调整系统参数、平衡不正当业务失衡、管理激励、奖励及惩罚、保障数据要素不被滥用、垄断，以及相关敏感的关键基础数据的隐私保护。

在另外一些实施例中，系统还可以包括：门户模块。门户模块也可以称为门户。门户模块可以指通过计算机web页面、手机APP和微信小程序等方式用可视化交互界面给供需双方使用。同时可视化界面会呈现业务分析、行业报告、供应链优化、权益分成和关键词排名等数据。

门户模块中可以包含但不限于：注册认证子模块、权益报表子模块、规则调整子模块、关键词分类层级树子模块、关键词热度权重统计子模块、关键词竞价排名子模块和可视化交互界面子模块等。

其中，注册认证子模块用于供应方和/或需求方进行注册账户并进行认证，即供需双方注册账户并进行个人或单位认证。

其中，权益报表子模块用于查看具有权限的账号的权益报表。

其中，规则调整子模块用于调整具有权限的账号的产品的信息和服务资源规则参数。

其中，关键词分类层级树子模块用于存储按照层级进行分类的关键词。

其中，关键词热度权重统计子模块用于查看系统中所有关键词的排名情况及使用频率。

其中，可视化交互界面子模块用于进行人机交互，以完成账号注册、接收关键词、按照分类显示关键词以及显示关键词的排名。

其中，关键词竞价排名子模块用于根据竞价排名策略对关键词进行排名，并在关键词被搜索时，基于关键词的排名进行显示。

可选的，竞价排名策略说明：该策略首先根据关键词/组对平台的竞价发起方、需求方和现有互联网引擎进行多项数据智能处理和分析得出潜在价值得分，然后将得出潜在价值得分的关键词/组划分到同类竞价关键词进行得分比较并得出排名，最后将关键词/组排名情况及竞价费用反馈给参与竞价的供应方。

竞价排名策略的目的是为了激励竞价参与方挖掘更多潜在价值高的关键词/组、以及与潜在价值高的关键词/组对应最紧密的产品或服务；潜在价值得分越高的关键词/组所得排名将越靠前。同时潜在价值得分越高的关键词/组平台将会减免或返还竞价费用，这样一方面通过挖掘潜在价值得分高的关键词/组使得供需双方实现以少量的经济投入得到更高的回报；另外一方面解决了传统以价高者得的竞价排名方式这类不良的盈利商业模式。

下面介绍竞价排名的操作流程：

步骤1：参与竞价的供应方提交竞价关键词/组

步骤2：审核所提交竞价关键词/组是否符合国家信息安全法

步骤3：计算竞价发起方多项数据得出分值

步骤4：计算涉及该竞价关键词/组的需求方多项数据得出分值

步骤5：计算现有互联网引擎对该竞价关键词/组现有和历史数据得出分值

步骤6：对三项分值进行合计

步骤7：划分到同类组并进行对比排名

步骤8：反馈参与竞价的供应方并确认是否执行

步骤9：关键词/组投放。

在一些实施例中，门户模块还可以包括输入输出子模块，输入输出子模块用于供需双方账号登录与登出。

可选的，本申请实施例提供的系统可以采用智能生态网络(Intelligent EcoNetworking，简称IEN)作为系统架构框架。

本实施例，建立基于区块链的多层级多系统泛中心合作平台系统，该系统基于区块链的数字经济将形成“多方对多方”以及“多层级、长链条”的去中心化/多中心化/点对点互联网直接协作的分布式系统。构建了一个网格状的多成员集合的长链条合作系统、建立宏微观统筹、合理公平的权益分配机制是建立社会化产业生态。形成分布式商业系统，提高资源与服务的周转利用率、加强了监管与实时性干预、调节能力，防止形成垄断、促进共同富裕、避免信息不对称而导致的大数据杀熟等。

下面介绍应用于上述系统的基于区块链的多层级多系统泛中心合作方法。

请参考图5，图5为本申请实施例提供的一种基于区块链的多层级多系统泛中心合作方法的交互示意图，本实施例的方法可以应用于区块链的多层级多方合作系统中，下面以本实施例提供的方法应用于上述图3和图4所示的系统为例进行说明。本实施例中以供应类型的节点为供应类型的节点1和供应类型的节点2为例进行说明，本实施例提供的方法可以包括以下步骤：

S51：需求类型的节点向基于区块链的多层级多系统泛中心合作平台系统发布需求请求消息。

其中，需求请求消息中包含需求的产品的信息，产品的信息包括产品的关键词。

可以理解，本实施例中的产品可以指商品或者服务。即产品包括了实物商品也包括了能提供的服务。

当需求方有相应的需求的产品时，可以通过需求类型的节点基于智能合约在系统中发布携带有需求的产品的信息的需求请求消息。供应方在系统中的供应类型的节点可以收到该需求请求消息，从而进行下一步的匹配。

S52：供应类型的节点根据需求的产品的信息和自身所存储的供应方的产品的信息，得到多个候选的供应方。

其中，供应类型的节点中存储的每个产品的信息有对应的供应方。

其中，每个供应类型的节点中存储有一个或多个供应方，其中，每个供应方具有一个或多个产品。

其中，每个候选的供应方的产品的信息中包含需求的产品的信息

可选的，供应类型的节点将需求的产品的信息与自身所存储的供应方的产品的信息进行匹配，得到多个候选的供应方，候选的供应方的产品的信息中包含需求的产品的信息。

系统中的供应类型的节点在接收到需求请求消息以后，将需求请求消息中携带的产品的信息与自身所存储的供应方的产品的信息进行匹配。匹配结果可以为以下几种情况：

情况一：供应类型的节点没有匹配到供应方的产品的信息，即当前的供应类型的节点中并没有满足需求请求消息中需求的产品的要求的产品，则当前的供应类型的节点针对该需求请求消息可以不进行后续处理。

情况二：供应类型的节点匹配到一个候选的供应方，该候选的供应方的产品的信息符合需求请求消息中的产品的信息，则供应类型的节点向需求类型的节点发送匹配结果，匹配结果中包含符合需求的产品的信息的供应方的产品的信息。

情况三：供应类型的节点匹配到多个候选的供应方，每个候选的供应方均具有符合需求的产品。

S53：供应类型的节点基于智能合约，根据多个候选的供应方基于博弈算法进行处理，直到达到纳什平衡，得到目标供应方以及需求的产品的信息在目标供应方中的分配结果。

对于上述情况三，该供应类型的节点需要在多个候选的供应方中进行分配，需要综合需求方和供应方的利益情况，从而完成匹配。这实际上是一种博弈的场景，即候选的供应方之间既存在合作又存在竞争。而对于需求方来说，如果不选择给出的分配结果，则对于候选的供应方来说也将是一种损失。

本实施例中，供应类型的节点基于智能合约，根据多个候选的供应方基于博弈算法进行处理，直到达到纳什平衡，得到目标供应方以及需求的产品的信息在目标供应方中的分配结果。

其中，目标供应方为候选的供应方中的部分或者全部。目标供应方为此次满足需求请求消息中的产品的需求，且该目标供应方的组合形式及分配结果为优选的方案。

S54：供应类型的节点向需求类型的节点发送分配结果。

每个供应类型的节点进行上述匹配过程以后，分别想需求类型的节点发送自身的分配结果。

本实施例，通过基于区块链的多层级多系统泛中心合作平台系统，基于区块链这种去中心化的系统同，系统透明度高，不易形成垄断，在有相应产品或者服务的需求时，可以在系统中发布相应的需求请求消息，供应类型的节点根据需求请求消息中携带的需求的产品的信息与自身存储的供应方的产品的信息进行匹配，并在匹配到多个供应方的情况下，在多个供应方通过博弈算法进行处理，从而，得到最终的分配结果，每个供应类型的节点将自身匹配得到的分配结果发送给需求类型的节点，以使需求类型的节点进行选择，从而完成了基于区块链的协作竞争的产品分配过程，促进市场的活性与公平性，提高资源与服务的周转效率，降低协作成本，提高市场各层级参与方的利益与积极性。

在一些实施例中，S51可以通过发布/订阅机制来实现，下面以图4所示的本申请实施例提供的一种发布/订阅系统模型为例进行说明。

由于发布/订阅、消息两种路由技术具有松耦合、匿名、多对多通信和可扩展的特性，所以特别适合于没有集中控制的分布式架构和构建多层级、多成员的系统平台。下面以图6所示的发布/订阅系统模型为例进行说明。

请参见图6，图6为本申请实施例提供的一种发布/订阅系统模型示意图，在平台中供应方(发布者)、需求方(订阅者)和信息自动撮合匹配服务组成，信息自动撮合匹配服务作为供应方和需求方的中间件，需求方向信息自动撮合匹配服务需求命名数据格式(订阅)信息，表达对特定信息的需求，供应方把供应命名数据格式信息形式发送到信息自动撮合匹配服务，信息自动撮合匹配服务随后发送通知信息到需求方。而在这种松耦合的情况下，供应方和需求方不是直接交互，而是通过信息自动撮合匹配服务。信息自动撮合匹配服务使得供应商无需知道需求方是否在线，需求方只需要关注所发布的信息，而不管何时何地和人发布了信息。

进一步地，基于上述发布/订阅机制，S52中可以通过基于产品的信息中包含的关键词建立名字空间，从而构成一种类似命名数据网络，基于路由机制的命名寻址的通信方式实现消息的发送/订阅。下面以具体的实施例进行详细说明：

在图5所示实施例的基础上，进一步地，S52可以通过如下步骤实现：

供应类型的节点基于产品的信息中包含的关键词建立的名字空间，以命名寻址的通信方式接收需求类型的节点发送的需求请求消息。

其中，基于产品的信息中包含的关键词建立的名字空间为一种数据结构，命名数据格式是供需双方先通过定义关键字集合内容(如：照片、人物照片)和元数据信息(如：照片图像分辨率、作者、日期或地点)，然后生成两类数据报文，一类是interest兴趣包(又称请求包)，用于数据供应方发出请求到网络中获取数据；另一类是data数据包，是数据供应方真实请求的数据内容。

基于名字空间进行寻址从而获取数据的方式即为命名寻址，类似命名数据网络中给数据包命名并执行路由转发的网络寻址方法。

可选的，需求请求消息中还可以包含可路由的标识前缀信息。

其中，可路由的标识前缀信息用于基于命名寻址指示向区块链中的供应类型的节点，也就是需求请求消息需要送达的供应类型的节点。

在区块链采用命名寻址的网络中，可路由的标识前缀信息可以以名称指向区块链中的供应类型的节点，从而将该需求请求消息发送给指向的供应类型的节点。

本实施例，通过采用基于名字空间的命名寻址的通信方式，可以更加快速的将需求请求消息进行发布，提高了需求响应速度，从而提供了系统整体的响应效率。

在另外一些实施例中，关键词包括：关键字集合、元数据信息和数据包标签，关键字集合包括一个或多个产品关键字；从而建立双向关键字命名寻址的通信机制。

其中，数据包标签是指产品的分类，数据包标签的类别相对大于关键字集合，关键字集合是指产品的细化分类，元数据信息是指产品的属性信息，例如，数据包标签(如：照片)、关键字集合内容(如：风景照片、人物照片)、元数据信息(如：照片图像分辨率、作者、日期或地点等)。

双向关键字命名寻址是指一种给数据包建立<关键字集合、元数据信息>的格式的报文结构，然后通过建立基于关键字的建立路由表结构进行网络中节点路由分发的工作机理。需求方构建请求方传输报文、供应方构建发送方请求报文；双方关键字可以进行精确匹配或者模糊匹配；每个节点都有一个匹配的计算引擎；为了提高匹配性能和降低消息的广播冗余，需要制定一些列关键词分类表，各个节点通过注册或者选择特定的关键词作为业务域空间，增强业务的语义表达能力及收敛能力；每个节点也有新增关键词的功能，但是需要复合一定的规则，接收方也需要根据一定的规则(例如白名单)方能接受相关的关键词。

实现供需双方基于形成命名数据格式后两类分组，即interest(兴趣)分组和data(内容)分组，两组中通过关键词组和元数据信息形成数据报文，快速撮合匹配算法为纽带，通过拉(pull)的方式对数据进行多级逐个匹配。该算法减少每个业务节点计算量和需方数据包的匹配次数，通过缓存加快相同或类似数据包匹配响应速度，并且确保了需方数据包匹配结果完全正确性。

S52匹配的过程可以为：

步骤a、将供应方数据报文根据格式进行分类得到多个属性表达式，再将这些属性表达式根据其他相似表达式组合得到属性表达式集合；(多个属性表达式分为两类：一类是关键词组，第二类为元数据信息，每一类中都带有逻辑匹配符)

步骤b、将属性表达式集合hash映射至相关业务节点中；

步骤c、需求方数据包进入业务节点匹配时，业务节点通过计算需求方数据包键值查找节点中对应的属性表达式集合；(有对应的属性表达式集合，接着进入第“4”，如没有业务节点将广播到其他业务节点)

步骤d、属性表达式集合内通过优先级排列顺序查找符合需求方数据包的属性表达式；(有对应的属性表达式集式，接着进入第“5”，如没有业务节点将广播到其他业务节点)

步骤e、符合的属性表达式将通过逻辑匹配符将需求方数据包直接传递下一个相关联的属性表达式进行直接匹配。

步骤f、供应方数据报文的所有属性表达式匹配完成后，将结束匹配并每个节点进行随机缓存，随机缓存为了加快后续相同或类似数据包匹配响应速度。另外如果供应方数据报文的所有属性表达式匹配过程中途有一个属性表达式匹配失败，将终止匹配并告知该数据报文中还未进行匹配的属性表达式不再对该数据包进行匹配。

一种可能的实现方式中，在匹配类型是模糊匹配的情况下，需求请求消息中还包括匹配类型，匹配类型包括模糊匹配和精确匹配。

S52可以通过如下步骤实现：

S521：供应类型的节点将需求请求消息中的数据包标签分别与每个供应方的数据包标签进行匹配，确定标签匹配的供应方。

S522：供应类型的节点将需求请求消息中的关键字集合分别与每个标签匹配的供应方的关键字集合进行匹配，得到多个候选的供应方。

另一种可能的实现方式中，在匹配类型是精确匹配的情况下，S12可以通过如下步骤实现：

S52a：供应类型的节点将需求请求消息中的数据包标签分别与每个供应方的数据包标签进行匹配，确定标签匹配的供应方。

S52b：供应类型的节点将需求请求消息中的关键字集合分别与每个标签匹配的供应方的关键字集合进行匹配，确定关键字匹配的供应方。

S52c：供应类型的节点将需求请求消息中的元数据信息分别与每个关键字匹配的供应方的元数据信息进行匹配，得到多个候选的供应方。

在另外一些实施例中，在S54之后还可以包括：

S55：需求类型的节点显示所有的从供应类型的节点接收到的分配结果；

S56：需求类型的节点基于接收到的选择指令，从所有的分配结果中选择一个分配结果为目标分配结果；

S57：需求类型的节点向目标分配结果对应的供应类型的节点发送选中通知。

其中，选中通知用于指示目标分配结果对应的供应类型的节点发送的分配结果被选中。

S58：目标分配结果对应的供应类型的节点存储需求的产品的信息和分配结果的对应关系。

进一步地，S52之前还可以包括如下步骤：

根据需求的产品的信息与自身存储的需求的产品的信息和分配结果的对应关系，判断是否自身已经存储了需求的产品的信息对应的分配结果。

若自身已经存储了需求的产品的信息对应的分配结果，则继续执行S54。若自身并未存储需求的产品的信息对应的分配结果，则继续执行S52。

本实施例，通过在被选中的供应类型的节点中存储需求的产品的信息和分配结果的对应关系，在下一次有相同的需求的产品的信息时，可以不用执行相应的匹配步骤，直接获取到分配结果，缩短了匹配时间，提高了匹配效率，从而提高了系统的效率。

在另外一些实施例中，S53可以通过如下步骤实现：

S531：供应类型的节点获取初始供应方集合，初始供应方集合中包含至少一个供应方。

S532：供应类型的节点从获取的第一个待合并供应方集合开始，到最后一个待合并供应方集合结束，进行迭代处理，得到目标分配方案。

其中，待合并供应方集合与初始供应方集合没有交集。

其中，S532可以包括如下步骤：

S5321：供应类型的节点基于智能合约，确定需求的产品的信息在初始供应方集合的第一分配方案；确定初始供应方集合的效用值。

S5322：供应类型的节点基于智能合约，确定需求的产品的信息在合并供应方集合的第二分配方案。

其中，供应类型的节点确定合并供应方集合的效用值，合并供应方集合包括初始供应方集合和待合并供应方集合。

S5323：在合并供应方集合的效用值大于初始供应方集合的效用值的情况下，供应类型的节点更新初始供应方集合为合并供应方集合，返回执行确定需求的产品的信息在初始供应方集合的第一分配方案和初始供应方集合的效用值，直到没有合并供应方集合的效用值大于初始供应方集合的效用值，确定目标分配方案为第一分配方案。

其中，供应方集合的效用值为根据供应方集合中的节点的资源利用率、成本和供应方集合中的节点对应的服务提供商的收益得到的。

可选的，可以根据如下公式(1)得到供应方集合的效用值：

其中，U(C)是供应方集合的效用值，UR(T,F)是需求的产品分配到供应方集合以后供应方的资源利用率，Eco

可选的，根据如下公式(2)可以得到所有供应方的收益：

其中，Eco

可选的，根据如下公式(3)可以得到设备的资源利用率：

其中，UR(T,F)是需求的产品分配到供应方的产品的集合以后供应方的资源利用率，Re

下面以具体的实例进行说明本申请的需求分配方法。

一个或者多个需求方(这一步可能需要单独的算法流程，比方说轮巡，避免不公平)，多个层级供应方(每个层级包括一个或者多个供应链联盟成员)---依次轮替执行类似递归。下面实例中的网约房订单对应上述实施例的需求方的需求的产品的信息，下面实例中的服务提供方对应上述实施例的供应方。

实例1：

请参见图7，图7为本申请实施例提供的一种单个网约房订单对应单个服务提供方的处理流程示意图。S1:在区块链中发布消息，例如，需求方可以在区块链中发布网约房订单，服务提供方可以在区块链中发布。(S1对应上述实施例中的S51)

S2:区块链系统接收到需求方发布的网约房订单以后，基于快速撮合匹配算法为网约房订单匹配到单个服务提供方(对应上述实施例中的S52)，基于合作联盟博弈任务分配算法将网约房订单各需求优先级分配给单个服务提供方，单个服务提供方按照优先级提供满足各需求的服务(对应上述实施例中的S53)。

S3:将需求匹配情况发送给供需双方。(对应上述实施例中的S54)

S4:供需双方在线下完成交易等。

实例2：

请参见图8，图8为本申请实施例提供的一种单个网约房订单对应多个服务提供方的处理流程示意图。S1:在区块链中发布消息，例如，需求方可以在区块链中发布网约房订单，服务提供方可以在区块链中发布。(S1对应上述实施例中的S51)

S2:区块链系统接收到需求方发布的网约房订单以后，快速撮合匹配算法为单个网约房订单匹配出多个服务提供方(对应上述实施例中的S52)，然后通过合作联盟博弈算法对多个服务提供方互相博弈形成最优质满足需求的合作联盟，接着合作联盟博弈任务分配算法为联盟成员进行最优任务分配，最优任务分配后联盟各成员按任务为单个网约房订单提供服务(对应上述实施例中的S53)。

S3:将需求匹配情况发送给供需双方。(对应上述实施例中的S54)

S4:供需双方在线下完成交易等。

实例3：

请参见图9，图9为本申请实施例提供的一种多个网约房订单对应多个服务提供方的处理流程示意图。S1:在区块链中发布消息，例如，需求方可以在区块链中发布网约房订单，服务提供方可以在区块链中发布。(S1对应上述实施例中的S51)

S2:区块链系统接收到需求方发布的网约房订单以后，快速撮合匹配算法为多个网约房订单匹配出多个服务提供方(对应上述实施例中的S52)，然后联盟博弈算法对多个网约房订单互相博弈形成最优需求合作联盟，同时也对多个原料互相博弈形成最优质满足满足需求合作联盟；在双边形成合作联盟后，合作联盟博弈任务分配算法为双边联盟成员进行最优任务分配，最优任务分配后多个服务提供方合作联盟按照任务分配为多个网约房订单合作联盟提供最优组合服务(对应上述实施例中的S53)。

S3:将需求匹配情况发送给供需双方。(对应上述实施例中的S54)

S4:供需双方在线下完成交易等。

本申请实施例提供一种计算机可读存储介质，所述介质上存储有程序，所述程序能够被处理器执行以实现上述实施例的方法。

本领域技术人员可以理解，上述实施方式中各种方法的全部或部分功能可以通过硬件的方式实现，也可以通过计算机程序的方式实现。当上述实施方式中全部或部分功能通过计算机程序的方式实现时，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器、随机存储器、磁盘、光盘、硬盘等，通过计算机执行该程序以实现上述功能。例如，将程序存储在设备的存储器中，当通过处理器执行存储器中程序，即可实现上述全部或部分功能。另外，当上述实施方式中全部或部分功能通过计算机程序的方式实现时，该程序也可以存储在服务器、另一计算机、磁盘、光盘、闪存盘或移动硬盘等存储介质中，通过下载或复制保存到本地设备的存储器中，或对本地设备的系统进行版本更新，当通过处理器执行存储器中的程序时，即可实现上述实施方式中全部或部分功能。