CN111507719B - Method and system for dynamically updating alliance chain verification node in centralized mode - Google Patents
Method and system for dynamically updating alliance chain verification node in centralized mode Download PDFInfo
- Publication number
- CN111507719B CN111507719B CN202010321250.0A CN202010321250A CN111507719B CN 111507719 B CN111507719 B CN 111507719B CN 202010321250 A CN202010321250 A CN 202010321250A CN 111507719 B CN111507719 B CN 111507719B
- Authority
- CN
- China
- Prior art keywords
- node
- public key
- consensus
- web service
- service provider
- 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.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention relates to the technical field of blockchains, and provides a method for dynamically updating a alliance chain verification node in a centralized manner, which comprises the following steps: s1, setting a Web service provider, wherein the Web service provider is provided with a pair of public keys and private key pairs, and manages a public key list of consensus nodes; and S2, after receiving the request of the nodes of the alliance chain, the Web server returns response data to the nodes, wherein the response data comprises a public key list of the consensus nodes for updating by the nodes. The invention also correspondingly provides a system for dynamically updating the alliance chain verification node in a centralized mode. The invention can make the node join/exit the consensus network without restarting the old node, thus realizing dynamic update.
Description
Technical Field
The present invention relates to blockchain technology, and more particularly, to a method and system for dynamically updating federated chain authentication nodes in a centralized manner
Background
The alliance chain refers to a blockchain with a plurality of institutions participating in management together, each institution runs one or more nodes, wherein data only allows different institutions in the system to read, write and send transactions, and the transaction data is recorded together. The design privacy rights may vary between private chains and federation chains, and the rights design requirements in blockchain federation chains tend to be more complex. Essentially, the federation chain belongs to a private chain, but the degree of privatization is different.
The federation chain is typically limited in number of nodes and one node can communicate with all other nodes, ultimately achieving consensus by voting. This involves the problem of nodes joining/exiting the consensus network, how to quickly notify all consensus nodes when a node joins/exits the consensus network, and it is an important issue to have an updated list of consensus nodes in the next round of consensus.
The most straightforward approach is to first shut down all consensus nodes and modify the configuration file and then reload all consensus nodes, but this approach is inefficient and requires the entire blockchain network to be taken out of service, and is therefore not desirable.
Another way is that when the node joins/exits, an administrator constructs a transaction of joining/exiting the node, sends the transaction to the chain to make consensus, and after the consensus passes, the consensus nodes use a new consensus node list to make a new round of consensus. This has the advantage that the old consensus node does not need to be restarted, the effect of dynamic updating is achieved, and the disadvantage that events which are irrelevant to the service, such as the joining/exiting of the consensus node, are recorded on the chain.
Disclosure of Invention
Aiming at the problems in the background technology, the invention provides a method for dynamically updating a alliance chain verification node in a centralized mode, which comprises the following steps: s1, setting a Web service provider, wherein the Web service provider is provided with a pair of public keys and private key pairs, and manages a public key list of consensus nodes; and S2, after receiving the request of the nodes of the alliance chain, the Web server returns response data to the nodes, wherein the response data comprises a public key list of the consensus nodes for updating by the nodes.
The invention also provides a system for dynamically updating the alliance chain verification node in a centralized mode, which comprises a Web service provider and a node, wherein the Web service provider is provided with a pair of public keys and private key pairs, manages a public key list of the consensus node, and returns response data to the node after receiving a request of the node of the alliance chain, wherein the response data comprises the public key list of the consensus node for updating by the node; the node is configured with a Web service request address of a Web service provider and a signature public key of the Web service provider; periodically initiating a Web request to the Web service provider by the node, and obtaining response data from the Web service provider; the node judges whether the public key list of the consensus is changed, if so, the local public key list is updated, and the new public key list of the consensus is directly used in a new round of consensus.
The beneficial effects of the invention include: 1) The nodes join/exit the consensus network, and the old nodes do not need to be restarted, so that dynamic updating is realized; 2) The events which are irrelevant to the services such as the joining/exiting of the node to the consensus network do not need to be recorded on the chain through the transaction; 3) All consensus nodes can finally achieve consensus, and a new round of consensus is entered by using the latest consensus node list; 4) The same list of public keys is not applied multiple times (guaranteed by Sequence); 5) The list of public keys that are common knowledge returned by the Web service cannot be tampered with (signature assurance).
Drawings
For easier understanding of the present invention, the present invention will be described in more detail by referring to specific embodiments shown in the drawings. These drawings depict only typical embodiments of the invention and are not therefore to be considered to limit the scope of the invention.
FIG. 1 is a flow chart of one embodiment of the method of the present invention.
Fig. 2 is a flow chart of another embodiment of the method of the present invention.
Detailed Description
Embodiments of the present invention will now be described with reference to the drawings, wherein like elements are designated by like reference numerals. The following embodiments and technical features in the embodiments may be combined with each other without collision.
Fig. 1 shows a flow chart of the method of the present invention.
S1, setting a Web service provider, wherein the Web service provider is provided with a pair of public keys and private key pairs, and managing a public key list of the consensus nodes.
The federation chain differs greatly from the public chain in that there are a small number of nodes in the federation chain, each node knows the public keys of all other nodes in common, and the collection of these public keys is called the public key list of the common nodes.
The Web service request address of the Web service provider and the signature public key of the Web service provider are configured in each node of the federation chain.
S3, the node periodically (e.g. at 1 second intervals) initiates a Web request, and obtains response data from the Web service provider, where the response data includes a public key list of consensus nodes.
More specifically, the Web service provider constructs the response data after service initiation, the steps comprising:
a1 Reading a list of public keys in the configuration file;
a2 Signing the list of public keys with the private key;
a3 The public key, the public key list signature, the public key list and the current sequence number are included into the response data together, and the response data is directly returned when waiting for the request of the node. The current sequence number may be incremented.
Thus, the response data includes: the method comprises the steps of signing public key publicKey of a Web service provider, consensus public key list Validator list, signing public key list Signature and Sequence number Sequence.
And S4, the node judges whether the public key list of the consensus is changed, if so, the local public key list of the consensus is updated, and the new public key list of the consensus is directly used in a new round of consensus.
Specifically, after the consensus list is obtained, the node judges whether the list has a change or not through a Sequence field of a Sequence number in the returned response. If the Sequence number is changed, the node verifies whether the signature of the public key list is correct or not through the locally configured public key of the Web server. If so, the local public key list is updated.
Preferably, after the node obtains the response, it determines whether there is a change in the public key list through Sequence number Sequence. The function of the Sequence number is equivalent to the current version number, the node caches the processed Sequence number, and when the consensus public key list is acquired next time, whether the response is processed or not is judged by comparing the cached Sequence number with the Sequence number of the current response so as to avoid repeated processing of the response.
Preferably, to prevent exposure of the private key of the Web service provider, the public key list can be signed off-line, and the signature is updated simultaneously when the public key list is updated, without configuring the private key into the Web service provider.
As shown in fig. 2, when a node joins or exits the federation chain, the node notifies the Web service provider, and for different situations, the flow of the Web service provider is as follows.
When a node joins the consensus network, the Web service provider updates the consensus public key list, synchronizes the latest block, and opens the consensus. The new node requests a list of public keys for consensus from the Web service provider. For the old node, a request is made to the Web service provider to read the public key list of the consensus, and a new round of consensus is entered using the new public key list of the consensus. When the node exits, the Web service provider updates the consensus public key list.
It can be seen that when a node joins or exits, after receiving a notification, the Web service provider updates the maintained public key list, updates the public key list, and restarts the Web service. Thus, the old node does not need to be restarted, and dynamic updating is achieved.
In addition, because the blockchain is a distributed system, the workflow of each consensus node is independent, some nodes update the consensus public key list faster, some nodes are slower, each node cannot guarantee the consistency of the time for updating the consensus public key list, and the problem that the new blocks cannot achieve consensus due to inconsistent block numbers of each node applying the new consensus list may occur.
For example, in a blockchain using PBFT as the consensus algorithm, the consensus nodes change from 7 to 4, provided that the following formula is used:
leader_index＝(ledger_index+view)％node_size
as a leader node election algorithm, assuming that two of the remaining 4 consensus nodes update the consensus public key list before entering the next round of block consensus, and two update the consensus public key list after entering the next round of block consensus, a situation of inconsistent leader_index calculation occurs, so that two leader appears, and finally consensus cannot be achieved.
If the remaining 4 nodes number 1, 2, 3, 4, the next round of chunks ' ledger_index=100, view=0, nodes 1, 2 update the public key list of consensus before entering 100 # chunk consensus, node_size=4, and nodes 3, 4 update the public key list of consensus after entering 100 # chunk consensus, node_size=7, then for nodes 1, 2 ' leder_index= (100+0)% 4=0, and for nodes 3, 4 ' leder_index= (100+0)% 7=2.
For the cases presented above, the method of the invention is: if the block cannot achieve consensus, judging whether the consensus public key list is updated just, if so, rolling back the block to the last block achieving consensus, and restarting block consensus by using the new consensus public key list.
In the above example, block 100 cannot agree, but block 99 can agree, and then 4 nodes can restart the consensus of block 100 with the new consensus public key list, so that a consensus leader node can be obtained, and finally agree.
According to another aspect of the present invention, a system for dynamically updating federation authentication nodes in a centralized manner is provided, the system comprising: service providers and nodes. The service provider and node implement the functions and steps as described previously.
The Web service provider has a pair of public and private key pairs and manages a public key list of consensus nodes. The Web service provider constructs response data after service initiation, including:
a1 Reading a list of public keys in the configuration file;
a2 Signing the list of public keys with the private key;
a3 The public key, the public key list signature, the public key list and the current sequence number are included into the response data together, and the response data is directly returned when waiting for the request of the node. The current sequence number may be incremented.
Thus, the response data includes: the method comprises the steps of signing public key publicKey of a Web service provider, consensus public key list Validator list, signing public key list Signature and Sequence number Sequence.
The Web service request address of the Web service provider and the signature public key of the Web service provider are configured in each node of the federation chain. The nodes periodically (e.g., 1 second apart) initiate Web requests and obtain response data from the Web service provider, the response data comprising a list of public keys of the consensus nodes.
The node judges whether the public key list of the consensus is changed, if so, the local public key list is updated, and the new public key list of the consensus is directly used in a new round of consensus. Specifically, after the consensus list is obtained, the node judges whether the list has a change or not through a Sequence field of a Sequence number in the returned response. If the Sequence number is changed, the node verifies whether the signature of the public key list is correct or not through the locally configured public key of the Web server. If so, the local public key list is updated.
Preferably, after the node obtains the response, it determines whether there is a change in the public key list through Sequence number Sequence. The function of the Sequence number is equivalent to the current version number, the node caches the processed Sequence number, and when the consensus public key list is acquired next time, whether the response is processed or not is judged by comparing the cached Sequence number with the Sequence number of the current response so as to avoid repeated processing of the response.
Preferably, to prevent exposure of the private key of the Web service provider, the public key list can be signed off-line, and the signature is updated simultaneously when the public key list is updated, without configuring the private key into the Web service provider.
When a node joins or exits the federation chain, the node notifies the Web service provider, and for different situations, the flow of the Web service provider is as follows.
When a node joins the consensus network, the Web service provider updates the consensus public key list, synchronizes the latest block, and opens the consensus. The new node requests a list of public keys for consensus from the Web service provider. For the old node, a request is made to the Web service provider to read the public key list of the consensus, and a new round of consensus is entered using the new public key list of the consensus. When the node exits, the Web service provider updates the consensus public key list.
It can be seen that when a node joins or exits, after receiving a notification, the Web service provider updates the maintained public key list, updates the public key list, and restarts the Web service. Thus, the old node does not need to be restarted, and dynamic updating is achieved.
In addition, because the blockchain is a distributed system, the workflow of each consensus node is independent, some nodes update the consensus public key list faster, some nodes are slower, each node cannot guarantee the consistency of the time for updating the consensus public key list, and the problem that the new blocks cannot achieve consensus due to inconsistent block numbers of each node applying the new consensus list may occur. If the block cannot achieve consensus, judging whether the consensus public key list is updated just, if so, rolling back the block to the last block achieving consensus, and restarting block consensus by using the new consensus public key list.
The above embodiments are only preferred embodiments of the present invention, and it is intended that the common variations and substitutions made by those skilled in the art within the scope of the technical solution of the present invention are included in the scope of the present invention.
Claims (9)
1. A method for dynamically updating a federated chain verification node in a centralized manner, comprising:
setting a Web service provider, wherein the Web service provider is provided with a pair of public keys and private key pairs, and manages a public key list of the consensus nodes;
configuring a Web service request address of a Web service provider and a signature public key of the Web service provider in each node of the alliance chain;
periodically initiating a Web request to the Web service provider by the node, and obtaining response data from the Web service provider;
after receiving a request of a node of the alliance chain, the Web service provider returns response data to the node, wherein the response data comprises a public key list of the consensus node for updating by the node;
the node judges whether the public key list of the consensus node has a change, if so, the local public key list of the consensus node is updated, and the new public key list of the consensus node is directly used in a new round of consensus.
2. The method of claim 1, wherein the response data is constructed by:
a1 A Web service provider reads a public key list of the consensus node;
a2 A Web service provider signs the public key list of the consensus nodes by using the private key;
a3 The Web service provider includes the own public key, the public key list signature of the consensus node, the public key list of the consensus node and the current sequence number into the response data to form the response data.
3. The method for dynamically updating a federated chain authentication node in a centralized fashion as recited in claim 1,
after the public key list of the consensus node is obtained, the node judges whether the list has change or not through the serial number in the returned response,
if the serial number is changed, the node verifies whether the signature of the public key list of the public nodes is correct through the public key of the locally configured Web service provider, and if so, the public key list of the local public nodes is updated.
4. The method for dynamically updating a federated chain authentication node in a centralized fashion as recited in claim 1,
when the block cannot reach the consensus, judging whether the public key list of the consensus node is updated just, if so, rolling back the block to the last block reaching the consensus, and restarting the block consensus by using the new public key list of the consensus node.
5. The method for dynamically updating a federated chain verification node in a centralized fashion of claim 1, further comprising:
when the node joins or exits, after receiving the notification, the Web service provider updates the public key list of the public key of the node, and restarts the Web service.
6. The method for dynamically updating a federated chain verification node in a centralized fashion of claim 2, further comprising:
the public key list of the common node is signed off line, when the public key list of the common node is updated, the signature is updated at the same time, and the private key is not configured in the Web service provider.
7. A system for dynamically updating alliance chain verification nodes in a centralized manner is characterized by comprising a Web service provider and nodes,
the Web service provider is provided with a pair of public keys and private key pairs, manages a public key list of the consensus nodes, and returns response data to the nodes after receiving the request of the nodes of the alliance chain, wherein the response data comprises the public key list of the consensus nodes for updating by the nodes;
the node is configured with a Web service request address of a Web service provider and a signature public key of the Web service provider; periodically initiating a Web request to the Web service provider by the node, and obtaining response data from the Web service provider; the node judges whether the public key list of the consensus node has a change, if so, the local public key list of the consensus node is updated, and the new public key list of the consensus node is directly used in a new round of consensus.
8. The system for dynamically updating federated chain authentication nodes in a centralized fashion as recited in claim 7,
the response data is constructed by the steps of: a1 A Web service provider reads a public key list of the consensus node; a2 A Web service provider signs the public key list of the consensus nodes by using the private key; a3 The Web service provider includes the self public key, the public key list signature of the consensus node, the public key list of the consensus node and the current sequence number into the response data to form the response data;
after the public key list of the consensus node is obtained, the node judges whether the list is changed or not by returning a sequence number in the response, if the sequence number is changed, the node verifies whether the signature of the public key list of the consensus node is correct or not by a locally configured public key of the Web service provider, and if the signature of the public key list of the consensus node is correct, the local public key list of the consensus node is updated.
9. The system for dynamically updating federated chain authentication nodes in a centralized fashion as recited in claim 7,
when the node joins or exits, after receiving the notification, the Web service provider updates the public key list of the public key of the node, and restarts the Web service.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010321250.0A CN111507719B (en) | 2020-04-22 | 2020-04-22 | Method and system for dynamically updating alliance chain verification node in centralized mode |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010321250.0A CN111507719B (en) | 2020-04-22 | 2020-04-22 | Method and system for dynamically updating alliance chain verification node in centralized mode |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111507719A CN111507719A (en) | 2020-08-07 |
| CN111507719B true CN111507719B (en) | 2023-04-28 |
Family
ID=71876586
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010321250.0A Active CN111507719B (en) | 2020-04-22 | 2020-04-22 | Method and system for dynamically updating alliance chain verification node in centralized mode |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111507719B (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106789090A (en) * | 2017-02-24 | 2017-05-31 | 陈晶 | Public key infrastructure system and semi-random participating certificate endorsement method based on block chain |
| CN106878000A (en) * | 2017-03-06 | 2017-06-20 | 中钞信用卡产业发展有限公司北京智能卡技术研究院 | A kind of alliance's chain common recognition method and system |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111756550B (en) * | 2017-03-28 | 2023-08-22 | 创新先进技术有限公司 | Block chain consensus method and device |
| CN108600272B (en) * | 2018-05-10 | 2020-08-04 | 阿里巴巴集团控股有限公司 | Block chain data processing method, device, processing equipment and system |
| CN109450843B (en) * | 2018-09-14 | 2021-06-15 | 众安信息技术服务有限公司 | SSL certificate management method and system based on block chain |
| CA3058244C (en) * | 2019-03-29 | 2021-04-27 | Alibaba Group Holding Limited | Retrieving access data for blockchain networks using highly available trusted execution environments |
-
2020
- 2020-04-22 CN CN202010321250.0A patent/CN111507719B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106789090A (en) * | 2017-02-24 | 2017-05-31 | 陈晶 | Public key infrastructure system and semi-random participating certificate endorsement method based on block chain |
| CN106878000A (en) * | 2017-03-06 | 2017-06-20 | 中钞信用卡产业发展有限公司北京智能卡技术研究院 | A kind of alliance's chain common recognition method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111507719A (en) | 2020-08-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110430087B (en) | Block chain hot upgrade architecture design and implementation | |
| CN110569309B (en) | Apparatus, method, system, and medium for implementing blockchain | |
| US20220108285A1 (en) | Methods and Systems for Object Validated Blockchain Accounts | |
| Decker et al. | Bitcoin meets strong consistency | |
| WO2018228337A1 (en) | Service data storage method, computer readable storage medium and electronic device | |
| WO2019223469A1 (en) | Block chain network management method, device, medium and electronic device | |
| JP6900266B2 (en) | Operation management method, operation management system, and operation management program | |
| CN110572450B (en) | Data synchronization method and device, computer readable storage medium and computer equipment | |
| US11593321B2 (en) | Systems and methods of self-administered protocols on a blockchain platform | |
| WO2019184775A1 (en) | Management data storage method and device, and storage medium | |
| CN111464353B (en) | Block link point management method, device, computer and readable storage medium | |
| US20230037932A1 (en) | Data processing method and apparatus based on blockchain network, and computer device | |
| WO2022121538A1 (en) | Data synchronization method and system based on blockchain, and related device | |
| US20210374112A1 (en) | Migration support system, migration support method, and node | |
| CN112075062A (en) | Automated commit transaction management in blockchain networks | |
| CN110597918A (en) | Account management method and device and computer readable storage medium | |
| CN111447069B (en) | Low-frequency access data processing method based on block chain | |
| CN111737104A (en) | Block chain network service platform, test case sharing method thereof and storage medium | |
| CN112650812A (en) | Data fragment storage method and device, computer equipment and storage medium | |
| US20190385183A1 (en) | Method for automatically providing cryptocurrency to recommender using propagation on sns | |
| CN112507019A (en) | PBFT consensus system and method based on intelligent contracts | |
| CN111507719B (en) | Method and system for dynamically updating alliance chain verification node in centralized mode | |
| CN113449322A (en) | Data sharing method and device based on block chain, electronic equipment and readable medium | |
| KR102349014B1 (en) | Method and system for building fast synchronizable decentralized distributed database | |
| WO2023082883A1 (en) | Cross-blockchain transaction processing method and apparatus, and computer device, computer storage medium and computer program product |
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 |