CN112199239A - Method, device and system for restarting block chain node - Google Patents
Method, device and system for restarting block chain node Download PDFInfo
- Publication number
- CN112199239A CN112199239A CN202011147256.7A CN202011147256A CN112199239A CN 112199239 A CN112199239 A CN 112199239A CN 202011147256 A CN202011147256 A CN 202011147256A CN 112199239 A CN112199239 A CN 112199239A
- Authority
- CN
- China
- Prior art keywords
- node
- restart
- request
- service
- restarting
- 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
- 238000000034 method Methods 0.000 title claims abstract description 61
- 238000012545 processing Methods 0.000 claims abstract description 64
- 230000007704 transition Effects 0.000 claims abstract description 18
- 238000012795 verification Methods 0.000 claims description 65
- 238000012423 maintenance Methods 0.000 claims description 40
- 238000004590 computer program Methods 0.000 claims description 13
- 230000008569 process Effects 0.000 description 27
- 230000006870 function Effects 0.000 description 22
- 238000010586 diagram Methods 0.000 description 20
- 230000002159 abnormal effect Effects 0.000 description 9
- 238000004891 communication Methods 0.000 description 9
- 238000012790 confirmation Methods 0.000 description 5
- 239000000872 buffer Substances 0.000 description 4
- 230000004044 response Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 244000035744 Hura crepitans Species 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002688 persistence Effects 0.000 description 2
- 238000007781 pre-processing Methods 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 239000003550 marker Substances 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1438—Restarting or rejuvenating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
-
- 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)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Databases & Information Systems (AREA)
- Computing Systems (AREA)
- Data Mining & Analysis (AREA)
- Retry When Errors Occur (AREA)
Abstract
The invention discloses a method, a device and a system for restarting a block chain node, which relate to the technical field of block chains, wherein the method comprises the following steps: receiving a job request from an external system, the job request being one of: restarting the operation request and the service request by the node; responding to the operation request as a node restarting operation request, and performing consensus operation based on a preset restarting operation contract; responding to success of consensus operation, sending a node restart instruction to a service execution unit so that the service execution unit performs closed-loop processing on services in a processing state within a preset restart transition time window; and responding to the completion of processing of the received update type service from the service execution unit, and sending a node restart instruction to the external system so as to enable the external system to execute node restart operation. By the method and the device, better service experience can be guaranteed.
Description
Technical Field
The invention relates to the technical field of block chains, in particular to a method, a device and a system for restarting a block chain node.
Background
The blockchain is a solution for jointly accounting by using cryptography to ensure access security, using a P2P (Peer-to-Peer) communication technology to realize Peer-to-Peer communication, using a consensus mechanism to realize accounting legitimacy, and using a chain structure to store data. The block chain business system extracts the business rules into intelligent contracts, deploys the intelligent contracts on all member nodes of the block chain business chain, realizes traceable business processing flow and non-falsifiable result through a consensus mechanism among the member nodes and the same account book on the member nodes, and ensures that information intercommunication, capacity sharing and value interchange of all alliance member parties are established on a compliance, safety and right-confirming order internet. When a block chain service scene falls to the ground, a block chain network needs to be established, and each alliance participant manages, operates and maintains the block chain member nodes. At present, when a block chain is technically upgraded, all alliance parties need to perform restart operation in an appointed time window, the restart operation is mainly completed through processes of offline negotiation, notification, cooperation and the like, however, the process is long, and in the process of restarting different block chain member nodes for a long time, in-process transaction abnormal interruption and commonly recognized transaction block abnormal are easily caused in an upgrade window, so that unfriendly service experience is caused, and even block chain link point bifurcation can be caused to influence the normal start of a block chain network after upgrading.
Disclosure of Invention
In view of the above, the present invention provides a method, an apparatus, and a system for restarting a blockchain node to solve at least one of the above-mentioned problems.
According to a first aspect of the present invention, there is provided a method for restarting a blockchain node, the method comprising: receiving a job request from an external system, the job request being one of: restarting the operation request and the service request by the node; responding to the operation request as a node restarting operation request, and performing consensus operation based on a preset restarting operation contract; responding to success of consensus operation, sending a node restart instruction to a service execution unit so that the service execution unit performs closed-loop processing on services in a processing state within a preset restart transition time window; and responding to the completion of processing of the received update type service from the service execution unit, and sending a node restart instruction to the external system so as to enable the external system to execute node restart operation.
According to a second aspect of the present invention, there is provided a block link point rebooting apparatus, comprising: a job request receiving unit configured to receive a job request from an external system, the job request being one of: restarting the operation request and the service request by the node; the consensus unit is used for responding to the operation request which is a node restarting operation request and carrying out consensus operation based on a preset restarting operation contract; the instruction internal sending unit is used for responding to the success of the consensus operation and sending a node restarting instruction to the service execution unit so as to enable the service execution unit to carry out closed-loop processing on the service in the processing state in a preset restarting transition time window; and the instruction external sending unit is used for responding to the completion of processing of the received update type service from the service execution unit and sending a node restart instruction to the external system so as to enable the external system to execute node restart operation.
According to a third aspect of the present invention, there is provided a system for rebooting a block link point, the system comprising: the restarting device is located on a verification node side, the operation and maintenance management system sends a node restarting operation request to the restarting device and executes a node restarting operation, and the service system sends a service request to the restarting device.
According to a fourth aspect of the present invention, there is provided an electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the steps of the above method when executing the program.
According to a fifth aspect of the invention, a computer-readable storage medium is provided, on which a computer program is stored which, when being executed by a processor, carries out the steps of the above-mentioned method.
According to the technical scheme, when the received job request from the external system is the node restarting operation request, performing consensus operation on the node restart operation request, sending a node restart instruction to the service execution unit after the consensus operation is successful, so that the service execution unit performs closed-loop processing on the service in the processing state in the restart transition time window, and when the service execution unit has processed the update type service, the node restart instruction is sent to the external system, so that the external system can perform the node restart operation, compared with the prior art, the embodiment of the invention does not need the offline negotiation process, and the updating type service can be processed in time through closed-loop processing, the system problems of block branching and the like caused by abnormal interruption of the in-transit service in the restarting process are avoided, and better service experience is ensured.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to these drawings without creative efforts.
FIG. 1 is a block diagram of a block chain nexus restart system according to an embodiment of the present invention;
fig. 2 is a block diagram of the block link point restart device 10 according to an embodiment of the present invention;
fig. 3 is a detailed block diagram of the block link point restart apparatus 10 according to an embodiment of the present invention;
FIG. 4 is an exemplary architecture diagram of a block chain node reboot system according to an embodiment of the invention;
fig. 5 is a block diagram of the structure of a verification node 2 according to an embodiment of the present invention;
FIG. 6 is a consensus flow diagram of the instruction consensus module 132, according to an embodiment of the present invention;
FIG. 7 is a flowchart of a restart operation of the verification node 2 according to an embodiment of the present invention;
FIG. 8 is a flow chart of a block link point restart method according to an embodiment of the present invention;
fig. 9 is a schematic block diagram of a system configuration of an electronic apparatus 600 according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
Based on the technical scheme, the embodiment of the invention provides a block chain node restarting scheme which can ensure the automation and the safety of the block chain node restarting operation process, avoid a complicated and tedious offline negotiation process, avoid the system problems of block bifurcation and the like caused by the abnormal interruption of in-transit operation (or called transaction), and ensure better service experience. Embodiments of the present invention are described in detail below with reference to the accompanying drawings.
Fig. 1 is a block diagram of a block link point restart system according to an embodiment of the present invention, as shown in fig. 1, the system including: the system comprises a block link point restarting device 10 and an external system 20 comprising an operation and maintenance management system 201 and a service system 202, wherein the restarting device is located on a verification node side, the operation and maintenance management system sends a node restarting operation request to the restarting device and executes a node restarting operation, and the service system sends a service request to the restarting device. The block link point restart device 10 is described in detail below.
As shown in fig. 2, the block link point restart apparatus 10 includes: a job request receiving unit 101, a consensus unit 102, an instruction internal transmitting unit 103, and an instruction external transmitting unit 104, wherein:
a job request receiving unit 101 configured to receive a job request from an external system, the job request being one of: and restarting the operation request and the service request by the node.
The node restart operation request comes from the operation and maintenance management system 201, and the service request comes from the service system 202.
And the consensus unit 102 is used for responding to the job request being a node restarting operation request and performing consensus operation based on a preset restarting operation contract.
In actual operation, the preset restart operation contract may be referred to as a pre-manufactured chain code.
And the instruction internal sending unit 103 is configured to send a node restart instruction to the service execution unit in response to a success of the consensus operation, so that the service execution unit performs closed-loop processing on a service (i.e., a transaction) in a processing state within a preset restart transition time window.
The service execution unit is located at the verification node side, and is configured to execute a corresponding service operation according to the service request received by the job request receiving unit 101.
The closed-loop processing here means that, when the service execution unit receives a node restart instruction, all the services (for example, update type services) in the processing state are processed within a preset restart transition time window (for example, T seconds), and no update type services are executed.
An instruction external sending unit 104, configured to send a node restart instruction to the external system (specifically, the operation and maintenance management system 201) in response to that the update type service received from the service execution unit is processed, so that the external system executes a node restart operation.
When the received job request from the external system is a node restart operation request, the consensus unit 102 performs consensus operation on the node restart operation request through the job request receiving unit 101, and after the consensus operation is successful, the instruction internal sending unit 103 sends a node restart instruction to the service execution unit, so that the service execution unit performs closed-loop processing on the service in a processing state in a restart transition time window, and when the service execution unit has processed an update-type service, the instruction external sending unit 104 sends the node restart instruction to the operation and maintenance management system 201, so that the operation and maintenance management system 201 can execute the node restart operation, compared with the prior art, the embodiment of the present invention does not need an offline negotiation process, and can process the update-type service in time through the closed-loop processing, thereby avoiding the system branching problem of blocks and the like caused by abnormal interruption of the in-transit service during the restart process, and better service experience is guaranteed.
In one embodiment, as shown in fig. 3, the block link point restart apparatus 10 further comprises: a restart to-be-executed identifier updating unit 105, configured to update the preset node restart to-be-executed identifier to a node restart to-be-executed state. The node restart to-be-executed identifier is used for indicating whether the node is in a restart to-be-executed state, and when the node restart to-be-executed identifier indicates that the node is in the restart to-be-executed state, closed-loop operation is executed.
Accordingly, the block link point restart device 10 further includes: a judgment unit 106, a job request processing unit 107, and an inquiry unit 108, wherein:
a determining unit 106, configured to determine whether the preset node restart to-be-executed identifier indicates a node restart to-be-executed state.
A job request processing unit 107, configured to, when the determination result is negative, perform a re-check operation on the job request, that is, detect whether the job request is a repeat service; and rejecting the update type service request when the judgment result is yes and the job request is the update type service request.
The query unit 108 is configured to, when the operation request is a query type service request, execute an operation corresponding to the query type service request.
That is, when the node restart to-be-executed identifier indicates that the node is in a restart to-be-executed state, if the received job request is an update type service request, the update type service request is rejected; if the received job request is a query-type service request, it may be executed.
In one embodiment, the block link point restart device 10 may further include: and the secure restart identifier updating unit 109 is configured to update the secure restart identifier in the preset service chain to a restart state. The secure restart marker is used to indicate whether a block link point is in a restart state. And when the operation and maintenance management system executes the node restarting operation, the safe restarting identification is updated to be in a restarting state.
For a better understanding of the present invention, embodiments of the present invention are described in detail below in conjunction with the exemplary architecture diagram of the system shown in FIG. 4.
As shown in fig. 4, the system includes: a service chain 1, a verification node 2 (having the function of the above block link node restarting device 10), a verification node operation and maintenance management system 3 (corresponding to the above operation and maintenance management system 201), and a service system 4 (corresponding to the above service system 202). Each of the portions is described below.
(1) Service chain 1
The service chain 1 is constructed according to the uplink service requirement of an external service system 4, the chain comprises a plurality of verification nodes 2, all belong to member nodes of the service chain, and the member nodes are all provided with a system intelligent contract for performing system restart operation request interaction with a verification node operation and maintenance management system 3 and a service intelligent contract for performing service request interaction with the service system 4. Assuming that the total number of verification nodes is 3f +1, wherein f represents the number of supportable fault-tolerant nodes, the minimum value is 1, the system restart operation request and the service request adopt a Byzantine fault-tolerant algorithm for consensus, after each verification node in a service chain receives at least 2f +1 consistent confirmation messages from other verification nodes, the transaction can complete the consensus at the current stage, after the consensus at three stages of the Byzantine fault-tolerant algorithm is completed, the consensus is successful, the system restart operation request and the service request are executed, and the execution result can be used as legal data to generate a new block and carry out persistence.
(2) Authentication node 2
The verification node 2 is used for receiving a system restart operation request initiated by an external verification node operation and maintenance management system 3 and a service request initiated by a service system 4, all the verification nodes have consistent internal structures, performing authority verification on transactions and completing repetition and parameter validity check, broadcasting the transactions to other verification nodes in a service chain 1 after the check is passed, receiving block broadcast notification to be identified of other verification nodes, performing parameter validity check on the transactions to be identified, entering a three-stage consensus process after the check is passed, wherein the first stage is pre-prepare consensus, the second stage is pre-prepare consensus, the third stage is commit consensus, the three stages are sequentially executed, after the consistency confirmation messages of 2f +1 other transaction consensus nodes are cumulatively received in the current stage, the consensus in the current stage is completed and enters the next stage, the common identification of the three stages is completely finished, the subsequent table block batch common identification message is legal, new block data is generated according to the data after logic processing in the contract, and the relevant system flow after the contract is executed is triggered.
(3) Verification node operation and maintenance management system 3
The operation and maintenance management system 3 of the verification node is a matching management operation and maintenance system of the verification node 2, and is generally deployed by different alliance member parties of the service chain 1, one verification node operation and maintenance management system 3 can manage one or more verification nodes 2 according to the alliance operation convention operation and maintenance of the service chain 1, that is, a plurality of verification nodes 2 of the service chain 1 are matched with a plurality of verification node operation and maintenance management systems 3 at the same time, the internal structures of the verification node operation and maintenance management systems 3 are all consistent, and only the managed verification node information is different. The verification node operation and maintenance management system 3 may initiate a restart request instruction of the service link blockchain network (i.e., the above-mentioned node restart operation request) to the verification node 2, and may receive the restart instruction of the service link blockchain network pushed by the verification node 2 (i.e., the above-mentioned node restart instruction) and perform a restart operation of the verification node 2. The operation and maintenance management system 3 of the verification node can also initiate a restart query instruction of the service chain blockchain network to the verification node 2, and query the evidence storage record of the related safe restart operation of the service chain blockchain network.
(4) Service system 4
The service system 4 is a service transaction request initiating system, initiates a service transaction request to the verification node 2 of the service chain 1, including update type transactions and query type transactions, receives the transaction request processing return information of the verification node 2, and performs related service logic closed loop.
Fig. 5 is a block diagram of the structure of the verification node 2, and as shown in fig. 5, the verification node 2 includes: the system comprises an external request transceiver 11, a transaction routing device 12, a pre-made chain code consensus and execution device 13 and a service contract consensus and execution device 14. Preferably, the verification node 2 has the function of the block link point restart device 10 described above. Each part is described in detail below.
(1) External request transmitter-receiver 11
The external request transceiver 11 is responsible for receiving a restart operation request initiated by the verification node operation and maintenance management system 3 and a service request initiated by the service system 4, verifying a transaction according to a transaction certificate, detecting whether a current system has successfully executed a system restart instruction, detecting whether a related intelligent contract has been normally deployed and operated on a current network node, and repeatedly submitting and judging the transaction.
(2) Transaction routing device 12
The transaction routing device 12 is responsible for judging the transaction type of the intelligent contract and controlling the transaction to enter a corresponding contract consensus route.
(3) Prefabricated chain code consensus and execution device 13
The pre-formed chain code consensus and execution device 13 is a core working device for the safe restart of the service chain blockchain network, and is responsible for performing validity check on a restart operation request initiated by the verification node operation and maintenance management system 3, performing instruction consensus, triggering a relevant restart process of the service chain blockchain network according to a service rule (corresponding to the preset restart operation contract) in the pre-formed chain code, completing block update, sending a restart flag update instruction, receiving instruction feedback information, updating a restart operation identifier, and pushing a restart instruction to the verification node operation and maintenance management system 3.
Referring to fig. 5, the apparatus 13 for recognizing and executing the pre-formed chain codes specifically includes: an instruction checking module 131, an instruction consensus module 132, and an instruction notification sending module 133, wherein:
the instruction checking module 131 is configured to check a received restart operation request instruction, specifically, check a system restart operation parameter and perform instruction consensus preprocessing, and is mainly responsible for checking information such as a transaction request parameter and a source, generate a hash (hash) of an instruction request block after the check is passed, store a block consensus message in a local disk, add 1 to a block sequence number, and then broadcast the block consensus message to other verification nodes 2 in the service chain 1.
The instruction consensus module 132 is a core module for completing system restart instruction consensus, performs a three-stage consensus process on the transaction by using a Byzantine consensus algorithm, represents that the system restart instruction request is legal when the consensus of the three stages is completed, and performs persistent endorsement according to a data write-in block after the system restart prefabricated chain code logic processing.
Fig. 6 is a flow chart of the consensus process of the instruction consensus module 132, as shown in fig. 6, the flow chart includes:
step 601: the verification node 2 receives a restart operation request instruction of the verification node operation and maintenance management system 3, and the format of the restart operation request instruction is as follows: the system comprises a contract execution sandbox, a runtime (stub, function, args), a function and an args, wherein the stub is a container support interface provided by the contract execution sandbox, the function is a contract function name required to be called, and the args is an input parameter corresponding to the contract function. And analyzing the request parameters and judging whether the transaction is a repeated submission transaction.
Step 602B: if the transaction is judged not to be repeatedly submitted, the pre-formed chain code consensus and execution device 13 stores the transaction request into a local memory array (reqStore) and judges the transaction type.
Step 603B: and if the transaction type function value is update, the transaction is represented as an update request transaction, the query request parameter args is analyzed and checked, the request data is packaged into block data, the block height is added by 1, the block hash is calculated, and the block height, the block data and the block hash are broadcasted to other member nodes on the service chain 1 for transaction consensus. And then, judging whether the consistent confirmation messages of 2f +1 verification nodes are received or not.
Step 604B: if the consistency confirmation information of 2f +1 verification nodes is not received within overtime, the consensus fails, a failure log is recorded, failure log information of the consensus failure recording is returned, transaction cache information is deleted, the block serial number seqNo is reduced by 1, the transaction failure information is fed back to the verification node operation and maintenance management system to carry out transaction failure closed-loop processing, and the memory array reqStore is cleared.
The instruction notification sending module 133 is a workflow module that completes the system restart instruction consensus result flow, and is responsible for notifying the system restart instruction consensus result to the service contract consensus and execution device 14 and the verification node operation and maintenance management system 3, and the service contract consensus and execution device 14 performs closed-loop processing of the service request in the system restart transition time window (corresponding to the preset restart transition time window), and the verification node operation and maintenance management system 3 performs related system restart closed-loop operation according to the instruction.
(4) Service contract consensus and execution device 14
The service contract consensus and execution device 14 is a core working device for processing a service chain transaction request, and is responsible for performing validity check on a service request initiated by the service system 4, triggering related restart transition time window service closed-loop processing according to a system restart flag, and performing service logics such as transaction consensus and block update in a non-restart time transition time window.
Referring to fig. 5, the service contract consensus and execution device 14 specifically includes: a transaction checking module 141, a transaction query module 142, a transaction consensus module 143, and a system notification receiving module 144, wherein:
the transaction checking module 141 is configured to check the received service request, specifically, check a service request parameter and perform transaction consensus preprocessing, and is responsible for checking information such as a service request parameter and a source, checking a system security restart flag, if the system security restart time window is used, only processing query transaction, and directly rejecting and returning to the service prompt of "during current system update maintenance, please try again later" to the service system 4. And if the time window is a non-system safe restart time window, storing the hash of the service request block into a local disk, adding 1 to the block sequence number, and then broadcasting the block consensus message to other verification nodes in the service chain 1.
The transaction query module 142 is a transaction processing module that completes query-type service requests, and is responsible for returning the latest block information in the current service contract to the service system 4 according to the service requests, and data queries are directly obtained from the local account book without consensus.
The transaction consensus module 143 is a core module for completing update-type service transaction consensus, and performs three-stage consensus processing on the transaction by using a byzantine consensus algorithm within a non-system security restart time window, wherein after the consensus at the three stages is completed, the service request is legal, and data after logical processing according to a service contract is written into a block for persistence.
The system notification receiving module 144 is a workflow module for receiving a system restart instruction, and is responsible for receiving a system restart instruction notification (corresponding to the node restart instruction sent by the instruction internal sending unit 103) sent by the pre-manufactured chain code consensus and execution device 13, updating the secure restart flag according to the transaction timeout time of the service contract, presetting a system restart time window, and feeding back information of successful system secure restart instruction reception to the pre-manufactured chain code consensus and execution device 13 for subsequent process processing after the system restart time window is closed.
Fig. 7 is a flowchart of the restart operation of the authentication node 2, which includes, as shown in fig. 7:
step 701: the verification node 2 in the service chain 1 receives a transaction request from an external system, the external request transceiver 11 determines that a system restart pending execution flag (restart todoflag) is 0, if 0, the transaction router 12 executes a re-check first, if the transaction is a repeated transaction, the transaction router is discarded, and if the transaction is a non-repeated transaction, the transaction router determines the transaction routing according to a contract ID (identification).
Step 703: the instruction checking module 131 checks the information such as the transaction request parameter and the source, generates a hash of the instruction request block after the check is passed, stores the block consensus message reqsymessage in the local disk by using the hash as a key value, adds 1 to the block sequence number seqNo, and broadcasts the block consensus message reqsymessage, the block hash, and the block sequence number seqNo to other verification nodes in the service chain 1.
Step 704: the command consensus module 132 performs a transaction consensus on the block consensus message using a byzantine consensus algorithm. If the consensus fails, recording failure log information, using the block hash to find block request information sucReqSysMessage recorded by the local disk and delete the block request information sucReqSysMessage, subtracting 1 from the block serial number seqnO, removing reqStore, and feeding back transaction failure information to the verification node operation and maintenance management system to prompt the verification node operation and maintenance management system to perform transaction failure closed-loop processing. If the consensus is successful, the sucReqSysMessage, the world state information stateData after the transaction execution, the world state information hashstatehash after the transaction execution, and the block serial number seqNo are used as the latest block data to be persisted, and the instruction update notification module 133 sends the changed system security restart instruction to the service contract consensus and execution device 14.
Step 705: the system notification receiving module 144 receives the system security restart instruction sent by the pre-manufactured chain code consensus and execution device 13, checks the transaction timeout time T seconds set by the current service contract after receiving the system security restart instruction, updates the security restart flag (restart flag) in the service chain to 1, and feeds back the information that the security restart instruction is successfully received to the instruction update notification module 133 after waiting T seconds to ensure that all received update transactions in the system are completely processed.
Step 706: the transaction checking module 141 checks whether the system security restart flag, refartflag, is 1, if so, it indicates that the system security restart process has been entered, checks the transaction type and the information such as the transaction request parameter, and if it is an inquiry transaction, routes the transaction to the transaction inquiry module 142, and returns the inquiry result to the service system 4. If the transaction is an update type transaction, the log is recorded, the reqStore is cleared, and a service prompt of 'the current system is updating and maintaining, and please try again later' is returned to the service system 4 for performing related service closed-loop processing.
Step 707: the instruction update notification module 133 waits for the service contract consensus and the safety restart instruction of the execution device 14 to receive feedback, records the transaction log after the feedback is successfully received, updates the restart to-be-executed flag, namely, restarttoflag, to be 1, and pushes the safety restart instruction to the verification node operation and maintenance management system to prompt the verification node operation and maintenance management system 3 to perform safety restart processing.
Step 708: the operation and maintenance management system 3 of the verification node performs the restart operation of the managed verification node 2 according to the safety restart instruction pushed by the pre-manufactured chain code consensus and execution device 13, and after the restart operation is successful, the system updates the safety restart flag, namely, the restart tofodeflag, into the service chain to be updated to 0, and the restart to-be-executed flag, namely, the restart to 0.
As can be seen from the above description, the embodiment of the present invention provides a system for safely restarting a blockchain network, which can ensure that negotiation operations among member nodes are simple and transparent when the blockchain network needs to be restarted, such as upgrading, and the like, and can ensure that an on-the-way update transaction is not interrupted abnormally during the restart process, and a new transaction is prompted friendly.
In this embodiment, the following advantageous effects can be achieved:
(1) the restart negotiation process is efficient: when a service chain is established, a prefabricated chain code for system safety restarting decision is arranged by default, when restarting is needed, the corresponding system flow is automatically verified and triggered through consensus operation of the prefabricated chain code, and manual intervention is not needed;
(2) the safety traceability of the restart process is as follows: the prefabricated chain code also adopts a block connection technology, trust transfer between service chain verification nodes is realized based on the execution of an intelligent contract, the restarting operation is safe and reliable, and the process can be traced;
(3) ensuring that the in-transit business transaction is not damaged in the restarting process: according to effective marking control in a service chain, the on-the-way service transaction can be normally processed and completed through the customized time window cache, the system abnormal influences such as block branching and the like caused by abnormal interruption are avoided, the on-the-way transaction is not damaged, and the stability and the service experience of a service chain system are improved.
In practical operation, the systems, units and modules referred to in the above embodiments may be combined or may be singly arranged, and the present invention is not limited thereto.
Based on similar inventive concepts, the embodiment of the present invention further provides a method for restarting a block chain node, and preferably, the method is applicable to the above apparatus for restarting a block chain node.
Fig. 8 is a flowchart of the block link point restart method, as shown in fig. 8, the method includes:
And step 802, responding to the operation request as a node restarting operation request, and performing consensus operation based on a preset restarting operation contract.
And 803, in response to the success of the consensus operation, sending a node restart instruction to the service execution unit, so that the service execution unit performs closed-loop processing on the service in the processing state within a preset restart transition time window.
And then, updating the preset safe restart identifier in the service chain into a restart state. And when the safe restart identifier is in a restart state, performing closed-loop processing on the service in the processing state in a restart transition time window.
After that, the preset node restart to-be-executed identifier may be updated to the node restart to-be-executed state. Therefore, when a job request of an external system is received, whether a preset node restart to-be-executed identifier indicates a node restart to-be-executed state can be judged, and when the judgment result is negative, a judgment and re-check operation is carried out on the job request; and rejecting the update type service request when the judgment result is yes and the job request is the update type service request.
In one embodiment, when the operation request is a query type service request, the operation corresponding to the query type service request can be directly executed without being limited by the node restarting the identifier to be executed.
As can be seen from the above description, when a received job request from an external system is a node restart operation request, performing consensus operation on the node restart operation request, and after the consensus operation is successful, sending a node restart instruction to a service execution unit, so that the service execution unit performs closed-loop processing on a service in a processing state within a restart transition time window, and when the service execution unit has processed an update-type service, sending the node restart instruction to the external system, so that the external system can perform the node restart operation.
In actual operation, the specific execution flow of each step may refer to the description in the system embodiment, and is not described herein again.
The present embodiment also provides an electronic device, which may be a desktop computer, a tablet computer, a mobile terminal, and the like, but is not limited thereto. In this embodiment, the electronic device may be implemented by referring to the above method embodiment and the block link point restarting device/system embodiment, and the contents thereof are incorporated herein, and repeated descriptions are omitted.
Fig. 9 is a schematic block diagram of a system configuration of an electronic apparatus 600 according to an embodiment of the present invention. As shown in fig. 9, the electronic device 600 may include a central processor 100 and a memory 140; the memory 140 is coupled to the central processor 100. Notably, this diagram is exemplary; other types of structures may also be used in addition to or in place of the structure to implement telecommunications or other functions.
In one embodiment, the block link point restart function may be integrated into the cpu 100. The central processor 100 may be configured to control as follows:
receiving a job request from an external system, the job request being one of: restarting the operation request and the service request by the node;
responding to the operation request as a node restarting operation request, and performing consensus operation based on a preset restarting operation contract;
responding to success of consensus operation, sending a node restart instruction to a service execution unit so that the service execution unit performs closed-loop processing on services in a processing state within a preset restart transition time window;
and responding to the completion of processing of the received update type service from the service execution unit, and sending a node restart instruction to the external system so as to enable the external system to execute node restart operation.
As can be seen from the above description, the electronic device provided in the embodiment of the present application, when a job request received from an external system is a node restart operation request, performing consensus operation on the node restart operation request, sending a node restart instruction to the service execution unit after the consensus operation is successful, so that the service execution unit performs closed-loop processing on the service in the processing state in the restart transition time window, and when the service execution unit has processed the update type service, the node restart instruction is sent to the external system, so that the external system can perform the node restart operation, compared with the prior art, the embodiment of the invention does not need the offline negotiation process, and the updating type service can be processed in time through closed-loop processing, the system problems of block branching and the like caused by abnormal interruption of the in-transit service in the restarting process are avoided, and better service experience is guaranteed.
In another embodiment, the block link point restarting device/system may be configured separately from the cpu 100, for example, the block link point restarting device/system may be configured as a chip connected to the cpu 100, and the block link point restarting function is realized by the control of the cpu.
As shown in fig. 9, the electronic device 600 may further include: communication module 110, input unit 120, audio processing unit 130, display 160, power supply 170. It is noted that the electronic device 600 does not necessarily include all of the components shown in FIG. 9; furthermore, the electronic device 600 may also comprise components not shown in fig. 9, which may be referred to in the prior art.
As shown in fig. 9, the central processor 100, sometimes referred to as a controller or operational control, may include a microprocessor or other processor device and/or logic device, the central processor 100 receiving input and controlling the operation of the various components of the electronic device 600.
The memory 140 may be, for example, one or more of a buffer, a flash memory, a hard drive, a removable media, a volatile memory, a non-volatile memory, or other suitable device. The information relating to the failure may be stored, and a program for executing the information may be stored. And the central processing unit 100 may execute the program stored in the memory 140 to realize information storage or processing, etc.
The input unit 120 provides input to the cpu 100. The input unit 120 is, for example, a key or a touch input device. The power supply 170 is used to provide power to the electronic device 600. The display 160 is used to display an object to be displayed, such as an image or a character. The display may be, for example, an LCD display, but is not limited thereto.
The memory 140 may be a solid state memory such as Read Only Memory (ROM), Random Access Memory (RAM), a SIM card, or the like. There may also be a memory that holds information even when power is off, can be selectively erased, and is provided with more data, an example of which is sometimes called an EPROM or the like. The memory 140 may also be some other type of device. Memory 140 includes buffer memory 141 (sometimes referred to as a buffer). The memory 140 may include an application/function storage section 142, and the application/function storage section 142 is used to store application programs and function programs or a flow for executing the operation of the electronic device 600 by the central processing unit 100.
The memory 140 may also include a data store 143, the data store 143 for storing data, such as contacts, digital data, pictures, sounds, and/or any other data used by the electronic device. The driver storage portion 144 of the memory 140 may include various drivers of the electronic device for communication functions and/or for performing other functions of the electronic device (e.g., messaging application, address book application, etc.).
The communication module 110 is a transmitter/receiver 110 that transmits and receives signals via an antenna 111. The communication module (transmitter/receiver) 110 is coupled to the central processor 100 to provide an input signal and receive an output signal, which may be the same as in the case of a conventional mobile communication terminal.
Based on different communication technologies, a plurality of communication modules 110, such as a cellular network module, a bluetooth module, and/or a wireless local area network module, may be provided in the same electronic device. The communication module (transmitter/receiver) 110 is also coupled to a speaker 131 and a microphone 132 via an audio processor 130 to provide audio output via the speaker 131 and receive audio input from the microphone 132 to implement general telecommunications functions. Audio processor 130 may include any suitable buffers, decoders, amplifiers and so forth. In addition, an audio processor 130 is also coupled to the central processor 100, so that recording on the local can be enabled through a microphone 132, and so that sound stored on the local can be played through a speaker 131.
An embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored, where the computer program is executed by a processor to implement the steps of the block link point restarting method.
In summary, the embodiment of the present invention provides a block chain network secure restart scheme, where a secure restart prefabricated chain code is introduced, the prefabricated chain code is configured by default when a block chain service chain is established to implement upgrade start operation consensus of block chain nodes, after an external trigger instruction for upgrade start is received, the consensus of the instruction is performed among service chain member nodes, only the upgrade start instruction that the consensus passes through is really triggered, meanwhile, a secure restart flag is used to ensure normal return of an in-transit update transaction in the triggering process, and a new transaction return friendly prompt is added, so that automation and security of the upgrade start process of the block chain service chain can be ensured, a complicated and tedious offline negotiation process is avoided, system problems such as block bifurcation caused by abnormal interruption of the in-transit transaction are avoided, and good service experience is ensured.
The preferred embodiments of the present invention have been described above with reference to the accompanying drawings. The many features and advantages of the embodiments are apparent from the detailed specification, and thus, it is intended by the appended claims to cover all such features and advantages of the embodiments which fall within the true spirit and scope thereof. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the embodiments of the invention to the exact construction and operation illustrated and described, and accordingly, all suitable modifications and equivalents may be resorted to, falling within the scope thereof.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
The principle and the implementation mode of the invention are explained by applying specific embodiments in the invention, and the description of the embodiments is only used for helping to understand the method and the core idea of the invention; meanwhile, for a person skilled in the art, according to the idea of the present invention, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present invention.
Claims (13)
1. A method of restarting a blockchain node, the method comprising:
receiving a job request from an external system, the job request being one of: restarting the operation request and the service request by the node;
responding to the operation request as a node restarting operation request, and performing consensus operation based on a preset restarting operation contract;
responding to success of consensus operation, sending a node restart instruction to a service execution unit so that the service execution unit performs closed-loop processing on services in a processing state within a preset restart transition time window;
and responding to the completion of processing of the received update type service from the service execution unit, and sending a node restart instruction to the external system so as to enable the external system to execute node restart operation.
2. The method of claim 1, wherein after sending a node restart instruction to the external system, the method further comprises:
and updating the preset node restart to-be-executed identifier into a node restart to-be-executed state.
3. The method of claim 2, wherein after receiving a job request from an external system, the method further comprises:
judging whether the preset node restart to-be-executed identifier indicates a node restart to-be-executed state or not;
when the judgment result is negative, carrying out a reexamination operation on the operation request; and rejecting the update type service request when the judgment result is yes and the job request is the update type service request.
4. The method of claim 3, wherein when the job request is a query-type service request, the method further comprises:
and executing the operation corresponding to the query type service request.
5. The method of claim 1, wherein after sending a node restart instruction to a service execution unit, the method further comprises:
and updating the preset safe restart identifier in the service chain into a restart state.
6. A block link point restart apparatus, the apparatus comprising:
a job request receiving unit configured to receive a job request from an external system, the job request being one of: restarting the operation request and the service request by the node;
the consensus unit is used for responding to the operation request which is a node restarting operation request and carrying out consensus operation based on a preset restarting operation contract;
the instruction internal sending unit is used for responding to the success of the consensus operation and sending a node restarting instruction to the service execution unit so as to enable the service execution unit to carry out closed-loop processing on the service in the processing state in a preset restarting transition time window;
and the instruction external sending unit is used for responding to the completion of processing of the received update type service from the service execution unit and sending a node restart instruction to the external system so as to enable the external system to execute node restart operation.
7. The apparatus of claim 6, further comprising:
and the restarting to-be-executed identifier updating unit is used for updating the preset node restarting to-be-executed identifier into a node restarting to-be-executed state.
8. The apparatus of claim 7, further comprising:
the judging unit is used for judging whether the preset node restarting to-be-executed identifier indicates a node restarting to-be-executed state;
the job request processing unit is used for carrying out repeated check operation on the job request when the judgment result is negative; and rejecting the update type service request when the judgment result is yes and the job request is the update type service request.
9. The apparatus of claim 8, wherein when the job request is a query-type service request, the apparatus further comprises:
and the query unit is used for executing the operation corresponding to the query type service request.
10. The apparatus of claim 6, further comprising:
and the safe restart identifier updating unit is used for updating the safe restart identifier in the preset service chain into a restart state.
11. A system for restarting a block link point, the system comprising: the apparatus according to any one of claims 6 to 10, and an external system comprising an operation and maintenance management system and a service system, wherein the apparatus is located on a verification node side, the operation and maintenance management system sends a node restart operation request to the apparatus and performs a node restart operation, and the service system sends a service request to the apparatus.
12. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the steps of the method according to any of claims 1 to 5 are implemented when the processor executes the program.
13. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011147256.7A CN112199239B (en) | 2020-10-23 | 2020-10-23 | Restarting method, device and system of block chain node |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011147256.7A CN112199239B (en) | 2020-10-23 | 2020-10-23 | Restarting method, device and system of block chain node |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112199239A true CN112199239A (en) | 2021-01-08 |
| CN112199239B CN112199239B (en) | 2023-10-27 |
Family
ID=74011060
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011147256.7A Active CN112199239B (en) | 2020-10-23 | 2020-10-23 | Restarting method, device and system of block chain node |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112199239B (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110032436A (en) * | 2019-04-04 | 2019-07-19 | 杭州秘猿科技有限公司 | Support the block chain of pause and starting common recognition method, system and electronic equipment |
| US20190356469A1 (en) * | 2018-05-16 | 2019-11-21 | International Business Machines Corporation | Identifying faults in a blockchain ordering service |
| CN111026569A (en) * | 2019-10-25 | 2020-04-17 | 贵阳信息技术研究院（中科院软件所贵阳分部） | Method for repairing designated block data in alliance chain |
| CN111478828A (en) * | 2020-06-24 | 2020-07-31 | 支付宝(杭州)信息技术有限公司 | Pressure testing method, device and system for block chain network |
-
2020
- 2020-10-23 CN CN202011147256.7A patent/CN112199239B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20190356469A1 (en) * | 2018-05-16 | 2019-11-21 | International Business Machines Corporation | Identifying faults in a blockchain ordering service |
| CN110032436A (en) * | 2019-04-04 | 2019-07-19 | 杭州秘猿科技有限公司 | Support the block chain of pause and starting common recognition method, system and electronic equipment |
| CN111026569A (en) * | 2019-10-25 | 2020-04-17 | 贵阳信息技术研究院（中科院软件所贵阳分部） | Method for repairing designated block data in alliance chain |
| CN111478828A (en) * | 2020-06-24 | 2020-07-31 | 支付宝(杭州)信息技术有限公司 | Pressure testing method, device and system for block chain network |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112199239B (en) | 2023-10-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3654618B1 (en) | Audio broadcasting method, device, and system, and smart broadcasting apparatus | |
| US10064025B2 (en) | Offline peer-assisted notification delivery | |
| CN111382164B (en) | Service processing method based on block chain network | |
| CN109447601B (en) | Method for performing witness transfer transactions in blockchain networks | |
| CN110601858B (en) | Certificate management method and device | |
| US7366505B2 (en) | Apparatus and method for delivering messages to a mobile information terminal | |
| CN113395315B (en) | Message broadcasting method, cloud loudspeaker box and cloud pushing platform | |
| CN113282310A (en) | Application management method and system, vehicle-mounted device, server and readable storage medium | |
| CN113179282A (en) | Method and device for merging account numbers and server | |
| CN113760611B (en) | System site switching method and device, electronic equipment and storage medium | |
| CN111222869A (en) | Transaction data processing method, device, computer equipment and medium | |
| CN110769411A (en) | Method, device, equipment and system for stably realizing batch OTA (over the air) upgrade of terminal equipment | |
| CN112087475A (en) | Message pushing method and device for cloud platform component application and message server | |
| CN111262747B (en) | Internet of things-based equipment network access control method and Internet of things platform | |
| CN112199239A (en) | Method, device and system for restarting block chain node | |
| CN113347033B (en) | Root cause positioning method and system based on block chain and verification node | |
| CN114285657B (en) | Firewall security policy change verification method and device | |
| CN111666590A (en) | Distributed file secure transmission method, device and system | |
| CN113268272B (en) | Application delivery method, device and system based on private cloud | |
| CN112381538A (en) | Data processing method, terminal equipment and storage medium | |
| CN112732660A (en) | Intervention type file transmission method, device and system | |
| CN112101810A (en) | Risk event control method, device and system | |
| CN114640956A (en) | Short message issuing method, device and system and electronic equipment | |
| CN115118628B (en) | Abnormal message processing method and device | |
| CN114202427B (en) | Block chain-based private fund raising method, system and storage medium |
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 |