CN113535853A - Method for block chain network and related product - Google Patents
Method for block chain network and related product Download PDFInfo
- Publication number
- CN113535853A CN113535853A CN202110838249.XA CN202110838249A CN113535853A CN 113535853 A CN113535853 A CN 113535853A CN 202110838249 A CN202110838249 A CN 202110838249A CN 113535853 A CN113535853 A CN 113535853A
- Authority
- CN
- China
- Prior art keywords
- consensus
- ledger
- nodes
- height
- consensus nodes
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 48
- 238000004590 computer program Methods 0.000 claims abstract description 5
- 238000012795 verification Methods 0.000 claims description 19
- 230000004044 response Effects 0.000 claims description 16
- 230000008569 process Effects 0.000 description 16
- 238000010586 diagram Methods 0.000 description 10
- 238000004891 communication Methods 0.000 description 5
- 230000002093 peripheral effect Effects 0.000 description 4
- 238000012360 testing method Methods 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000012423 maintenance Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000010200 validation analysis Methods 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000000007 visual effect Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
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
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Computing Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The present invention relates to a method, apparatus, blockchain system and computer program product for blockchain, wherein a blockchain network comprises a plurality of consensus nodes, the method comprising performing at each consensus node the following operations: acquiring local latest account book information of the consensus node; in a preset time period before the account book consensus operation is executed in the blockchain network, declaring the local latest account book information to other consensus nodes in the blockchain network; and utilizing the announced local latest ledger information received from other consensus nodes to select to execute ledger updating operation so as to obtain the whole network latest ledger before executing the ledger consensus operation. By using the technical scheme of the invention, the consensus efficiency of the nodes in the block chain system can be effectively improved, and the overall performance of the block chain architecture is further improved.
Description
Technical Field
The present invention relates generally to the field of blockchain technology. More particularly, the present invention relates to a method, apparatus, block chain system and computer program product for a block chain network.
Background
This section is intended to provide a background or context to the embodiments of the invention that are recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Thus, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
The block chain system is a decentralized distributed accounting system, the related consensus mechanism should have a certain number of node fault tolerance mechanisms, namely when a number of nodes within the theoretical threshold range of the consensus algorithm have faults, errors or fraudulent behaviors, the block chain system can still normally operate, and a new effective account book is generated. However, in practical applications, the situations of failure, error and fraud of the consensus nodes exceeding the theoretical threshold number of the consensus algorithm still cannot be avoided. For example, a certain number of nodes need to be restarted for operation and maintenance reasons, or nodes in the system are deployed too intensively and some force-inefficacy factors occur, so that most of the nodes are down or out of service. When the consensus nodes in the system stop service, part of the consensus nodes may not store the latest valid ledger. Therefore, when each consensus node loads a stored account book and restarts, the block chain system may be split due to inconsistency of the latest valid account books in each consensus node, and thus consensus cannot be achieved.
At present, the restoration of the split blockchain system is mainly performed by adopting a human intervention mode. The manual intervention mode needs to subjectively judge the consensus node storing the latest effective account book, and manually copy the account book information from the consensus node to other consensus nodes or set a complex logic operation to intervene the starting sequence of the consensus nodes so as to guide most of the consensus nodes to obtain the latest effective account book. It can be seen that this artificial bootstrap operation greatly reduces the efficiency of consensus of nodes in the blockchain system, and thus the overall performance of the blockchain architecture.
Disclosure of Invention
In order to solve at least the technical problems described in the above background section, the present invention proposes a solution for a blockchain network. By using the scheme of the invention, each consensus node in the block chain network can select and update the account book by using the local latest account book information declared by other consensus nodes to obtain the whole network latest account book before executing the account book consensus operation. In view of this, the present invention provides solutions in the following aspects.
A first aspect of the invention provides a method for a blockchain network comprising a plurality of consensus nodes, the method comprising at each consensus node: acquiring local latest account book information of the consensus node; declaring the local latest account book information to other consensus nodes in the blockchain network within a predetermined time period before account book consensus operation is performed in the blockchain network; and utilizing the announced local latest ledger information received from the other consensus nodes to select to execute ledger updating operation so as to obtain the whole network latest ledger before executing the ledger consensus operation.
In one embodiment, wherein selecting to perform ledger update operations using the announced local up-to-date ledger information received from the other consensus node comprises: verifying local latest account book information announced by the other consensus nodes; determining to execute ledger updating operation in response to the local latest ledger information announced by the other consensus nodes passing verification; or determining not to execute the ledger updating operation in response to the local latest ledger information announced by the other consensus nodes not being verified.
In one embodiment, wherein the local latest ledger information comprises ledger heights related to ledger quantities, wherein validating local latest ledger information announced by the other consensus nodes comprises: validating locally up-to-date ledger information announced by the other consensus nodes according to a comparison of ledger heights in the consensus nodes and ledger heights in the other consensus nodes.
In one embodiment, wherein verifying based on the comparison comprises: judging whether the height of the account book in the consensus node is larger than the height of the account book in the other consensus nodes; and in response to the ledger height in the consensus node being greater than or equal to the ledger height in the other consensus nodes, determining that the locally latest ledger information announced by the other consensus nodes is not validated; or in response to the height of the ledger in the consensus node being less than the height of the ledger in the other consensus nodes, determining that the locally latest ledger information announced by the other consensus nodes is validated.
In one embodiment, wherein the local up-to-date ledger information comprises ledger height in relation to ledger quantity and a consensus accreditation in relation to ledger trustworthiness, wherein validating the local up-to-date ledger information announced by the other consensus nodes comprises validating the ledger height and the consensus accreditation in the other consensus nodes.
In one embodiment, wherein verifying ledger height and consensus accreditation in the other consensus nodes comprises: judging whether the height of the account book in the consensus node is larger than the height of the account book in the other consensus nodes; verifying consensus certificates in the other consensus nodes; in response to the ledger height in the consensus node being greater than or equal to the ledger height in the other consensus nodes and/or the consensus accreditation in the other consensus nodes failing to verify, determining that the locally latest ledger information announced by the other consensus nodes fails to verify; or in response to the ledger height in the consensus node being less than the ledger height in the other consensus nodes and the consensus certification in the other consensus nodes passing verification, determining that the locally latest ledger information announced by the other consensus nodes passes verification.
In one embodiment, wherein announcing the local latest ledger information to other consensus nodes within the blockchain network comprises: periodically announce the local latest ledger information to the other consensus nodes within the predetermined time period.
In one embodiment, the local latest ledger information of the consensus node in each cycle includes ledger information loaded when the consensus node starts up or ledger information updated in the previous cycle.
In one embodiment, the method further comprises: setting the length of the predetermined time period according to the number of common identification nodes in the blockchain network; and/or setting a period for performing announcement within the predetermined period of time according to the number of common identification nodes within the blockchain network.
A second aspect of the invention provides an apparatus comprising: a processor; and a memory storing computer instructions for a blockchain network, which when executed by the processor, cause the apparatus to perform the methods described in the foregoing and in the following embodiments.
A third aspect of the invention provides a computer program product comprising program instructions for a blockchain network, which when executed by a processor, cause the method to be carried out as described in the preceding and following embodiments.
In a fourth aspect of the present invention, a block chain system is provided, including: a plurality of consensus nodes, wherein each of said consensus nodes comprises a device as provided in the second aspect of the present invention, wherein said device is configured to perform the method as described in the preceding and in the following embodiments, to obtain a whole network up-to-date ledger prior to performing ledger consensus operations.
By using the scheme provided by the invention, each consensus node in the block chain network can select to update the ledger by using the local latest ledger information announced by other consensus nodes so as to obtain the latest ledger of the whole network before executing the consensus operation of the ledger. Specifically, each of the consensus nodes in the blockchain network obtains the local latest ledger information of the node, declares the local latest ledger information to other consensus nodes within a predetermined time period before performing ledger consensus operation, and then selectively updates the ledger by using the local latest ledger information declared by other consensus nodes to obtain the global latest ledger, so that most of the consensus nodes in the blockchain network can obtain the global latest ledger, and the problem of system splitting caused by inconsistency of the global latest ledger in the consensus nodes is effectively avoided. The scheme of the invention does not need manual intervention, can effectively improve the consensus efficiency of the nodes in the block chain system and reduce the maintenance cost of the block chain network. In addition, the scheme of the invention does not need to introduce additional complex logic operation, can effectively reduce the development difficulty of the block chain network, and further improves the overall performance of the block chain architecture.
Drawings
The above and other objects, features and advantages of exemplary embodiments of the present invention will become readily apparent from the following detailed description read in conjunction with the accompanying drawings. Several embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar or corresponding parts and in which:
FIG. 1 is an architecture diagram illustrating a blockchain network according to an embodiment of the present invention;
fig. 2 is a flow diagram illustrating a method for a blockchain network according to an embodiment of the present invention;
fig. 3 is a flow diagram illustrating a selection to perform ledger update operations according to an embodiment of the present invention;
fig. 4 is a flow diagram illustrating another method for a blockchain network according to an embodiment of the present invention; and
fig. 5 is a structural diagram illustrating a consensus node according to an embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention, and it is apparent that the described embodiments are some, but not all embodiments of the present invention. All other embodiments, which can be obtained by a person skilled in the art without making creative efforts based on the embodiments of the present invention, belong to the protection scope of the present invention.
It should be understood that the terms "first", "second", "third" and "fourth", etc. in the claims, the description and the drawings of the present invention are used for distinguishing different objects and are not used for describing a particular order. The terms "comprises" and "comprising," when used in the specification and claims of this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
It is also to be understood that the terminology used in the description of the invention herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in the specification and claims of this application, the singular form of "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should be further understood that the term "and/or" as used in the specification and claims of this specification refers to any and all possible combinations of one or more of the associated listed items and includes such combinations.
As used in this specification and claims, the term "if" may be interpreted contextually as "when", "upon" or "in response to a determination" or "in response to a detection". Similarly, the phrase "if it is determined" or "if a [ described condition or event ] is detected" may be interpreted contextually to mean "upon determining" or "in response to determining" or "upon detecting [ described condition or event ]" or "in response to detecting [ described condition or event ]".
The following detailed description of embodiments of the invention refers to the accompanying drawings.
In order to better understand the solution of the present invention, a block chain network will be briefly described below with reference to fig. 1.
Fig. 1 is an architecture diagram 100 illustrating a blockchain network in accordance with an embodiment of the present invention. The blockchain network may include a plurality of consensus nodes, where a consensus node may be understood as a node in the blockchain network that may share blockchain data and may participate in the blockchain consensus process.
As shown in fig. 1, the blockchain network may include A, B, C, D four consensus nodes and be formed by a network of nodes A, B, C, D. It is to be understood that the block chain network is illustrated with four common nodes for illustrative purposes only, and the number of common nodes in the block chain network is not limited.
In the background of the invention, after the service of the consensus node in the blockchain network is stopped due to operation and maintenance or due to some inefficacy factors, the consensus node needs to be restarted to recover the accounting and provide normal service to the outside. In one embodiment, the example of restarting A, B, C, D four consensus nodes in FIG. 1 is illustrated. Assuming the aforementioned four nodes prior to reboot, A, B two consensus nodes have not persisted the full network recent ledger into their storage, while C, D two consensus nodes have persisted the full network recent ledger into their storage. In the service process of restarting the four common nodes, the account book that can be loaded by A, B two common nodes is inconsistent with the account book that can be loaded by C, D two common nodes, so that the blockchain network is split and the common knowledge cannot be achieved. In order to solve this technical problem, the present invention proposes a technical solution as shown in fig. 2.
Fig. 2 is a flow diagram illustrating a method 200 for a blockchain network according to an embodiment of the present invention. The blockchain network may include a plurality of consensus nodes, and each consensus node may perform the steps shown in fig. 2. It is understood that the blockchain network and the consensus node herein may have the same general properties as the blockchain network and the consensus node described above in connection with fig. 1, and further performance optimization and improvement is obtained by the solution of the present invention.
For each of the aforementioned consensus nodes, as shown in fig. 2, at step S201, local up-to-date ledger information of the consensus node may be acquired. In one embodiment, the aforementioned local latest ledger information may be obtained from a storage device (e.g., a local disk) of the consensus node. It is understood that the aforementioned manner of acquiring the local latest account book information is only one possible implementation manner of step S201, and the scheme of the present invention is not limited thereto. For example, the up-to-date ledger information may also be stored at a cloud end associated with the consensus node. Next, in step S202, the local latest ledger information may be announced to other consensus nodes in the blockchain network within a predetermined time period before performing ledger consensus in the blockchain network. In one embodiment, the aforementioned step S202 may be implemented by a step S202-1 shown in dashed box.
Specifically, at step S202-1, the aforementioned local latest ledger information may be periodically announced to the aforementioned other consensus nodes within a predetermined period of time. In some implementation scenarios, the aforementioned predetermined period of time and the aforementioned period for performing the announcement may be set according to the aforementioned number of common nodes within the blockchain network. For example, when the size of the blockchain network is large (i.e., the number of the common nodes therein is large), the length of the predetermined period and the length of the period may be increased. By increasing the length of the aforementioned predetermined period of time, the probability that other consensus nodes receive the local latest ledger information can be increased. In addition, the length of the period is increased, so that the announcement frequency of the information (including the latest account book information of the information) can be reduced, the consumption of the broadband of the import and export network can be reduced, and the network congestion can be avoided. It is understood that step S202-1 shown in fig. 2 is only one possible implementation of step S202, and the present invention is not limited thereto. Other steps or ways may be taken by those skilled in the art to implement step S202 in accordance with the teachings of the present invention.
Next, at step S203, the announced local latest ledger information received from the other consensus nodes can be utilized to select to perform the ledger update operation, so as to obtain the global latest ledger before performing the ledger consensus operation. One embodiment for implementing step S203 will be described below with reference to fig. 3.
Fig. 3 is a flow diagram illustrating a selection to perform ledger update operation 300, according to an embodiment of the present invention.
As shown in fig. 3, at step S203-1, the local latest ledger information announced by the aforementioned other consensus nodes may be verified, and at step S203-2, it is determined whether the verification is passed. In some implementations, the aforementioned local up-to-date ledger information may include ledger heights that are related to ledger quantities. In this scenario, the foregoing verification operation may be implemented according to a comparison between the ledger height in the foregoing consensus node and the ledger height in the foregoing other consensus node. For example, it may be determined whether the height of the ledger in the aforementioned common node is greater than the height of the ledger in the aforementioned other common nodes. When the height of the ledger in the common identification node is greater than or equal to the height of the ledger in the other common identification nodes, it can be determined that the local latest ledger information announced by the other common identification nodes is not verified. Otherwise, it may be determined that the authentication is passed.
In other implementation scenarios, the aforementioned local latest ledger information may include ledger height related to ledger quantity and consensus certification related to ledger credibility, where the consensus certification may be set according to a consensus mechanism involved in the blockchain network, for example, a digital signature of the ledger, a workload certification of miners, and the like may be included. In this scenario, the ledger height and the consensus certification in the other consensus nodes described above may be verified to implement the foregoing verification operation. For example, it may be determined whether the height of the ledger in the aforementioned consensus node is greater than the height of the ledger in the aforementioned other consensus node, and the proof of consensus in the aforementioned other consensus node is verified (for example, the digital signature or the workload proof of the aforementioned ledger may be verified). When the ledger height in the aforementioned consensus node is greater than or equal to the ledger height in the aforementioned other consensus node, or when the consensus confirmation in the aforementioned other consensus node fails to be verified, or when the ledger height in the aforementioned consensus node is greater than or equal to the ledger height in the aforementioned other consensus node and the consensus confirmation in the aforementioned other consensus node fails to be verified, it may be determined that the locally latest ledger information announced by the aforementioned other consensus node fails to be verified. In contrast, when the height of the ledger in the consensus node is smaller than the heights of the ledgers in the other consensus nodes, and the consensus certification in the other consensus nodes passes the verification, it can be determined that the local latest ledger information announced by the other consensus nodes passes the verification.
When it is determined at the aforementioned step S203-2 that the verification is passed, then at step S203-3, it is determined that the ledger update operation is performed. In contrast, when it is determined at the aforementioned step S203-2 that the verification is not passed, then at a step S203-4, it is determined that the ledger update operation is not performed. In an embodiment, in the process that each of the aforementioned common nodes periodically declares its local latest account information within a predetermined time period, if the local latest account information declared by a plurality of the aforementioned other common nodes is received, the local latest account information declared by the other common nodes may be sequentially verified according to the sequence of the receiving times. In this process, the latest local ledger information announced by each of the aforementioned consensus nodes may include ledger information loaded at startup or ledger information updated in the previous period. It is understood that step S203-1, step S203-2, step S203-3, and step S203-4 shown in fig. 3 are only one possible implementation manner of step S203, and the scheme of the present invention is not limited thereto. Other steps or ways may be taken by those skilled in the art to implement step S203 in accordance with the teachings of the present invention.
Fig. 4 is a flow diagram illustrating another method 400 for a blockchain network according to an embodiment of the present invention. The blockchain network includes a plurality of consensus nodes, and each consensus node may perform the steps shown in fig. 4. It is to be understood that the blockchain network and the common node may be the blockchain network and the common node described above in conjunction with fig. 2 and 3, and therefore the description of the blockchain network and the common node also applies to the following description.
As shown in fig. 4, in step S401, after each of the aforementioned consensus nodes in the blockchain network starts to load the stored ledger information, and a guidance announcement is performed for a time period T, the ledger consensus operation is performed. The time period T may be referred to as a booting time period of the consensus node (e.g., may be the predetermined time period described above), and thus the description of the predetermined time period also applies to the booting time period T.
Next, in step S402, in the guiding period T, each of the aforesaid common nodes announces the ledger information loaded by the node to other common nodes in the aforesaid blockchain network at intervals of the period T (which may be the aforesaid period for performing announcement), so as to complete the guiding announcement of the node. In one embodiment, the aforementioned boot time period T and the interval time period T may be preset by a node program, or may be configured and specified in a node configuration file. Further, the above-mentioned ledger information loaded by the node may be the above-mentioned local latest ledger information, so that the above-mentioned local latest ledger information described with reference to fig. 2 and fig. 3 is also applicable to the ledger information loaded by the node. In addition, regarding the aforementioned announcement operation, in an embodiment, the announcement operation may be specifically implemented in a manner of full network broadcast or in a manner of other P2P message propagation protocols (for example, Gossip protocol).
In step S403, when receiving the guidance announcement, the other consensus nodes verify the ledger information in the guidance announcement, and after the verification is passed, perform ledger update operation and store the updated ledger by using the ledger information. In some embodiment scenarios, ledger information in the guidance announcement may include ledger height and consensus certificates. In this scenario, in one embodiment, the aforementioned validation operation may specifically involve validation of ledger height and consensus proofs in the aforementioned guidance announcement. For example, it is determined whether the height of the ledger in the aforementioned guidance announcement is greater than the height of the ledger in the own node, and the consensus certification in the aforementioned guidance announcement is verified (for example, a digital signature of the ledger or verification of workload certification of miners, etc.). When the height of the ledger in the guidance announcement is larger than that of the ledger in the node and the consensus certification in the guidance announcement passes the verification, it can be determined that the ledger information in the guidance announcement passes the verification. Otherwise, it may be determined that the authentication is not passed.
The above steps S401 to S403 will be further described with reference to A, B, C, D four consensus nodes in fig. 1.
The blockchain network in this embodiment may involve a HotStuff consensus protocol, according to which a threshold signature may be employed as a proof of work for the ledger. It is understood that the threshold signature here means that the consensus nodes sign the account proposal by using respective private keys, and the signature is collected by the leader node of the current consensus round. Other consensus nodes (including the leader node itself) only need to send the signature message to the leader node. Then, the leader node aggregates the number of signatures satisfying the threshold number into one signature (which may be referred to as an aggregated signature) and broadcasts the aggregated signature to the other nodes, and the other nodes only need to verify the signature once in each round of consensus.
In this embodiment, the height of the ledger of the latest ledger of the whole network, where A, B, C, D four consensus nodes have passed through consensus before the restart, is N, the height of the ledger stored by the consensus nodes a and B before the restart is N-1, and the height of the ledger stored by the consensus nodes C and D before the restart is N. The foregoing specific implementation process of steps S401 to S403 may involve the following operations:
first, an initialization operation is performed. For example, the node service process may be set to be boot-up and self-started in the device system of each common node, and a daemon process of the node service process is started. The daemon process is used for monitoring the running state of the node service process and can restart the node service process after the node service process is stopped. For example, the guidance time period T (e.g., 10s) and the guidance announcement interval time T (e.g., 1s) may be configured in a configuration file of each common node.
Then, an announcement operation is performed at the four consensus nodes. After the restart of the service processes such as the consensus nodes a and B, the guidance account book loaded from the storage device and the aggregated signature of the guidance account book are announced every 1s (i.e. the loaded account book information is announced). After the service process of the consensus node C, D is restarted, the guidance account book loaded from the storage device and the aggregated signature of the guidance account book are declared every 1s (i.e. the loaded account book information is declared). The height of the account book of the guiding account books of the consensus nodes A and B is N-1, the height of the account book of the guiding account books of the consensus nodes C and D is N, and the adopted declaration method can be full-network broadcasting.
Then, an ledger update operation is performed at the consensus nodes a and B. After receiving the guidance announcement message of the consensus node C or the consensus node D, the consensus nodes A and B verify the guidance announcement of the consensus node C or the consensus node D. For example, when it is determined that ledger height N is greater than ledger height N-1 in the guidance announcement of consensus node C or consensus node D, it may be determined that the verification of ledger height passes; and verifying the aggregated signature of the ledger with height N. Since the ledger of height N has passed consensus before the consensus node A, B, C, D reboots and is persisted into its storage by the C, D consensus node, the aggregated signature of the ledger of height N is a valid proof. Then, the consensus nodes a and B persist the aforementioned ledger of height N and the aggregated signature of the ledger into a storage device. Since the consensus node A, B is still within the guiding period T, the ledger with the height N may be used as the guiding ledger of the node, and the announcement operation related to the consensus node A, B is repeated.
Then, ledger update operations are performed at consensus nodes C and D. After receiving the bootstrap announcement message of the consensus node a or the node B, the consensus node C, D verifies the bootstrap announcement of the consensus node a or the node B, which may specifically refer to the above-mentioned verification operations performed at the consensus nodes a and B. Since ledger height N-1 in the boot announcement is less than ledger height N in consensus node C, D, validation does not pass. In addition, since the two consensus nodes C, D are still within the guiding period T, the ledger with the ledger height N is taken as the guiding ledger of the node, and the announcement operation related to the consensus node C, D is repeated.
Finally, after the aforementioned guidance period is ended, any node A, B, C, D obtains the ledger of height N, and may start to perform ledger consensus operation based on the ledger of height N being obtained.
Fig. 5 is a schematic block diagram illustrating a consensus node 500 according to an embodiment of the present invention. The consensus node 500 may comprise a device 501 according to embodiments of the present invention, as well as its peripherals and external networks. As described above, the consensus node (e.g., via device 501) implements operations of announcing local latest ledger information of the node and selecting ledger update to be performed using the local latest ledger information announced by other nodes, so as to implement the scheme of the present invention described above in conjunction with fig. 2-4.
As shown in fig. 5, the device 501 may include a CPU5011, which may be a general-purpose CPU, a special-purpose CPU, or other execution unit that processes and programs to run. Further, the device 501 may further include a mass memory 5012 and a read only memory ROM 5013, wherein the mass memory 5012 may be configured to store various types of data including ledger, ledger information, announcement cycle, etc., and various programs required for a blockchain network, and the ROM 5013 may be configured to store a power-on self test for the device 501, initialization of various functional modules in the system, drivers for basic input/output of the system, and data required for booting an operating system.
Further, the device 501 also includes other hardware platforms or components, such as the illustrated TPU 5014, GPU 5015, FPGA5016, and MLU 5017. It is understood that although various hardware platforms or components are shown in the device 501, this is by way of example and not by way of limitation, and those skilled in the art may add or remove corresponding hardware as may be desired. For example, the device 501 may include only a CPU as a well-known hardware platform and another hardware platform as a test hardware platform of the present invention.
The device 501 of the present invention also includes a communication interface 5018 so that it may be connected to a local area network/wireless local area network (LAN/WLAN)505 through the communication interface 5018, which in turn may be connected to a local server 506 through the LAN/WLAN or to the Internet ("Internet") 507. Alternatively or additionally, the inventive device 501 may also be directly connected to the internet or a cellular network based on wireless communication technology, such as third generation ("3G"), fourth generation ("4G"), or 5 th generation ("5G"), through the communication interface 5018.
The peripheral devices of the device 501 may include a display device 502, an input device 503, and a data transmission interface 504. In one embodiment, the display device 502 may, for example, include one or more speakers and/or one or more visual displays configured to provide voice prompts and/or visual displays of the operational procedures or end results of the testing apparatus of the present invention. Input device 503 may include, for example, a keyboard, mouse, microphone, gesture capture camera, or other input buttons or controls configured to receive input of test data or user instructions. The data transfer interface 504 may include, for example, a serial interface, a parallel interface, or a universal serial bus interface ("USB"), a small computer system interface ("SCSI"), serial ATA, FireWire ("FireWire"), PCI Express, and a high-definition multimedia interface ("HDMI"), which are configured for data transfer and interaction with other devices or systems. According to the scheme of the present invention, the data transmission interface 504 may receive local latest ledger information of the local node or local latest ledger information announced by other nodes, and transmit the local latest ledger information of the local node to the device 501.
The aforementioned CPU5011, mass storage 5012, ROM 5013, TPU 5014, GPU 5015, FPGA5016, MLU5017, and communication interface 5018 of the device 501 of the present invention may be interconnected by a bus 5019 through which data interaction with peripheral devices is achieved. Through this bus 5019, the CPU5011 may control other hardware components in the device 501 and their peripherals in one embodiment.
In operation, the processor CPU5011 of the device 501 of the present invention may obtain local up-to-date ledger information for its own node and other nodes through the input device 503 or the data transmission interface 504, and call computer program instructions or code stored in the memory 5012 to process the obtained information so as to obtain a whole-network up-to-date ledger before performing ledger reconciliation operations.
From the above description of the modular design of the present invention, it can be seen that the system of the present invention can be flexibly arranged according to application scenarios or requirements without being limited to the architecture shown in the accompanying drawings. Further, it should also be understood that any module, unit, component, server, computer, or device performing operations of examples of the invention may include or otherwise access a computer-readable medium, such as a storage medium, computer storage medium, or data storage device (removable) and/or non-removable) such as a magnetic disk, optical disk, or magnetic tape. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules or other data. In this regard, the present invention also discloses a computer readable storage medium having stored thereon computer readable instructions for a blockchain network, which when executed by one or more processors, perform the methods and operations previously described in connection with the figures.
While various embodiments of the present invention have been shown and described herein, it will be obvious to those skilled in the art that such embodiments are provided by way of example only. Numerous modifications, changes, and substitutions will occur to those skilled in the art without departing from the spirit and scope of the present invention. It should be understood that various alternatives to the embodiments of the invention described herein may be employed in practicing the invention. It is intended that the following claims define the scope of the invention and that the module compositions, equivalents, or alternatives falling within the scope of these claims be covered thereby.
Claims (12)
1. A method for a blockchain network comprising a plurality of consensus nodes, the method comprising performing the following at each consensus node:
acquiring local latest account book information of the consensus node;
declaring the local latest account book information to other consensus nodes in the blockchain network within a predetermined time period before account book consensus operation is performed in the blockchain network; and
and selecting to execute the accounting book updating operation by utilizing the declared local latest accounting book information received from the other consensus nodes so as to obtain the whole network latest accounting book before executing the accounting book consensus operation.
2. The method of claim 1, wherein selecting to perform ledger update operations utilizing announced local up-to-date ledger information received from the other consensus nodes comprises:
verifying local latest account book information announced by the other consensus nodes;
determining to execute ledger updating operation in response to the local latest ledger information announced by the other consensus nodes passing verification; or
And determining not to execute the ledger updating operation in response to the local latest ledger information announced by the other consensus nodes not being verified.
3. The method of claim 2, wherein the local up-to-date ledger information comprises ledger heights related to ledger quantities, wherein validating local up-to-date ledger information announced by the other consensus nodes comprises:
validating locally up-to-date ledger information announced by the other consensus nodes according to a comparison of ledger heights in the consensus nodes and ledger heights in the other consensus nodes.
4. The method of claim 3, wherein verifying based on the comparison comprises:
judging whether the height of the account book in the consensus node is larger than the height of the account book in the other consensus nodes; and
in response to the ledger height in the consensus node being greater than or equal to the ledger height in the other consensus nodes, determining that the locally latest ledger information announced by the other consensus nodes is not validated; or
In response to the ledger height in the consensus node being less than the ledger height in the other consensus nodes, determining that the locally most recent ledger information announced by the other consensus nodes is validated.
5. The method of claim 2, wherein the local up-to-date ledger information comprises ledger height relative to a number of ledgers and a proof of consensus relative to ledger credibility, wherein validating local up-to-date ledger information declared by the other nodes of consensus comprises validating ledger height and proof of consensus in the other nodes of consensus.
6. The method of claim 5, wherein verifying ledger height and consensus accreditation in the other consensus nodes comprises:
judging whether the height of the account book in the consensus node is larger than the height of the account book in the other consensus nodes;
verifying consensus certificates in the other consensus nodes;
in response to the ledger height in the consensus node being greater than or equal to the ledger height in the other consensus nodes and/or the consensus accreditation in the other consensus nodes failing to verify, determining that the locally latest ledger information announced by the other consensus nodes fails to verify; or
In response to the ledger height in the consensus node being less than the ledger height in the other consensus nodes and the consensus certification in the other consensus nodes passing verification, determining that the locally most recent ledger information announced by the other consensus nodes passes verification.
7. The method of any of claims 1-6, wherein announcing the local latest ledger information to other consensus nodes within the blockchain network comprises:
periodically announce the local latest ledger information to the other consensus nodes within the predetermined time period.
8. The method of claim 7, wherein the local up-to-date ledger information for the consensus node in each cycle comprises ledger information loaded at startup of the consensus node or ledger information updated in a previous cycle.
9. The method of claim 8, further comprising:
setting the length of the predetermined time period according to the number of common identification nodes in the blockchain network; and/or
Setting a period for performing announcement within the predetermined period of time according to the number of common nodes within the blockchain network.
10. An apparatus, comprising:
a processor; and
a memory storing computer instructions for a blockchain network, which when executed by the processor, cause the apparatus to perform the method of any of claims 1-9.
11. A computer program product comprising program instructions for a blockchain network, which when executed by a processor, cause the method according to any one of claims 1-9 to be carried out.
12. A blockchain system, comprising:
a plurality of consensus nodes, wherein each of said consensus nodes comprises a device according to claim 10, wherein said device is configured to perform the method according to any of claims 1-9 to obtain a whole network up-to-date ledger prior to performing ledger consensus operations.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110838249.XA CN113535853A (en) | 2021-07-23 | 2021-07-23 | Method for block chain network and related product |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110838249.XA CN113535853A (en) | 2021-07-23 | 2021-07-23 | Method for block chain network and related product |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113535853A true CN113535853A (en) | 2021-10-22 |
Family
ID=78089457
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110838249.XA Pending CN113535853A (en) | 2021-07-23 | 2021-07-23 | Method for block chain network and related product |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113535853A (en) |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111026770A (en) * | 2019-10-29 | 2020-04-17 | 北京海益同展信息科技有限公司 | Account book processing method and device for block chain nodes, server and storage medium |
-
2021
- 2021-07-23 CN CN202110838249.XA patent/CN113535853A/en active Pending
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111026770A (en) * | 2019-10-29 | 2020-04-17 | 北京海益同展信息科技有限公司 | Account book processing method and device for block chain nodes, server and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102469267B1 (en) | Blockchain consensus method, accounting node and node | |
| CN107220141B (en) | Data file checking method and device | |
| US20110320794A1 (en) | Flash System And Method For Updating The Flash System | |
| KR20150022849A (en) | Auto-update while running client interface with handshake | |
| CN112817625A (en) | System upgrading method and device, electronic equipment and storage medium | |
| CN114422155B (en) | Proposal consensus execution method, block chain system, device and storage medium | |
| CN113127569A (en) | Consensus method and device for block chain system, electronic equipment and storage medium | |
| CN114338715A (en) | Data synchronization method, block chain system, terminal device and storage medium | |
| CN110163012A (en) | Mainboard powering method, apparatus and system based on programming device | |
| CN111159090B (en) | Information processing method and device and electronic equipment | |
| CN111752577B (en) | Upgrading method and equipment for system version | |
| CN113535853A (en) | Method for block chain network and related product | |
| CN111090537B (en) | Cluster starting method and device, electronic equipment and readable storage medium | |
| CN111984287A (en) | Equipment upgrading method and system | |
| CN115964721A (en) | Program verification method and electronic equipment | |
| CN110610091A (en) | Security PXE method based on domestic network platform | |
| EP4075309A1 (en) | Secure boot device | |
| CN116610336A (en) | Firmware upgrading method, system, device and readable storage medium | |
| CN116339908A (en) | Virtual machine starting method, device, computer equipment and storage medium | |
| CN115827069A (en) | Starting control method, system and device for server mainboard | |
| CN111666219B (en) | Service function verification method and device, computer system and storage medium | |
| CN110659052B (en) | Method and system for updating system software in network equipment and readable storage medium | |
| CN114153503A (en) | BIOS control method, device and medium | |
| CN111405297A (en) | Activity list settlement method and device and storage medium | |
| JP7363617B2 (en) | Communication devices, information processing methods, and systems |
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 |