WO2018032817A1 - 一种一致性数据累积协同组装方法 - Google Patents

一种一致性数据累积协同组装方法 Download PDF

Info

Publication number
WO2018032817A1
WO2018032817A1 PCT/CN2017/084163 CN2017084163W WO2018032817A1 WO 2018032817 A1 WO2018032817 A1 WO 2018032817A1 CN 2017084163 W CN2017084163 W CN 2017084163W WO 2018032817 A1 WO2018032817 A1 WO 2018032817A1
Authority
WO
WIPO (PCT)
Prior art keywords
assembly
node
mutual trust
result
check
Prior art date
Application number
PCT/CN2017/084163
Other languages
English (en)
French (fr)
Inventor
史兴国
史兴东
陈光宇
Original Assignee
苏州超块链信息科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 苏州超块链信息科技有限公司 filed Critical 苏州超块链信息科技有限公司
Priority to US16/317,880 priority Critical patent/US10735415B2/en
Priority to EP17840793.8A priority patent/EP3503495A4/en
Publication of WO2018032817A1 publication Critical patent/WO2018032817A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5033—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering data affinity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1044—Group management mechanisms 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1061—Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
    • H04L67/1063—Discovery through centralising entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • the invention belongs to the field of computer technology, and particularly relates to a method for peer-to-peer auditing and collaborative assembly of public shared data in a network parallel computing environment.
  • the above arbitration methods are centralized/quasi-centered coordination means, a set of central node/quasi-center nodes need to be set up and run, other nodes register with the group nodes, and use centralized coordination and arbitration mechanism to realize data assembly, and Correspondingly, a consistency check relationship is established for the data. This is a common treatment for distributed computing applications to the consistency of public shared data.
  • centralized arbitration mechanism will reduce the parallelism of the system and increase the risk of single point failure.
  • the central node has become the object of cyber attacks and hijacking because of its importance.
  • centralized arbitration means is not applicable to decentralized computing applications.
  • the current POW arbitration method for decentralized applications requires a lot of computing resources, and the arbitration efficiency is very low.
  • an object of the present invention is to provide a consistent data accumulation cooperative assembly method.
  • the invention utilizes the method of trust accumulation and multiplication among nodes to realize a multi-node collaborative assembly with consistency school
  • the recognized rule f check is predefined in the software running by the node or negotiated by the A and B nodes (the same below); the nodes running the same software generally follow the same communication protocol and recognized rules.
  • the data block conforming to the accepted rule f check is regarded as a trusted data block.
  • the A and B nodes are respectively independently assembled into a data block group [C] according to the agreed generation rule f check and the assembly result is exchanged, and the A and B nodes are respectively used.
  • the generation rule f check mutually reviews the assembly result. If the assembly result is the same, the A and B nodes are trusted partners. If the node holds different results, the node will be ignored by the other party; the trust partner node treats [C] as new own data, and each Repeat the above steps to find other nodes to continuously expand the data block group [C] according to the generation rule f check until the restriction condition of the generation rule f check is reached; the network allows to assemble any number of data block groups at the same time, multiple data block groups [C n is independently audited by each node and assembled according to the merge rule f join . The merged data block group broadcast is sent to other nodes for review.
  • the result of failing to meet the merge rule f join is discarded, and the consistent assembly result is broadcast to the network. It is independently reviewed by the nodes in the network and encapsulated according to the rule f sign . The nodes mutually audit the encapsulation results through broadcast, and are supported by the most nodes. The result of the installation is the public shared data block group recognized by the participating nodes.
  • a consistent data accumulation collaborative assembly method the steps of which are:
  • Any network node A having data addition requirements encapsulates the data D into a data block D A to be authenticated according to a generation rule f check ; then node A broadcasts a mutual trust assembly invitation to the network;
  • the network node B checks the received mutual trust assembly invitation according to the generation rule f check ; if the node A's mutual trust assembly invitation passes the review, the node B assembles the data block D A in the mutual trust invitation and the node B to be authenticated data block. D B is assembled according to the generation rule f check , and then the obtained assembly result [C] is returned to the node A;
  • Node A verifies the legality of the assembly result [C], and if the verification passes, replies to Node B and forms a mutual trust partner with Node B;
  • the node composing the mutual trust partner checks whether the stored assembly result [C] reaches the setting condition of the assembly rule f build ; if the setting condition is not reached, the nodes constituting the mutual trust partner respectively broadcast the mutual trust assembly invitation to the network, and then perform Step 5) until the set condition is reached;
  • the network node i checks the received mutual trust assembly invitation according to the generation rule f check . If the review is passed, the node i merges the assembly result [C] in the mutual trust assembly invitation with the to-be-authenticated data block D i of the node i according to the generation rule. f check is assembled, and then the updated assembly result [C] is returned to the inviting node; the inviting node verifies the reply according to the generation rule f check , and if the verification passes, the updated assembly result [C] is sent to the mutual trust partner.
  • the other nodes in the audit after all the nodes in the mutual trust partner are approved, the node in the mutual trust partner saves the updated assembly result [C], and adds the node i to the mutual trust partner.
  • each assembly result corresponds to a mutual trust partner group; the mutual trust partner group corresponding to the assembly result i is composed of nodes that pass the assembly result i.
  • each mutual trust partner group broadcasts a merge invitation to the network, and the intra-group node of the mutual trust partner group that receives the merge invitation reviews and records the assembly result of other mutual trust partner groups according to the generation rule f check, and constitutes an assembly result of the review. Assembling the result list; then exchanging the assembly result list between each mutual trust partner group, selecting the jointly approved assembly result; then composing the jointly approved assembly result into the recognized data set [C] all according to the merge rule f join .
  • all nodes participating in generating and approving the recognized data set [C] all independently encapsulate [C] all and add consistency check data according to the same encapsulation rule f sign to obtain public shared data; each mutual trust partner group The nodes respectively hold the public shared data, and the mutual trust relationship between the nodes is released.
  • each node in the network independently audits multiple assembly results, and then assembles and merges the assembled assembly results according to the merge rule f join , and then sends the merged data block group to other nodes for review; the node will conform to the merge rule.
  • the data block group of f join is broadcasted to the network, and the nodes in the network independently examine and receive the data block groups and encapsulate them according to the merge rule f sign , and then the nodes mutually audit the encapsulation result by broadcasting, and the package supported by the most nodes is supported.
  • the result is a public shared block group.
  • the assembly result [C] corresponds to a mutual trust partner group, and the assembly result [C] is the recognized data group [C] all .
  • the mutual trust assembly invitation includes a data block D A to be authenticated, and a generation rule f check ; the mutual trust assembly invitation includes a current assembly result [C] and a generation rule f check .
  • the generation rule f check is a predefined rule or a rule generated by negotiation by several nodes.
  • the generation rule f check includes an f check difficulty coefficient, a verification mode information, a current trust chain length, an assembly sequence, and a desired chain length.
  • the set condition is a desired chain length.
  • step 3 when node A receives the assembly result [C] returned by a plurality of different nodes, and each assembly result [C] is verified, the verification result that is first received and verified is selected.
  • the node replies and forms a mutual trust partner with the node.
  • Network nodes can organize and co-assemble consistent data without relying on specific centralized coordination means; the data assembly process is open and extensible; the data assembly process is independently audited by participating nodes, malicious data and malicious nodes are Ignore, it can effectively resist malicious attacks and unexpected errors; the assembled data is held by the participating nodes and mutually verified, which can prevent malicious tampering or hijacking; the data assembly efficiency is high, the assembly scale is increased by 2 n , and can be completed in a short time. A large number of data and nodes for mutual review and coordination.
  • Figure 1 illustrates a node data assembly process in the present invention
  • FIG. 2 illustrates an execution flow of a data assembling node in the present invention.
  • any network node A having data addition requirements encapsulates its own data D into a data block D A to be authenticated according to a generation rule f check ;
  • Node A broadcasts a mutual trust assembly invitation to the network, the invitation includes a data block D A to be authenticated, an assembly requirement generation rule f check (including a difficulty coefficient definition, a verification mode definition, a current trust chain length, a desired chain length, and an assembly sequence).
  • an assembly requirement generation rule f check including a difficulty coefficient definition, a verification mode definition, a current trust chain length, a desired chain length, and an assembly sequence.
  • any listening node B selects an invitation that meets the assembly condition, checks the legality of the data block in the invitation according to the generation rule f check , and ignores the request and the difficulty coefficient that does not meet the assembly expectation in the request, and the school
  • the request method, the current chain of trust length, the length of the expected chain, etc. require an invalid request.
  • the data in the legal request and the data block D B to be authenticated of the node are assembled into ⁇ D A , D B ⁇ according to the generation rule f check and are called [C] (as shown in FIG. 1 ), and then the assembly result [C] ] reply to the inviting party node A, requesting an audit;
  • the inviting party node A receives the assembly reply, verifies the legality of the assembly [C] according to the generation rule f check , and replies to the invitee node B to form a mutual trust partner. If the assembly reply is not valid, node A ignores the reply and listens for responses from other nodes. If the monitoring times out, repeat step 2;
  • any node of the mutual trust partner receives the assembly invitation/assembly response during the monitoring, it continues to verify the invitation/reply according to the generation rule f check . If it is a legal assembly result, it submits it to other nodes in the mutual trust partner to review the assembly. Consistency of the results, after obtaining the audit approval of all mutual trust nodes, node A and its mutual trust node add the data block corresponding to the new reply in the assembly result [C] (as shown in Figure 1), and add the new one to the mutual trust partner. Node, forming a mutual trust partner group, repeat step 5;
  • the mutual trust partner group broadcasts the merge invitation to the network while listening to other merge requests on the network; the merge invitation includes the assembly result [C] itself and an identification field indicating that it is a merge invitation; the merge invitation may also be broadcast only The invitation package is merged, and the [C] is sent to the other party after the node responds.
  • the mutual trust partner group collects the monitored merge invitation as much as possible, and the group nodes check and record the legality of the assembly result [C] of other mutual trust partner groups according to the generation rule f check , and finally form the current group approval [C] List
  • the mutual trust partner group exchanges the [C] list approved by the group, selects the jointly recognized [C] according to the merge rule f join composition [C] all , [C] all becomes the recognized data group of the mutual trust partner group;
  • any network node A having data addition requirements encapsulates its own data D into a data block D A to be authenticated according to a generation rule f check ;
  • Node A broadcasts a mutual trust assembly invitation to the network, the invitation includes a data block D A to be authenticated, an assembly requirement generation rule f check (including a difficulty coefficient definition, a verification mode definition, a current trust chain length, a desired chain length, and an assembly sequence).
  • an assembly requirement generation rule f check including a difficulty coefficient definition, a verification mode definition, a current trust chain length, a desired chain length, and an assembly sequence.
  • any listening node B selects an invitation that meets the assembly condition, checks the legality of the data block in the invitation according to the generation rule f check , and ignores the request and the difficulty coefficient that do not meet the assembly expectation in the request.
  • the method of verification, the current length of the chain of trust, the length of the expected chain, etc. require an invalid request.
  • the data in the legal request and the data block D B to be authenticated of the node are assembled into ⁇ D A , D B ⁇ according to the generation rule f check and are called [C] (as shown in FIG. 1 ), and then the assembly result [C] ] reply to the inviting party node A, requesting an audit;
  • the inviting party node A receives the assembly reply, verifies the legality of the assembly [C] according to the generation rule f check , and replies to the invitee node B to form a mutual trust partner. If the assembly reply is not valid, node A ignores the reply and listens for responses from other nodes. If the monitoring times out, repeat step 2;
  • any node of the mutual trust partner receives the assembly invitation/assembly reply after listening, it continues to verify the invitation/reply according to the generation rule f check . If the result is legal assembly, the node A and its mutual trust node are assembled in the result [C. Add the data block corresponding to the new reply (as shown in Figure 1), add the new node to the mutual trust partner, and form a mutual trust partner group according to the mutual trust dependency chain, repeat step 5;
  • the mutual trust partner group broadcasts the merge invitation to the network while listening to other merge requests on the network;
  • the mutual trust partner group collects the monitored merge invitation as much as possible, and the group nodes check and record the legality of the assembly result [C] of other mutual trust partner groups according to the generation rule f check , and finally form the current group approval [C] List
  • the mutual trust partner group exchanges the [C] list approved by the group, selects the jointly recognized [C] according to the merge rule f join composition [C] all , [C] all becomes the recognized data group of the mutual trust partner group;
  • any network node A having data addition requirements encapsulates its own data D into a data block D A to be authenticated according to a generation rule f check ;
  • Node A broadcasts a mutual trust assembly invitation to the network, the invitation includes a data block D A to be authenticated, an assembly requirement generation rule f check (including a difficulty coefficient definition, a verification mode definition, a current trust chain length, a desired chain length, and an assembly sequence).
  • an assembly requirement generation rule f check including a difficulty coefficient definition, a verification mode definition, a current trust chain length, a desired chain length, and an assembly sequence.
  • any listening node B selects an invitation that meets the assembly condition, checks the legality of the data block in the invitation according to the generation rule f check , and ignores the request and the difficulty coefficient that do not meet the assembly expectation in the request.
  • the method of verification, the current length of the chain of trust, the length of the expected chain, etc. require an invalid request.
  • the data in the legal request and the data block D B to be authenticated of the node are assembled into ⁇ D A , D B ⁇ according to the generation rule f check and are called [C] (as shown in FIG. 1 ), and then the assembly result [C] ] reply to the inviting party node A, requesting an audit;
  • the inviting party node A receives the assembly reply, verifies the legality of the assembly [C] according to the generation rule f check , and replies to the invitee node B to form a mutual trust partner. If the assembly reply is not valid, node A ignores the reply and listens for responses from other nodes. If the monitoring times out, repeat step 2;
  • any node of the mutual trust partner receives the assembly invitation/assembly reply after listening, it continues to verify the invitation/reply according to the generation rule f check . If it is a legal assembly result, it submits to other nodes in the mutual trust partner to review the assembly. Consistency of the results, after obtaining the audit approval of all mutual trust nodes, node A and its mutual trust node add the data block corresponding to the new reply in the assembly result [C] (as shown in Figure 1), and add the new one to the mutual trust partner. Node, forming a mutual trust partner group, repeat step 5;
  • the mutual trust partner group collects the monitored assembly invitation as much as possible. When the network node participates in the assembly, it also preferentially selects the group with more mutual trust partners. After a period of time, the final dominant group forms the mutual trust partner group with the most mutual trust nodes in the network. Current maximum mutual trust group;
  • the maximum mutual trust group external broadcast [C] request encapsulation confirmation any node can participate in the package confirmation, the [C] node is authorized to encapsulate [C] and add consistency check data according to the same encapsulation rule f sign ,
  • the result of the encapsulation should be consistent at each node (or a digital digest of the encapsulation result or the encapsulation result between nodes to confirm the consistency of the calculation result), that is, legal public shared data.
  • the nodes in the mutual trust partner group respectively hold legal public shared data, and the mutual trust relationship between the nodes is released.
  • the node corresponding to the data that has not been approved by the audit during the assembly process needs to repeat the step 1 to retry a new round of data assembly with its own data D.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Multimedia (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种一致性数据累积协同组装方法。本方法为：1)节点A按照生成规则将数据D封装为数据块DA；然后广播互信组装邀请；2)节点B审查通过该互信组装邀请后，将DA与节点B的数据块DB按照生成规则组装后回复给节点A；3)节点A验证组装结果合法后与节点B结成互信伙伴；4)互信伙伴节点检查存储的组装结果是否达到组装规则的设定条件；如果未达到则互信伙伴节点分别向网络广播互信组装邀请；5)节点i审查通过互信组装邀请后，将该组装结果与节点i的数据块Di按照生成规则组装，然后将新的组装结果回复给邀请节点；邀请节点的互信伙伴中的所有节点均审核通过后，保存该新的组装结果并在该互信伙伴中增加该节点i。

Description

一种一致性数据累积协同组装方法 技术领域
本发明属于计算机技术领域，具体涉及网络并行计算环境中，多节点对等审核、协同组装公有共享数据的方法。
背景技术
互联网应用中存在着大量离散数据的存储和处理需求，这些数据同时具有逻辑离散性和时间离散性的特点，在传统的基于事务的数据处理方式下显得尤为低效且封闭，由此业界逐渐改用大数据技术来应对这类离散性数据的读写和处理需求，改善了性能和扩展能力，但出于对性能和操作性的考量，大数据技术一定程度上降低了对数据一致性的要求。因此当网络中的离散节点需要以各自持有离散数据形成公有共享数据，并要求该数据同时满足在校验逻辑上公认的一致性时(如分布式多节点分别同时维护一组离散交易数据并需要保持交易的全局一致性；多个处理节点各自离散的接收或产生一组输入数据后实时的协调生成一组公认的一致性数据等)，则必须通过一些特定仲裁和协调机制来实现。目前的仲裁方法一般包括：中心服务器仲裁、代理节点仲裁、加权节点仲裁。
以上仲裁方法均为中心化/准中心化协调手段，需要设置和运行一组中心节点/准中心节点，其他节点向该组节点注册，使用中心化的协调和仲裁机制实现对数据的组装，并相应的为数据建立一致性校验关系。这是目前分布式计算应用对公有共享数据一致性的常见的处理方式。
此外，还有一种采用POW(工作量证明)算法来协调节点的数据组装行为的方法，即POW仲裁方法，被用在完全去中心化计算环境中。
综上，在目前的网络运算中，采用中心化的仲裁机制会降低系统的并行性，增加单点失效的风险。同时中心节点因其重要性，也成为网络攻击和劫持的对象。另外中心化仲裁手段也不适用于去中心化计算的应用场合。而目前的对去中心化应用支持较好的POW仲裁方法需要耗费大量的计算资源，仲裁效率也非常低。
发明内容
针对现有技术中存在的技术问题，本发明的目的在于提供一种一致性数据累积协同组装方法。本发明利用节点间信任累积和倍增的方式，实现了一种多节点协同组装具有一致性校 验关系的公有共享数据的方法：
任一网络节点A以自有数据块DA，与网络上的任意对等节点B的数据块DB，按照节点间约定的公认规则fcheck相互审核对方的数据块，其中，节点A和B间通过广播方式相互发现，公认规则fcheck在节点运行的软件中预定义或由A、B节点协商产生(下同)；运行相同软件的节点一般遵循相同的通讯协议和公认规则。符合公认规则fcheck的数据块被视为可信数据块，由A、B节点分别按照约定的生成规则fcheck各自独立组装为数据块组[C]并交换组装结果，A、B节点分别使用生成规则fcheck相互审查组装结果，若组装结果相同则A、B节点结为信任伙伴，节点若持不同结果则将被对方忽略；信任伙伴节点将[C]视为新的自有数据，各自重复以上步骤，寻找其他节点按照生成规则fcheck不断扩展数据块组[C]，直至达到生成规则fcheck的限制条件；网络中允许同时组装任意多个数据块组，多个数据块组[C]n由各节点分别独立审核和按照合并规则fjoin组装合并，合并后的数据块组广播发送给其它节点进行审核，不符合合并规则fjoin的结果被抛弃，一致的组装结果向网络广播，由网络中的节点分别独立审查并按照规则fsign封装，节点间通过广播相互审核封装结果，受最多数节点支持的封装结果即为参与节点公认的公有共享数据块组。
本发明的技术方案为：
一种一致性数据累积协同组装方法，其步骤为：
1)有数据添加需求的任一网络节点A按照生成规则fcheck将数据D封装为待认证的数据块DA；然后节点A向网络广播互信组装邀请；
2)网络节点B根据生成规则fcheck审查收到的互信组装邀请；如果节点A的互信组装邀请通过审查，则节点B将该互信组装邀请中的数据块DA与节点B的待认证数据块DB按照生成规则fcheck进行组装，然后将得到的组装结果[C]回复给节点A；
3)节点A验证该组装结果[C]的合法性，如果验证通过则回复节点B，并与节点B结成互信伙伴；
4)组成互信伙伴的节点检查存储的组装结果[C]是否达到组装规则fbuild的设定条件；如果未达到该设定条件，则组成互信伙伴的节点分别向网络广播互信组装邀请，然后进行步骤5)，直至达到该设定条件；
5)网络节点i根据生成规则fcheck审查收到的互信组装邀请，如果通过审查，则节点i将该互信组装邀请中的组装结果[C]与节点i的待认证数据块Di按照生成规则fcheck进行组装，然后将更新后的组装结果[C]回复给邀请节点；邀请节点根据生成规则fcheck验证该回复，若验证通过，则将该更新后的组装结果[C]发送给互信伙伴中的其他节点 审核，当该互信伙伴中的所有节点均审核通过后，该互信伙伴中的节点保存该更新后的组装结果[C]，并在该互信伙伴中增加该节点i。
进一步的，网络中同时存在多个组装结果，每一组装结果对应一互信伙伴群；组装结果i对应的互信伙伴群由对该组装结果i审核通过的节点构成。
进一步的，各互信伙伴群向网络广播合并邀请，收到该合并邀请的互信伙伴群的群内节点根据生成规则fcheck审核并记录其他互信伙伴群的组装结果，将审查通过的组装结果构成一组装结果列表；然后各互信伙伴群之间交换组装结果列表，选取共同认可的组装结果；然后按合并规则fjoin将共同认可的组装结果组成公认数据组[C]all。
进一步的，所有参与生成并认可该公认数据组[C]all的节点按照同一封装规则fsign独立对[C]all进行封装和添加一致性校验数据，得到公有共享数据；各互信伙伴群中的节点分别持有该公有共享数据，节点间的互信关系解除。
进一步的，网络中各节点分别对多个组装结果独立审核，然后将审核通过的组装结果按照合并规则fjoin组装合并，然后将合并后的数据块组发送给其他节点审核；节点将符合合并规则fjoin的数据块组向网络广播，网络中的节点对收到的数据块组分别独立审查并按照合并规则fsign封装，然后节点间通过广播相互审核封装结果，将受最多数节点支持的封装结果作为公有共享数据块组。
进一步的，当网络中仅存在一个组装结果[C]时，该组装结果[C]对应一个互信伙伴群，该组装结果[C]即为公认数据组[C]all。
进一步的，该互信组装邀请包含待认证的数据块DA、生成规则fcheck；该互信组装邀请包含当前组装结果[C]、生成规则fcheck。
进一步的，该生成规则fcheck为预定义的规则或由若干节点协商产生的规则。
进一步的，该生成规则fcheck包括fcheck难度系数、校验方式信息、当前信任链长度、组装顺序和期望链长度。
进一步的，该设定条件为期望链长度。
进一步的，步骤3)中，当节点A收到多个不同节点返回的组装结果[C]，且各组装结果[C]均验证通过时，选择最先收到且验证通过的验证结果对于的节点进行回复，并与该节点结成互信伙伴。
与现有技术相比，本发明的积极效果为：
网络节点不需依赖特定的中心化协调手段，即可自行组织和共同组装一致性数据；数据 组装过程是开放的和可扩展的；数据组装过程由参与节点分别独立审核，恶意数据和恶意节点被忽略，可有效抵御恶意攻击和意外错误；组装的数据由参与节点分别持有并相互验证，可防止恶意篡改或劫持；数据组装效率较高，组装规模以2n增长，可在短时间内完成大量数据和节点的互审及协调。
附图说明
图1示例了本发明中的节点数据组装过程；
(a)数据组装阶段1，(b)数据组装阶段2，(c)数据组装阶段3，
图2示例本发明中的数据组装节点的执行流程。
具体实施方式
下面结合附图对本发明进行进一步详细描述。
实施例1：
1，如图2所示，有数据添加需求的任一网络节点A将自有数据D按照生成规则fcheck封装为待认证的数据块DA；
2，节点A向网络广播互信组装邀请，该邀请包含待认证的数据块DA、组装要求生成规则fcheck(包括难度系数定义，校验方式定义，当前信任链长度，期望链长度，组装顺序等信息)；
3，任一监听节点B收到互信组装邀请后，选择符合组装条件的邀请，按照生成规则fcheck审查该邀请中数据块的合法性，忽略请求中不符合组装期望的请求和难度系数、校验方式、当前信任链长度、期望链长度等要求不合法的请求。将合法请求中的数据与本节点的待认证数据块DB按照生成规则fcheck组装成为{DA,DB}并称作[C](如图1所示)，然后将组装结果[C]回复给邀请方节点A，请求审核；
4，邀请方节点A收到组装回复，根据生成规则fcheck验证该组装[C]的合法性，并回复受邀方节点B，结成互信伙伴。若组装回复不合法则节点A忽略该回复，监听其他节点的回复。若监听超时，重复步骤2；
5，组成互信伙伴的节点必然拥有一致的组装结果[C]，并各自存储，若未达到组装规则fcheck中期望链长度的限制，则继续向网络广播互信组装邀请。若已达生成规则fcheck中期望链长度的限制，视同[C]已组装结束，则跳转至步骤7；
6，互信伙伴中的任意一节点在监听时收到组装邀请/组装回复后，继续根据生成规则 fcheck验证该邀请/回复，若是合法组装结果，则提交给互信伙伴中的其他节点审核该组装结果的一致性，获得所有互信节点的审核认可后，节点A及其互信节点在组装结果[C]中增加该新回复所对应的数据块(如图1所示)，互信伙伴中增加该新节点，形成互信伙伴群，重复步骤5；
7，由于并行处理的原因，网络中同时存在多个互信伙伴群和多个已完成组装的[C]。互信伙伴群向网络广播合并邀请，同时监听网络上的其他合并请求；该合并邀请包括组装结果[C]本身和一个识别域，该识别域表明其为一个合并邀请；该合并邀请也可仅仅广播合并邀请包，待有节点响应后再发送[C]给对方。
8，互信伙伴群尽可能收集监听到的合并邀请，并由群内节点根据生成规则fcheck审核和记录其他互信伙伴群的组装结果[C]的合法性，最终形成当前群认可的[C]列表；
9，各互信伙伴群之间交换获本群认可的[C]列表，选取共同认可的[C]按合并规则fjoin组成[C]all，[C]all成为互信伙伴群的公认数据组；
10，所有参与生成并认可[C]all的节点按照同一封装规则fsign独立对[C]all进行封装和添加一致性校验数据，该封装结果在各节点计算结果应一致(或节点间再次广播封装结果或封装结果的数字摘要来确认计算结果的一致性)，获多数节点一致性认可的封装结果即为合法的公有共享数据。数据完成封装后，互信伙伴群中的节点分别持有合法公有共享数据，节点间的互信关系解除。组装过程中未能通过审核而被抛弃的数据所对应的节点，需持自有数据D重复步骤1重新尝试新一轮的数据组装。
实施例2
1，如图2所示，有数据添加需求的任一网络节点A将自有数据D按照生成规则fcheck封装为待认证的数据块DA；
2，节点A向网络广播互信组装邀请，该邀请包含待认证的数据块DA、组装要求生成规则fcheck(包括难度系数定义，校验方式定义，当前信任链长度，期望链长度，组装顺序等信息)；
3，任一监听节点B收到互信组装邀请后，选择符合组装条件的邀请，按照生成规则fcheck审查该邀请中数据块的合法性，忽略请求中不符合组装期望的请求和难度系数，校验方式，当前信任链长度，期望链长度等要求不合法的请求。将合法请求中的数据与本节点的待认证数据块DB按照生成规则fcheck组装成为{DA,DB}并称作[C](如图1所示)，然后将组装结果[C]回复给邀请方节点A，请求审核；
4，邀请方节点A收到组装回复，根据生成规则fcheck验证该组装[C]的合法性，并回复受邀方节点B，结成互信伙伴。若组装回复不合法则节点A忽略该回复，监听其他节点的回复。若监听超时，重复步骤2；
5，组成互信伙伴的节点必然拥有一致的组装结果[C]，并各自存储，若未达到组装规则fcheck中期望链长度的限制，则继续向网络广播互信组装邀请。若已达生成规则fcheck中期望链长度的限制，视同[C]已组装结束，则跳转至步骤7；
6，互信伙伴中的任意一节点在监听时收到组装邀请/组装回复后，继续根据生成规则fcheck验证该邀请/回复，若是合法组装结果，提请节点A及其互信节点在组装结果[C]中增加该新回复所对应的数据块(如图1所示)，互信伙伴中增加该新节点，按照互信依赖链形成互信伙伴群，重复步骤5；
7，由于并行处理的原因，网络中同时存在多个互信伙伴群和多个已完成组装的[C]。互信伙伴群向网络广播合并邀请，同时监听网络上的其他合并请求；
8，互信伙伴群尽可能收集监听到的合并邀请，并由群内节点根据生成规则fcheck审核和记录其他互信伙伴群的组装结果[C]的合法性，最终形成当前群认可的[C]列表；
9，各互信伙伴群之间交换获本群认可的[C]列表，选取共同认可的[C]按合并规则fjoin组成[C]all，[C]all成为互信伙伴群的公认数据组；
10，所有参与生成并认可[C]all的节点按照同一封装规则fsign独立对[C]all进行封装和添加一致性校验数据，除必须的校验码以外，fcheck和fsign也作为校验规则添加进一致性校验数据中。该封装结果在各节点计算结果应一致(或节点间再次广播封装结果或封装结果的数字摘要来确认计算结果的一致性)，即为合法的公有共享数据。数据完成封装后，互信伙伴群中的节点分别持有合法公有共享数据，节点间的互信关系解除。组装过程中未能通过审核而被抛弃的数据所对应的节点，需持自有数据D重复步骤1重新尝试新一轮的数据组装。
实施例3：
1，如图2所示，有数据添加需求的任一网络节点A将自有数据D按照生成规则fcheck封装为待认证的数据块DA；
2，节点A向网络广播互信组装邀请，该邀请包含待认证的数据块DA、组装要求生成规则fcheck(包括难度系数定义，校验方式定义，当前信任链长度，期望链长度，组装顺序等信息)；
3，任一监听节点B收到互信组装邀请后，选择符合组装条件的邀请，按照生成规则fcheck 审查该邀请中数据块的合法性，忽略请求中不符合组装期望的请求和难度系数，校验方式，当前信任链长度，期望链长度等要求不合法的请求。将合法请求中的数据与本节点的待认证数据块DB按照生成规则fcheck组装成为{DA,DB}并称作[C](如图1所示)，然后将组装结果[C]回复给邀请方节点A，请求审核；
4，邀请方节点A收到组装回复，根据生成规则fcheck验证该组装[C]的合法性，并回复受邀方节点B，结成互信伙伴。若组装回复不合法则节点A忽略该回复，监听其他节点的回复。若监听超时，重复步骤2；
5，组成互信伙伴的节点必然拥有一致的组装结果[C]，并各自存储，若未达到组装规则fcheck中期望链长度的限制，则继续向网络广播互信组装邀请。若已达生成规则fcheck中期望链长度的限制，视同[C]已组装结束，则跳转至步骤7；
6，互信伙伴中的任意一节点在监听时收到组装邀请/组装回复后，继续根据生成规则fcheck验证该邀请/回复，若是合法组装结果，则提交给互信伙伴中的其他节点审核该组装结果的一致性，获得所有互信节点的审核认可后，节点A及其互信节点在组装结果[C]中增加该新回复所对应的数据块(如图1所示)，互信伙伴中增加该新节点，形成互信伙伴群，重复步骤5；
7，互信伙伴群尽可能收集监听到的组装邀请，网络节点参与组装时也优先选择互信伙伴多的群加入，一段时间后，最终优势群形成当前网内互信节点最多的互信伙伴群，称为当前最大互信群；
8，最大互信群对外广播[C]请求封装确认，任一节点均可参与封装确认，认可[C]的节点按照同一封装规则fsign独立对[C]进行封装和添加一致性校验数据，该封装结果在各节点计算结果应一致(或节点间再次广播封装结果或封装结果的数字摘要来确认计算结果的一致性)，即为合法的公有共享数据。数据完成封装后，互信伙伴群中的节点分别持有合法公有共享数据，节点间的互信关系解除。组装过程中未能通过审核而被抛弃的数据所对应的节点，需持自有数据D重复步骤1重新尝试新一轮的数据组装。

Claims (12)

  1. 一种一致性数据累积协同组装方法，其步骤为：
    1)有数据添加需求的任一网络节点A按照生成规则fcheck将数据D封装为待认证的数据块DA；然后节点A向网络广播互信组装邀请；
    2)网络节点B根据生成规则fcheck审查收到的互信组装邀请；如果节点A的互信组装邀请通过审查，则节点B将该互信组装邀请中的数据块DA与节点B的待认证数据块DB按照生成规则fcheck进行组装，然后将得到的组装结果[C]回复给节点A；
    3)节点A验证该组装结果[C]的合法性，如果验证通过则回复节点B，并与节点B结成互信伙伴；
    4)组成互信伙伴的节点检查存储的组装结果[C]是否达到组装规则fcheck的设定条件；如果未达到该设定条件，则组成互信伙伴的节点分别向网络广播互信组装邀请，然后进行步骤5)，直至达到该设定条件；
    5)网络节点i根据生成规则fcheck审查收到的互信组装邀请，如果通过审查，则节点i将该互信组装邀请中的组装结果[C]与节点i的待认证数据块Di按照生成规则fcheck进行组装，然后将更新后的组装结果[C]回复给邀请节点；邀请节点根据生成规则fcheck验证该回复，若验证通过，则将该更新后的组装结果[C]发送给互信伙伴中的其他节点审核，当该互信伙伴中的所有节点均审核通过后，该互信伙伴中的节点保存该更新后的组装结果[C]，并在该互信伙伴中增加该节点i。
  2. 如权利要求1所述的方法，其特征在于，网络中同时存在多个组装结果，每一组装结果对应一互信伙伴群；组装结果[C]i对应的互信伙伴群由对该组装结果i审核通过的节点构成。
  3. 如权利要求2所述的方法，其特征在于，各互信伙伴群向网络广播合并邀请，收到该合并邀请的互信伙伴群的群内节点根据生成规则fcheck审核并记录其他互信伙伴群的组装结果，将审查通过的组装结果构成一组装结果列表；然后各互信伙伴群之间交换组装结果列表，选取共同认可的组装结果；然后按合并规则fjoin将共同认可的组装结果组成公认数据组[C]all。
  4. 如权利要求3所述的方法，其特征在于，所有参与生成并认可该公认数据组[C]all的节点按照同一封装规则fsign独立对[C]all进行封装和添加一致性校验数据，得到公有共享数据；各互信伙伴群中的节点分别持有该公有共享数据，节点间的互信关系解除。
  5. 如权利要求2所述的方法，其特征在于，网络中各节点分别对多个组装结果独立审核，然后将审核通过的组装结果按照合并规则fjoin组装合并，然后将合并后的数据块组发送给其 他节点审核；节点将符合合并规则fjoin的数据块组向网络广播，网络中的节点对收到的数据块组分别独立审查并按照合并规则fsign封装，然后节点间通过广播相互审核封装结果，将受最多数节点支持的封装结果作为公有共享数据块组。
  6. 如权利要求1所述的方法，其特征在于，当网络中仅存在一个组装结果[C]时，该组装结果[C]对应一个互信伙伴群，该组装结果[C]即为公认数据组[C]all。
  7. 如权利要求1所述的方法，其特征在于，该互信组装邀请包含待认证的数据块DA、生成规则fcheck；该互信组装邀请包含当前组装结果[C]、生成规则fcheck。
  8. 如权利要求1～7任一所述的方法，其特征在于，该生成规则fcheck为预定义的规则或由若干节点协商产生的规则。
  9. 如权利要求1～7任一所述的方法，其特征在于，该生成规则fcheck包括校验方式信息、组装顺序和期望链长度。
  10. 如权利要求9所述的方法，其特征在于，该设定条件为期望链长度。
  11. 如权利要求9所述的方法，其特征在于，该生成规则fcheck还包括fcheck难度系数和当前信任链长度。
  12. 如权利要求1～7任一所述的方法，其特征在于，步骤3)中，当节点A收到多个不同节点返回的组装结果[C]，且各组装结果[C]均验证通过时，选择最先收到且验证通过的验证结果对于的节点进行回复，并与该节点结成互信伙伴。
PCT/CN2017/084163 2016-08-18 2017-05-12 一种一致性数据累积协同组装方法 WO2018032817A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/317,880 US10735415B2 (en) 2016-08-18 2017-05-12 Method for accumulating and co-assembling consistent data
EP17840793.8A EP3503495A4 (en) 2016-08-18 2017-05-12 METHOD FOR COLLECTING AND CO-ASSEMBLING UNIFORM DATA

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610686127.2 2016-08-18
CN201610686127.2A CN106357604B (zh) 2016-08-18 2016-08-18 一种一致性数据累积协同组装方法

Publications (1)

Publication Number Publication Date
WO2018032817A1 true WO2018032817A1 (zh) 2018-02-22

Family

ID=57843416

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/084163 WO2018032817A1 (zh) 2016-08-18 2017-05-12 一种一致性数据累积协同组装方法

Country Status (4)

Country Link
US (1) US10735415B2 (zh)
EP (1) EP3503495A4 (zh)
CN (1) CN106357604B (zh)
WO (1) WO2018032817A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106357604B (zh) * 2016-08-18 2019-07-23 苏州超块链信息科技有限公司 一种一致性数据累积协同组装方法
CN107040585B (zh) * 2017-02-22 2020-06-19 创新先进技术有限公司 一种业务校验的方法及装置
CN107341702B (zh) 2017-03-08 2020-06-23 创新先进技术有限公司 一种业务处理的方法及装置
CN116319119B (zh) * 2023-05-26 2023-09-26 广东广宇科技发展有限公司 一种伴随式迭代通信验证方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104580253A (zh) * 2015-01-30 2015-04-29 网易（杭州）网络有限公司 一种处理用户数据的方法及装置
WO2015142765A1 (en) * 2014-03-17 2015-09-24 Coinbase, Inc Bitcoin host computer system
CN105488665A (zh) * 2015-11-25 2016-04-13 布比（北京）网络技术有限公司 一种去中心化的交易方法
CN105808325A (zh) * 2016-03-03 2016-07-27 布比（北京）网络技术有限公司 一种数据处理的方法及装置
CN106357604A (zh) * 2016-08-18 2017-01-25 史兴国 一种一致性数据累积协同组装方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7120797B2 (en) * 2002-04-24 2006-10-10 Microsoft Corporation Methods for authenticating potential members invited to join a group
US7698465B2 (en) * 2004-11-23 2010-04-13 Microsoft Corporation Generalized Paxos
US9230286B2 (en) * 2008-03-14 2016-01-05 Industrial Technology Research Institute Methods and systems for associating users through network societies
US9100453B2 (en) * 2011-10-08 2015-08-04 Broadcom Corporation Social device security in a social network
US20150163066A1 (en) * 2013-12-06 2015-06-11 Telefonaktiebolaget L M Ericsson (Publ) Teleconferencing system and method
US20160164884A1 (en) * 2014-12-05 2016-06-09 Skuchain, Inc. Cryptographic verification of provenance in a supply chain
US10263779B2 (en) * 2015-09-24 2019-04-16 Jonetix Corporation Secure communications using loop-based authentication flow
CN105608165A (zh) * 2015-12-21 2016-05-25 用友网络科技股份有限公司 一种分布式数据库主键生成的方法和系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015142765A1 (en) * 2014-03-17 2015-09-24 Coinbase, Inc Bitcoin host computer system
CN104580253A (zh) * 2015-01-30 2015-04-29 网易（杭州）网络有限公司 一种处理用户数据的方法及装置
CN105488665A (zh) * 2015-11-25 2016-04-13 布比（北京）网络技术有限公司 一种去中心化的交易方法
CN105808325A (zh) * 2016-03-03 2016-07-27 布比（北京）网络技术有限公司 一种数据处理的方法及装置
CN106357604A (zh) * 2016-08-18 2017-01-25 史兴国 一种一致性数据累积协同组装方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3503495A4 *

Also Published As

Publication number Publication date
EP3503495A1 (en) 2019-06-26
US10735415B2 (en) 2020-08-04
CN106357604A (zh) 2017-01-25
EP3503495A4 (en) 2020-04-15
CN106357604B (zh) 2019-07-23
US20190227851A1 (en) 2019-07-25

Similar Documents

Publication Publication Date Title
JP7278453B2 (ja) ブロックチェーン・ネットワークにおいてトランザクションを管理するための方法、記憶媒体、電子デバイス、トランザクション検証ノード、スーパー・ノード及びブロックチェーン・ネットワーク
Li et al. An optimized byzantine fault tolerance algorithm for consortium blockchain
CN109450638B (zh) 基于区块链的电子元器件数据管理系统及方法
EP4209980A1 (en) Computer-implemented system and method for managing a large distributed memory pool in a blockchain network
US20230316273A1 (en) Data processing method and apparatus, computer device, and storage medium
WO2018032817A1 (zh) 一种一致性数据累积协同组装方法
WO2023020233A1 (zh) 基于区块链的数据处理方法、装置、设备及存储介质
CN114745140B (zh) 基于聚合加密的城市规划领域区块链共识验证方法及系统
JP2023525973A (ja) マルチレイヤ通信ネットワーク
US20230360046A1 (en) Blockchain-based block processing method and apparatus, device, storage medium, and program product
Wu et al. Reinforced practical Byzantine fault tolerance consensus protocol for cyber physical systems
WO2023168993A1 (zh) 基于区块链的数据处理方法、装置、设备、介质及产品
WO2023103689A1 (zh) 一种区块链中随机数的生成方法、装置、区块链节点、存储介质和计算机程序产品
WO2023082883A1 (zh) 跨区块链处理事务的方法、装置、计算机设备、计算机存储介质及计算机程序产品
Lei et al. Improved Method of Blockchain Cross‐Chain Consensus Algorithm Based on Weighted PBFT
Huang et al. Consensus of whom? A spectrum of blockchain consensus protocols and new directions
Tang et al. TP-PBFT: A Scalable PBFT Based On Threshold Proxy Signature for IoT-Blockchain Applications
Wu et al. Blockchain consensus mechanism for distributed energy transactions
Choi et al. Hierarchical trust chain framework for IoT services
Chen et al. Thinkey: A scalable blockchain architecture
JP2023513950A (ja) 階層化ネットワーク
WO2021115554A1 (en) A service based interface for establishing distributed consensus
Liu et al. Domain Name Service Mechanism Based on Master-Slave Chain.
Ying et al. LOPE: A Low‐Overhead Payment Verification Method for Blockchains
Li et al. Audit as You Go: A Smart Contract‐Based Outsourced Data Integrity Auditing Scheme for Multiauditor Scenarios with One Person, One Vote

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17840793

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017840793

Country of ref document: EP

Effective date: 20190318