CN115860742A - Data synchronization method, node, storage medium and equipment for light node in block chain - Google Patents
Data synchronization method, node, storage medium and equipment for light node in block chain Download PDFInfo
- Publication number
- CN115860742A CN115860742A CN202310167843.XA CN202310167843A CN115860742A CN 115860742 A CN115860742 A CN 115860742A CN 202310167843 A CN202310167843 A CN 202310167843A CN 115860742 A CN115860742 A CN 115860742A
- Authority
- CN
- China
- Prior art keywords
- mmr
- block
- root
- transaction
- head
- 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
Links
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application discloses a data synchronization method, nodes, storage media and equipment for light nodes in a block chain, and belongs to the technical field of block chains. The method comprises the following steps: when a light node with the block height of n-1 synchronizes data of an nth block, block information and an MMR head of the nth block are obtained from all nodes, wherein the MMR head comprises a transaction root of the current block and an MMR root of a previous block, the transaction root is obtained by performing hash calculation according to all transactions, and the MMR root is obtained by performing calculation on an MMR certificate according to a Mercury mountain algorithm; acquiring the MMR root of the (n-1) th block stored locally; verifying according to the MMR root of the (n-1) th block, the block information of the nth block and the MMR root; when the verification passes, the MMR header and the MMR certificate of the nth block are synchronized to the local. The application can reduce the storage pressure of the light nodes and can also ensure the safety in the synchronization process.
Description
Technical Field
The embodiment of the application relates to the technical field of block chains, in particular to a data synchronization method, nodes, a storage medium and equipment for light nodes in a block chain.
Background
The block chain data is chain type account book data, and the state of the account on the chain is generated by the result after the account book data (transaction data) is executed, so that the chain data comprises the block data (block information and transaction information) and the state data (result after the transaction is executed), and the account book data can continuously expand along with the accumulation of time. Meanwhile, since the state of the block chain is the result of accumulation performed by each transaction in each block from the creation block, the latest state needs to be verified based on the complete ledger data, which requires that many running full nodes need to store the full amount of ledger data, which is a large storage pressure for light nodes that only need to perform query operations.
Disclosure of Invention
The embodiment of the application provides a data synchronization method, a node, a storage medium and equipment for a light node in a block chain, which are used for solving the problem that the storage pressure of the light node is continuously increased due to continuous expansion of the state of the block chain. The technical scheme is as follows:
in one aspect, a method for synchronizing data of a light node in a block chain is provided, where the method includes:
when a light node with the block height of n-1 needs to synchronize data of an nth block, acquiring block information of the nth block and an MMR (Merkel mountain MMR) head from all nodes in a block chain, wherein the MMR head comprises a transaction root of a current block and an MMR root of a previous block, the transaction root is obtained by calculating all transaction hashes in the current block, the MMR root is obtained by calculating an MMR certificate of the current block according to an MMR algorithm, the MMR certificate comprises hashes of MMR heads located at preset positions in a binary tree after the MMR heads of all blocks are arranged in the binary tree, and n is more than or equal to 1;
acquiring the MMR root of the (n-1) th block stored locally;
verifying according to the MMR root of the (n-1) th block, the block information of the nth block and the MMR root;
and when the verification is passed, synchronizing the MMR header and the MMR certificate of the nth block to the local.
In a possible implementation manner, the verifying according to the MMR root of the n-1 th block, the block information of the nth block, and the MMR root includes:
acquiring all transaction hashes from the block information of the nth block, calculating a transaction root according to all transaction hashes, and verifying whether the transaction root obtained by calculation is consistent with the transaction root in the MMR head of the nth block;
and verifying whether the MMR root in the MMR header of the nth block is consistent with the MMR root of the (n-1) th block stored locally.
In one possible implementation, the method further includes:
when the block height m of the light node is not continuous with the block height m of the block needing synchronization, block information, an MMR (media mass register) head and an MMR (media mass register) certificate of the mth block are obtained from all nodes in the block chain, wherein m is more than or equal to 1;
verifying according to the block information, the MMR header and the MMR certificate of the mth block;
and when the verification is passed, synchronizing the MMR header and the MMR certificate of the mth block to the local.
In a possible implementation manner, the verifying according to the block information of the mth block, the MMR header, and the MMR certificate includes:
acquiring all transaction hashes from the block information of the mth block, calculating a transaction root according to all transaction hashes, and verifying whether the calculated transaction root is consistent with the transaction root in the MMR head of the mth block;
and calculating the MMR certificate according to an MMR algorithm, and verifying whether the calculated MMR root is consistent with the MMR root in the MMR head of the mth block.
In one possible implementation, the method further includes:
receiving a query request carrying an object identifier, wherein the object identifier is a transaction identifier or a block identifier;
inquiring object information from all nodes in the block chain according to the object identification;
verifying the object information;
and after the verification is passed, synchronizing the object information to the local.
In a possible implementation manner, when the object identifier is a transaction identifier, the object information includes transaction information, a mercker certificate of a transaction tree, an MMR header of a block to which the transaction belongs, and an MMR certificate, and then the verifying the object information includes:
verifying whether the MMR head in the object information is consistent with a locally stored MMR head;
calculating transaction hash according to the transaction information, and verifying whether the calculated transaction hash is consistent with the transaction hash obtained according to the Mercker certification;
acquiring all transaction hashes of the block to which the transaction belongs according to the Mercker certificate, calculating a transaction root according to all transaction hashes, and verifying whether the calculated transaction root is consistent with the transaction root in the MMR head;
and calculating the MMR proof according to an MMR algorithm, and verifying whether the calculated MMR root is consistent with the MMR root in the MMR head.
In a possible implementation manner, when the object identifier is a block identifier, and the object information includes block information, an MMR header, and an MMR certificate, the verifying the object information includes:
verifying whether the MMR head in the object information is consistent with a locally stored MMR head;
calculating the block hash according to the block information, and verifying whether the calculated block hash is consistent with the block hash in the MMR head;
acquiring all transaction hashes in the block information, calculating a transaction root according to all transaction hashes, and verifying whether the calculated transaction root is consistent with a transaction root in the MMR head;
and calculating the MMR proof according to an MMR algorithm, and verifying whether the calculated MMR root is consistent with the MMR root in the MMR head.
In one aspect, a light node in a blockchain is provided, the light node comprising:
an obtaining module, configured to obtain, when a light node with a block height of n-1 needs to synchronize data of an nth block, block information of the nth block and an MMR header of a merck mountain from a full node in a block chain, where the MMR header includes a transaction root of a current block and an MMR root of a previous block, the transaction root is obtained through hash calculation according to all transactions in the current block, the MMR root is obtained through calculation of an MMR certificate of the current block according to an MMR algorithm, the MMR certificate includes hashes of MMR headers located at predetermined positions in a binary tree after the MMR headers of all blocks are arranged in the binary tree, and n is greater than or equal to 1;
the acquisition module is further configured to acquire an MMR root of an n-1 th block stored locally;
the verification module is used for verifying according to the MMR root of the (n-1) th block, the block information of the nth block and the MMR root;
and the synchronization module is used for synchronizing the MMR head and the MMR certificate of the nth block to the local when the verification is passed.
In one aspect, a computer-readable storage medium is provided, in which at least one instruction is stored, and the at least one instruction is loaded and executed by a processor to implement the data synchronization method for a light node in a block chain as described above.
In one aspect, a computer device is provided, which includes a processor and a memory, where at least one instruction is stored in the memory, and the instruction is loaded and executed by the processor to implement the data synchronization method for a light node in a block chain as described above.
The technical scheme provided by the embodiment of the application has the beneficial effects that at least:
the light node only needs to synchronize the MMR header and the MMR of one block, so that the storage pressure of the light node can be reduced compared with the condition that the full amount of block headers need to be stored. Moreover, the light node can check the block information and the MMR header, and the safety of the light node in the synchronization process is not sacrificed.
The light nodes can be synchronized from the latest block, and the storage pressure of the nodes can be reduced compared to the block header requiring synchronization of all blocks from the beginning.
The light node can perform existence certification aiming at the transaction and the block, and the transaction information and the block information inquired by the light node can be guaranteed to be real and reliable.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
FIG. 1 is a schematic diagram of a chained data structure provided by an embodiment of the present application;
fig. 2 is a flowchart of a method of a data synchronization method of a light node according to an embodiment of the present application;
fig. 3 is a schematic connection diagram of a light node and a trusted node of a device according to an embodiment of the present application;
FIG. 4 is a schematic diagram illustrating connection of a light node of the apparatus with a consensus node and a read-only node according to an embodiment of the present application;
fig. 5 is a flowchart of a method for data synchronization of a light node in a blockchain according to an embodiment of the present application;
FIG. 6 is a flow chart of a method of presence attestation provided by an embodiment of the present application;
FIG. 7 is a block diagram of a light node in a blockchain as provided by one embodiment of the present application;
fig. 8 is a block diagram of a light node in a blockchain according to an embodiment of the present application.
Detailed Description
To make the objects, technical solutions and advantages of the embodiments of the present application more clear, the embodiments of the present application will be further described in detail with reference to the accompanying drawings.
In this embodiment, a chained data structure is generated for all blocks in a block chain, where each block corresponds to an MMR (Merkle Mountain) header in the data structure. Referring to fig. 1, the MMR header MMR _ header includes a block hash block _ hash, a transaction root transacton _ root, a state root state _ root, and an MMR root pre _ MMR _ root of a previous block. The calculation processes of these four data are explained below.
(1) Block Hash _ hash
The block hash block _ hash is obtained by calculating block information by using a hash algorithm. That is, block _ HASH = HASH (block _ bytes), where block _ bytes represents block information and HASH () represents a HASH algorithm.
(2) Transaction root
The transaction root is calculated from all transaction hashes in the current block. In other words, the transaction root is the root of the merck tree of all transaction hashes within the current tile. That is, transaction _ root = MERKLE _ TREE (tx _ hash1, tx _ hash 2.. Wherein tx _ hash represents a transaction hash).
(3) State root _ root
The state root state _ root is a root result obtained by sequentially executing all transactions on the block chain according to the block sequence and the sequence in the blocks to obtain key-value pairs (key-values) and solving all the key-value pairs according to a Merkle Patricia Tries algorithm. That is, state _ root = MERKLE _ pattern _ TRIES (kv 1, kv2, kv 3.), wherein kv represents a key-value pair.
(4) MMR root MMR _ root
The MMR root MMR _ root is obtained by calculating an MMR proof MMR _ proof of the block according to an MMR algorithm, wherein the MMR proof MMR _ proof comprises the Hash of the MMR head MMR _ header positioned at a preset position in a binary tree after the MMR head MMR _ header of all the blocks is arranged in the binary tree. That is, MMR _ root = MMR (MMR _ header _ hash1, MMR _ header _ hash 2.), where MMR _ header _ hash represents MMR header hash.
The predetermined position may be a perk position, assuming position =2 P0 +2 P1 +…+2 Pk P0 > P1 > … > Pk, position is the position of the current block in MMR _ TREE, and perk position is
。
Referring to fig. 2, a data synchronization method of the light node is described below.
Wherein m is more than or equal to 1.
When data synchronization is performed for the first time after the light node is online, the block height of the light node is not continuous with the block height of a block needing synchronization. The on-line can be a first on-line or a second on-line after off-line.
After the light node 301 comes on line, the trusted node 302 may be connected to obtain the consensus address and node list of the current newest block height, as shown in fig. 3. Here, the light node 301 is a storage sensitive node, and the trusted node 302 is a full node that includes a full amount of block information and at least latest status data, and the full node includes both a consensus node and a non-consensus node.
Referring to fig. 4, after acquiring the consensus address and the node list with the highest current latest block, the light node 401 may synchronize data from other nodes. Specifically, the light node 401 tries to establish a connection with all nodes on the node list, the light node 401 may be connected to the consensus node 402 or the read-only node 403, and the consensus node 402 or the read-only node 403 may both respond to the synchronization request of the light node 401 and feed back the block information block of the mth block, the MMR header MMR _ header, and the MMR certificate MMR _ proof to the light node 401.
It should be noted that, according to the property of Byzantine Fault Tolerance (BFT) consensus, the additional consensus information signature information is recorded in the block, so that it can be ensured that the address signature meeting the requirement of Byzantine Fault Tolerance consensus exists in the block received by the light node, and the signature number meets 2f + 1.
In this embodiment, the light node needs to perform verification twice.
(1) The first verification is: and the light node acquires all transaction hashes from the block information of the mth block, calculates a transaction root according to all transaction hashes, and verifies whether the calculated transaction root is consistent with the transaction root in the MMR head of the mth block. That is, MMR _ root = = MMR _ pro _ VERIFY (MMR _ PROOF). If the transaction root obtained by calculation is consistent with the transaction root in the MMR head of the mth block, the first verification is considered to be passed; and if the transaction root obtained by calculation is inconsistent with the transaction root in the MMR head of the mth block, the first verification is not passed.
(2) The second verification is: and the light node calculates the MMR certificate according to the MMR algorithm and verifies whether the MMR root obtained by calculation is consistent with the MMR root in the MMR head of the mth block. That is, transaction _ root = = MERKLE _ TREE (tx _ hash1, tx _ hash 2.). If the MMR root obtained by calculation is consistent with the MMR root in the MMR head of the mth block, the second verification is considered to be passed; and if the MMR root obtained by calculation is inconsistent with the MMR root in the MMR head of the mth block, the second verification is not passed.
Only if the two verifications are passed, the light node considers that the verification is passed, and step 203 is executed; otherwise, the light node considers that the verification is not passed and needs to perform data synchronization again.
And step 203, synchronizing the MMR head and the MMR certificate of the mth block to the local when the verification is passed.
The light node stores the MMR header and the MMR proof MMR _ proof of the mth block, then the light node can continue to perform data synchronization of the subsequent blocks on the basis of the mth block, and in the process, the block information and the transaction information are not stored in the light node.
In the byzantine fault-tolerant algorithm, if the common identification check cannot pass through a certain block height due to the change of the common identification node, the light node needs to resynchronize the latest common identification node list information at the block height to the full node so as to ensure that the common identification check is correct.
It should be noted that, in this embodiment, the data synchronization refers to synchronizing the MMR _ header and MMR _ proof of a block, and does not refer to synchronizing the block header of the block, which is not described herein again.
Referring to fig. 5, a flowchart of a method for data synchronization of a light node in a block chain according to an embodiment of the present application is shown, which may be applied to a system including the node synchronization system shown in fig. 1. The data synchronization method for the light node in the block chain may include:
The MMR head comprises a transaction root of a current block and an MMR root of a previous block, the transaction root is obtained by calculating all transaction hashes in the current block, the MMR root is obtained by calculating an MMR certificate of the current block according to an MMR algorithm, the MMR certificate comprises hashes of MMR heads located at preset positions in a binary tree after the MMR heads of all the blocks are arranged in the binary tree, and n is larger than or equal to 1.
When the light node with the block height of n-1 needs to synchronize the data of the nth block, the light node is indicated to be synchronized with the data of the (n-1) th block, and then the data of the nth block is synchronized on the basis.
Specifically, the light node sends a synchronization request to the whole node, and the whole node feeds back the block information block of the nth block and the MMR header MMR _ header to the light node.
It should be noted that, according to the property of the byzantine fault-tolerant (BFT) consensus, the additional consensus information signature information is recorded in the block, so that it can be ensured that the address signature meeting the byzantine fault-tolerant consensus requirement is received in the block by the light node, and the number of signatures meets 2f + 1.
The light node reads the MMR root from the locally stored MMR header of the (n-1) th chunk.
In this embodiment, the light node needs to perform verification twice.
(1) The first verification is: and the light node acquires all transaction hashes from the block information of the nth block, calculates a transaction root according to all transaction hashes, and verifies whether the calculated transaction root is consistent with the transaction root in the MMR head of the nth block. That is, transaction _ root = = MERKLE _ TREE (tx _ hash1, tx _ hash 2.). If the transaction root obtained by calculation is consistent with the transaction root in the MMR head of the nth block, the first verification is considered to be passed; and if the calculated transaction root is not consistent with the transaction root in the MMR head of the nth block, the first verification is not passed.
(2) The second verification is: the light node verifies whether the MMR root in the MMR header of the nth block is consistent with the MMR root of the locally stored nth-1 block. That is, current _ MMR _ header.pre _ MMR _ root = = light _ node _ MMR _ root, that is, whether the MMR root MMR _ root of the n-1 th block in the light node and the MMR head pre _ MMR _ root in the MMR head of the n-th block coincide. If the MMR root obtained by calculation is consistent with the MMR root in the MMR head of the (n-1) th block, the second verification is considered to be passed; and if the MMR root obtained by calculation is not consistent with the MMR root in the MMR head of the (n-1) th block, the second verification is not passed.
Only if the two verifications are passed, the light node considers that the verification is passed, and step 504 is executed; otherwise, the light node considers that the verification is not passed and needs to perform data synchronization again.
And step 504, synchronizing the MMR header and the MMR certificate of the nth block to the local when the verification is passed.
The light node stores the MMR head MMR _ header and the MMR proof MMR _ proof of the nth block, then the light node can continue to carry out data synchronization of subsequent blocks on the basis of the nth block, and in the process, block information and transaction information cannot be stored in the light node.
In the byzantine fault-tolerant algorithm, if the common identification check cannot pass through a certain block height due to the change of the common identification node, the light node needs to resynchronize the latest common identification node list information at the block height to the full node so as to ensure that the common identification check is correct.
In summary, according to the data synchronization method for the light node in the block chain provided in the embodiment of the present application, the light node only needs to synchronize the MMR header and the MMR header of one block, which proves that compared with the case of storing the full number of block headers, the storage pressure of the light node can be reduced. Moreover, the light node can check the block information and the MMR header, and the safety of the light node in the synchronization process is not sacrificed.
The light nodes can be synchronized from the latest block, and the storage pressure of the nodes can be reduced compared to the block header requiring synchronization of all blocks from the beginning.
Referring to fig. 6, the present embodiment provides a method for existence verification, after existence verification, the synchronized blocks or transactions are regarded as hot data to be stored permanently in the light node for later query.
When the transaction needs to be inquired, the object identifier carried in the inquiry request is the transaction identifier; when the block needs to be queried, the object identifier carried in the query request is the block identifier.
When the object identification is the transaction identification, the object information comprises transaction information, a Mercker certification of a transaction tree, an MMR (media Merrier) header of a block to which the transaction belongs and an MMR certification; when the object identification is a tile identification, the object information includes tile information, an MMR header, and an MMR manifest.
When the object information includes transaction information, a mercker certificate of a transaction tree, an MMR header of a block to which a transaction belongs, and an MMR certificate, verifying the object information may include four times of verification:
(1) And verifying whether the MMR header in the object information is consistent with the locally stored MMR header. That is, mmr _ header = = mrr _ header that the light node has stored. If the MMR head in the object information is consistent with the MMR head stored locally, the first verification is considered to pass; and if the MMR head in the object information is inconsistent with the locally stored MMR head, the first verification is not passed.
(2) And calculating the transaction hash according to the transaction information, and verifying whether the calculated transaction hash is consistent with the transaction hash obtained according to the Mercker certification. That is, HASH (transaction information) = = transaction _ HASH. If the calculated transaction hash is consistent with the transaction hash obtained according to the Mercker certification, the second verification is considered to be passed; and if the calculated transaction hash is inconsistent with the transaction hash obtained according to the Mercker certification, the second verification is not passed.
(3) And acquiring all transaction hashes of the block to which the transaction belongs according to the Mercker certification, calculating a transaction root according to all the transaction hashes, and verifying whether the calculated transaction root is consistent with the transaction root in the MMR head. That is, MERKLE _ TREE (all transaction information within a block) = = transaction _ root. If the transaction root obtained by calculation is consistent with the transaction root in the MMR head, the third verification is considered to be passed; and if the calculated transaction root is inconsistent with the transaction root in the MMR header, the third verification is not passed.
(4) And calculating the MMR proof according to the MMR algorithm, and verifying whether the MMR root obtained by calculation is consistent with the MMR root in the MMR head. That is, MMR _ root = = MMR _ pro _ VERIFY (MMR _ PROOF). If the MMR root obtained by calculation is consistent with the MMR root in the MMR head, the fourth verification is considered to be passed; and if the calculated MMR root is not consistent with the MMR root in the MMR head, the fourth verification is not passed.
If the four verifications are passed, the light node considers that the verification is passed, and step 604 is executed; otherwise, the light node may consider the verification failed and need to re-perform the transaction presence attestation.
When the object information includes the tile information, the MMR header, and the MMR certificate, verifying the object information may include four times of verification:
(1) And verifying whether the MMR header in the object information is consistent with the locally stored MMR header. That is, mmr _ header = = mrr _ header that the light node has stored. If the MMR head in the object information is consistent with the MMR head stored locally, the first verification is considered to pass; and if the MMR head in the object information is inconsistent with the locally stored MMR head, the first verification is not passed.
(2) And calculating the block hash according to the block information, and verifying whether the calculated block hash is consistent with the block hash in the MMR head. That is, HASH (block information) = = mmr _ header. If the calculated block hash is consistent with the block hash in the MMR head, the second verification is considered to be passed; and if the calculated block hash is not consistent with the block hash in the MMR head, the second verification is not passed.
(3) And acquiring all transaction hashes in the block information, calculating a transaction root according to all transaction hashes, and verifying whether the calculated transaction root is consistent with the transaction root in the MMR head. I.e. MERKLE _ TREE (all transactions within a block) = = mmr _ header. If the transaction root obtained by calculation is consistent with the transaction root in the MMR head, the third verification is considered to be passed; and if the calculated transaction root is not consistent with the transaction root in the MMR head, the third verification is not passed.
(4) And calculating the MMR proof according to the MMR algorithm, and verifying whether the MMR root obtained by calculation is consistent with the MMR root in the MMR head. That is, MMR _ root = = MMR _ pro _ VERIFY (MMR _ PROOF). If the MMR root obtained by calculation is consistent with the MMR root in the MMR head, the fourth verification is considered to be passed; and if the calculated MMR root is not consistent with the MMR root in the MMR head, the fourth verification is not passed.
If the four verifications are passed, the light node considers that the verification is passed, and step 604 is executed; otherwise, the light node may consider the verification failed and need to re-perform the block existence certification.
And step 604, synchronizing the object information to the local after the verification is passed.
After the transaction presence verification passes, the light node may store the transaction information in a database. Alternatively, the light node may store the block information in the database after the block presence verification passes.
In this embodiment, the light node may perform presence verification for the transaction and the block, and may ensure that the transaction information and the block information queried by the light node are real and reliable.
Referring to fig. 7, a block diagram illustrating a structure of a light node in a blockchain according to an embodiment of the present application is shown, where the light node may include:
an obtaining module 710, configured to obtain, when a light node with a block height of n-1 needs to synchronize data of an nth block, block information and an MMR header of the nth block from a whole node in a block chain, where the MMR header includes a transaction root of a current block and an MMR root of a previous block, the transaction root is obtained through hash calculation according to all transactions in the current block, the MMR root is obtained through calculation of an MMR certificate of the current block according to an MMR algorithm, the MMR certificate includes a hash of an MMR header located at a predetermined position in a binary tree after the MMR headers of all blocks are arranged in the binary tree, and n is greater than or equal to 1;
the obtaining module 710 is further configured to obtain an MMR root of the n-1 th block stored locally;
the verification module 720 is configured to perform verification according to the MMR root of the nth-1 block, the block information of the nth block, and the MMR root;
and a synchronization module 730, configured to synchronize the MMR header and the MMR certificate of the nth block to the local when the verification passes.
In an alternative embodiment, the verification module 720 is further configured to:
acquiring all transaction hashes from the block information of the nth block, calculating a transaction root according to all transaction hashes, and verifying whether the calculated transaction root is consistent with the transaction root in the MMR head of the nth block;
and verifying whether the MMR root in the MMR header of the nth block is consistent with the MMR root of the (n-1) th block stored locally.
In an optional embodiment, the obtaining module 710 is further configured to obtain, when the block height of the light node is not continuous with the block height m of the block that needs to be synchronized, block information, an MMR header, and an MMR certificate of an m-th block from all nodes in the block chain, where m is greater than or equal to 1;
the verification module 720 is further configured to perform verification according to the block information of the mth block, the MMR header, and the MMR certificate;
the synchronization module 730 is further configured to synchronize the MMR header and the MMR certificate of the mth block to the local when the verification passes.
In an alternative embodiment, the verification module 720 is further configured to:
acquiring all transaction hashes from the block information of the mth block, calculating a transaction root according to all transaction hashes, and verifying whether the calculated transaction root is consistent with the transaction root in the MMR head of the mth block;
and calculating the MMR certificate according to the MMR algorithm, and verifying whether the calculated MMR root is consistent with the MMR root in the MMR head of the mth block.
Referring to fig. 8, in an alternative embodiment, the apparatus further includes:
a receiving module 740, configured to receive a query request carrying an object identifier, where the object identifier is a transaction identifier or a block identifier;
a query module 750, configured to query the object information for all nodes in the block chain according to the object identifier;
the verification module 720 is further configured to verify the object information;
and the synchronization module 730 is further configured to synchronize the object information to the local after the verification is passed.
In an alternative embodiment, when the object identifier is a transaction identifier, the object information includes transaction information, a mercker certificate of a transaction tree, an MMR header of a block to which the transaction belongs, and an MMR certificate, the verification module 720 is further configured to:
verifying whether the MMR head in the object information is consistent with the locally stored MMR head;
calculating transaction hash according to the transaction information, and verifying whether the calculated transaction hash is consistent with the transaction hash obtained according to the Mercker certification;
obtaining all transaction hashes of a block to which the transaction belongs according to the Merckel certification, calculating a transaction root according to all the transaction hashes, and verifying whether the transaction root obtained through calculation is consistent with a transaction root in the MMR head or not;
and calculating the MMR proof according to the MMR algorithm, and verifying whether the MMR root obtained by calculation is consistent with the MMR root in the MMR head.
In an alternative embodiment, when the object id is a chunk id, the object information includes chunk information, an MMR header, and an MMR certificate, the verification module 720 is further configured to:
verifying whether the MMR head in the object information is consistent with the locally stored MMR head;
calculating block hash according to the block information, and verifying whether the calculated block hash is consistent with the block hash in the MMR head;
acquiring all transaction hashes in the block information, calculating a transaction root according to all transaction hashes, and verifying whether the calculated transaction root is consistent with a transaction root in the MMR head;
and calculating the MMR proof according to the MMR algorithm, and verifying whether the MMR root obtained by calculation is consistent with the MMR root in the MMR head.
In summary, in the light node in the block chain provided in the embodiment of the present application, the light node only needs to synchronize the MMR header and the MMR header of one block, which proves that compared with the case of storing the full number of block headers, the storage pressure of the light node can be reduced. Moreover, the light node can check the block information and the MMR header, and the safety of the light node in the synchronization process is not sacrificed.
The light nodes can be synchronized from the latest block, and the storage pressure of the nodes can be reduced compared to the block header requiring synchronization of all blocks from the beginning.
The light node can perform existence certification aiming at the transaction and the block, and the transaction information and the block information inquired by the light node can be guaranteed to be real and reliable.
One embodiment of the present application provides a computer-readable storage medium having at least one instruction stored therein, which is loaded and executed by a processor to implement the data synchronization method for a light node in a blockchain as described above.
One embodiment of the present application provides a computer device, which includes a processor and a memory, where the memory stores at least one instruction, and the instruction is loaded and executed by the processor to implement the data synchronization method for a light node in a blockchain as described above.
It should be noted that: in the above embodiment, when the light node in the block chain synchronizes the data of the light node in the block chain, only the division of the functional modules is used for illustration, and in practical application, the function distribution may be completed by different functional modules according to needs, that is, the internal structure of the light node in the block chain is divided into different functional modules, so as to complete all or part of the functions described above. In addition, the embodiments of the data synchronization method for the light node in the block chain and the light node in the block chain provided in the foregoing embodiments belong to the same concept, and specific implementation processes thereof are described in detail in the embodiments of the method and are not described herein again.
It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, where the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.
The above description should not be taken as limiting the embodiments of the present application, and any modifications, equivalents, improvements, etc. made within the spirit and principle of the embodiments of the present application should be included in the scope of the embodiments of the present application.
Claims (10)
1. A method for data synchronization of a light node in a blockchain, the method comprising:
when a light node with the block height of n-1 needs to synchronize data of an nth block, acquiring block information of the nth block and an MMR (Merkel mountain MMR) head from all nodes in a block chain, wherein the MMR head comprises a transaction root of a current block and an MMR root of a previous block, the transaction root is obtained by calculating all transaction hashes in the current block, the MMR root is obtained by calculating an MMR certificate of the current block according to an MMR algorithm, the MMR certificate comprises hashes of MMR heads located at preset positions in a binary tree after the MMR heads of all blocks are arranged in the binary tree, and n is more than or equal to 1;
acquiring the MMR root of the (n-1) th block of the local storage;
verifying according to the MMR root of the (n-1) th block, the block information of the nth block and the MMR root;
and when the verification is passed, synchronizing the MMR head and the MMR certificate of the nth block to the local.
2. The method according to claim 1, wherein the verifying according to the MMR root of the n-1 th block, the block information of the n-th block, and the MMR root comprises:
acquiring all transaction hashes from the block information of the nth block, calculating a transaction root according to all transaction hashes, and verifying whether the calculated transaction root is consistent with the transaction root in the MMR head of the nth block;
verifying whether the MMR root in the MMR header of the nth block is consistent with the MMR root of the (n-1) th block stored locally.
3. The method of claim 1, further comprising:
when the block height m of the light node is not continuous with the block height m of the block needing synchronization, block information, an MMR (media mass register) head and an MMR (media mass register) certificate of the mth block are obtained from all nodes in the block chain, wherein m is more than or equal to 1;
verifying according to the block information, the MMR header and the MMR certificate of the mth block;
and when the verification is passed, synchronizing the MMR head and the MMR certificate of the m block to the local.
4. The method according to claim 3, wherein said verifying according to the block information of the m-th block, the MMR header and the MMR certificate comprises:
acquiring all transaction hashes from the block information of the mth block, calculating a transaction root according to all the transaction hashes, and verifying whether the transaction root obtained by calculation is consistent with the transaction root in the MMR head of the mth block;
and calculating the MMR certificate according to an MMR algorithm, and verifying whether the calculated MMR root is consistent with the MMR root in the MMR head of the mth block.
5. The method according to any one of claims 1 to 4, further comprising:
receiving a query request carrying an object identifier, wherein the object identifier is a transaction identifier or a block identifier;
inquiring object information from all nodes in the block chain according to the object identification;
verifying the object information;
and after the verification is passed, synchronizing the object information to the local.
6. The method according to claim 5, wherein when the object identifier is a transaction identifier, the object information includes transaction information, a Mercker certificate of a transaction tree, an MMR header and an MMR certificate of a block to which the transaction belongs, and the verifying the object information includes:
verifying whether the MMR head in the object information is consistent with a locally stored MMR head;
calculating transaction hash according to the transaction information, and verifying whether the calculated transaction hash is consistent with the transaction hash obtained according to the Mercker certification;
acquiring all transaction hashes of the block to which the transaction belongs according to the Mercker certificate, calculating a transaction root according to all transaction hashes, and verifying whether the calculated transaction root is consistent with the transaction root in the MMR head;
and calculating the MMR proof according to an MMR algorithm, and verifying whether the calculated MMR root is consistent with the MMR root in the MMR head.
7. The method according to claim 5, wherein when the object id is a block id, the object information includes block information, an MMR header, and an MMR certificate, and the verifying the object information includes:
verifying whether the MMR head in the object information is consistent with a locally stored MMR head;
calculating the block hash according to the block information, and verifying whether the calculated block hash is consistent with the block hash in the MMR head;
acquiring all transaction hashes in the block information, calculating a transaction root according to all transaction hashes, and verifying whether the calculated transaction root is consistent with a transaction root in the MMR head;
and calculating the MMR proof according to an MMR algorithm, and verifying whether the MMR root obtained by calculation is consistent with the MMR root in the MMR head.
8. A light node in a blockchain, the light node comprising:
an obtaining module, configured to obtain, when a light node with a block height of n-1 needs to synchronize data of an nth block, block information of the nth block and an MMR header of a merck mountain from a full node in a block chain, where the MMR header includes a transaction root of a current block and an MMR root of a previous block, the transaction root is obtained through hash calculation according to all transactions in the current block, the MMR root is obtained through calculation of an MMR certificate of the current block according to an MMR algorithm, the MMR certificate includes hashes of MMR headers located at predetermined positions in a binary tree after the MMR headers of all blocks are arranged in the binary tree, and n is greater than or equal to 1;
the acquisition module is further used for acquiring the MMR root of the (n-1) th block stored locally;
the verification module is used for verifying according to the MMR root of the (n-1) th block, the block information of the nth block and the MMR root;
and the synchronization module is used for synchronizing the MMR head and the MMR certificate of the nth block to the local when the verification is passed.
9. A computer-readable storage medium having stored therein at least one instruction which is loaded and executed by a processor to implement the method for data synchronization of a light node in a blockchain according to any one of claims 1 to 7.
10. A computer device comprising a processor and a memory, the memory having stored therein at least one instruction that is loaded and executed by the processor to implement the method of data synchronization of a light node in a blockchain according to any of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310167843.XA CN115860742B (en) | 2023-02-27 | 2023-02-27 | Data synchronization method, node, storage medium and equipment for light node in block chain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310167843.XA CN115860742B (en) | 2023-02-27 | 2023-02-27 | Data synchronization method, node, storage medium and equipment for light node in block chain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115860742A true CN115860742A (en) | 2023-03-28 |
| CN115860742B CN115860742B (en) | 2023-06-27 |
Family
ID=85659056
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310167843.XA Active CN115860742B (en) | 2023-02-27 | 2023-02-27 | Data synchronization method, node, storage medium and equipment for light node in block chain |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115860742B (en) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108681900A (en) * | 2018-07-18 | 2018-10-19 | 众安信息技术服务有限公司 | The method of light node verification transaction |
| CN111680049A (en) * | 2020-05-15 | 2020-09-18 | 杭州趣链科技有限公司 | Block chain-based processing method and processing device for Internet of things data |
| CN112287034A (en) * | 2020-12-24 | 2021-01-29 | 腾讯科技（深圳）有限公司 | Data synchronization method, equipment and computer readable storage medium |
| CN112287033A (en) * | 2020-12-24 | 2021-01-29 | 腾讯科技（深圳）有限公司 | Data synchronization method, equipment and computer readable storage medium |
| CN112887365A (en) * | 2021-01-08 | 2021-06-01 | 浙江泰科数联信息技术有限公司 | Ultra-lightweight node verification method and device based on MMR algorithm block chain |
| CN114416883A (en) * | 2022-01-27 | 2022-04-29 | 成都质数斯达克科技有限公司 | Block chain light node data synchronization method, device, equipment and readable storage medium |
| US20220368538A1 (en) * | 2021-04-27 | 2022-11-17 | ToposWare Japan Inc. | Zero-knowledge proof based cross-chain interoperability |
-
2023
- 2023-02-27 CN CN202310167843.XA patent/CN115860742B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108681900A (en) * | 2018-07-18 | 2018-10-19 | 众安信息技术服务有限公司 | The method of light node verification transaction |
| CN111680049A (en) * | 2020-05-15 | 2020-09-18 | 杭州趣链科技有限公司 | Block chain-based processing method and processing device for Internet of things data |
| CN112287034A (en) * | 2020-12-24 | 2021-01-29 | 腾讯科技（深圳）有限公司 | Data synchronization method, equipment and computer readable storage medium |
| CN112287033A (en) * | 2020-12-24 | 2021-01-29 | 腾讯科技（深圳）有限公司 | Data synchronization method, equipment and computer readable storage medium |
| CN112883117A (en) * | 2020-12-24 | 2021-06-01 | 腾讯科技（深圳）有限公司 | Data synchronization method, equipment and computer readable storage medium |
| CN112887365A (en) * | 2021-01-08 | 2021-06-01 | 浙江泰科数联信息技术有限公司 | Ultra-lightweight node verification method and device based on MMR algorithm block chain |
| US20220368538A1 (en) * | 2021-04-27 | 2022-11-17 | ToposWare Japan Inc. | Zero-knowledge proof based cross-chain interoperability |
| CN114416883A (en) * | 2022-01-27 | 2022-04-29 | 成都质数斯达克科技有限公司 | Block chain light node data synchronization method, device, equipment and readable storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115860742B (en) | 2023-06-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109313654B (en) | Method and system for desynchronized recovery of licensed blockchains using bloom filters | |
| CN108805570B (en) | Data processing method, device and storage medium | |
| CN109313752B (en) | Method and system for forming an efficient consensus mechanism for licensed blockchains using audit guarantees | |
| CN110875893B (en) | Consensus verification method, check node and block chain system | |
| RU2449358C1 (en) | Distributed file system and data block consistency managing method thereof | |
| CN110399424B (en) | Block generation method, block generation device, block chain node and storage medium | |
| CN107679863B (en) | Block chain system and method for quickly verifying block | |
| CN109981565B (en) | Block chain platform based on Meta-BFT consensus mechanism and implementation method | |
| WO2020199713A1 (en) | Data verification method, system, apparatus, and device | |
| CN111694502B (en) | Block chain data storage method, device, equipment and storage medium | |
| CN113127562A (en) | Low-redundancy block chain data storage and retrieval method and system | |
| CN115225639B (en) | Changing method and device for consensus trusted cluster, computer equipment and medium | |
| CN112035144A (en) | Block chain system upgrading method and device, computer equipment and storage medium | |
| CN113138880B (en) | Block chain system gray level publishing method, device, equipment and storage medium | |
| CN112732803B (en) | Consensus block chain transaction query verification method and system | |
| CN115860742A (en) | Data synchronization method, node, storage medium and equipment for light node in block chain | |
| CN113553373A (en) | Data synchronization method and device, storage medium and electronic equipment | |
| CN111061813B (en) | Method, apparatus and computing device for data synchronization in blockchain network | |
| CN111414417B (en) | Video copyright management method based on block chain | |
| US20220083656A1 (en) | Apparatus and method for tolerating byzantine faults in blockchain platforms | |
| CN113630445B (en) | Data storage method and device based on block chain network | |
| CN114661231A (en) | Storage synchronization method and device for parameter change records of power grid monitoring master station system | |
| CN113779146A (en) | Distributed electronic certificate verifiable storage system based on block chain | |
| CN114202425A (en) | Method, device and storage medium for predicting multi-main-chain interlinkage of language machine | |
| CN112131229A (en) | Block chain-based distributed data access method and device and storage node |
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 |