CN111209339A - Block synchronization method, device, computer and storage medium - Google Patents

Block synchronization method, device, computer and storage medium Download PDF

Info

Publication number
CN111209339A
CN111209339A CN202010006922.9A CN202010006922A CN111209339A CN 111209339 A CN111209339 A CN 111209339A CN 202010006922 A CN202010006922 A CN 202010006922A CN 111209339 A CN111209339 A CN 111209339A
Authority
CN
China
Prior art keywords
block
transaction
voting
consensus
node
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
CN202010006922.9A
Other languages
Chinese (zh)
Other versions
CN111209339B (en
Inventor
刘攀
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
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 Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202010006922.9A priority Critical patent/CN111209339B/en
Publication of CN111209339A publication Critical patent/CN111209339A/en
Application granted granted Critical
Publication of CN111209339B publication Critical patent/CN111209339B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Abstract

The embodiment of the application discloses a block synchronization method, which comprises the following steps: the method comprises the steps that a first node device obtains a transaction block sent by a second node device, and the block head of the transaction block comprises voting information and block head attribute parameters of a plurality of core nodes; detecting the validity of the block header attribute parameters; determining a consensus result of the trading block according to the voting information in the block header of the trading block; and if the block head attribute parameter is a legal parameter and the consensus result is a successful consensus result, adding the transaction block into a transaction account book corresponding to the first node device. By adopting the method and the device, the real effectiveness of the synchronous block can be guaranteed, and the accuracy of the service data is improved.

Description

Block synchronization method, device, computer and storage medium
Technical Field
The present application relates to the field of block chain technologies, and in particular, to a block synchronization method, apparatus, computer, and storage medium.
Background
Due to the characteristics of de-centering and anti-tampering of the blockchain, the application of the blockchain is more and more extensive, and it is very important to ensure the accuracy of the block data when performing block synchronization among nodes in the blockchain. Currently, when block synchronization is performed among nodes in a block chain, a node that is synchronizing a block generally synchronizes a block header of the block first, checks whether a hash value of a previous block included in the block header is consistent with a hash value of a previous block corresponding to the block, and writes the block into an account book of the node when the hash value of the previous block included in the block header is consistent with the hash value of the previous block corresponding to the block.
Disclosure of Invention
The embodiment of the application provides a block synchronization method and a block synchronization device, which can improve the accuracy of a synchronized block.
An aspect of the present application provides a block synchronization method, including:
the method comprises the steps that a first node device obtains a transaction block sent by a second node device, and the block head of the transaction block comprises voting information and block head attribute parameters of a plurality of core nodes;
detecting the validity of the block header attribute parameters;
determining a consensus result of the trading block according to the voting information in the block header of the trading block;
and if the block head attribute parameter is a legal parameter and the consensus result is a successful consensus result, adding the transaction block into a transaction account book corresponding to the first node device.
An aspect of the present embodiment provides a block synchronization apparatus, where the apparatus includes:
the first acquisition module is used for acquiring a transaction block sent by second node equipment by first node equipment, and a block header of the transaction block comprises voting information and block header attribute parameters of a plurality of core nodes;
the detection module is used for detecting the validity of the block head attribute parameters;
the first determining module is used for determining a consensus result of the transaction blocks according to the voting information in the block headers of the transaction blocks;
and the adding module is used for adding the transaction block into a transaction account book corresponding to the first node device if the block head attribute parameter is a legal parameter and the consensus result is a successful consensus result.
Wherein the voting information comprises a voting block hash; the device further comprises:
a second determining module, configured to determine a block header hash of the transaction block according to the block header attribute parameter;
the first determining module includes:
a comparison unit, configured to compare the chunk hash with voting chunk hashes corresponding to a plurality of pieces of voting information;
a first determining unit, configured to determine that the consensus result of the transaction block is a consensus failure result if there is illegal voting information in the voting information; the voting block hash corresponding to the illegal voting information is different from the block header hash;
the first determining unit is further configured to determine that the consensus result of the transaction block is the consensus success result if the plurality of pieces of voting information are all legal voting information.
The voting information in the block header of the transaction block further comprises an identifier and a voting signature of a corresponding core node;
the first determining module includes:
a first obtaining unit, configured to obtain a legal core node list; the legal core node list comprises the identifiers of the plurality of core nodes and a public key corresponding to each identifier;
a second determining unit, configured to determine that the consensus result of the transaction block is a consensus failure result if a core node that does not belong to the legal core node list exists among the plurality of core nodes;
the voting and signature checking unit is used for acquiring the public key of the core node according to the identifier of the core node and checking and signing the voting signature of the corresponding core node by adopting the public key of the core node if the plurality of core nodes all belong to the legal core node list;
the second determining unit is further configured to determine that the consensus result of the transaction block is a consensus failure result if a core node with a voting signature verification failure exists in the plurality of core nodes;
the second determining unit is further configured to determine that the consensus result of the transaction block is the consensus successful result if the voting signatures of the plurality of core nodes are all checked successfully.
Wherein the first determining module comprises:
a counting unit, configured to determine, as target voting information, voting information that votes successfully in the voting information of the multiple core nodes, and count the number of votes in the target voting information;
a third determining unit, configured to determine that the consensus result of the transaction block is a consensus failure result if the number of votes is smaller than a voting threshold;
the third determining unit is further configured to determine that the consensus result of the transaction block is the consensus success result if the voting number is greater than or equal to the voting threshold.
Wherein the block header attribute parameters comprise a hash value of the transaction block and a block height of the transaction block;
the detection module comprises:
a second obtaining unit, configured to obtain the hash value and the block height of the transaction block;
the first searching unit is used for determining the height of a previous block of the transaction block according to the block height, and searching the previous block of the transaction block from the transaction book based on the height of the previous block;
a fourth determining unit, configured to determine that the block header attribute parameter is an illegal parameter if the preceding block is not found;
the fourth determining unit is further configured to obtain a block header hash value of the previous block if the previous block is found, and determine that the block header attribute parameter is an illegal parameter if the block header hash value of the previous block is different from the previous hash value;
the fourth determining unit is further configured to determine that the block header attribute parameter is the legal parameter if the block header hash value of the previous block is the same as the previous hash value.
Wherein, the detection module includes:
a third obtaining unit, configured to obtain a block header attribute set, where the block header attribute set includes a plurality of block header attributes;
the second searching unit is used for searching a block head attribute parameter corresponding to each block head attribute from the block heads of the transaction blocks;
a fifth determining unit, configured to determine that the block header attribute parameter is an illegal parameter if a missing block header attribute exists in the plurality of block header attributes; the missing block header attribute has no corresponding block header attribute parameter in the block header.
Wherein the apparatus further comprises:
the second acquisition module is used for acquiring transaction data in the block body of the transaction block and acquiring a checking Mercker root of the transaction block according to the transaction data;
the detection module comprises:
a fifth obtaining unit, configured to obtain a default mercker root in a block header attribute parameter of the transaction block;
a sixth determining unit, configured to determine that the block header attribute parameter is an illegal parameter if the default mercker root is different from the verification mercker root;
the sixth determining unit is further configured to determine that the block header attribute parameter is the legal parameter if the default mercker root is the same as the verification mercker root.
Wherein the transaction block further comprises a block generation signature;
the detection module comprises:
a sixth obtaining unit, configured to obtain the block generation signature of the transaction block and a public key of a generation core node of the transaction block;
the generation signature verification unit is used for verifying the signature generated by the block by adopting the public key of the generation core node;
a seventh determining unit, configured to determine that the block header attribute parameter is an illegal parameter if the signature verification fails;
the seventh determining unit is further configured to determine that the block header attribute parameter is a legal parameter if the signature verification passes.
Wherein the apparatus further comprises:
a third determining module, configured to determine an abnormal core node from the multiple core nodes if the consensus result is a consensus failure result, where the abnormal core node is a core node with abnormal voting information;
a deletion module for deleting the transaction block;
and the broadcasting module is used for broadcasting a voting information abnormal message, wherein the voting information abnormal message comprises the abnormal core node, so that the plurality of core nodes check the abnormal core node.
Wherein the apparatus further comprises:
the analysis module is used for acquiring transaction data in the block body of the transaction block and analyzing the transaction data to obtain a transaction process if the block head attribute parameter is a legal parameter and the consensus result is a successful consensus result;
the execution module is used for executing the transaction process to obtain an execution result of the transaction process;
and the storage module is used for storing the execution result and the transaction block into the transaction ledger in a related manner, and the step of adding the transaction block into the transaction ledger corresponding to the first node device is executed through the adding module.
Wherein the apparatus further comprises:
a third obtaining module, configured to obtain, based on a heartbeat mechanism, a generation message of the transaction block sent by a core network, where the core network includes the multiple core nodes;
the broadcast module is further configured to broadcast a transaction block synchronization request to the plurality of core nodes in the core network, and execute, based on the transaction block synchronization request, a step in which the first node device acquires a transaction block sent by a second node device, where the second node device is a core node in the core network.
One aspect of the embodiments of the present application provides a computer device, including a processor, a memory, and an input/output interface;
the processor is connected to the memory and the input/output interface, respectively, where the input/output interface is used for inputting data and outputting data, the memory is used for storing program codes, and the processor is used for calling the program codes to execute the block synchronization method according to an aspect of the embodiment of the present application.
An aspect of the embodiments of the present application provides a computer-readable storage medium, which stores a computer program, where the computer program includes program instructions, and the program instructions, when executed by a processor, perform a block synchronization method as described in an aspect of the embodiments of the present application.
The embodiment of the application has the following beneficial effects:
in the embodiment of the application, the first node device determines a consensus result of the transaction block according to voting information of a plurality of core nodes included in a block header of the transaction block by acquiring the transaction block sent by the second node device, detects the legality of the block header attribute parameters in the block header of the transaction block, and adds the transaction block to a transaction account book corresponding to the first node device when the consensus result is a successful consensus result and the block header attribute parameters are legal parameters. Through the process, when the first node equipment synchronizes the transaction block from the second node equipment, the consistency of the block head and the block body of the transaction block is verified, and the voting condition of the transaction block is verified, so that the real effectiveness of the synchronized block is improved.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.
Fig. 1a is a block synchronization architecture diagram according to an embodiment of the present application;
fig. 1b is a block synchronization network according to an embodiment of the present application;
fig. 2 is a flowchart of a block synchronization method according to an embodiment of the present application;
fig. 3 is a schematic diagram of a transaction block synchronization scenario provided in an embodiment of the present application;
fig. 4 is a schematic block synchronization interaction flow chart according to an embodiment of the present application;
fig. 5 is a schematic diagram illustrating a transaction block consensus scenario provided by an embodiment of the present application;
fig. 6 is a schematic diagram of a block header attribute parameter detection scenario based on a preceding block according to an embodiment of the present disclosure;
fig. 7 is a schematic diagram of a block header attribute parameter detection scenario based on a mercker root according to an embodiment of the present application;
fig. 8 is a schematic diagram of a signature verification of a transaction block according to an embodiment of the present application;
fig. 9 is a schematic diagram of a block synchronization apparatus according to an embodiment of the present application;
fig. 10 is a schematic structural diagram of a computer device according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Specifically, referring to fig. 1a, fig. 1a is a block synchronization architecture diagram provided in an embodiment of the present application, as shown in fig. 1a, a first node device 101 sends a block synchronization request to a second node device cluster 102 associated with the first node device, and the second node device cluster 102 may include a second node device 1021, a second node device 1022, and a second node device 1023. Taking the second node device 1021 as an example, if the second node device 1021 receives the block synchronization request, the block requested for synchronization by the first node device 101 is sent to the first node device 101. Assuming that the second node device 1021 receives the block synchronization request, it sends a transaction block to the first node device 101 in response to the block synchronization request, and the block header of the transaction block includes the voting information and the block header attribute parameters of the plurality of core nodes. The first node device 101 checks the data included in the transaction block, including detecting the validity of the block header attribute parameters, and determines the consensus result of the transaction block according to the voting information in the block header of the transaction block, if the block header attribute parameters are legal parameters and the consensus result is a successful consensus result, the transaction block is added to the transaction account book corresponding to the first node device 101. When the first node device 101 is a data node, the second node device cluster 102 may be regarded as a core network, the core network is composed of a plurality of core nodes, each core node may be regarded as corresponding to the second node device 1021, the second node device 1022, the second node device 1023, and the like, where each core node corresponding to the second node device 1021, the second node device 1022, and the second node device 1023 is a part of core nodes in the listed core network, and the core network may further include other core nodes; when the first node device 101 is a light node, the second node device cluster 102 may be regarded as an intermediate network, where the intermediate network is composed of a plurality of data nodes, and each data node corresponds to the second node device 1021, the second node device 1022, the second node device 1023, and the like, where each data node corresponding to the second node device 1021, the second node device 1022, and the second node device 1023 is a part of the listed data nodes in the intermediate network, and the intermediate network may further include other data nodes.
Further, referring to fig. 1b, fig. 1b is a schematic diagram of a block synchronization network according to an embodiment of the present application, which is used for explaining the service network to which the above-mentioned core network, intermediate network and light node belong. As shown in fig. 1b, the block synchronization network includes a core network 103, an intermediate network 104 and a service network 105, wherein the core network 103 includes a plurality of core nodes 1031, the intermediate network 104 includes a plurality of data nodes 1041, and the service network 105 includes a plurality of light nodes 1051. The core node 1031 is responsible for consensus of each block in the block synchronous network, packaging the acquired transaction data into blocks, and writing the blocks passing the consensus into a transaction account book; the data node 1041 is responsible for synchronizing the ledger information in any core node 1031, that is, acquiring the newly generated block from any core node 1031 in the core network 103, synchronizing the acquired block, and adding the block into its own ledger; the light node 1051 belongs to a service node, and is responsible for synchronizing the block data related to the service from the data node 1041, that is, according to the service responsible by the light node 1051, the block related to the service responsible by itself is acquired from the data node 1041 connected to the light node 1051, and the acquired block is added to the account book of the light node 1051. The block synchronization between the first node device 101 and the second node device 1021 in the second node device cluster 102 in fig. 1a may be that the data node 1041 acquires a transaction block from the core node 1031 to perform synchronization, where the first node device 101 is the data node 1041 and the second node device 1021 is the core node 1031; or the light node 1051 may acquire transaction data from the data node 1041 to synchronize, where the first node device 101 is the light node 1051, and the second node device 1021 is the data node 1041. In the block synchronous network, network connections exist among the core nodes 1031, and data interaction can be performed; each data node 1041 is connected to one or more core nodes 1031, a block may be obtained and synchronized from the connected core nodes 1031, network connection may also be performed between the data nodes 1041 to perform data interaction, the network connection between the data nodes 1041 may be full connection, or network connection between different data nodes 1041 may be established according to specific requirements of the data nodes 1041; each light node 1051 is coupled to one or more data nodes 1041, and blocks can be retrieved and synchronized from the coupled data nodes 1041. Here, it can be considered that what is recorded in each core node 1031 and each data node 1041 is a full quantum chain, and what is recorded in each light node 1051 is a partial chain.
Each core node 1031 in the core network 103, each data node 1041 in the intermediate network 104, and each light node 1051 in the service network 105 may be a computer device, such as a server and an electronic device, where the electronic device includes a mobile phone, a tablet computer, a notebook computer, a palm computer, an intelligent sound, a mobile internet device (MID, mobile internet device), a POS (Point Of Sales) machine, a wearable device (e.g., an intelligent watch, an intelligent bracelet, etc.), and the like.
Further, the following description is made for the above-mentioned partial nouns:
1. block chains: in a narrow sense, a block chain is a chain data structure taking a block as a basic unit, and the prior transaction history is verified by utilizing a digital abstract in the block, so that the block chain is suitable for the requirements of tamper resistance and expandability under a distributed accounting scene; in a broad sense, blockchain also refers to distributed accounting techniques implemented by blockchain architecture, including distributed consensus, privacy and security protection, peer-to-peer communication techniques, network protocols, intelligent contracts, and the like. The goal of the blockchain is to implement a distributed data record ledger that allows only additions and not deletions. The basic structure of the ledger bottom layer is a linear linked list. The linked list is composed of a series of 'blocks', the Hash (Hash) value of the previous block is recorded in the subsequent block, and whether each block (and the transaction in the block) is legal or not can be quickly checked by calculating the Hash value. If a node in the network proposes to add a new block, the block must be acknowledged through a consensus mechanism.
2. Block (Block): all transactions and status results, etc. occurring over a period of time are recorded, which is a consensus on the current ledger status. Specifically, for a block chain, each time data is written, i.e. the above transaction process, a block is created.
3. Chain (Chain): the blocks are connected in series according to the occurrence sequence and are log records of the state change of the whole account book.
4. A consensus mechanism: the verification and confirmation of the transaction are completed in a short time through the voting of special nodes, the goal is to make all core nodes keep consistent block chain diagrams, which is an algorithm for achieving distributed consensus, such as Proof of Work (POW), Proof of rights and interests mechanism (PoS), and a bayer Byzantine consensus algorithm (PBFT).
It is understood that the method provided by the embodiment of the present invention can be executed by a computer device, including but not limited to a terminal or a server. The node in the embodiment of the present invention may be a computer device.
Further, please refer to fig. 2, wherein fig. 2 is a flowchart of a block synchronization method according to an embodiment of the present disclosure. As shown in fig. 2, the first node device is used as an execution subject for description, and the block synchronization process includes the following steps:
in step S201, the first node device obtains a transaction block sent by the second node device, where a block header of the transaction block includes voting information of a plurality of core nodes and block header attribute parameters.
Specifically, when monitoring that a new transaction block is generated by the second node device, the first node device sends a transaction block synchronization request to the second node device, the second node device sends the transaction block to the first node device based on the transaction block synchronization request, the first node device obtains the transaction block sent by the second node device, and a block header of the transaction block includes voting information of a plurality of core nodes and block header attribute parameters. The first node device may not send a transaction block synchronization request to the second node device, and after the second node device generates a new transaction block, the transaction block is broadcast to each first node device, so that the first node device can acquire the transaction block. The data interaction between the first node device and the second node device is performed through broadcasting, in other words, the first node device broadcasts a transaction block synchronization request, a node which sends a transaction block to the first node device based on the transaction block synchronization request is the second node device, or the second node device broadcasts the transaction block after generating the transaction block, and the node which receives the transaction block is marked as the first node device. In the embodiment of the present application, the description is performed by using a first node device that receives a transaction block and a second node device that sends the transaction block, that is, a group of the first node device and the second node device involved in transaction block synchronization is used for description, and other nodes may also perform block synchronization according to the embodiment of the present application.
Step S202, detecting the validity of the block head attribute parameters.
Specifically, the block header attribute parameters are parameters included in a block header of the transaction block, such as a block header hash value, a previous hash value, a block height, a default mercker root, a block generation signature, a timestamp, and the like, and are detected to detect the validity of the block header attribute parameters. Specifically, whether a block head attribute parameter included in a block head of the transaction block is complete or not is detected, that is, whether a block head attribute without a corresponding parameter exists in the block head is detected, whether the block head attribute parameter is correct or not is detected, and the validity of the block head attribute parameter is obtained by detecting the integrity and the correctness of the block head attribute parameter.
In step S203, a consensus result of the transaction block is determined according to the voting information in the block header of the transaction block.
Specifically, the consensus result of the transaction block is determined according to the voting information in the block header of the transaction block. Specifically, voting information in a block header of the transaction block is obtained, each piece of voting information corresponds to one core node, each piece of voting information is a voting condition of the corresponding core node for the transaction block, and each piece of voting information is checked according to each piece of voting information in the block header of the transaction block to obtain a voting result for the transaction block, so that whether the consensus result of the transaction block is a consensus success result or a consensus failure result is determined.
In step S204, if the block header attribute parameter is a legal parameter and the consensus result is a successful consensus result, the transaction block is added to the transaction book.
Specifically, if the block head attribute parameter is a legal parameter and the consensus result of the transaction block is a successful consensus result, the transaction block is added to the transaction book corresponding to the first node device, so as to store the transaction block in the first node device.
In the embodiment of the present application, the validity of the attribute parameter of the block header detected in step S202 and the consensus result of the transaction block determined according to the voting information in the block header of the transaction block in step S203 are not in sequence, that is, step S202 may be executed first, step S203 may be executed then, step S203 may be executed first, step S202 may be executed then, or step S202 and step S203 may be executed simultaneously.
Further, referring to fig. 3, fig. 3 is a schematic view of a transaction block synchronization scenario provided in an embodiment of the present application. As shown in fig. 3, the first node device 301 broadcasts a transaction block synchronization request, when the second node device 302 receives the transaction block synchronization request, a transaction block is sent to the first node device 301 based on the transaction block synchronization request, the first node device 301 obtains the transaction block 303 sent by the second node device 302, obtains a block header attribute parameter 304 included in a block header of the transaction block 303 and voting information 305 of a plurality of core nodes, obtains transaction data 306 in a block of the transaction block 303, detects validity of the block header attribute parameter 304 based on the transaction data 306 and the like, and determines a consensus result of the transaction block according to the voting information 305 in the block header of the transaction block. Judging the validity and consensus of the block header attribute parameter 304, and if the block header attribute parameter 304 is a valid parameter and the consensus is a successful consensus, adding the transaction block 303 to the transaction book 307 of the first node device 301; if the tile header attribute parameter 304 is not a valid parameter, or the consensus result is not a successful consensus result, i.e., the tile header attribute parameter 304 is an invalid parameter, or the consensus result is a failed consensus result, the transaction tile 303 is deleted.
In the embodiment of the application, the first node device checks the block header attribute parameters recorded in the block header of the transaction block and the voting information of the plurality of core nodes by acquiring the transaction block sent by the second node device, and adds the acquired transaction block into the transaction account book when the consensus result of the transaction block is determined to be the consensus success result according to the voting information of each core node and the block header attribute parameter is the legal parameter. Through the steps, the first node equipment checks the acquired block head of the transaction block and the transaction data in the block head, so that the accuracy of the transaction data is improved, and the real effectiveness of the synchronous block is improved.
Further, referring to fig. 4, fig. 4 is a schematic block synchronization interaction flow chart according to an embodiment of the present disclosure. As shown in fig. 4, it is assumed that the core network includes M core nodes, the intermediate network includes N data nodes, and M and N are positive integers, and the block synchronization process includes the following steps:
in step S401, the first node device sends a transaction block synchronization request.
Specifically, the first node device broadcasts a transaction block synchronization request.
When the first node device is a data node and the second node device is a core node, the first node device acquires a transaction block generation message sent by a core network based on a heartbeat mechanism, wherein the core network comprises a plurality of core nodes; broadcasting a transaction block synchronization request to a plurality of core nodes in the core network, that is, broadcasting a transaction block synchronization request to M core nodes in the core network, the second node device executing step S402 based on the transaction block synchronization request, sending a transaction block to the first node device, the first node device executing step S403 based on the transaction block synchronization request, and acquiring the transaction block sent by the second node device, where the second node device is a core node in the core network. Optionally, when the first node device is connected to a part of core nodes in each core node in the core network, and the first node device broadcasts a transaction block synchronization request to a plurality of core nodes in the core network, the plurality of core nodes are each core node connected to the first node device.
When the first node device is a light node and the second node device is a data node, the first node device obtains a storage message of a transaction block sent by the intermediate network based on a heartbeat mechanism, broadcasts a transaction block synchronization request to a plurality of data nodes in the intermediate network, namely broadcasts the transaction block synchronization request to N data nodes in the intermediate network, and the second node device is a data node in the intermediate network at the moment. Optionally, when the first node device is connected to a part of data nodes in each data node in the intermediate network, and the first node device broadcasts a transaction block synchronization request to a plurality of data nodes in the intermediate network, the plurality of data nodes are each data node connected to the first node device.
The method comprises the steps that a generation core node generates a transaction block according to transaction data, the transaction block is broadcasted to other core nodes in a core network, when any one core node in the core network votes for the transaction block to pass, voting information of the other core nodes aiming at the transaction block is acquired, if the acquired voting information determines that the consensus of the transaction block has passed, the acquired voting information is added into a block header of the transaction block, the transaction block added with the voting information is added into an account book of the transaction block, and the transaction block comprising the voting information is broadcasted to the other core nodes, so that each core node in the core network records the transaction block. In this case, since the voting information is added on the basis of the transaction block without the voting information to obtain the transaction block containing the voting information, and the data in the transaction blocks recorded in different core nodes except for the voting information in the block header are completely consistent, the block consistency is ensured, and the added voting information is the record of the voting condition of the transaction block and does not affect the transaction data of the transaction block itself and the data in the block header, it can be considered that, in the present application, for the same transaction block, the consistency of the data other than the voting information is ensured when the nodes record, the voting information can be considered as additional data of the transaction block, so that when the voting information in the block headers of the transaction blocks recorded in different core nodes is not completely the same, the synchronization of the blocks in the application is not affected. Each piece of voting information may include an identifier of a core node, a voting block hash of an approved transaction block, and a block height of the approved transaction block, and each piece of voting information may further include a voting signature of a corresponding core node and whether to vote for a block that does not contain a transaction.
Optionally, after each core node in the core network acquires the transaction block, the voting information of each core node needs to be generated no matter whether the transaction block is approved or not, after each core node acquires the voting information of all the core nodes, all the acquired voting information is added to the block header of the transaction block, at this time, each piece of voting information further includes a voting attitude for the transaction block, where the voting attitude includes a successful voting or a failed voting, the successful voting is used to indicate that the transaction block is approved, and the failed voting is used to indicate that the transaction block is not approved. The transaction blocks recorded by the core nodes in this way are completely consistent, and include data of the transaction blocks and voting information of the core nodes. Optionally, because there may be a situation that the core node is abnormal and cannot vote, so that the core node which normally works in the core network cannot acquire the voting information of all the core nodes, a voting time interval may be preset, if the core node does not acquire the voting information of all the other core nodes in the core network after acquiring the transaction block after the voting time interval, a voting information acquisition request is sent to the core node which does not acquire the voting information, and if the voting information of this core node is not acquired yet, the core node is considered to be abnormal, and the core node abnormality is written into a block header of the transaction block as the voting information of this core node.
The transaction block consensus is determined based on a Byzantine algorithm or a consensus algorithm such as a more than half passing mechanism, the consensus algorithm for determining the transaction block consensus is not limited to the two algorithms, and other algorithms which can be used for determining that the transaction block meets the condition of adding the account book can be used.
For example, referring to fig. 5, fig. 5 is a schematic diagram of a transaction block consensus scenario provided in the embodiment of the present application, as shown in fig. 5, it is assumed that the core network includes a core node 501, a core node 502, a core node 503, a core node 504, a core node 505, and a core node 506, when the core node 501 generates a transaction block, that is, the core node 501 is a core node, the core node 501 broadcasts the transaction block to other core nodes, and the other core nodes vote for the transaction block. Take core node 504 as an example and the consensus algorithm used is byzantine 2/3. In one case, only the core node that approves the transaction block needs to generate the voting information for the transaction block, when the core node 504 acquires the voting information of the core node 501, the voting information of the core node 503 and the voting information of the core node 506, and then acquires the voting information of 4 core nodes to the transaction block in total, which satisfies the condition of bexada 2/3, the core node 504 adds the voting information of the core node 501, the voting information of the core node 503, the voting information of the core node 504 and the voting information of the core node 506 to the block header of the transaction block, and adds the transaction block to which the voting information is added to the vote book of the core node 504, that is, as long as the core node 504 acquires the voting information that reaches the voting threshold value, regardless of whether the core node 502 and the core node 505 approve the transaction block, the transaction block is uplinked and the voting threshold is determined based on the consensus algorithm used, where the voting threshold is determined to be 4 based on byzantine 2/3. In one case, all core nodes need to generate voting information of transaction blocks, after acquiring all voting information from the core node 501 to the core node 506, the core node 504 counts the number of successfully voted voting information in all voting information, and if the number of successfully voted voting information reaches a voting threshold, all voting information is added to a block header of the transaction block, and the transaction block to which the voting information is added to the book of the core node 504, for example, the voting information of the core node 501, the core node 502, the core node 503, and the core node 506 acquired by the core node 504 is successfully voted voting information, the voting information of the core node 505 is unsuccessfully voted voting information, 5 successfully voted voting information has been acquired, and the condition of the byzang 2/3 is satisfied, all voting information is added to the block header of the transaction block, the transaction block including the voting information is added to the ledger of the core node 504.
In step S402, the second node device sends the transaction block to the first node device.
Specifically, the second node device sends the transaction block to the first node device. When the first node device is a data node and the second node device is a core node, the second node device directly sends the transaction block to the first node device because the data node stores a full link; when the first node device is a light node and the second node device is a data node, the second node device determines a service data type in charge of the first node device due to the light node storage part chain, determines an acquisition authority of the first node device for a transaction block according to the service data type, sends the transaction block to the first node device if the first node device has the acquisition authority for the transaction block, and sends an unrelated transaction message to the first node device if the first node device does not have the acquisition authority for the transaction block, the unrelated transaction message is used for informing that a transaction in the transaction block of the first node device is unrelated to the first node device, for example, when the first node device is a node in charge of entertainment related services and the transaction block records a transaction in a financial aspect, it is determined that the first node device does not have the acquisition authority for the transaction block, an unrelated transaction message is sent to the first node device.
In step S403, the first node device detects the validity of the block header attribute parameter.
Specifically, the first node device detects the validity of the block header attribute parameter, that is, detects whether the block header attribute parameter is a valid parameter or an invalid parameter. The validity of the block header attribute parameter can be detected by the following method:
a1, the block head attribute parameter comprises the previous hash value of the transaction block and the block height of the transaction block, the previous hash value and the block height of the transaction block are obtained, the previous block height of the transaction block is determined according to the block height, and the previous block of the transaction block is searched from the transaction book based on the previous block height. If the previous block is not found, determining the attribute parameter of the block head as an illegal parameter; if the previous block is found, acquiring a block head hash value of the previous block, and if the block head hash value of the previous block is different from the previous hash value, determining that the block head attribute parameter is an illegal parameter; and if the block head hash value of the previous block is the same as the previous hash value, determining the block head attribute parameter as a legal parameter. If the first node device is a light node and the second node device is a data node, because the light node records a partial chain, even if the hash value of the transaction block has no problem, the situation that the previous block cannot be found in the light node can occur, so that the method is only suitable for the situation that the first node device is a data node and the second node device is a core node.
Specifically, referring to fig. 6, fig. 6 is a schematic view of a block header attribute parameter detection scene based on a preceding block according to an embodiment of the present disclosure. As shown in fig. 6, a block height 602 is obtained from the block head attribute parameter of the block head of the transaction block 601, and a subsequent block height 603 is obtained according to the block height 602, wherein the value of the subsequent block height 603 is smaller than the block height 602 by 1. Acquiring a previous block corresponding to the previous block height 603 from the transaction book 604, if the previous block corresponding to the previous block height is not found, determining that the block head attribute parameter is an illegal parameter, if the maximum block height in the transaction book is 5, the acquired previous block height 603 is 6, and if no block with the block height of 6 exists in the transaction book 604, determining that the block head attribute parameter is an illegal parameter; or, if the maximum block height in the transaction book is 7, the obtained previous block height 603 is 6, and the block with the block height of 6 in the transaction book 604 is not the block with the maximum block height in the current transaction book 604, it is determined that the block header attribute parameter is the illegal parameter. If the previous block 606 is found, the block head hash value 607 of the previous block is obtained from the previous block 606, the previous hash value 605 is obtained from the transaction block 601, the consistency 608 between the previous hash value 605 and the block head hash value 607 of the previous block is detected, if the two are not consistent, the block head attribute parameter is determined to be an illegal parameter, and if the two are consistent, the block head attribute parameter is determined to be a legal parameter.
A2, obtaining a block head attribute set, wherein the block head attribute set comprises a plurality of block head attributes, searching a block head attribute parameter corresponding to each block head attribute from the block head of the transaction block, and if a missing block head attribute exists in the plurality of block head attributes, determining the block head attribute parameter as an illegal parameter, wherein the missing block head attribute does not have a corresponding block head attribute parameter in the block head. Specifically, the plurality of block header attributes included in the block header attribute set are data to be recorded when the transaction block is generated, a parameter corresponding to each block header attribute is obtained from the block header attribute parameters of the transaction block, if the block header attribute is missing, the block header attribute parameter is represented to be incomplete, and the block header attribute parameter is determined to be an illegal parameter. For example, the block header attribute set includes a "timestamp attribute, a block header hash attribute, a block height attribute, and a previous hash value attribute", and obtains a parameter corresponding to each block header attribute from the block header attribute parameters, and if the timestamp, the block header hash, the block height, and the previous hash value are found, the block header attribute parameter is determined to be a legal parameter, thereby ensuring the integrity of each attribute recorded in the block header of the transaction block.
A3, acquiring transaction data in the block body of the transaction block, and acquiring a checking Mercker root of the transaction block according to the transaction data; acquiring a default Merck root in a block head attribute parameter of a transaction block; if the default Merck root is different from the inspected Merck root, determining the block head attribute parameter as an illegal parameter; if the default Merck root is the same as the inspected Merck root, the block header attribute parameter is determined to be a legal parameter.
Specifically, referring to fig. 7, fig. 7 is a schematic diagram of a block header attribute parameter detection scenario based on a merkel root according to an embodiment of the present disclosure. As shown in fig. 7, a default mercker root 702 is obtained from the block head attribute parameters in the block head of the transaction block 701, and transaction data is obtained from the block body of the transaction block 701, where the transaction data includes p pieces of transaction data, i.e., transaction data 1, transaction data 2, and transaction data p, where p is a positive integer. According to the method for generating the mercker root, the verified mercker root 703 corresponding to the transaction data is obtained, and the method for generating the mercker root is the default method for generating the mercker root 702. For example, hash 1 is generated from transaction data 1 and transaction data 2, hash 2 is generated from transaction data 3 and transaction data 4, until hash x is generated from transaction data (p-1) and transaction data p, further hashes are generated from hash 1 and hash 2, …, and hashes (x-1) and hash x are further generated until only one hash value is generated, which is pingmercker root 703, where x is a positive integer and x is p/2. The consistency 704 between the default merkel root 702 and the inspected merkel root 703 is detected, if the default merkel root 702 is not the same as the inspected merkel root 703, the block header attribute parameter is determined to be an illegal parameter, and if the default merkel root 702 is the same as the inspected merkel root 703, the block header attribute parameter is determined to be a legal parameter.
A4, the transaction block further comprises a block generation signature. Specifically, a block generation signature of the transaction block and a public key of a generation core node of the transaction block are obtained; adopting a public key for generating a core node to verify the signature generated by the block; if the signature verification fails, determining the block head attribute parameter as an illegal parameter; and if the signature verification passes, determining the block header attribute parameter as a legal parameter.
Specifically, reference may be made to fig. 8 for a process of performing signature verification based on a hash value, which is a schematic diagram of signature verification of a transaction block according to an embodiment of the present application. As shown in fig. 8, the first node device obtains data 802 requiring signature verification from a transaction block 801, the data to be verified 802 includes the chunk generation signature obtained from the chunk header and the public key of the generation core node of the transaction chunk, and the transaction data obtained from the chunk body, extract the chunk generation signature 803, the tile generation signature 803 is decrypted by generating the public key 804 of the core node, resulting in a signature hash value, further, the first node device may perform a hash operation on the transaction data by using a hash algorithm 805 (the hash algorithm 805 is a hash algorithm used for generating the core node generation block generation signature 803), to obtain a transaction hash value corresponding to the transaction data, and if the transaction hash value is equal to the signature hash value, the transaction data is not tampered in the transmission process, the signature is verified to pass, and the block header attribute parameter is determined to be a legal parameter; if the transaction hash value is not equal to the signature hash value, it indicates that the actual data in the transaction data may be tampered in the transmission process, the signature verification fails, and the block header attribute parameter is determined to be an illegal parameter.
Optionally, the method for detecting the validity of the block header attribute parameter may be a detection method combining any one or more of the methods a1 through a4, when the block header attribute parameter is detected by the detection method combining a plurality of the methods a1 through a4, the block header attribute parameter can be determined to be a valid parameter only if the condition for determining the block header attribute parameter to be the valid parameter in several methods is simultaneously satisfied, and the block header attribute parameter is determined to be an illegal parameter as long as one condition is not satisfied. That is, the above methods a1 to A4 may constitute several detection methods including methods of a1, a2, A3 and A4, etc. which are single methods, methods of a1 and a2, a1 and A3, a1 and A4, a2 and A3, a2 and A4, A3 and A4, etc. which are two methods, methods of a1 and a2 and A3, a1 and a2 and A4, a1 and A3 and A4, a2 and A3 and a 39 4, etc. which are three methods, and methods of a1 and a2, A3 and A4, etc. which are all methods. The above is a combination of several optional methods, and other methods that can detect the validity of the block header attribute parameter are not limited herein. Taking one of the combined detection methods as an example, as in a1 and a2, only the previous block of the transaction block is found in the transaction book, the hash value of the block head of the previous block is the same as the hash value of the previous block, and the block head attribute parameter corresponding to each block head attribute can be found from the block head of the transaction block, the block head attribute parameter is determined to be a legal parameter, otherwise, the block head attribute parameter is determined to be an illegal parameter.
Similarly, a detection method combined by other methods can determine that the block header attribute parameter is a legal parameter only when the block header attribute parameter satisfies all legal conditions in the methods forming the detection method, otherwise, the block header attribute parameter is determined to be an illegal parameter, wherein the legal conditions are conditions for determining that the block header attribute parameter is a legal parameter in the corresponding method. In other words, the methods a1 to a4 described above may be randomly combined to form a new detection method, where the detection method includes several methods (one or more methods selected from a1 to a 4), and when legal conditions of the several methods are simultaneously satisfied, the block header attribute parameter is determined to be a legal parameter, and no description is made here, which may specifically refer to a determination method after the methods a1 and a2 are combined.
The more methods the detection method comprises, the more complete the verification of the transaction block, and the more accurate and deterministic the synchronized transaction block can be guaranteed. The block header hashes mentioned in the present application are obtained for the block header data of the block where the block header hashes are located, such as the block header hash value of the preceding block and the block header hashes of the transaction blocks, where the block header data is data other than the voting information in the block header of the block where the block header hashes are located. For example, the block header hash of the transaction block refers to the generation core node that generated the initial transaction block for which no voting information was included when generating the initial transaction block.
In step S404, the first node device determines a consensus result of the transaction block according to the voting information in the block header of the transaction block.
Specifically, the first node device determines the consensus result of the transaction blocks according to the voting information in the block header of the transaction block, that is, determines whether the consensus result of the transaction block is a consensus successful result or a consensus failure result. Wherein, determining the consensus result of the transaction block can be performed by:
b1, the voting information comprises voting block hash; determining the block head hash of the transaction block according to the block head attribute parameters; comparing the block head hash with voting block hashes corresponding to the plurality of voting information; if the plurality of pieces of voting information have illegal voting information, determining that the consensus result of the transaction blocks is a consensus failure result; the voting block hash corresponding to the illegal voting information is different from the block hash; and if the plurality of pieces of voting information are all legal voting information, determining that the consensus result of the transaction blocks is a consensus success result. The voting block hash is used to indicate that the voting information is a hash of a block for which the voting information is intended, and the block header hash is generated according to data in the block header of the transaction block except the voting information, that is, the block header hash can be considered to be generated according to the block header attribute parameter in the block header of the transaction block. If the block head hash is the same as the voting block hash, the voting block hash is considered as the vote of the transaction block corresponding to the block head hash, and when all the voting block hashes are the same as the block head hash, all the voting information in the block head is considered as the vote of the transaction block, and the consensus result of the transaction block is determined to be the consensus success result; if the voting block hash is different from the block head hash, the voting information which is not aiming at the transaction block exists in the block head, and the consensus result of the transaction block is determined to be a consensus failure result.
B2, the voting information in the block header of the transaction block further includes the identification of the corresponding core node and the voting signature. Acquiring a legal core node list, wherein the legal core node list comprises identifiers of a plurality of core nodes and a public key corresponding to each identifier; if the core nodes which do not belong to the legal core node list exist in the plurality of core nodes, determining that the consensus result of the transaction block is a consensus failure result; if the plurality of core nodes belong to the legal core node list, acquiring the public key of the core node according to the identifier of the core node, and verifying the signature of the voting corresponding to the core node by adopting the public key of the core node; if the core node with the voting signature verification failure exists in the plurality of core nodes, determining that the consensus result of the transaction block is the consensus failure result; and if the voting signatures of the plurality of core nodes are checked successfully, determining that the consensus result of the transaction block is a consensus successful result. The list of valid core nodes includes identifiers of all core nodes in the core network and a public key corresponding to each identifier, and includes M core nodes. The method comprises the steps of obtaining the identification of a core node in each piece of voting information of a transaction block, obtaining the identification of the core node in each piece of voting information from a legal core node list, obtaining the public key of the core node in each piece of voting information if the legal core node list comprises the identification of the core node in each piece of voting information, checking and signing corresponding voting signatures based on the public key of the core node, determining that the consensus result of the transaction block is a consensus successful result if each voting signature is checked and signed successfully, and determining that the consensus result of the transaction block is a consensus failed result if the identification of the core node with the piece of voting information does not belong to the legal core node or the voting signature fails to check and sign. The block head of the transaction block comprises K pieces of voting information, K is a positive integer and is less than or equal to M.
B3, determining the voting information which votes successfully in the voting information of the plurality of core nodes as target voting information, and counting the voting number of the target voting information; if the voting number is smaller than the voting threshold value, determining that the consensus result of the transaction block is a consensus failure result; and if the voting number is greater than or equal to the voting threshold, determining that the consensus result of the transaction blocks is the consensus success result.
In one case, only the core node that approves the transaction block needs to generate the voting information for the transaction block, each piece of voting information in the block header of the transaction block is the target voting information that votes successfully, when the block header includes K pieces of voting information, the number of votes for the target voting information is counted to be K, and assuming that the core network includes M core nodes, the voting threshold is determined according to M and a consensus algorithm. When the voting number K is smaller than the voting threshold, the number of the core nodes of the transaction block is accepted to be insufficient, the condition of successful consensus is not met, and the consensus result of the transaction block is determined to be a consensus failure result; when the voting number K is larger than or equal to the voting threshold, the number of the core nodes of the transaction block is accepted to be enough, the condition of successful consensus is met, and the result of the consensus of the transaction block is determined to be a successful consensus result. For example, when K is 4, M is 6, and the consensus algorithm is byzantine 2/3, the voting threshold is determined to be 4 according to the M and consensus algorithm, and K is equal to the voting threshold 4, the consensus result of the transaction block is determined to be a successful consensus result.
In one case, all core nodes need to generate the voting information of the transaction block, and each piece of voting information in the block header of the transaction block includes target voting information of successful voting and possibly voting information of failed voting. When the block header comprises K pieces of voting information, obtaining the voting attitude in each piece of voting information, and determining the voting information with the voting attitude being successful as target voting information. And determining a voting threshold value according to the M and the consensus algorithm, and counting the voting number of the target voting information in the K pieces of voting information, wherein the voting number is less than or equal to K. When the voting number is smaller than the voting threshold value, the number of the core nodes which approve the transaction block is insufficient, the condition of successful consensus is not satisfied, and the consensus result of the transaction block is determined to be a consensus failure result; when the voting number is larger than or equal to the voting threshold, the number of the core nodes of the transaction block is enough to satisfy the condition of successful consensus, and the consensus result of the transaction block is determined to be the successful consensus result. For example, when K and M are both 6 and the consensus algorithm is byzantine 2/3, the voting threshold is determined to be 4 according to M and the consensus algorithm, the number of votes for the target voting information in the K pieces of voting information is counted to obtain 4, and the voting number 4 is equal to the voting threshold 4, then the consensus result of the transaction block is determined to be a successful consensus result.
Alternatively, the method for determining the consensus result of the transaction block may be a consensus result determination method combining any one or more of the methods B1 through B3, when the block header attribute parameters are detected by the consensus result determination methods combining a plurality of the methods B1 through B3, the consensus result of the transaction block is determined to be a consensus success result only if the condition for determining the consensus result of the transaction block to be a consensus success result in several methods is satisfied, and the consensus result of the transaction block is determined to be a consensus failure result as long as one condition is not satisfied. That is, the above methods B1 to B3 may constitute several consensus result determination methods including methods B1, B2, and B3, etc. consisting of a single method, methods B1 and B2, B1 and B3, and methods B2 and B3, etc. consisting of two methods, and methods B1 and B2, and B3, etc. consisting of all methods. The above is a combination of several optional methods, and other methods that can determine the consensus result of the transaction block are not limited herein. Taking one of the combined consensus result determination methods as an example, as in B1 and B2, only if the hash of the voting block in all the voting information is the same as the hash of the block header of the transaction block, and the core node list includes all the core nodes of the voting information, the voting signature in each voting information passes the check signature, and the consensus result of the transaction block is determined to be a successful consensus result, otherwise, the consensus result of the transaction block is determined to be a failed consensus result.
Similarly, the consensus result determining method formed by combining other methods can determine that the consensus result of the transaction block is the consensus success result only when the voting information satisfies all the consensus success conditions in the methods forming the consensus result determining method, or else, determine that the consensus result of the transaction block is the consensus failure result, wherein the consensus success condition is a condition for determining that the consensus result of the transaction block is the consensus success result in the corresponding method. In other words, the methods B1 to B3 may be combined randomly to form a new consensus result determination method, which is composed of several methods (one or more methods selected from B1 to B3), and when the consensus success conditions of the several methods are simultaneously met, the consensus result of the transaction block is determined to be the consensus success result, which is not described herein, specifically, refer to the determination method after the methods B1 and B2 are combined.
The more methods the consensus result determination method comprises, the more complete the verification of the transaction block, and the more accurate and deterministic the synchronized transaction block can be guaranteed.
The steps S403 and S404 are both the verification of the transaction block, and there is no order of execution, and after the execution results of the steps S403 and S404 are both obtained, the subsequent process is determined according to the execution results of the steps S403 and S404. Specifically, if the block header attribute parameter is determined to be a legal parameter in step S403 and the consensus result of the transaction block is determined to be a successful consensus result in step S404, step S405 is executed, otherwise, step S406 is executed, i.e., when the block header attribute parameter is an illegal parameter or the consensus result of the transaction block is a failed consensus result (if any condition of the illegal parameter and the successful consensus result of the transaction block is satisfied), step S406 is executed.
In step S405, the first node device adds the transaction block to the transaction account book corresponding to the first node device.
Specifically, the first node device adds the transaction block to a transaction book corresponding to the first node device. Further, if the block head attribute parameter is a legal parameter and the consensus result is a successful consensus result, acquiring transaction data in the block body of the transaction block, and analyzing the transaction data to obtain a transaction process; executing the transaction process to obtain an execution result of the transaction process; and storing the execution result and the transaction block into the transaction book in a correlated manner, and adding the transaction block into the transaction book corresponding to the first node device. Taking the first node device as a data node, for example, a transaction execution block may be generated according to the execution result, and the transaction execution block is added to an execution block chain in the transaction book, where the execution block chain is used to record the execution result of each transaction block obtained from the core node, and the transaction execution block further includes a block height of the transaction block or a block header hash of the transaction block, and is used to indicate that the transaction execution block is the execution result of the transaction block; alternatively, the execution result may be stored in association with the transaction block directly. When the first node device is a light node, the execution result of the first node device may also be stored in a manner that the data node stores the execution result, and the execution block chain of the light node is used to record the execution result of each transaction block acquired from the data node.
Optionally, after the data node acquires the transaction block, it may be determined whether the data node is an execution object of the transaction block, and if the data node is not an execution object of the transaction data in the transaction block, the transaction block is added to the transaction book of the light node; if the data node can execute the transaction data in the transaction block, the process of obtaining the execution result and storing the execution result is executed, and the transaction block is added to the transaction book of the light node. After the light node acquires the transaction block, the execution condition of the transaction block can be acquired, and if the transaction process corresponding to the transaction data in the transaction block is executed, the transaction block is added to the transaction book of the light node; and if the transaction process corresponding to the transaction data in the transaction block is not executed, executing the process of obtaining the execution result and storing the execution result, and adding the transaction block into the transaction book of the light node.
In step S406, the first node device deletes the transaction block.
Specifically, when the block header attribute parameter is an illegal parameter or the consensus result of the transaction blocks is a consensus failure result, the first node device deletes the transaction blocks. Further, if the consensus result is a consensus failure result, determining an abnormal core node from the plurality of core nodes, wherein the abnormal core node is a core node with abnormal voting information; deleting the transaction block, and broadcasting a voting information exception message, wherein the voting information exception message comprises the exception core node, so that the plurality of core nodes check the exception core node.
In the embodiment of the application, a first node device acquires a transaction block sent by a second node device, wherein a block header of the transaction block comprises voting information of a plurality of core nodes and block header attribute parameters; and detecting the legality of the block head attribute parameters, determining the consensus result of the transaction blocks according to the voting information of the core nodes, and adding the transaction blocks into a transaction account book corresponding to the first node equipment if the block head attribute parameters are legal parameters and the consensus result of the transaction blocks is a successful consensus result. Through the process, when the first node equipment synchronously transacts the block from the second node equipment, the consistency, the accuracy and the integrity of the block head and the block body of the transaction block can be verified, and meanwhile, the voting condition of the transaction block is verified, so that the real effectiveness of the synchronous block is improved, and the accuracy of transaction data is improved.
Referring to fig. 9, fig. 9 is a schematic diagram of a block synchronization apparatus according to an embodiment of the present disclosure. The block synchronization apparatus may be a computer program (including program code) running in a computer device, for example, the block synchronization apparatus is an application software; the apparatus may be used to perform the corresponding steps in the methods provided by the embodiments of the present application. As shown in fig. 9, the block synchronization apparatus 90 can be used in the computer device in the embodiment corresponding to fig. 2, and specifically, the block synchronization apparatus 90 can include: the device comprises a first acquisition module 11, a detection module 12, a first determination module 13 and an adding module 14.
A first obtaining module 11, configured to obtain, by a first node device, a transaction block sent by a second node device, where a block header of the transaction block includes voting information of multiple core nodes and block header attribute parameters;
a detection module 12, configured to detect validity of the block header attribute parameter;
a first determining module 13, configured to determine a consensus result of the transaction blocks according to the voting information in the block headers of the transaction blocks;
an adding module 14, configured to add the transaction block to a transaction book corresponding to the first node device if the block header attribute parameter is a legal parameter and the consensus result is a successful consensus result.
The voting information comprises voting block hash; the above apparatus 90 further comprises:
a second determining module 15, configured to determine a block header hash of the transaction block according to the block header attribute parameter;
the first determining module 13 includes:
a comparing unit 131, configured to compare the chunk hash with a plurality of voting chunk hashes corresponding to the voting information;
a first determining unit 132, configured to determine that the consensus result of the transaction block is a consensus failure result if there is illegal voting information in the plurality of pieces of voting information; the voting block hash corresponding to the illegal voting information is different from the block header hash;
the first determining unit 132 is further configured to determine that the consensus result of the transaction block is the consensus success result if all the voting information is legal voting information.
The voting information in the block header of the transaction block further includes an identifier and a voting signature corresponding to the core node;
the first determining module 13 includes:
a first obtaining unit 133, configured to obtain a legal core node list; the legal core node list comprises the identifiers of the plurality of core nodes and a public key corresponding to each identifier;
a second determining unit 134, configured to determine that the consensus result of the transaction block is a consensus failure result if a core node that does not belong to the valid core node list exists among the plurality of core nodes;
a voting signature verification unit 135, configured to, if all the core nodes belong to the legal core node list, obtain a public key of the core node according to the identifier of the core node, and verify a voting signature of a corresponding core node by using the public key of the core node;
the second determining unit 134 is further configured to determine that the consensus result of the transaction block is a consensus failure result if a core node with a voting signature verification failure exists among the plurality of core nodes;
the second determining unit 134 is further configured to determine that the consensus result of the transaction block is the consensus result if the voting signatures of the plurality of core nodes are all checked successfully.
Wherein, the first determining module 13 includes:
a counting unit 136, configured to determine, as target voting information, voting information that has been successfully voted among the voting information of the plurality of core nodes, and count the number of votes cast by the target voting information;
a third determining unit 137, configured to determine that the consensus result of the transaction block is a consensus failure result if the number of votes is smaller than a voting threshold;
the third determining unit 137 is further configured to determine that the consensus result of the transaction block is the consensus success result if the number of votes is greater than or equal to the voting threshold.
Wherein, the block head attribute parameters comprise the previous hash value of the transaction block and the block height of the transaction block;
the detection module 12 includes:
a second obtaining unit 121, configured to obtain the hash value and the block height of the transaction block;
a first searching unit 122, configured to determine a height of a previous block of the transaction block according to the block height, and search the previous block of the transaction block from the transaction book based on the height of the previous block;
a fourth determining unit 123, configured to determine, if the previous block is not found, that the block header attribute parameter is an illegal parameter;
the fourth determining unit 123 is further configured to, if the previous block is found, obtain a hash value of a block header of the previous block, and if the hash value of the block header of the previous block is different from the hash value of the previous block, determine that the attribute parameter of the block header is an illegal parameter;
the fourth determining unit 123 is further configured to determine that the header attribute parameter is the valid parameter if the header hash value of the previous block is the same as the previous hash value.
Wherein, the detecting module 12 includes:
a third obtaining unit 124, configured to obtain a block header attribute set, where the block header attribute set includes a plurality of block header attributes;
a second searching unit 125, configured to search a block header attribute parameter corresponding to each block header attribute from the block headers of the transaction blocks;
a fifth determining unit 126, configured to determine that the block header attribute parameter is an illegal parameter if a missing block header attribute exists in the plurality of block header attributes; the missing block header attribute does not have the corresponding block header attribute parameter in the block header.
Wherein the apparatus 90 further comprises:
a second obtaining module 16, configured to obtain transaction data in a block of the transaction block, and obtain a checking mercker root of the transaction block according to the transaction data;
the detection module 12 includes:
a fifth obtaining unit 127, configured to obtain a default mercker root in the block header attribute parameter of the transaction block;
a sixth determining unit 128, configured to determine that the block header attribute parameter is an illegal parameter if the default mercker root is different from the inspected mercker root;
the sixth determining unit 128 is further configured to determine the block header attribute parameter as the legal parameter if the default mercker root is the same as the verification mercker root.
Wherein, the transaction block further comprises a block generation signature;
the detection module 12 includes:
a sixth obtaining unit 129, configured to obtain the block generation signature of the transaction block and the public key of the generation core node of the transaction block;
a generation and verification unit 1210, configured to verify the signature generated by the block by using the public key of the generated core node;
a seventh determining unit 1211, configured to determine that the block header attribute parameter is an illegal parameter if the signature verification fails;
the seventh determining unit 1211 is further configured to determine the block header attribute parameter as a valid parameter if the verification passes.
Wherein the apparatus 90 further comprises:
a third determining module 17, configured to determine an abnormal core node from the plurality of core nodes if the consensus result is a consensus failure result, where the abnormal core node is a core node having abnormal voting information;
a deleting module 18, configured to delete the transaction block;
a broadcasting module 19, configured to broadcast a voting information exception message, where the voting information exception message includes the exception core node, so that the plurality of core nodes check the exception core node.
Wherein the apparatus 90 further comprises:
an analysis module 20, configured to obtain transaction data in the block of the transaction block and analyze the transaction data to obtain a transaction process if the block header attribute parameter is a legal parameter and the consensus result is a successful consensus result;
an execution module 21, configured to execute the transaction process to obtain an execution result of the transaction process;
a storage module 22, configured to store the execution result and the transaction block into the transaction ledger in an associated manner, and execute the step of adding the transaction block into the transaction ledger corresponding to the first node device through the adding module 14.
Wherein the apparatus 90 further comprises:
a third obtaining module 23, configured to obtain, based on a heartbeat mechanism, a generation message of the transaction block sent by a core network, where the core network includes the multiple core nodes;
the broadcast module 19 is further configured to broadcast a transaction block synchronization request to the plurality of core nodes in the core network, and execute a step of the first node device acquiring a transaction block sent by a second node device based on the transaction block synchronization request, where the second node device is a core node in the core network.
The embodiment of the application describes a block synchronization device, wherein a first node device obtains a transaction block sent by a second node device through the device, determines a consensus result of the transaction block according to voting information of a plurality of core nodes contained in a block header of the transaction block, detects the legality of a block header attribute parameter in the block header of the transaction block, and adds the transaction block to a transaction account book corresponding to the first node device when the consensus result is a successful consensus result and the block header attribute parameter is a legal parameter. Through the process, when the first node equipment synchronizes the transaction block from the second node equipment, the consistency of the block head and the block body of the transaction block is verified, and the voting condition of the transaction block is verified, so that the real effectiveness of the synchronized block is improved, and the accuracy of transaction data is improved.
Referring to fig. 10, fig. 10 is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 10, the computer device 1000 in the embodiment of the present application may include: one or more processors 1001, memory 1002, and input-output interface 1003. The processor 1001, the memory 1002, and the input/output interface 1003 are connected by a bus 1004. The memory 1002 is configured to store a computer program, where the computer program includes program instructions, and the input/output interface 1003 is configured to input data and output data, where the data interaction between the light nodes and the data nodes, the data interaction between the data nodes and the core nodes, the data interaction between the light nodes, the data interaction between the data nodes, and the data interaction between the core nodes; the processor 1001 is configured to execute program instructions stored in the memory 1002 to perform the following operations:
the method comprises the steps that a first node device obtains a transaction block sent by a second node device, and the block head of the transaction block comprises voting information and block head attribute parameters of a plurality of core nodes;
detecting the validity of the block header attribute parameters;
determining a consensus result of the trading block according to the voting information in the block header of the trading block;
and if the block head attribute parameter is a legal parameter and the consensus result is a successful consensus result, adding the transaction block into a transaction account book corresponding to the first node device.
In an embodiment, the voting information includes a voting block hash; the processor 1001 further performs the following steps:
determining the block head hash of the transaction block according to the block head attribute parameters;
the determining the consensus result of the transaction blocks according to the voting information in the block header of the transaction blocks comprises:
comparing the block head hash with a plurality of voting block hashes corresponding to the voting information;
if the plurality of pieces of voting information have illegal voting information, determining that the consensus result of the transaction block is a consensus failure result; the voting block hash corresponding to the illegal voting information is different from the block header hash;
if the plurality of pieces of voting information are all legal voting information, the consensus result of the transaction block is determined to be the consensus success result.
In one embodiment, the voting information in the block header of the transaction block further includes an identifier and a voting signature of a corresponding core node;
when the processor 1001 determines the consensus result of the transaction block according to the voting information in the block header of the transaction block, the following steps are specifically performed:
acquiring a legal core node list; the legal core node list comprises the identifiers of the plurality of core nodes and a public key corresponding to each identifier;
if a core node which does not belong to the legal core node list exists in the plurality of core nodes, determining that the consensus result of the transaction block is a consensus failure result;
if the plurality of core nodes all belong to the legal core node list, acquiring the public key of the core node according to the identifier of the core node, and adopting the public key of the core node to check the voting signature of the corresponding core node;
if a core node with voting signature check-out failure exists in the plurality of core nodes, determining that the consensus result of the transaction block is a consensus failure result;
and if the voting signatures of the plurality of core nodes are checked successfully, determining that the consensus result of the transaction block is the consensus result.
In an embodiment, when the processor 1001 determines the consensus result of the transaction blocks according to the voting information in the block header of the transaction block, the following steps are specifically performed:
determining voting information which votes successfully in the voting information of the plurality of core nodes as target voting information, and counting the voting number of the target voting information;
if the voting number is smaller than the voting threshold value, determining that the consensus result of the transaction block is a consensus failure result;
if the voting number is greater than or equal to the voting threshold, the consensus result of the transaction block is determined to be the consensus success result.
In one embodiment, the block header attribute parameters include a hash value of the transaction block and a block height of the transaction block;
when the processor 1001 performs the above-mentioned detection of the validity of the block header attribute parameter, the following steps are specifically performed:
acquiring the previous hash value and the block height of the transaction block;
determining the height of a previous block of the transaction block according to the height of the block, and searching the previous block of the transaction block from the transaction book based on the height of the previous block;
if the previous block is not found, determining the block head attribute parameter as an illegal parameter;
if the previous block is found, acquiring a block head hash value of the previous block, and if the block head hash value of the previous block is different from the previous hash value, determining the block head attribute parameter as an illegal parameter;
and if the block head hash value of the previous block is the same as the previous hash value, determining that the block head attribute parameter is the legal parameter.
In an embodiment, when the processor 1001 detects the validity of the block header attribute parameter, the following steps are specifically performed:
acquiring a block head attribute set, wherein the block head attribute set comprises a plurality of block head attributes;
searching a block head attribute parameter corresponding to each block head attribute from the block heads of the transaction blocks;
if the plurality of block head attributes have missing block head attributes, determining the block head attribute parameters as illegal parameters; the missing block header attribute does not have the corresponding block header attribute parameter in the block header.
In an embodiment, the processor 1001 further performs the following steps:
acquiring transaction data in a block body of the transaction block, and acquiring a checking Merck root of the transaction block according to the transaction data;
when the processor 1001 detects the validity of the block header attribute parameter, the following steps are specifically executed:
acquiring a default Merck root in the block head attribute parameters of the transaction block;
if the default merck root is different from the inspected merck root, determining the block header attribute parameter as an illegal parameter;
if the default merck root is the same as the inspected merck root, the block header attribute parameter is determined to be the legal parameter.
Wherein, in one embodiment, the transaction block further comprises a block generation signature;
when the processor 1001 detects the validity of the block header attribute parameter, the following steps are specifically performed:
acquiring the block generation signature of the transaction block and a public key of a generation core node of the transaction block;
adopting the public key of the generated core node to verify the signature generated by the block;
if the signature check fails, determining the block head attribute parameter as an illegal parameter;
and if the verification tag passes, determining the block head attribute parameter as a legal parameter.
In an embodiment, the processor 1001 further performs the following steps:
if the consensus result is a consensus failure result, determining an abnormal core node from the plurality of core nodes, wherein the abnormal core node is a core node with abnormal voting information;
deleting the transaction block, and broadcasting a voting information exception message, wherein the voting information exception message comprises the exception core node, so that the plurality of core nodes check the exception core node.
In an embodiment, the processor 1001 further performs the following steps:
if the block head attribute parameter is a legal parameter and the consensus result is a successful consensus result, acquiring transaction data in a block body of the transaction block, and analyzing the transaction data to obtain a transaction process;
executing the transaction process to obtain an execution result of the transaction process;
and associating the execution result with the transaction block, storing the execution result into the transaction book, and executing the step of adding the transaction block into the transaction book corresponding to the first node device.
In an embodiment, the processor 1001 further performs the following steps:
acquiring a generation message of the transaction block sent by a core network based on a heartbeat mechanism, wherein the core network comprises a plurality of core nodes;
broadcasting a transaction block synchronization request to the plurality of core nodes in the core network, and executing a step of acquiring a transaction block sent by a second node device by the first node device based on the transaction block synchronization request, wherein the second node device is a core node in the core network.
In some possible embodiments, the processor 1001 may be a Central Processing Unit (CPU), and the processor 1001 may also be other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, and so on. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The memory 1002 may include both read-only memory and random-access memory, and provides instructions and data to the processor 1001 and the input/output interface 1003. A portion of the memory 1002 may also include non-volatile random access memory. For example, the memory 1002 may also store device type information.
In a specific implementation, the computer device 1000 may execute the implementation manners provided in the steps in fig. 2 through the built-in functional modules thereof, which may specifically refer to the implementation manners provided in the steps in fig. 2, and details are not described herein again.
The embodiment of the present application provides a computer device, including: the processor, the input/output interface and the memory, which are used for obtaining the computer instructions in the memory through the processor and executing the steps of the method shown in the above fig. 2, so as to perform the block synchronization operation. With computer instructions in the memory, the processor performs the steps of: the first node device determines a consensus result of the transaction block according to voting information of a plurality of core nodes contained in a block head of the transaction block by acquiring the transaction block sent by the second node device, detects the legality of a block head attribute parameter in the block head of the transaction block, and adds the transaction block into a transaction book corresponding to the first node device when the consensus result is a consensus success result and the block head attribute parameter is a legal parameter. Through the process, when the first node equipment synchronizes the transaction block from the second node equipment, the consistency of the block head and the block body of the transaction block is verified, and the voting condition of the transaction block is verified, so that the real effectiveness of the synchronized block is improved, and the accuracy of transaction data is improved.
An embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, where the computer program includes program instructions, and when the program instructions are executed by a processor, the block synchronization method provided in each step in fig. 2 is implemented, which may specifically refer to the implementation manner provided in each step in fig. 2, and is not described herein again.
The computer-readable storage medium may be the block synchronization apparatus provided in any of the foregoing embodiments or an internal storage unit of the computer device, such as a hard disk or a memory of the computer device. The computer readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a Smart Memory Card (SMC), a Secure Digital (SD) card, a flash card (flash card), and the like, provided on the computer device. Further, the computer-readable storage medium may also include both an internal storage unit and an external storage device of the computer device. The computer-readable storage medium is used for storing the computer program and other programs and data required by the computer device. The computer readable storage medium may also be used to temporarily store data that has been output or is to be output.
The terms "first," "second," and the like in the description and in the claims and drawings of the embodiments of the present application are used for distinguishing between different objects and not for describing a particular order. Furthermore, the terms "comprises" and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, apparatus, product, or apparatus that comprises a list of steps or elements is not limited to the listed steps or modules, but may alternatively include other steps or modules not listed or inherent to such process, method, apparatus, product, or apparatus.
Those of ordinary skill in the art will appreciate that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be embodied in electronic hardware, computer software, or combinations of both, and that the components and steps of the examples have been described in a functional general in the foregoing description for the purpose of illustrating clearly the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
The method and the related apparatus provided by the embodiments of the present application are described with reference to the flowchart and/or the structural diagram of the method provided by the embodiments of the present application, and each flow and/or block of the flowchart and/or the structural diagram of the method, and the combination of the flow and/or block in the flowchart and/or the block diagram can be specifically implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block or blocks of the block diagram. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block or blocks of the block diagram. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block or blocks.
The above disclosure is only for the purpose of illustrating the preferred embodiments of the present application and is not to be construed as limiting the scope of the present application, so that the present application is not limited thereto, and all equivalent variations and modifications can be made to the present application.

Claims (15)

1. A method for block synchronization, the method comprising:
the method comprises the steps that a first node device obtains a transaction block sent by a second node device, and the block head of the transaction block comprises voting information and block head attribute parameters of a plurality of core nodes;
detecting the validity of the block header attribute parameters;
determining a consensus result of the trading block according to the voting information in the block header of the trading block;
and if the block head attribute parameter is a legal parameter and the consensus result is a successful consensus result, adding the transaction block into a transaction account book corresponding to the first node device.
2. The method of claim 1, wherein the voting information comprises a voting block hash; the method further comprises the following steps:
determining the block head hash of the transaction block according to the block head attribute parameter;
the determining the consensus result of the transaction block according to the voting information in the block header of the transaction block comprises:
comparing the block head hash with a plurality of voting block hashes corresponding to the voting information;
if illegal voting information exists in the plurality of pieces of voting information, determining that the consensus result of the transaction block is a consensus failure result; the voting block hash corresponding to the illegal voting information is different from the block header hash;
and if the plurality of pieces of voting information are all legal voting information, determining that the consensus result of the transaction block is the consensus success result.
3. The method of claim 1, wherein the voting information in the block header of the transaction block further comprises an identification of a corresponding core node and a voting signature;
the determining the consensus result of the transaction block according to the voting information in the block header of the transaction block comprises:
acquiring a legal core node list; the legal core node list comprises the identifiers of the plurality of core nodes and a public key corresponding to each identifier;
if the core node which does not belong to the legal core node list exists in the plurality of core nodes, determining that the consensus result of the transaction block is a consensus failure result;
if the plurality of core nodes all belong to the legal core node list, acquiring the public key of the core node according to the identifier of the core node, and adopting the public key of the core node to check the voting signature of the corresponding core node;
if a core node with voting signature check-out failure exists in the plurality of core nodes, determining that the consensus result of the transaction block is a consensus failure result;
and if the voting signatures of the plurality of core nodes are checked successfully, determining that the consensus result of the transaction block is the consensus successful result.
4. The method of claim 1, wherein determining consensus results for the transaction block based on the voting information in a block header of the transaction block comprises:
determining voting information which votes successfully in the voting information of the plurality of core nodes as target voting information, and counting the voting number of the target voting information;
if the voting number is smaller than the voting threshold value, determining that the consensus result of the transaction block is a consensus failure result;
if the voting number is larger than or equal to the voting threshold, determining that the consensus result of the transaction block is the consensus success result.
5. The method of claim 1, wherein the block header attribute parameters include a subsequent hash value of the transaction block and a block height of the transaction block;
the detecting the validity of the block header attribute parameter includes:
acquiring the previous hash value and the block height of the transaction block;
determining a subsequent block height of the transaction block according to the block height, and searching the subsequent block of the transaction block from the transaction book based on the subsequent block height;
if the previous block is not found, determining the block head attribute parameter as an illegal parameter;
if the previous block is found, acquiring a block head hash value of the previous block, and if the block head hash value of the previous block is different from the previous hash value, determining that the block head attribute parameter is an illegal parameter;
and if the block head hash value of the previous block is the same as the previous hash value, determining the block head attribute parameter as the legal parameter.
6. The method of claim 1, wherein said detecting the validity of the block header attribute parameter comprises:
acquiring a block head attribute set, wherein the block head attribute set comprises a plurality of block head attributes;
searching a block head attribute parameter corresponding to each block head attribute from the block heads of the transaction blocks;
if the plurality of block head attributes have missing block head attributes, determining the block head attribute parameters as illegal parameters; the missing block header attribute has no corresponding block header attribute parameter in the block header.
7. The method of claim 1, wherein the method further comprises:
acquiring transaction data in a block body of the transaction block, and acquiring a checking Merck root of the transaction block according to the transaction data;
the detecting the validity of the block header attribute parameter includes:
acquiring a default Merck root in a block head attribute parameter of the transaction block;
if the default Merck root is not the same as the inspected Merck root, determining the block head attribute parameter as an illegal parameter;
if the default Merck root is the same as the verification Merck root, determining the block header attribute parameter as the legal parameter.
8. The method of claim 1, wherein the transaction block further comprises a block generation signature;
the detecting the validity of the block header attribute parameter includes:
acquiring the block generation signature of the transaction block and a public key of a generation core node of the transaction block;
adopting the public key of the generated core node to verify the signature generated by the block;
if the signature check fails, determining the block header attribute parameter as an illegal parameter;
and if the signature verification passes, determining the block header attribute parameter as a legal parameter.
9. The method of claim 1, wherein the method further comprises:
if the consensus result is a consensus failure result, determining an abnormal core node in the plurality of core nodes, wherein the abnormal core node is a core node with abnormal voting information;
deleting the transaction block, and broadcasting a voting information exception message, wherein the voting information exception message comprises the exception core node, so that the plurality of core nodes check the exception core node.
10. The method of claim 1, wherein the method further comprises:
if the block head attribute parameter is a legal parameter and the consensus result is a successful consensus result, acquiring transaction data in the block body of the transaction block, and analyzing the transaction data to obtain a transaction process;
executing the transaction process to obtain an execution result of the transaction process;
and storing the execution result and the transaction block into the transaction book in an associated manner, and executing the step of adding the transaction block into the transaction book corresponding to the first node device.
11. The method of claim 1, wherein the method further comprises:
acquiring a generation message of the transaction block sent by a core network based on a heartbeat mechanism, wherein the core network comprises a plurality of core nodes;
broadcasting a transaction block synchronization request to the plurality of core nodes in the core network, and executing a step of acquiring a transaction block sent by a second node device by the first node device based on the transaction block synchronization request, wherein the second node device is a core node in the core network.
12. A block synchronization apparatus, comprising:
the system comprises an acquisition module, a processing module and a processing module, wherein the acquisition module is used for acquiring a transaction block sent by second node equipment by first node equipment, and a block head of the transaction block comprises voting information and block head attribute parameters of a plurality of core nodes;
the detection module is used for detecting the validity of the block head attribute parameters;
the first determining module is used for determining a consensus result of the transaction blocks according to the voting information in the block headers of the transaction blocks;
and the adding module is used for adding the transaction block into a transaction account book corresponding to the first node device if the block head attribute parameter is a legal parameter and the consensus result is a successful consensus result.
13. The apparatus of claim 12, wherein the voting information comprises a voting block hash; the device further comprises:
a second determining module, configured to determine a block header hash of the transaction block according to the block header attribute parameter;
the first determining module includes:
a comparison unit, configured to compare the chunk hash with voting chunk hashes corresponding to a plurality of pieces of voting information;
a first determining unit, configured to determine that the consensus result of the transaction block is a consensus failure result if there is illegal voting information in the voting information; the voting block hash corresponding to the illegal voting information is different from the block header hash;
the first determining unit is further configured to determine that the consensus result of the transaction block is the consensus success result if the plurality of pieces of voting information are all legal voting information.
14. A computer device comprising a processor, a memory, an input output interface;
the processor is connected to the memory and the input/output interface, respectively, wherein the input/output interface is used for inputting and outputting data, the memory is used for storing program codes, and the processor is used for calling the program codes to execute the method according to any one of claims 1-11.
15. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program comprising program instructions which, when executed by a processor, perform the method according to any one of claims 1-11.
CN202010006922.9A 2020-01-03 2020-01-03 Block synchronization method, device, computer and storage medium Active CN111209339B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010006922.9A CN111209339B (en) 2020-01-03 2020-01-03 Block synchronization method, device, computer and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010006922.9A CN111209339B (en) 2020-01-03 2020-01-03 Block synchronization method, device, computer and storage medium

Publications (2)

Publication Number Publication Date
CN111209339A true CN111209339A (en) 2020-05-29
CN111209339B CN111209339B (en) 2021-09-14

Family

ID=70784132

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010006922.9A Active CN111209339B (en) 2020-01-03 2020-01-03 Block synchronization method, device, computer and storage medium

Country Status (1)

Country Link
CN (1) CN111209339B (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022134951A1 (en) * 2020-12-24 2022-06-30 腾讯科技（深圳）有限公司 Data synchronization method and apparatus, and device and computer-readable storage medium
CN115280717A (en) * 2021-01-11 2022-11-01 微福斯有限责任公司 Block chain auditing system and method
WO2023020442A1 (en) * 2021-08-18 2023-02-23 华为技术有限公司 Blockchain generation method and apparatus

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106411503A (en) * 2016-11-28 2017-02-15 中国银行股份有限公司 Accounting method, accounting system, voting node and accounting node under block chain voting and accounting mode
CN108023896A (en) * 2017-12-28 2018-05-11 江苏通付盾科技有限公司 Block synchronous method and system
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
CN108846942A (en) * 2018-06-29 2018-11-20 青岛大学 Electronic voting method and system based on ether mill block chain
CN109189853A (en) * 2018-08-08 2019-01-11 众安信息技术服务有限公司 Method of data synchronization and device between a kind of block chain
CN109213901A (en) * 2018-09-18 2019-01-15 百度在线网络技术（北京）有限公司 A kind of method of data synchronization, device, equipment and the medium of block chain
WO2019113495A1 (en) * 2017-12-08 2019-06-13 Solana Labs, Inc. Systems and methods for cryptographic provision of synchronized clocks in distributed systems
CN109978516A (en) * 2019-03-06 2019-07-05 西安电子科技大学 The manufacture of block and synchronous method, information data processing terminal in block chain network
CN110471931A (en) * 2019-08-13 2019-11-19 山大地纬软件股份有限公司 A kind of digital asset trade identity maintaining method based on transaction in assets chain
CN110602148A (en) * 2019-10-10 2019-12-20 深圳前海微众银行股份有限公司 Method and device for generating state tree of block and verifying data on chain

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106411503A (en) * 2016-11-28 2017-02-15 中国银行股份有限公司 Accounting method, accounting system, voting node and accounting node under block chain voting and accounting mode
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
WO2019113495A1 (en) * 2017-12-08 2019-06-13 Solana Labs, Inc. Systems and methods for cryptographic provision of synchronized clocks in distributed systems
CN108023896A (en) * 2017-12-28 2018-05-11 江苏通付盾科技有限公司 Block synchronous method and system
CN108846942A (en) * 2018-06-29 2018-11-20 青岛大学 Electronic voting method and system based on ether mill block chain
CN109189853A (en) * 2018-08-08 2019-01-11 众安信息技术服务有限公司 Method of data synchronization and device between a kind of block chain
CN109213901A (en) * 2018-09-18 2019-01-15 百度在线网络技术（北京）有限公司 A kind of method of data synchronization, device, equipment and the medium of block chain
CN109978516A (en) * 2019-03-06 2019-07-05 西安电子科技大学 The manufacture of block and synchronous method, information data processing terminal in block chain network
CN110471931A (en) * 2019-08-13 2019-11-19 山大地纬软件股份有限公司 A kind of digital asset trade identity maintaining method based on transaction in assets chain
CN110602148A (en) * 2019-10-10 2019-12-20 深圳前海微众银行股份有限公司 Method and device for generating state tree of block and verifying data on chain

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
毛宁等: "基于电商平台的区块链状态同步问题研究", 《研究与开发》 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022134951A1 (en) * 2020-12-24 2022-06-30 腾讯科技（深圳）有限公司 Data synchronization method and apparatus, and device and computer-readable storage medium
CN115280717A (en) * 2021-01-11 2022-11-01 微福斯有限责任公司 Block chain auditing system and method
WO2023020442A1 (en) * 2021-08-18 2023-02-23 华为技术有限公司 Blockchain generation method and apparatus

Also Published As

Publication number Publication date
CN111209339B (en) 2021-09-14

Similar Documents

Publication Publication Date Title
US11550935B2 (en) Method, apparatus, and electronic device for blockchain-based recordkeeping
JP6882474B2 (en) Systems and methods for detecting replay attacks
US10958438B2 (en) Method, apparatus, and electronic device for blockchain-based recordkeeping
CN111209339B (en) Block synchronization method, device, computer and storage medium
KR101962686B1 (en) System and method for electronic voting
CN109543065B (en) Video active identification method combined with block chain
CN110826111B (en) Test supervision method, device, equipment and storage medium
CN110958319B (en) Method and device for managing infringement and evidence-based block chain
CN109598505B (en) Quality data processing method and device based on block chain
CN111143883B (en) Digital content evidence obtaining method, device and equipment based on block chain
US11366932B2 (en) Consensus method and data verification method, apparatus, and system of consortium blockchain
CN113326165B (en) Data processing method and device based on block chain and computer readable storage medium
CN111556115B (en) Block chain-based data processing method, device, equipment and storage medium
CN110599180A (en) Block chain-based vaccine circulation management method and device
US20220237326A1 (en) System and method for certifying integrity of data assets
US20220239668A1 (en) Blockchain-based message processing method and apparatus, device, and storage medium
CN110659967B (en) House management method and device based on block chain
CN109284331B (en) Certificate making information acquisition method based on service data resources, terminal equipment and medium
CN111475778A (en) Music data processing method and device based on block chain
CN112069529A (en) Block chain-based volume management method and device, computer and storage medium
CN111507840B (en) Block chain consensus method, apparatus, computer and readable storage medium
US20230009460A1 (en) Trail recording system and data verification method
CN109509095B (en) Video active identification method combined with block chain
CN112835854A (en) File storage method and device, electronic equipment and storage medium
CN113468201B (en) Cross-channel data linkage updating system based on resource element evidence storage channel

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant