WO2019242059A1 - 一种基于树状结构的分片区块链生成方法 - Google Patents

一种基于树状结构的分片区块链生成方法 Download PDF

Info

Publication number
WO2019242059A1
WO2019242059A1 PCT/CN2018/096932 CN2018096932W WO2019242059A1 WO 2019242059 A1 WO2019242059 A1 WO 2019242059A1 CN 2018096932 W CN2018096932 W CN 2018096932W WO 2019242059 A1 WO2019242059 A1 WO 2019242059A1
Authority
WO
WIPO (PCT)
Prior art keywords
group
leader
block
members
sub
Prior art date
Application number
PCT/CN2018/096932
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/972,988 priority Critical patent/US11375010B2/en
Publication of WO2019242059A1 publication Critical patent/WO2019242059A1/zh

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1061Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
    • H04L67/1068Discovery involving direct consultation or announcement among potential requesting and potential source peers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/123Applying verification of the received information received data contents, e.g. message integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1044Group management mechanisms 
    • H04L67/1046Joining mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1044Group management mechanisms 
    • H04L67/1053Group management mechanisms  with pre-configuration of logical or physical connections with a determined number of other peers
    • H04L67/1057Group management mechanisms  with pre-configuration of logical or physical connections with a determined number of other peers involving pre-assessment of levels of reputation of peers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1059Inter-group management mechanisms, e.g. splitting, merging or interconnection of groups
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1074Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1076Resource dissemination mechanisms or network resource keeping policies for optimal resource availability in the overlay network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1074Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1078Resource delivery mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/46Secure multiparty computation, e.g. millionaire problem
    • H04L2209/463Electronic voting

Definitions

  • the present application relates to the field of blockchain technology, and in particular, to a method for generating a fragmented blockchain based on a tree structure.
  • Blockchain is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus mechanisms, and encryption algorithms.
  • the biggest feature of the blockchain is that there is no need for a centralized service node.
  • Decentralization means that there is no centralized configuration management node in a distributed service cluster responsible for determining the order of messages in the network.
  • member nodes in the distributed service cluster may have inconsistent states between nodes due to the unreliability of the network communication channel. Therefore, the blockchain introduced a consensus protocol (consensus algorithm) It is used to deal with the consistency problem of decentralized distributed clusters.
  • Consensus algorithms are used to ensure the consistency of distributed systems.
  • traditional consensus algorithms often need to generate a leader node in the cluster to reduce the amount of messages sent by the user to the cluster and determine the order of the messages.
  • the client since the blockchain system does not have a central node, the client needs to send its own request to all service nodes. Unreliable channels and network delays will cause each node to have inconsistent views on the client requests it receives, so the consensus protocol of the blockchain first requires the nodes within the cluster to determine the order of client requests, and then decide whether it can Perform a client request.
  • the traditional blockchain adopts the idea of electing a leader by electing the leader and letting the leader decide which client requests to execute.
  • the blockchain uses a single-linked list to store the executed client requests.
  • traditional blockchains use proof of work to elect leaders. The service node will try to find a set of client requests that meet the requirements according to the rules.
  • the consistency protocol based on the single-chain table storage form requires that the entire blockchain service network will only generate a set of client requests at a time, and the blockchain system requires each time
  • the collection needs to be verified using a one-way hash function, and only the collection that meets the requirements can be written to the database.
  • the one-way hash function is irreversible, service nodes can only use exhaustive methods to brute force to find the set that meets the requirements. The process of finding the set often takes a long time and requires a lot of computing power.
  • this application aims to provide a method for generating a fragmented block chain based on a tree structure.
  • a method for generating a fragmented block chain based on a tree structure includes:
  • the leader generates at least one block by packaging according to the state of its own local database, and broadcasts the at least one block to all members of its group;
  • Verify the consistency of the at least one block execute the block according to the verification result of the consistency, and synchronize the block to other packets.
  • the method for generating a fragmented blockchain based on a tree structure wherein the dividing the server system into at least one group, and selecting leaders of each group are specifically:
  • Leaders are selected based on the proof of work of members contained in each group, where the leader is the member with the smallest amount of proof of work.
  • the method for generating a sharded block chain based on a tree structure wherein the leader generates at least one block by package according to the state of its own local database, and broadcasts the at least one block to all members of its group.
  • the leader obtains its own local database status, and determines executable client requests and execution order according to the local database status;
  • Package at least one block according to the executable client request and the execution order, and multicast the at least one block to all members of the group in which it is located.
  • the method for generating a sharded block chain based on a tree structure, wherein the verification is consistent with the at least one block, and the block is executed according to a verification result of the consistency, and the block is Synchronizing to other groups includes:
  • the leader generates the block to generate a corresponding voting slip, and transmits the voting slip to all members included in its group in turn according to a preset ring topology in order to include each client in the block. Request a vote;
  • the leader will vote on the completed voting slip, and determine the block corresponding to each group according to the completed voting slip, and synchronize the blocks to other groups.
  • the method for generating a sharded block chain based on a tree structure, wherein the verification is consistent with the at least one block, and the block is executed according to a verification result of the consistency, and the block is After syncing to other groups also includes:
  • the leader of the next round of each group repeatedly opens the next round of blocks.
  • leader offset is determined according to the hash value
  • next round of each group is determined according to the leader and the leader offset respectively.
  • Leaders include:
  • the leader offset of each group is determined in a clockwise direction, and the leader of each group is offset according to the leader offset to obtain the next round of leaders.
  • the method for generating a fragmented blockchain based on a tree structure wherein the leader offset is determined according to the hash value, and the next round of each group is determined according to the leader and the leader offset respectively.
  • the leaders behind include:
  • the new member When receiving a request from a new member to join the server system, the new member queries all the groups included in the server system and the members included in each group;
  • the new member completes his own proof of work, determines its corresponding group according to the proof of work, and broadcasts the proof of work to all members included in the group;
  • Each member votes on the new member, and determines whether the new member joins the group according to the voting result.
  • the method for generating a sharded block chain based on a tree structure, wherein after each member votes on the new member and determining whether the new member joins the group according to the voting result includes:
  • each member included in each group completes its own proof of work and broadcasts the proof of work to other members of its group;
  • the leader of each group divides its group into at least one sub-group according to a preset condition according to the received proof of work to generate a new group of the server system.
  • the method for generating a fragmented blockchain based on a tree structure, wherein the leader of each group divides its group into at least one sub-group according to a preset condition according to the received workload certification to generate a new server-side system includes:
  • the grouping also includes:
  • the leader obtains the number of sub-groups obtained by the division of the group
  • the client requests included in the corresponding sub-packets are equally divided into the sub-packets according to the generation order of the sub-packets and the number of the sub-packets.
  • this application provides a method for generating a fragmented blockchain based on a tree structure.
  • the method includes: dividing a server system into at least one group, and selecting leaders of each group separately.
  • the leader generates at least one block by package according to the state of its own local database, and broadcasts the at least one block to all members of its group; verifies the consistency of the at least one block, and according to the The result of the consistency verification executes the block and synchronizes the block to other packets.
  • the method uses a tree-like grouping structure to improve the efficiency of the block chain framework when generating blocks, and generates blocks based on the state of the leader's own local database, which improves the waste of resources when the system generates blocks and reduces the time when blocks are generated. Incurred delay.
  • FIG. 1 is a flowchart of an embodiment of a method for generating a fragmented blockchain based on a tree structure according to the present application.
  • FIG. 2 is a flowchart of another embodiment of a method for generating a fragmented blockchain based on a tree structure according to the present application.
  • FIG. 1 is a flowchart of a method for generating a fragmented blockchain based on a tree structure provided by the present application. The method includes:
  • the server system is divided into at least one group, and a leader of each group is selected.
  • the server system includes multiple service nodes, that is, the server system includes multiple members.
  • the proportion of maliciously manipulated service nodes included in the server-side system at any time is less than a quarter.
  • the division of the server system into at least one group refers to dividing the server system into at least one group including a preset number of members according to a preset condition.
  • the dividing the server-side system into at least one group, and selecting the leaders of each group specifically are:
  • the preset condition is that the number of members included in each group is a preset number threshold, that is, the server system is divided into a plurality of groups each including a preset number of members. And, when there is a group less than a preset number of thresholds, all members included in the group are expelled from the server system, and will be rejoined to the server system as new members.
  • the packet refers to an original packet of the server system, that is, a root of a tree formed by the original packet.
  • the leader is the initial leader of each group, which is elected based on proof of work. After the grouping is completed, each group member completes the proof of workload, and elects an initial leader according to the workload proof of each group member, and determines the block corresponding to the group in which the initial leader is located.
  • the initial leader is a member with a minimum workload certification among all members included in the group in which the leader is located.
  • the leader generates at least one block by packaging according to the state of its own local database, and broadcasts the at least one block to all members of its group.
  • the state of the local database may include a client request stored locally and a request sequence of the client request.
  • the leader determines the executable client requests according to its own client requests and the request sequence of each client request, and all determined executable client requests form a block.
  • the leader only considers the status of its own local database, which can avoid the problem of divergence of the request sequence of client requests due to network delays of members.
  • the leader receives and stores client requests in the time stamp order.
  • the leader When the number of client requests stored by the leader reaches a preset threshold, the leader Iterates through all the client requests stored in it and selects the executable client requests, and generates a block based on all the executable client requests obtained by the selection.
  • the leader generates at least one block by package according to the state of its own local database, and broadcasts the at least one block to all members of its group, which specifically include:
  • the leader obtains its own local database status, and determines an executable client request and execution order according to the local database status.
  • S22 Pack and generate at least one block according to the executable client request and the execution order, and multicast the at least one block to all members of the group in which it is located.
  • the leader broadcasts the block to all members of its group.
  • the members included in the group may not be in the same network segment, so the leader uses P2P technology to perform multicast, that is, the leader multicasts the block to all members of the group in which he belongs.
  • the verification consistency means that each member verifies all client requests included in the block to determine whether each client request included in the block is an executable client request.
  • the leader generates a voting slip according to the block, and each member fills in the voting slip in turn to verify the consistency of the block. Accordingly, verifying the consistency of the at least one block, and executing the block according to the verification result of the consistency, and synchronizing the block to other groups specifically include:
  • the leader generates the block to generate a corresponding voting slip, and transmits the voting slip to all members included in its group in turn according to a preset ring topology, so as to include each block in the block.
  • the client requests a vote;
  • the leader will vote on the completed voting slip, and determine the block corresponding to each group according to the completed voting slip, and synchronize the block to other groups.
  • the leader generates a voting slip according to the block
  • the structure of the voting slip may be similar to a block structure, which includes a head and a body.
  • the header of the voting slip includes the group to which the voting slip belongs, the hash value of the block corresponding to the voting slip, and the number of blocks generated by the corresponding block of the voting slip for the group to which it belongs;
  • the body contains the opinions of each member node included in the group corresponding to the voting slip on whether the client request contained in the block is executable.
  • a fixed constant is not used to indicate consent or disagreement, but the hash value requested by the client is used to indicate consent. Disagree. In this way, each member can encrypt the hash value or the inverse code of the hash value by using the private key stored by itself, and write the encrypted information into the body of the voting slip.
  • the leader sends the voting list to the members behind it in the order of the preset ring topology.
  • the leader can determine the subsequent members in a clockwise direction, and can also determine the subsequent counterclockwise in the case.
  • Members, and the transmission order determined by the leader is the voting order of the voting slips, that is, the leader sends the voting slips to the subsequent members in the order of the ring topology, and the member completes the voting and then sends the voting slips in accordance with the ring.
  • the topological structure is sequentially sent to the subsequent members, and so on until the voting list is returned to the leader.
  • the ring topology is determined according to a sorting result of a proof of work (for example, from small to large) when the previous round of packet splitting, and when the packet is an initial packet, the ring topology is based on The workload at the time of the initial grouping generation proves that the ranking results are determined.
  • a sorting result of a proof of work for example, from small to large
  • the voting slip when the voting slip will be transmitted along the ring topology and returned to the leader, the voting slip contains all the member nodes included in the group corresponding to the voting slip for the ability to execute each client in the block.
  • the requested vote in which, when the leader generates the voting ticket, all the clients in the block request a yes vote, and each member will vote on each client request in each block according to its own local database status.
  • the leader After the leader receives the completed voting slip, the leader will broadcast the completed voting slip to all members included in the group. Each member will independently verify the correctness and legitimacy of the voting slip based on the public key information of the corresponding node recorded locally. .
  • the valid votes means that the consent of at least half of the members has been obtained.
  • the valid votes can be appropriately increased according to the actual situation.
  • the leaders of each group will multicast the blocks and corresponding voting slips generated by their own group in this round to the leaders of other groups. After waiting for a period of synchronization, all leaders will use P2P technology to multicast the results of their synchronized blocks and voting slips to other leaders. All leaders will compare the block synchronization results and fill in possible gaps. And correct the error message.
  • the synchronization time may be determined according to the application scenario of the server system and the member size of the server system, wherein when the group is established, the leader of each group uses the group member information contained in the group as a specific block. Broadcast to the entire server system to determine the membership of the server system. In practical applications, the synchronization time can be adjusted using a moving average method, and the leader of the group will adjust according to the time of the previous synchronization block.
  • the leader can use a bitmap to indicate whether he has received a block of a certain group, and then compare the received results according to the bitmap.
  • the leader broadcasts the synchronized blocks and voting tables to the members of his own group and allows other members within the group to synchronize information. After receiving the block and voting form, members will independently verify and selectively execute requests in the block according to the results of the voting form.
  • the consistency of the at least one block is verified, and the block is executed according to a verification result of the consistency, and the blocks are synchronized
  • groupings also include:
  • the Merkel tree is that all blocks generated by grouping are sorted by the traversal order of the group in the tree (such as pre-order traversal) and are constructed into a Merkle Hash Tree with a degree of 2, and When some packets cannot generate blocks normally in this round of workflow or complete block synchronization between packets normally due to abnormal conditions, other packets will fill these packets with a special empty space that does not contain any client requests. Block. Then, a modulo operation is performed on the hash value of the generated Merkel tree root to obtain the leader of each group in the next round of work.
  • determining the leader offset according to the hash value, and respectively determining the leader of the next round of each group according to the leader and the leader offset specifically includes:
  • the modulo operation is performed relative to the number of members of each group, that is, the result of the modulo operation is the order of the new leader in the next round of work from the leader in the current work in the ring topology. Offset in the clockwise direction.
  • the tree-like grouping structure is used to determine the order of the blocks generated by different groupings in each round, and the identity of the leader in each group will be determined according to the hash value of the sorting result in the next round to generate blocks to ensure the election of leaders. Unpredictable, thus ensuring randomness and fairness.
  • determining the leader offset according to the hash value, and determining the leader of the next round of each group according to the leader and the leader offset respectively further includes:
  • the new member When receiving a request for a new member to join the server system, the new member queries all the groups included in the server system and the members included in each group;
  • the new member completes his own proof of work, determines its corresponding group according to the proof of work, and broadcasts the proof of work to all members included in the group;
  • the new member sends a broadcast to the server system, and queries the server system information through the broadcast.
  • the information of the server system may include all the packets included in the server system and the members included in each packet. .
  • the difficulty factor of the workload proof that it needs to complete is queried through broadcasting, and the workload proof is completed.
  • the proof of work is to use the hash value contained in the root of the Merkel tree constructed by all the blocks generated by the system in the previous round as the seed, and use the one-way hash function of SHA256 as the encryption function.
  • the seed and its own ID are used as a basis to find a character string, so that the hash value of the data obtained by concatenating the seed, ID, and character string satisfies the difficulty coefficient (that is, the number of prefix zeros of the data hash value), And when the new member finds the string, the proof of work is completed.
  • the difficulty coefficient that is, the number of prefix zeros of the data hash value
  • a group to be joined by the new member is determined according to the proof of workload, and the workload certificate is sent to the group corresponding to the new member through broadcasting.
  • the leader of the group to be joined by the new member determines the order of the new member according to the sort order of the received proof of work, and will arrange the results of the proof of work he received in the chronological order he received and generate the area within the group
  • the block process is sent to other member nodes, and the result of the vote determines which new members can join the group.
  • the leader of the group When a group decides to add a new member to the candidate list for the next group split, the leader of the group will broadcast the new member to the leaders of other groups, and then the leader of the other groups will notify the members of the group New members to join the server system join the server system network and its corresponding order.
  • the upper limit of the number of new members that can be accepted by each group must not exceed a preset number.
  • a group that meets the split condition in the server system will generate up to 2 new sub-groups each time (of which, After the split, the original group disappears), the number of members that the group can hold is greater than twice the preset number threshold, and the upper limit of the number of members that the group can hold can be restricted according to the application scenario, for example, the number of members that the group can hold is less than Three times the preset number threshold.
  • each member included in each group completes its own workload certification, and broadcasts the workload certification to other members of its group;
  • the leader of each group divides its group into at least one sub-group according to a preset condition according to the received workload certification to generate a new group of the server system.
  • the preset time threshold is preset and used to determine whether the server system meets the separation requirement. That is, when the current grouping time of the server system reaches a preset time threshold, it means that the server system meets the separation time requirement.
  • setting the separation condition includes that the number of members of a group reaches a preset number threshold and the separation interval between the server system and the last group split reaches a preset time threshold.
  • the server system When a designated block is generated in the server system to control the server system to enter the split state of the packet, the server system will stop the next block generation process and introduce a proof of work method to split the existing group in the system. And restructuring.
  • the hash function seed of the workload proof during packet splitting is derived from the value of the root of the Merkel tree formed by the result obtained when the system generated a block in the previous round.
  • the members of the split group After completing the proof of work, the members of the split group will broadcast the results of their own proof of work to all members in their group. When the members receive the results of the proof of work of other members, they will sort the results and the leader will receive the results.
  • the members After reaching the standard number of workload proofs that can form a group, the members are divided into a new group and the information of the group is packaged into a block. The other nodes are notified according to the generation of ordinary blocks. After receiving the block containing the new grouping information, each member independently checks the correctness of the data and then updates its own local grouping information.
  • the leader of each group divides its group into at least one sub-group according to the preset conditions according to the received workload proof, to generate a new group of the server system specifically includes:
  • the preset condition is that the number of members is a preset number. That is, after the subgroups are split, the number of members in each subgroup is verified in order, that is, the number of members in each subgroup is obtained separately, and the number of members is compared with the preset number to determine that all the presets are not met Conditional first subgroup, remove all first subgroups that do not meet the preset condition, expel all members of the first subgroup that do not meet the preset condition from the server system, and rejoin the server as new members
  • the system can ensure that the number of initial members of each sub-group obtained by the split is equal to a preset number.
  • each sub-group obtained by the split selects the initial leader through the proof of work method, and the next round of leaders is randomly determined by the offset method in the block generation process.
  • the client request corresponding to the packet needs to be divided according to the number of sub-packets obtained by the split.
  • the leader of each group divides its group into at least one sub-group according to preset conditions according to the received proof of work, and after generating a new group of the server system, it further includes:
  • the leader obtains the number of sub-groups obtained by the division of the group
  • the client requests included in the corresponding sub-packets are equally divided into the sub-packets according to the generation order of the sub-packets and the number of the sub-packets.
  • the new packet will inherit all the mapping rules of the original packet processing client request. If the packet is split into multiple sub-packets, the sub-packets evenly divide the mapping relationship of the original packets according to the order and quantity at the time of generation. The mapping relationship of the new subgroup must be a non-empty subset of the mapping relationship of the original group and the mapping relationships between different subgroups do not intersect each other. After the system completes the packet split, the client cannot know the change of the mapping relationship at the first time, so the client will still send its own request according to the expired local mapping cache.
  • a member of the original packet receives a request from a client, if the original packet generates at least one sub-packet, there must be a sub-packet that can respond to the request.
  • the original group member will inform the client of the changes in the original group mapping.
  • This method does not require the client to update the local cache at the first time.
  • the client does not need to immediately update the mapping relationship changes of the entire service network, but only updates the changes involved in its current request. This mode can avoid the broadcast storm that may be caused by the traditional blockchain that uses the grouping idea due to the simple grouping and the client broadcasts the request to the entire service network.

Abstract

本申请公开了一种基于树状结构的分片区块链生成方法,所述方法包括:将服务端系统划分为至少一个分组,并分别选取各分组的领导者;所述领导者根据自身本地数据库状态打包生成至少一区块,并将所述至少一区块广播至其所在分组的所有成员;验证所述至少一区块的一致性,并根据所述一致性的验证结果执行所述区块,并将所述区块同步至其他分组。本方法通过树状分组架构提高区块链框架生成区块时的效率,并且根据领导者自身本地数据库状态生成区块,改善了系统生成区块时的资源浪费现象并减小了生成区块时产生的时延。

Description

一种基于树状结构的分片区块链生成方法 技术领域
本申请涉及区块链技术领域,特别涉及一种基于树状结构的分片区块链生成方法。
背景技术
区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链的最大特点是无需中心化的服务节点。借助区块链技术可以降低维护高性能中心化设备的人力物力。去中心化意味着在分布式服务集群中没有中心化的配置管理节点负责确定网络中消息的顺序。但是,去中心化结构由于缺失配置管理中心使得分布式服务集群中的成员节点可能会因为网络通信信道的不可靠性导致节点之间的状态不一致,因此区块链引入了一致性协议(共识算法)用于处理去中心化的分布式集群的一致性问题。
传统的共识算法包括2PC,3PC,paxo和基于paxos算法衍生出的一系列算法。共识算法被用于保证分布式系统的一致性。但是传统的共识算法往往需要集群中产生一个领导者节点用于减小用户发往集群的消息量并确定消息的顺序。但由于区块链系统没有中心节点,所以客户端需要将自己的请求发送给所有的服务节点。而不可靠信道和网络延时会使得各个节点对收到的客户端请求的视角不一致,所以区块链的一致性协议首先需要让集群内部的节点确定客户端请求的顺序,然后再决定是否能够执行客户端请求。
传统的区块链是采用了选举领导者的思想,通过选举领导者并让领导者决定执行哪些客户端的请求。此外,为了保证系统的一致性和可验证性,区块链采用了单链表的形式存储已经执行的客户端请求。此外,为了避免系统中的领导者带来过多的中心化,传统区块链采用了工作量证明(proof of work)的方式选举领导者。服务节点会根据规则尝试着找到一个满足要求的客户端请求的集合。同时,为了保证区块链网络中节点的一致性,基于单链表存储形式的一致性协议要求整个区块链服务网络每次只会产生一个客户端请求的集合,并且区块链系统要求每次生成客户端请求的集合时需要利用单向散列函数对该集合进行验证,只有符合要求的集合才能被写入数据库。而由于单向散列函数具有不可逆性,所以服务节点只能利用穷举的方式去暴力寻找符合要求的集合,找寻集合的过程往往耗时很 长且需要消耗大量的计算力。
申请内容
鉴于现有技术的不足,本申请旨在提供一种基于树状结构的分片区块链生成方法。
本申请所采用的技术方案如下:
一种基于树状结构的分片区块链生成方法,其包括:
将服务端系统划分为至少一个分组,并分别选取各分组的领导者;
所述领导者根据自身本地数据库状态打包生成至少一区块,并将所述至少一区块广播至其所在分组的所有成员;
验证所述至少一区块的一致性,并根据所述一致性的验证结果执行所述区块,并将所述区块同步至其他分组。
所述基于树状结构的分片区块链生成方法,其中,所述将服务端系统划分为至少一个分组,并分别选取各分组的领导者具体为:
根据预设条件将所述服务端系统划分为至少一个分组,其中,各分组的成员数量均为预设数量阈值;
根据各分组包含的成员的工作量证明选取领导者,其中,所述领导者为具有最小工作证明量的成员。
所述基于树状结构的分片区块链生成方法,其中,所述领导者根据自身本地数据库状态打包生成至少一区块,并将所述至少一区块广播至其所在分组的所有成员具体包括:
所述领导者获取自身的本地数据库状态,并根据所述本地数据库状态确定可执行的客户端请求以及执行顺序;
根据可执行的客户端请求以及执行顺序打包生成至少一区块,并将所述至少一区块组播至其所在分组的所有成员。
所述基于树状结构的分片区块链生成方法,其中,所述验证所述至少一区块的一致性,并根据所述一致性的验证结果执行所述区块,并将所述区块同步至其他分组具体包括:
所述领导者生成所述区块产生对应的投票单,并将所述投票单按照预设的环状拓扑结构依次传送至其所在分组包含的所有成员,以对所述区块包含各客户端 请求进行投票;
领导者将投票完成的投票单,并根据所述投票完成的投票单确定各分组对应的区块,并将所述区块同步至其他分组。
所述基于树状结构的分片区块链生成方法,其中,所述验证所述至少一区块的一致性,并根据所述一致性的验证结果执行所述区块,并将所述区块同步至其他分组之后还包括:
根据各分组对应的区块构建默克尔树,并计算所述默克尔树的树根的哈希值;根据所述哈希值确定领导者偏移量,并根据所述领导者以及领导者偏移量分别确定各分组下一轮的领导者;
各分组下一轮的领导者重复开启下一轮的区块。
所述基于树状结构的分片区块链生成方法,其中,所述根据所述哈希值确定领导者偏移量,并根据所述领导者以及领导者偏移量分别确定各分组下一轮的领导者具体包括:
根据各分组包含的成员数量对所述哈希值进行取模运行,以得到各分组对应的领导者与下一轮领导者之间的距离;
根据各距离按照顺时针方向确定各分组的领导者偏移量,并各分组领导者按照所述领导者偏移量进行偏移,以得到下一轮的领导者。
所述基于树状结构的分片区块链生成方法,其中,所述根据所述哈希值确定领导者偏移量,并根据所述领导者以及领导者偏移量分别确定各分组下一轮的领导者之后还包括:
当接到新成员加入服务端系统的请求时,新成员查询所述服务端系统包含的所有分组以及各分组包含的成员;
新成员完成自身的工作量证明,根据所述工作量证明确定其对应的分组,并将所述工作量证明广播至所述分组包含的所有成员;
各成员对所述新成员进行表决,根据所述表决结果确定新成员是否加入所述分组。
所述基于树状结构的分片区块链生成方法,其中,所述各成员对所述新成员进行表决,根据所述表决结果确定新成员是否加入所述分组之后包括:
当监听到存在分组的成员数量达到预设数量时,判断服务端系统的分裂间隔 时间是否达到预设时间阈值;
当达到预设时间阈值时,各分组包含的各成员完成其自身的工作量证明,并将工作量证明广播至其所在分组的其他成员;
各分组的领导者根据接收到工作量证明按照预设条件将其所在分组划分为至少一个子分组,以生成服务端系统新的分组。
所述基于树状结构的分片区块链生成方法,其中,所述各分组的领导者根据接收到工作量证明按照预设条件将其所在分组划分为至少一个子分组,以生成服务端系统新的分组具体包括:
分别获取各子分组包含的成员数量,并根据所述成员数量确定各子分组是否满足预设条件的第一子分组;
将所有未满足预设条件的第一子分组去除,以生成服务端系统新的分组。
所述基于树状结构的分片区块链生成方法,其中,所述各分组的领导者根据接收到工作量证明按照预设条件将其所在分组划分为至少一个子分组,以生成服务端系统新的分组之后还包括:
领导者获取其所在分组划分得到的子分组的数量;
当所述子分组的数量为1时,将所述子分组对应分组包含的客户端请求同步至所述子分组;
当所述子分组的数量为大于1时,将所述子分组对应分组包含的客户端请求按照子分组生成顺序以及子分组的数量均分至各子分组。
有益效果:与现有技术相比,本申请提供了一种基于树状结构的分片区块链生成方法,所述方法包括:将服务端系统划分为至少一个分组,并分别选取各分组的领导者;所述领导者根据自身本地数据库状态打包生成至少一区块,并将所述至少一区块广播至其所在分组的所有成员;验证所述至少一区块的一致性,并根据所述一致性的验证结果执行所述区块,并将所述区块同步至其他分组。本方法通过树状分组架构提高区块链框架生成区块时的效率,并且根据领导者自身本地数据库状态生成区块,改善了系统生成区块时的资源浪费现象并减小了生成区块时产生的时延。
附图说明
图1为本申请提供的基于树状结构的分片区块链生成方法的一个实施例的 流程图。
图2为本申请提供的基于树状结构的分片区块链生成方法的另一个实施例的流程图。
具体实施方式
本申请提供一种基于树状结构的分片区块链生成方法,为使本申请的目的、技术方案及效果更加清楚、明确,以下参照附图并举实施例对本申请进一步详细说明。应当理解,此处所描述的具体实施例仅用以解释本申请,并不用于限定本申请。
本技术领域技术人员可以理解,除非特意声明,这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是,本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件,但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解,当我们称元件被“连接”或“耦接”到另一元件时,它可以直接连接或耦接到其他元件,或者也可以存在中间元件。此外,这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。
本技术领域技术人员可以理解,除非另外定义,这里使用的所有术语(包括技术术语和科学术语),具有与本申请所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是,诸如通用字典中定义的那些术语,应该被理解为具有与现有技术的上下文中的意义一致的意义,并且除非像这里一样被特定定义,否则不会用理想化或过于正式的含义来解释。
下面结合附图,通过对实施例的描述,对申请内容作进一步说明。
请参照图1,图1为本申请提供的基于树状结构的分片区块链生成方法的流程图。所述方法包括:
S10、将服务端系统划分为至少一个分组,并分别选取各分组的领导者。
具体地,所述服务端系统包括多个服务节点,即服务端系统包括多个成员。并且,所述服务端系统在任意时刻其包括的被恶意操纵的服务节点的比重小于四分之一。所述服务端系统划分为至少一个分组指的是根据预设条件将所述服务端系统划分包至少一个包含有预设数量的成员的分组。相应的,所述将服务端系统 划分为至少一个分组,并分别选取各分组的领导者具体为:
S11、根据预设条件将所述服务端系统划分为至少一个分组,其中,各分组的成员数量均为预设数量阈值;
S12、根据各分组包含的成员的工作量证明选取领导者,其中,所述领导者为具有最小工作证明量的成员。
具体地,所述预设条件为各分组包含的成员数量为预设数量阈值,也就是说,将所述服务端系统划若干各包含有预设数量阈值成员的分组。并且,当存在少于预设数量阈值的分组时,将该分组包含的所有成员逐出所述服务端系统,并且将作为新成员重新加入所述服务端系统。此外,所述分组指的是所述服务端系统的原始分组,即原始分组构成的树的树根。
此外,所述领导者为各分组的初始领导者,其是根据工作量证明选举得到的。在分组完成后,各分组成员完成工作量证明,并根据各分组成员的工作量证明选举初始领导者,通过所述初始领导者确定其所处分组对应的区块。在本实施例中,所述初始领导者是其所处分组包含的所有成员中具有最小工作量证明的成员。
S20、所述领导者根据自身本地数据库状态打包生成至少一区块,并将所述至少一区块广播至其所在分组的所有成员。
具体地,所述本地数据库状态可以包括本地存储的客户端请求以及客户端请求的请求顺序。所述领导者根据其自身存在的客户端请求以及各客户端请求的请求顺序确定可执行的客户端请求,确定的所有可执行的客户端请求构形成区块。在本实施例中,所述领导者仅考虑其自身本地数据库状态,这样可以避免各成员因网络延时而产生的客户端请求的请求顺序的分歧的问题。此外,所述领导者根据自身本地数据库状态打包生成至少一区块之前,领导者接收并按时间戳顺序存储客户端请求,当领导者存储的客户端请求的数量达到预设阈值时,领导者遍历其存储的所有客户端请求挑选可执行客户端请求,并根据挑选得到的所有可执行客户端请求生成区块。相应的,所述领导者根据自身本地数据库状态打包生成至少一区块,并将所述至少一区块广播至其所在分组的所有成员具体包括:
S21、所述领导者获取自身的本地数据库状态,并根据所述本地数据库状态确定可执行的客户端请求以及执行顺序;
S22、根据可执行的客户端请求以及执行顺序打包生成至少一区块,并将所 述至少一区块组播至其所在分组的所有成员。
具体地,所述领导者将所述区块广播给其所在分组的所有成员。所述分组包含的成员可能不在同一网段中,从而所述领导者采用P2P的技术进行组播,即领导者将所述区块组播给其所在分组的所有成员。
S30、验证所述至少一区块的一致性,并根据所述一致性的验证结果执行所述区块,并将所述区块同步至其他分组。
具体地,所述验证一致性指的是各成员对所述区块包括的所有客户端请求的进行验证,以确定所述区块包括的各客户端请求是否为可执行客户端请求。所述领导者根据所述区块生成一投票单,通过各成员依次填写所述投票单来对所述区块的一致性进行验证。相应的,所述验证所述至少一区块的一致性,并根据所述一致性的验证结果执行所述区块,并将所述区块同步至其他分组具体包括:
S31、所述领导者生成所述区块产生对应的投票单,并将所述投票单按照预设的环状拓扑结构依次传送至其所在分组包含的所有成员,以对所述区块包含各客户端请求进行投票;
S32、领导者将投票完成的投票单,并根据所述投票完成的投票单确定各分组对应的区块,并将所述区块同步至其他分组。
具体地,所述领导者根据所述区块生成一投票单,所述投票单的结构可以类似于区块结构,其包括头部和主体。其中,所述投票单的头部包含了投票单所属的分组、投票单对应的区块的哈希值和投票单对应区块为其所属分组产生的第几个区块;所述投票单的主体包含投票单对应的分组包含的各成员节点对该区块所包含的客户端请求是否可执行的意见。此外,为了保证恶意节点无法仿造其他成员节点的意见,这里不采用某个固定的常量表示同意或者不同意,而采用客户端请求的哈希值表示同意,客户端请求的哈希值的反码表示不同意。这样各成员可以采用其自身存储的私钥对哈希值或者哈希值的反码进行加密,并将加密后的信息写入投票单的主体。
此外,所述领导者将所述投票单按照预设环状拓扑结构顺序发送至位于其后的成员,领导者可以按照顺时针方向确定其后的成员,也可以案子逆时针方向确定其后的成员,并且所述领导者确定的传递顺序为所述投票单的投票顺序,即领导者按照环状拓扑结构顺序将投票单发送至其后的成员,该成员完成投票后再将 投票单按照环状拓扑结构顺序发送至其后的成员,依次类推直至所述投票单返回领导者。其中,所述环状拓扑结构是根据上一轮分组分裂时的工作量证明(如,从小到大)的排序结果确定,并且当所述分组为初始分组时,所述环状拓扑结构是根据初始分组生成时的工作量证明排序结果确定。
进一步,当投票单将会沿着环状拓扑结构传输下并传回至领导者时,投票单中包含了该投票单对应的分组包含的所有成员节点对于能否执行区块中的各客户端请求的投票,其中,所以领导者生成所述投票单时会对区块中的所有客户端请求投赞成票,各成员会根据其自身本地数据库状态对各区块中的各客户端请求进行投票。领导者在接收到完成投票的投票单后会将完成投票的投票单广播给分组包含的所有成员,各成员会根据本地记录的对应节点的公钥信息独立校验投票单的正确性和合法性。如果利用公钥解密后得到的结果是对应区块的客户端请求的哈希值或者是哈希值的反码,确定投票单的投票为有效且正确的;并执行区块中获得有效票数的客户端请求。在本实施例中,所述有效票数指的是至少获得超过半数成员的同意,当然所述有效票数可以根据实际情况适当调高。
此外,各分组的领导者将会向其他分组的领导者组播本轮中自己所在分组生成的区块和对应的投票单。在等待一段同步时间后,所有领导者将会利用P2P技术向其他领导者组播自己收到的同步区块和投票单的结果,所有的领导者将比对区块同步结果并填补可能的缺失和纠正错误信息。所述同步时间可以根据服务端系统的应用场景和服务端系统的成员规模而确定,其中,所述在分组成立时,各分组的领导者将其所在分组包含的分组成员信息的作为特定区块广播到整个服务端系统中,以使得确定服务端系统的成员规模。在实际应用中,所述同步时间可以采用移动平均法调整,分组的领导者会根据之前同步区块的时间进行调整。
进一步,领导者可以采用位图的方式表示自己是否收到某个分组的区块,然后根据位图对收到的结果进行对比。同时,领导者将自己同步的区块和投票表广播给自己所在分组的成员让分组内部的其他成员同步信息。成员在收到区块和投票表后会独立验证并按照投票表的结果选择性地执行区块中的请求。
在申请的另一个实施例中,如图2所示,所述验证所述至少一区块的一致性,并根据所述一致性的验证结果执行所述区块,并将所述区块同步至其他分组之后还包括:
S40、根据各分组对应的区块构建默克尔树,并计算所述默克尔树的树根的哈希值;
S50、根据所述哈希值确定领导者偏移量,并根据所述领导者以及领导者偏移量分别确定各分组下一轮的领导者;
S60、各分组下一轮的领导者重复开启下一轮的区块。
具体地,所述默克尔树是所有分组产生的区块以分组在树中的遍历顺序(如先序遍历)排序并构建成为一棵度为2的默克尔树Merkle Hash Tree,并且。当某些分组因为异常情况而无法在该轮工作流程中正常生成区块或者正常完成分组间区块的同步时,则其他分组将会对这些分组填充一个不包含任何客户端请求的特殊的空区块。再通过对生成的默克尔树的树根的哈希值进行取模运算,以得到每个分组下一轮工作时的领导者。相应的,所述根据所述哈希值确定领导者偏移量,并根据所述领导者以及领导者偏移量分别确定各分组下一轮的领导者具体包括:
S51、根据各分组包含的成员数量对所述哈希值进行取模运行,以得到各分组对应的领导者与下一轮领导者之间的距离;
S52、根据各距离按照顺时针方向确定各分组的领导者偏移量,并各分组领导者按照所述领导者偏移量进行偏移,以得到下一轮的领导者。
具体地,所述取模运算是相对于各分组的成员数量进行,即所述取模运算的结果为下一轮工作中新的领导者距离当前工作中领导者在环阵拓扑结构中的顺时针方向的偏移量。这样利用树状的分组结构确定每一轮中不同分组生成的区块的顺序并根据排序结果的哈希值决定下一轮生成区块时每个分组中的领导者的身份,保证选举领导者的不可预测的,从而确保了随机性和公平性。
在申请的再一个实施例中,所述根据所述哈希值确定领导者偏移量,并根据所述领导者以及领导者偏移量分别确定各分组下一轮的领导者之后还包括:
S70、当接到新成员加入服务端系统的请求时,新成员查询所述服务端系统包含的所有分组以及各分组包含的成员;
S80、新成员完成自身的工作量证明,根据所述工作量证明确定其对应的分组,并将所述工作量证明广播至所述分组包含的所有成员;
S90、各成员对所述新成员进行表决,根据所述表决结果确定新成员是否加 入所述分组。
具体地,所述新成员通过向服务端系统发送广播,通过该广播查询所述服务端系统信息,其中,所述服务端系统的信息可以包括服务端系统包含的所有分组以及各分组包含的成员。在获取到服务端系统的信息后通过广播查询其需要完成的工作量证明的难度系数,并完成所述工作量证明。所述工作量证明是将上一轮系统产生的所有区块构建成的默克尔树的树根中包含的哈希值作为种子,采用SHA256的单向散列函数作为加密函数,新成员以种子和其自身的ID作为基础,查找到一个字符串,以使得所述种子、ID和字符串拼接得到的数据的哈希值满足难度系数(即数据哈希值的前缀零的个数),并且当新成员查找到该字符串即完成了工作量证明。
进一步,在新成员完成工作量证明后,根据所述工作量证明确定新成员待加入的分组,并且通过广播向新成员对应的分组包含成员发送工作量证明。新成员待加入的分组的领导者根据接收到的工作量证明的排序顺序确定新成员的顺序,并会将自己收到的工作量证明结果以自己收到的时间顺序排列并以分组内部生成区块的流程发送给其他成员节点,表决后的结果确定哪些新成员可以加入分组。当分组决定将一个新成员纳入下一轮分组分裂的候选名单时,该分组的领导者将会将所述新成员广播给其他分组的leader,然后由其他分组的leader广播通知其所在分组的成员待加入服务端系统的新成员加入了服务端系统网络以及其对应的顺序。
此外,为了防止女巫攻击,限定各分组能够接受的新成员的上限不得超过预设数量,例如,服务端系统中达到分裂条件的分组每次分裂时会产生至多2个新的子分组(其中,分裂后原分组消失),则分组可以容纳的成员数量大于预设数量阈值的两倍,并且所述分组可以容纳的成员数量的上限可以根据应用场景进行约束,例如,分组可以容纳的成员数量小于预设数量阈值的三倍。
在申请的又一个实施例中,所述各成员对所述新成员进行表决,根据所述表决结果确定新成员是否加入所述分组之后包括:
S100、当监听到存在分组的成员数量达到预设数量时,判断服务端系统的分裂间隔时间是否达到预设时间阈值;
S110、当达到预设时间阈值时,各分组包含的各成员完成其自身的工作量证 明,并将工作量证明广播至其所在分组的其他成员;
S120、各分组的领导者根据接收到工作量证明按照预设条件将其所在分组划分为至少一个子分组,以生成服务端系统新的分组。
具体地,所述预设时间阈值为预先设定,用于确定服务端系统是否达到分离要求。也就是说,当服务端系统当前分组所处时长达到预设时间阈值时,说明服务端系统达到分离时间要求。在本实施例中,设定分离条件包括分组的成员数量达到预设数量阈值且服务端系统距离上次分组分裂的分离间隔时间达到预设时间阈值。当服务端系统中至少存在一个分组达到分离条件时,达到分裂条件的分组将会生成一个指定区块,通过指定区块请求服务端系统进入分裂状态。当服务端系统中产生用于控制服务端系统进入分组分裂状态的指定区块时,服务端系统将停止下一轮生成区块的流程并引入工作量证明的方式对系统中现存的分组进行分裂和重组。所述分组分裂时工作量证明的哈希函数种子来源于系统上一轮生成区块时得到的结果所构成的默克尔树的树根的值。分裂分组的成员在完成工作量证明后将在其自身的工作量证明的结果广播给其所在分组中所有的成员,当成员收到其他成员的工作量证明结果后将结果进行排序,领导者收到了能够组成分组的标准数量的工作量证明后将这些成员划分到一个新的分组中并将分组的信息打包成一个区块按照生成普通区块的通知给其他节点。收到包含了新的分组信息的区块后,各个成员独立校验数据的正确性然后更新其自身的本地分组信息。
进一步,在分组分裂完成后,需要严重分裂得到的各子分组的成员数量,以保证各子分组的成员数量均为预设数量。相应的,示例性的,所述各分组的领导者根据接收到工作量证明按照预设条件将其所在分组划分为至少一个子分组,以生成服务端系统新的分组具体包括:
分别获取各子分组包含的成员数量,并根据所述成员数量确定各子分组是否满足预设条件的第一子分组;
将所有未满足预设条件的第一子分组去除,以生成服务端系统新的分组。
具体地,所述预设条件为成员数量为预设数量。也就是说,在分裂得到子分组后,依次验证各子分组的成员数量,即分别获取各子分组的成员数量,并将各成员数量分别与预设数量进行比较,以确定所有不满足预设条件的第一子分组,并将不满足预设条件的所有第一子分组去除,将不满足预设条件的第一子分组的 所有成员逐出服务端系统,并作为新成员重新加入服务端系统,这样可以保证分裂得到的各子分组的初始成员数量均与为预设数量。此外,在分裂分组完成后,分裂得到的各子分组通过工作量证明的方式选取初始领导者,并且区块生成过程中采用偏移量的方式随机确定下一轮领导者。
进一步,在分裂分组完成后,需要根据分裂得到的子分组数量划分分组对应的客户端请求。相应的,所述各分组的领导者根据接收到工作量证明按照预设条件将其所在分组划分为至少一个子分组,以生成服务端系统新的分组之后还包括:
领导者获取其所在分组划分得到的子分组的数量;
当所述子分组的数量为1时,将所述子分组对应分组包含的客户端请求同步至所述子分组;
当所述子分组的数量为大于1时,将所述子分组对应分组包含的客户端请求按照子分组生成顺序以及子分组的数量均分至各子分组。
具体地,若分组在分裂期间只产生了一个新的分组,则这个新的分组将会继承原分组处理客户端请求的所有的映射规则。若分组分裂成了多个子分组,则子分组依据产生时的顺序和数量均分原分组的映射关系。新的子分组的映射关系必然是原分组映射关系的一个非空子集且不同子分组之间的映射关系互不相交。当系统完成分组分裂后,客户端并不能第一时间知道映射关系的变化,所以客户端还是会按照过期的本地映射缓存发送自己的请求。当原分组的成员收到来自客户端的请求时,若原分组至少产生了一个子分组,则必然有一个子分组可以响应该请求。原分组成员此时会告知客户端原分组映射关系所发生的变动。这种方式不需要客户端第一时间更新本地缓存,同时客户端无需立即更新整个服务网络的映射关系变动,而是只更新自己当前请求涉及到的变动。这种模式可以避免传统的采用分组思想的区块链因朴素分组而导致客户端向整个服务网络广播请求而可能导致的广播风暴。
最后应说明的是:以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本 申请各实施例技术方案的精神和范围。

Claims (10)

  1. 一种基于树状结构的分片区块链生成方法,其特征在于,其包括:
    将服务端系统划分为至少一个分组,并分别选取各分组的领导者;
    所述领导者根据自身本地数据库状态打包生成至少一区块,并将所述至少一区块广播至其所在分组的所有成员;
    验证所述至少一区块的一致性,并根据所述一致性的验证结果执行所述区块,并将所述区块同步至其他分组。
  2. 根据权利要求1所述基于树状结构的分片区块链生成方法,其特征在于,所述将服务端系统划分为至少一个分组,并分别选取各分组的领导者具体为:
    根据预设条件将所述服务端系统划分为至少一个分组,其中,各分组的成员数量均为预设数量阈值;
    根据各分组包含的成员的工作量证明选取领导者,其中,所述领导者为具有最小工作证明量的成员。
  3. 根据权利要求1所述基于树状结构的分片区块链生成方法,其特征在于,所述领导者根据自身本地数据库状态打包生成至少一区块,并将所述至少一区块广播至其所在分组的所有成员具体包括:
    所述领导者获取自身的本地数据库状态,并根据所述本地数据库状态确定可执行的客户端请求以及执行顺序;
    根据可执行的客户端请求以及执行顺序打包生成至少一区块,并将所述至少一区块组播至其所在分组的所有成员。
  4. 根据权利要求1所述基于树状结构的分片区块链生成方法,其特征在于,所述验证所述至少一区块的一致性,并根据所述一致性的验证结果执行所述区块,并将所述区块同步至其他分组具体包括:
    所述领导者生成所述区块产生对应的投票单,并将所述投票单按照预设的环状拓扑结构依次传送至其所在分组包含的所有成员,以对所述区块包含各客户端请求进行投票;
    领导者将投票完成的投票单,并根据所述投票完成的投票单确定各分组对应的区块,并将所述区块同步至其他分组。
  5. 根据权利要求1-4任一所述基于树状结构的分片区块链生成方法,其特征在于,所述验证所述至少一区块的一致性,并根据所述一致性的验证结果执行所 述区块,并将所述区块同步至其他分组之后还包括:
    根据各分组对应的区块构建默克尔树,并计算所述默克尔树的树根的哈希值;
    根据所述哈希值确定领导者偏移量,并根据所述领导者以及领导者偏移量分别确定各分组下一轮的领导者;
    各分组下一轮的领导者重复开启下一轮的区块。
  6. 根据权利要求5所述基于树状结构的分片区块链生成方法,其特征在于,所述根据所述哈希值确定领导者偏移量,并根据所述领导者以及领导者偏移量分别确定各分组下一轮的领导者具体包括:
    根据各分组包含的成员数量对所述哈希值进行取模运行,以得到各分组对应的领导者与下一轮领导者之间的距离;
    根据各距离按照顺时针方向确定各分组的领导者偏移量,并各分组领导者按照所述领导者偏移量进行偏移,以得到下一轮的领导者。
  7. 根据权利要求5所述基于树状结构的分片区块链生成方法,其特征在于,所述根据所述哈希值确定领导者偏移量,并根据所述领导者以及领导者偏移量分别确定各分组下一轮的领导者之后还包括:
    当接到新成员加入服务端系统的请求时,新成员查询所述服务端系统包含的所有分组以及各分组包含的成员;
    新成员完成自身的工作量证明,根据所述工作量证明确定其对应的分组,并将所述工作量证明广播至所述分组包含的所有成员;
    各成员对所述新成员进行表决,根据所述表决结果确定新成员是否加入所述分组。
  8. 根据权利要求7所述基于树状结构的分片区块链生成方法,其特征在于,所述各成员对所述新成员进行表决,根据所述表决结果确定新成员是否加入所述分组之后包括:
    当监听到存在分组的成员数量达到预设数量时,判断服务端系统的分裂间隔时间是否达到预设时间阈值;
    当达到预设时间阈值时,各分组包含的各成员完成其自身的工作量证明,并将工作量证明广播至其所在分组的其他成员;
    各分组的领导者根据接收到工作量证明按照预设条件将其所在分组划分为 至少一个子分组,以生成服务端系统新的分组。
  9. 根据权利要求8所述基于树状结构的分片区块链生成方法,其特征在于,所述各分组的领导者根据接收到工作量证明按照预设条件将其所在分组划分为至少一个子分组,以生成服务端系统新的分组具体包括:
    分别获取各子分组包含的成员数量,并根据所述成员数量确定各子分组是否满足预设条件的第一子分组;
    将所有未满足预设条件的第一子分组去除,以生成服务端系统新的分组。
  10. 根据权利要求8所述基于树状结构的分片区块链生成方法,其特征在于,所述各分组的领导者根据接收到工作量证明按照预设条件将其所在分组划分为至少一个子分组,以生成服务端系统新的分组之后还包括:
    领导者获取其所在分组划分得到的子分组的数量;
    当所述子分组的数量为1时,将所述子分组对应分组包含的客户端请求同步至所述子分组;
    当所述子分组的数量为大于1时,将所述子分组对应分组包含的客户端请求按照子分组生成顺序以及子分组的数量均分至各子分组。
PCT/CN2018/096932 2018-06-20 2018-07-25 一种基于树状结构的分片区块链生成方法 WO2019242059A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/972,988 US11375010B2 (en) 2018-06-20 2018-07-25 Sharding block chain generation method based on tree structure

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810635232.2A CN108847925B (zh) 2018-06-20 2018-06-20 一种基于树状结构的分片区块链生成方法
CN201810635232.2 2018-06-20

Publications (1)

Publication Number Publication Date
WO2019242059A1 true WO2019242059A1 (zh) 2019-12-26

Family

ID=64203058

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/096932 WO2019242059A1 (zh) 2018-06-20 2018-07-25 一种基于树状结构的分片区块链生成方法

Country Status (3)

Country Link
US (1) US11375010B2 (zh)
CN (1) CN108847925B (zh)
WO (1) WO2019242059A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113268382A (zh) * 2021-04-19 2021-08-17 支付宝(杭州)信息技术有限公司 在区块链系统中切换分片节点的方法及装置
CN115617918A (zh) * 2022-12-19 2023-01-17 深圳百纳维科技有限公司 分片式智能合约运行方法、装置、系统和储存介质

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109167660B (zh) * 2018-09-07 2021-05-14 腾讯科技(深圳)有限公司 选举代表节点设备方法、装置、计算机设备及存储介质
CN109756558A (zh) * 2018-12-04 2019-05-14 广州通链计算机智能技术有限责任公司 一种基于异步分组交换的拜占庭容错共识算法
CN109818837B (zh) * 2018-12-13 2022-04-12 深圳壹账通智能科技有限公司 智能家居控制方法、装置、计算机设备及存储介质
CN109788042A (zh) * 2018-12-28 2019-05-21 贵州蓝石科技有限公司 一种基于分组的区块链网络节点通信方法
CN110753026B (zh) * 2019-02-27 2020-10-30 北京嘀嘀无限科技发展有限公司 一种基于区块链的分片方法及装置
CN110113148B (zh) * 2019-04-28 2020-06-23 武汉理工大学 一种基于区块链的软件定义机会网络节点身份验证方法
EP3970343A4 (en) * 2019-05-15 2022-12-28 Nokia Technologies OY SCHEME FOR CREATING MULTIPLE PARALLEL BLOCKS FOR BLOCKCHAIN
CN110166565A (zh) * 2019-05-30 2019-08-23 中国联合网络通信集团有限公司 区块链分域触发方法及系统
CN110808838B (zh) * 2019-10-24 2020-09-22 华东师范大学 一种面向联盟链的分片方法
CN111083052B (zh) * 2019-12-19 2022-01-28 度小满科技(北京)有限公司 一种基于有序平衡二叉树的分片方法及装置
CN111428275B (zh) * 2020-03-13 2021-03-26 华东师范大学 一种面向联盟链的服务不停机分片增加方法
CN111526194B (zh) * 2020-04-17 2021-04-23 中南大学 基于分片技术的区块链系统并行共同挖矿方法
CN114077637B (zh) * 2020-08-12 2022-12-27 北京航空航天大学 分片区块链实现方法
CN112039860B (zh) * 2020-08-18 2021-04-06 上海简苏网络科技有限公司 一种在联盟链中实现联合共识分片的方法和装置
CN112565389B (zh) * 2020-11-30 2021-09-24 网易(杭州)网络有限公司 基于区块链的消息广播方法、装置、电子设备及存储介质
CN112633882A (zh) * 2020-12-28 2021-04-09 青岛海链数字科技有限公司 区块链网络及数据存储方法、装置、电子设备和存储介质
US20220229918A1 (en) * 2021-01-19 2022-07-21 Arm Cloud Technology, Inc. Consent management methods
CN114090306B (zh) * 2022-01-21 2022-04-19 安徽中科晶格技术有限公司 可插拔的区块链分层共识方法、系统、设备及存储介质
CN115102899B (zh) * 2022-08-24 2022-10-28 北京航空航天大学 一种基于负载均衡的区块链节点树形分片方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106656974A (zh) * 2016-10-17 2017-05-10 江苏通付盾科技有限公司 区块链的分组共识方法及系统
CN106878071A (zh) * 2017-01-25 2017-06-20 上海钜真金融信息服务有限公司 一种基于Raft算法的区块链共识机制
CN106886560A (zh) * 2016-12-29 2017-06-23 北京瑞卓喜投科技发展有限公司 树形区块链的生成方法及系统
US20170255950A1 (en) * 2016-03-04 2017-09-07 Forecast Foundation Ou Systems and methods for providing block chain state proofs for prediction market resolution
US20170323392A1 (en) * 2016-05-05 2017-11-09 Lance Kasper Consensus system for manipulation resistant digital record keeping
CN107395353A (zh) * 2017-04-24 2017-11-24 阿里巴巴集团控股有限公司 一种区块链共识方法及装置

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9960920B2 (en) * 2016-01-26 2018-05-01 Stampery Inc. Systems and methods for certification of data units and/or certification verification
US9679276B1 (en) * 2016-01-26 2017-06-13 Stampery, Inc. Systems and methods for using a block chain to certify the existence, integrity, and/or ownership of a file or communication
CN106559211B (zh) * 2016-11-22 2019-12-13 中国电子科技集团公司第三十研究所 一种区块链中隐私保护智能合约方法
US10102265B1 (en) * 2017-04-12 2018-10-16 Vijay K. Madisetti Method and system for tuning blockchain scalability for fast and low-cost payment and transaction processing
US10397328B2 (en) * 2017-05-17 2019-08-27 Nec Corporation Method and system for providing a robust blockchain with an integrated proof of storage
CN107171812A (zh) * 2017-07-18 2017-09-15 光载无限(北京)科技有限公司 一种基于区块链的无密钥签名基础设施构建方法
CN107528886B (zh) * 2017-07-25 2020-07-31 中国科学院计算技术研究所 区块链全网拆分方法与系统
CN107766540A (zh) * 2017-10-31 2018-03-06 上海分布信息科技有限公司 一种分区的区块链网络及其实现分区存储的方法
US20210089676A1 (en) * 2018-02-16 2021-03-25 Ecole Polytechnique Fédérale De Lausanne Epfl-Tto Methods and systems for secure data exchange

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170255950A1 (en) * 2016-03-04 2017-09-07 Forecast Foundation Ou Systems and methods for providing block chain state proofs for prediction market resolution
US20170323392A1 (en) * 2016-05-05 2017-11-09 Lance Kasper Consensus system for manipulation resistant digital record keeping
CN106656974A (zh) * 2016-10-17 2017-05-10 江苏通付盾科技有限公司 区块链的分组共识方法及系统
CN106886560A (zh) * 2016-12-29 2017-06-23 北京瑞卓喜投科技发展有限公司 树形区块链的生成方法及系统
CN106878071A (zh) * 2017-01-25 2017-06-20 上海钜真金融信息服务有限公司 一种基于Raft算法的区块链共识机制
CN107395353A (zh) * 2017-04-24 2017-11-24 阿里巴巴集团控股有限公司 一种区块链共识方法及装置

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113268382A (zh) * 2021-04-19 2021-08-17 支付宝(杭州)信息技术有限公司 在区块链系统中切换分片节点的方法及装置
CN113268382B (zh) * 2021-04-19 2022-08-09 支付宝(杭州)信息技术有限公司 在区块链系统中切换分片节点的方法及装置
CN115617918A (zh) * 2022-12-19 2023-01-17 深圳百纳维科技有限公司 分片式智能合约运行方法、装置、系统和储存介质

Also Published As

Publication number Publication date
US11375010B2 (en) 2022-06-28
CN108847925B (zh) 2020-09-15
US20210258375A1 (en) 2021-08-19
CN108847925A (zh) 2018-11-20

Similar Documents

Publication Publication Date Title
WO2019242059A1 (zh) 一种基于树状结构的分片区块链生成方法
WO2020258831A1 (zh) 用于区块链系统中的主节点切换处理的方法及装置
CN108881169B (zh) 基于区块链的时间分发和同步方法及系统、数据处理系统
Kim et al. Communication-efficient group key agreement
CN111625593A (zh) 基于区块链的数据处理方法、装置、计算机设备
US8868747B2 (en) P2P system and a resource query method for the same
US11962685B2 (en) High availability secure network including dual mode authentication
CN113626781B (zh) 一种基于可信组的区块链高效认证方法
Shang et al. Vectorsync: distributed dataset synchronization over named data networking
CN113067707B (zh) 基于区块链的数据处理方法、装置、设备及可读存储介质
WO2019218479A1 (zh) 一种信息的发送方法及设备
US7203768B2 (en) Managing network traffic using hashing functions
CN113259460A (zh) 跨链交互方法及装置
CN112395113A (zh) 实用拜占庭容错共识方法及装置、可读存储介质
CN115379581A (zh) 边缘云服务器流量卸载方法、系统、设备及存储介质
US11356448B1 (en) Device and method for tracking unique device and user network access across multiple security appliances
Han et al. Analysing and improving shard allocation protocols for sharded blockchains
Xu et al. Adaptchain: Adaptive scaling blockchain with transaction deduplication
CN116614519A (zh) 基于优化共识算法的视频及相关信息轻量级可信上链方法
CN116260826A (zh) 一种供应链溯源中拜占庭容错共识方法及系统
Zhang et al. HCA: Hashchain-based Consensus Acceleration via Re-voting
Kang Efficient data origin authentication scheme for video streaming transmitted by multiple senders.
Zhang et al. FortunChain: EC-VRF-based scalable blockchain system for realizing state sharding
Hu et al. A Data Flow Framework with High Throughput and Low Latency for Permissioned Blockchains
CN115102899B (zh) 一种基于负载均衡的区块链节点树形分片方法

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: 18923515

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 25/03/2021)

122 Ep: pct application non-entry in european phase

Ref document number: 18923515

Country of ref document: EP

Kind code of ref document: A1