CN109543456B - Block generation method and computer storage medium - Google Patents
Block generation method and computer storage medium Download PDFInfo
- Publication number
- CN109543456B CN109543456B CN201811312692.8A CN201811312692A CN109543456B CN 109543456 B CN109543456 B CN 109543456B CN 201811312692 A CN201811312692 A CN 201811312692A CN 109543456 B CN109543456 B CN 109543456B
- Authority
- CN
- China
- Prior art keywords
- node
- block
- request
- public key
- signature
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
Abstract
The embodiment of the invention provides a block generation method and a computer storage medium, which are applied to a alliance block chain, wherein the alliance block chain comprises a plurality of nodes, and each node regularly updates a public key and a private key of the node according to an instruction of a central node in the alliance block chain; the block generation method comprises the following steps: acquiring a block generation request initiated by a request node in a block chain of the alliance, wherein the block generation request carries a signature of block content data of a new block to be generated, and the signature of the block content data is signed by a private key updated by the request node; verifying the validity of the public key updated by the request node to a central node of the block chain of the alliance so as to verify the signature of the block content data according to the valid public key; if the signature of the chunk content data passes verification, the requesting node is caused to generate the requested new chunk after the chunk generation request agrees in the federation chunk chain.
Description
Technical Field
The embodiment of the invention relates to the technical field of computers, in particular to a block generation method and a computer storage medium.
Background
The blockchain is a novel application mode which utilizes computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. The block chains are divided into three categories, which are: a public blockchain, a federation blockchain (also referred to as a federation blockchain, an industry blockchain), and a private blockchain.
Wherein, the public block chain aims at all persons; federation blockchains are for a particular group and limited third parties; private blockchains are for individuals. In contrast, the alliance block chain has the highest requirement on security, only internally established preselected nodes can be used as bookkeepers in the alliance block chain, the nodes have the right to generate new blocks, and other nodes can participate in transactions but cannot ask about the bookkeeping process.
However, in the existing alliance block chain, a security mechanism is mostly used for encrypting and storing uplink information to ensure the security of uplink data, but there is no corresponding security mechanism to ensure the security of the block generation process, and in some cases, for example, I P corresponding to a preselected node as an account holder and a public and private key are stolen by an illegal person, the illegal person can use the identity of the preselected node to generate a new block in the alliance block chain, thereby posing a great threat to the data security in the alliance block chain.
Disclosure of Invention
Embodiments of the present invention provide a block generation method and a computer storage medium to solve the above problems.
The embodiment of the invention provides a block generation method, which is applied to a block chain of a alliance, wherein the block chain of the alliance comprises a plurality of nodes, and each node updates a public key and a private key of the node at regular time according to an instruction of a central node in the block chain of the alliance; the block generation method comprises the following steps: acquiring a block generation request initiated by a request node in the block chain of the alliance, wherein the block generation request carries a signature of block content data of a new block to be generated, and the signature of the block content data is signed by a private key updated by the request node; verifying the validity of the public key updated by the request node to a central node of the block chain of the alliance so as to verify the signature of the block content data according to the valid public key; if the signature of the chunk content data passes verification, causing the requesting node to generate the requested new chunk after the chunk generation request reaches consensus in the federation chunk chain.
The embodiment of the present invention further provides a computer readable medium, where the computer storage medium stores a readable program, where the readable program is applied to a federation blockchain, where the federation blockchain includes a plurality of nodes, and each node updates its public key and private key at regular time according to an instruction of a central node in the federation blockchain; the readable program includes: the instruction is used for acquiring a block generation request initiated by a request node in the block chain of the alliance, wherein the block generation request carries a signature of block content data of a new block to be generated, and the signature of the block content data is signed by a private key updated by the request node; instructions for verifying, to a central node of the federation blockchain, validity of the public key updated by the requesting node to verify a signature of the block content data according to the valid public key; instructions for causing the requesting node to generate the requested new tile after the tile generation request reaches consensus in the federation tile chain if signature verification of the tile content data passes.
As can be seen from the above technical solutions, in the block generation scheme provided in the embodiments of the present invention, after a request node updates its own public key and private key at regular time and obtains a block generation request initiated by the request node, the validity of the public key of the request node is verified to a central node, and it can be determined that the public key of the request node is the updated public key belonging to the request node in a living state (i.e., the first public key is valid), so that a signature of block content data of a new block to be generated included in the block generation request generated by the request node can be verified according to the valid public key of the request node, and thus the security of a block generation process in a federation block chain can be ensured, so as to improve the security of the federation block chain.
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 described below, it is obvious that the drawings in the following description are only some embodiments described in the embodiments of the present invention, and it is also possible for a person skilled in the art to obtain other drawings based on the drawings.
Fig. 1 is a flowchart illustrating a block generation method according to a first embodiment of the present invention;
FIG. 2 is a flowchart illustrating a block generation method according to a second embodiment of the present invention;
FIG. 3 is a flowchart illustrating a block generation method according to a third embodiment of the present invention;
fig. 4 is a flowchart illustrating a block generation method according to a fourth embodiment of the present invention.
Detailed Description
In order to make those skilled in the art better understand the technical solutions in the embodiments of the present invention, the technical solutions in the embodiments of the present invention will be described clearly and completely with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments of the present invention shall fall within the scope of the protection of the embodiments of the present invention.
The following further describes specific implementation of the embodiments of the present invention with reference to the drawings.
Example one
Referring to fig. 1, a flowchart illustrating steps of a block generation method according to a first embodiment of the present invention is shown.
The block generation method provided in this embodiment is applied to a federation block chain, where the federation block chain includes a plurality of nodes, and each node updates its public key and private key at regular time according to an instruction of a central node in the federation block chain. The nodes which regularly update the public keys and the private keys of the nodes according to the instructions of the central nodes also comprise the central nodes.
The block generation method of the present embodiment includes the following steps:
s102, acquiring a block generation request initiated by a request node in the block chain of the alliance.
The block generation request carries a signature of block content data of a new block to be generated, and the signature of the block content data is signed through a private key updated by the request node.
When a request node is added into a block chain of the alliance for the first time, a central node generates a public key and a private key for the request node, wherein the private key is stored by the request node and is used for encrypting or signing data sent by the request node; the public key is broadcast to other nodes of the federation blockchain for the other nodes to decrypt or verify the data sent by the requesting node.
In this embodiment, the request node is any node having a permission to generate a block in the federation block chain, and when the request node needs to generate a new block, the request node may generate and initiate a block generation request according to block content data of the new block to be generated, and broadcast the block generation request to the federation block chain. The block generation method of this embodiment is used after a request node initiates a block generation request, before all nodes of the entire federation block chain agree with the block generation request.
In this embodiment, a block generation method is described from the perspective of one node in a federation block chain, but it should be understood by those skilled in the art that the node may be any node in the federation block chain, or it may be said that processing of a new block generation request by all nodes in the federation block chain may be implemented with reference to an embodiment of the present invention.
Since the requesting node also updates its own public key and private key at regular time according to the instruction of the central node in the federation block chain, the signature of the block content data of the new block to be generated carried in the block generation request initiated by the requesting node can be obtained by signing through the private key updated by the requesting node.
The block content data of the new block to be generated may include, but is not limited to, the number of the new block to be generated, information of the block content corresponding to the new block, and the like.
Each new block has a number, which may be a HASH value corresponding to the block, and according to the number, it may be determined whether the new block has been generated, its position and link relation in the federation block chain, and so on.
For the information of the block content, those skilled in the art may also implement the information in any suitable manner according to actual needs, for example, summary information of the block content of the new block, and the like, which is not limited in this embodiment of the present invention. The signature of the block content data may be a digital signature generated by encrypting the digest information of the block content data by a private key.
And S104, verifying the validity of the public key updated by the request node to a central node of the block chain of the alliance, so as to verify the signature of the block content data according to the valid public key.
In this embodiment, each node updates its public key and private key at regular time according to the instruction of the central node in the federation block chain, so that the central node includes the updated public keys of all nodes. The node receiving the block generation request may verify the validity of the public key updated by the requesting node from the central node, i.e., determine that the public key of the requesting node for verifying the signature is the public key belonging to the requesting node that is updated and still alive.
In the step, the validity of the public key updated by the request node is verified, and the public key and the private key of the request node are updated at regular time, so that the validity of the public key of the request node can be ensured, and the time for using the public key and the private key is not long even if a lawbreaker steals the IP, the public key, the private key and the like of the request node, thereby ensuring the safety of the block chain of the alliance.
And S106, if the signature of the block content data passes the verification, enabling the requesting node to generate the requested new block after the block generation request is agreed in the alliance block chain.
If the signature of the tile content data is verified, the requesting node sending the tile generation request may be considered as a normal node, and subsequent other steps may be performed, such as determining that all nodes agree on the tile generation request through a consensus mechanism of a federation tile chain, and so on, so that the requesting node generates the requested new tile after the tile generation request agrees in the federation tile chain.
According to the embodiment, the request node updates its own public key and private key at regular time, and after the block generation request initiated by the request node is acquired, the validity of the public key of the request node is verified to the central node, so that the public key of the request node can be determined to be the updated public key belonging to the request node in a survival state (namely, the first public key is valid), and therefore, the signature of the block content data of the new block to be generated, which is included in the block generation request generated by the request node, can be verified according to the valid public key of the request node, and further, the security of the block generation process in the block chain of the alliance can be ensured, so that the security of the block chain of the alliance can.
The block generation method of the present embodiment may be executed by any suitable electronic device with data processing capability, including but not limited to: servers, mobile terminals (such as tablet computers, mobile phones and the like), PCs and the like.
Example two
Referring to fig. 2, a flowchart illustrating steps of a block generation method according to a second embodiment of the present invention is shown.
The block generation method provided in this embodiment is applied to a federation block chain, where the federation block chain includes a plurality of nodes, and each node updates its public key and private key at regular time according to an instruction of a central node in the federation block chain.
Optionally, in this embodiment, each node may update its own public key and private key at regular time in the following manner.
The current node regularly acquires a key updating instruction sent by the central node, wherein the key updating instruction carries a public key and a private key which are generated by the central node and used for updating; and the current node acquires the public key and the private key which are generated by the central node and used for updating according to the key updating instruction so as to update the public key and the private key of the current node at regular time.
In this embodiment, the key update instruction and the public key and the private key that are carried by the key update instruction and used for updating are generated by the central node. When the current node acquires the key update instruction sent by the central node at regular time, the key update instruction may be sent to the current node by the central node actively, or may be requested from the central node by the current node, which is not limited in this embodiment.
Because the public key and the private key used for updating of the current node are generated by the central node, the accuracy of the public key stored in the central node can be effectively ensured.
After the current node is updated, the central node may broadcast the updated public key to the federation block chain, so that other nodes in the federation block chain update the stored public key of the current node.
Based on the aforementioned timing update of the public key and the private key in each node, the block generation method of this embodiment includes the following steps:
s202, acquiring a block generation request initiated by a request node in the block chain of the alliance.
The block generation request carries a signature of block content data of a new block to be generated, and the signature of the block content data is signed through a private key updated by the request node.
Step S202 in this embodiment is similar to step S102 in the first embodiment, and this embodiment is not described herein again.
And S204, sending a verification request to the central node and acquiring a verification result fed back by the central node.
In this embodiment, the verification request is used to request verification of validity of the public key updated by the requesting node, and the verification request may carry public key data of the requesting node stored in the current node. After obtaining the verification request, the central node may compare the public key of the request node included in the verification request with the public key of the request node stored in the central node, and generate a verification result according to the comparison result. The verification result may include a validity verification result of the public key of the requesting node carried in the verification request, and optionally, if the verification result is invalid, the verification result may further include a valid public key of the requesting node stored in the central node.
S206, judging whether the public key of the request node carried by the verification request is valid according to the verification result; if yes, go to step S208; if not, go to step S210.
And S208, if the public key of the request node is determined to be valid, verifying the signature of the block content data according to the current public key of the request node. Go to step S212 for execution.
S210, if the public key of the request node is determined to be invalid, the block generation request is refused to be processed. And ending the process.
In this embodiment, if the verification result carries the valid public key of the requesting node stored in the central node, the public key is directly updated to the local, and if the verification result does not carry the valid public key of the requesting node, a request for obtaining the public key of the requesting node needs to be sent to the central node again to obtain the valid public key of the requesting node.
S212, if the signature of the block content data passes the verification, enabling the requesting node to generate the requested new block.
The data structure of the block in this embodiment may be different from the data structure of an existing block, the block in this embodiment may include a block header, a block body, and a hash value, the block body includes a plurality of operation instructions, the block header includes the hash values of the operation instructions, a value of a root of a Merkle tree formed by the operation instructions, a timestamp for generating the current block, and a hash value of a previous block adjacent to the current block, and the hash value included in the block data is generated based on the block header and the block body. Wherein each of the plurality of operation instructions comprises an operation type, a table name, and JSON-based content.
Based on this, the block content data of this embodiment includes a block header, a block body, and a hash value, where the block body includes a plurality of operation instructions, the block header includes the hash values of the operation instructions, the value of the root of the melkle tree formed by the operation instructions, a timestamp for generating the current block, and the hash value of the previous block adjacent to the current block, and the hash value included in the block data is generated based on the block header and the block body. Wherein each of the plurality of operation instructions comprises an operation type, a table name, and JSON-based content. Therefore, when the block of the block data structure is generated, the block processing time can be greatly saved, and the processing efficiency of the block is greatly improved.
In this embodiment, the signature generated by the private key of the requesting node can only be verified by the public key associated with the requesting node. Therefore, if the signature verification is passed, the requesting node can be determined to be normal, and the requesting node can be enabled to generate the requested new block; if the signature verification is not passed, the request node can be determined to have an exception, and the generation of a new block requested by the request node is refused.
If the signature passes, it indicates that the requesting node that sent the block generation request is a normal and legitimate node, and in this case, the current node that received the block generation request may send a confirmation message to inform other nodes (including the requesting node) in the federation block chain, and the current node confirms that the requesting node may generate a new block requested by the block generation request. If all nodes in the federation blockchain send acknowledgement messages, the block generation request may be considered to have agreed throughout the federation blockchain, at which point the requesting node may generate a new block.
In one possible approach, the process of the requesting node generating a new block based on the composition of the block data may include: receiving a block generation request initiated by a request node; analyzing the block generation request, and acquiring operation type information, operation object information and operation content information in the block generation request; generating an operation instruction expressed by an intermediate language having a mapping relation with the SQL language based on the operation type information, the operation object information and the operation content information; executing mapping operation on the operation instruction expressed by the intermediate language to obtain the operation instruction expressed by the SQL language; and executing new block generation processing corresponding to the block generation request based on the operation instruction expressed by the SQL language.
The operation type information includes information for instructing to perform data increase operation, the operation object information includes a table name of a data table, a bitcoin storage account of a certain user, and the like, for example, a student information table, a student score table, a student history table, the operation content information may include a field of the data table and an operation parameter, for example, the field of the data table may be a student name, a student age, and the like, the operation parameter may be a student surname of a little red, a student age of 8 years, and the like, and the operation content information may further include the number of bitcoins operated this time. It should be understood that the above description is only exemplary, and the embodiments of the present invention are not limited thereto.
In this embodiment, the intermediate language having a mapping relationship with the SQL language may be a SQL language similar to the SQL language or a simple version of the SQL language. For example, the operation instruction includes three main fields, which are "operation type", "table name", and "JOSN", and the representation example of the operation instruction expressed by the language similar to SQL language is: insert/update table json. The "insert/update" is a specific operation instruction that can correspond to the SQL language, the table is a variable, each specific operation can be embodied as a specific table name, the json is also a variable, and each specific operation can be embodied as an SQL instruction and/or statement corresponding to an operation process or an operation result.
In some optional embodiments, when the operation instruction expressed by the intermediate language having a mapping relation with the SQL language is generated, the operation type information, the operation object information, and the operation content information may be spliced to obtain the operation instruction expressed by the intermediate language having a mapping relation with the SQL language. It may be understood that any embodiment of generating an operation instruction expressed by an intermediate language having a mapping relation with the SQL language may be applied to this embodiment, and this is not limited in any way by the embodiment of the present invention.
It can be seen that, in the above block generation process, the generation operation instruction expressed by the SQL language recognized by the machine is not generated directly according to the block generation request, but the operation instruction expressed by the intermediate language having a mapping relation with the SQL language is generated based on the operation type information, the operation object information and the operation content information in the block generation request, and then the mapping operation is performed on the operation instruction expressed by the intermediate language, so as to obtain the operation instruction expressed by the SQL language, thereby saving the block generation processing time and greatly improving the block generation processing efficiency.
It should be noted that the requesting node in the above process may be any node in the federation blockchain, including the current node, and the current node may be a central node in the federation blockchain or a non-central node.
Through the process, the validity verification of the request node and the generation of the new block of the request node are realized.
Optionally, after step S212 in this embodiment, the method may further include:
s214, acquiring a new block generation notification message sent by the request node.
The new block generation notification message carries information of the generated new block, wherein the information of the new block includes a signature of the content data of the new block, and the signature of the content data of the new block is signed by the private key of the request node.
In this embodiment, the content data of the new chunk may include a HASH value of the new chunk, information of the chunk content of the new chunk, and the like, where the information of the chunk content of the new chunk may include a signature of the content data of the new chunk, and the signature of the content data of the new chunk may be: and encrypting the content data of the new block by the private key of the request node to obtain a digital signature.
S216, verifying the validity of the public key of the request node to the central node of the block chain of the alliance, and verifying the signature of the new block according to the public key updated by the valid request node.
In this embodiment, step S216 is similar to step S104 in the first embodiment, and this embodiment is not described herein again.
In this embodiment, the validity of the public key of the requesting node is verified again, and then the signature in the notification information generated by the new block is verified through the valid public key of the requesting node, so that the security of the process of generating the new block in the block chain of the federation is further improved, that is, the security of the data of the block chain of the federation is improved.
And S218, if the signature of the new block is verified, responding to the new block generation notification message to update the alliance block chain and the local block data by using the generated information of the new block.
After the requesting node generates a new block, the new block is broadcasted to all nodes of the alliance block chain, so that all nodes perform block updating, and data synchronization of all nodes in the alliance block chain is achieved.
After the alliance block chain and the local block data are updated, the uplink operation of the new block can be completed.
In this embodiment, the steps S214 to S218 may be executed by any node that receives the new block generation notification message, and after the current node receives the new block generation notification message, the current node may update the data of the locally stored alliance block chain with the generated new block according to the new block generation notification message.
According to the block generation scheme provided by the embodiment, on the basis that the request node updates its own public key and private key at regular time, after the block generation request initiated by the request node is acquired, the validity of the public key of the request node is verified to the central node, so that the signature of the block content data of the new block to be generated, which is included in the block generation request generated by the request node, can be verified according to the valid public key of the request node; after a request node generates a new block, acquiring a new block generation notification message sent by the request node, and verifying the validity of the public key of the request node again, so that a signature included in the new block generation notification message generated by the request node can be verified according to the valid public key of the request node.
The block generation method of the present embodiment may be executed by any suitable electronic device with data processing capability, including but not limited to: servers, mobile terminals (such as tablet computers, mobile phones and the like), PCs and the like.
EXAMPLE III
The present embodiment is based on the solution of the first embodiment or the second embodiment, and further improves the solution.
In this embodiment, the federation blockchain is set to further include an I P white list, the I P white list stores IP addresses of all nodes in the federation blockchain, and since the federation blockchain is for a set group and most enterprises of a set industry, if a certain enterprise joins the federation blockchain, the node is assigned to the certain enterprise, and when the node is generated, the IP address of the server of the enterprise corresponding to the node is reported to the federation blockchain, and the IP address of the server is added to the IP white list.
In this embodiment, as shown in fig. 3, the method further includes:
s302, whether the IP address of the request node is consistent with the IP address of the request node in a pre-stored IP white list or not is obtained and verified, and the validity of the IP address of the request node is verified.
Generally, when a request node in a federation blockchain is started, consistency and validity of an IP carried in a start request of the request node and an IP of the request node stored in an IP white list are checked, if the check is passed, the request node can be started, and if the check is not passed, the request node is not allowed to be started. By checking the IP of the requesting node when it starts, it is possible to prevent illegal nodes that are not provisioned in the federation blockchain from failing to start. But the procedure of the federation blockchain is public to all nodes in the federation blockchain, so a lawless person can skip this step by logging off part of the procedure of the federation blockchain that is used to verify the boot IP.
Therefore, in order to further improve the security of the federation blockchain, before generating a new block, the current node receiving the block generation request may perform step S302 described above to determine that the requesting node is not an unprovisioned illegal node through step S302.
S304, if the block generation requests are inconsistent or the IP addresses of the request nodes are invalid, the block generation requests are refused to be processed. And ending the process.
S306, if the IP addresses of the request nodes are consistent or valid, the block generation request is continuously processed, so that the request nodes generate the requested new blocks.
The IP address of the requesting node may be included as a parameter in the request issued by the requesting node, so that the IP address of the requesting node may be determined directly from the request initiated by the requesting node.
The following steps, as described in example one, may then continue.
S308, acquiring a block generation request initiated by a request node in the block chain of the alliance.
S310, verifying the validity of the public key updated by the request node to a central node of the block chain of the alliance, so as to verify the signature of the block content data according to the valid public key.
And S312, if the signature of the block content data passes the verification, enabling the requesting node to generate the requested new block. The execution of the above steps S308 to S312 is as described in the first embodiment, and is not described herein again.
In this embodiment, the IP white list may be stored locally in all nodes, and any node that obtains the block generation request initiated by the request node may perform the above-described verification process.
Of course, in another implementation manner of this embodiment, the IP white list may also be stored in the central node, and then the central node may perform the verification process, and then notify the verification result to other nodes.
Since the above-described verification process can be performed by the node itself, the lawless person cannot skip the verification process by logging out a part of the program, so that even if the lawless person successfully starts the node, the node does not have a function of generating a new block. Further, the above process of verifying the IP of the requesting node is combined with the validity of the public key of the requesting node in the first embodiment, so that the security of the federation blockchain can be further improved.
It should be noted that, in this embodiment, the above steps S302 to S306 are combined with the scheme in the first embodiment, and the step S102 (step S308 in this embodiment) is executed as an example before, but it should be understood by those skilled in the art that, in practical application, the steps S302 to S306 in this embodiment may also be executed before generating a new block after the signature verification in step S106 in the first embodiment (step S312 in this embodiment) passes, or the steps S302 to S306 and the steps S308 to S312 are executed in parallel, which is not limited in this embodiment.
Of course, in this embodiment, the above steps S302 to S306 may also be combined with the second embodiment, and the above steps S302 to S306 may be executed before step S202, or may be executed before generating a new block after the signature verification in step S212 in the second embodiment passes, or the steps S302 to S306 and the steps S202 to S210 are executed in parallel, which is not limited in this embodiment.
Further, after the embodiment is combined with the first embodiment or the second embodiment, it may be determined that the public key of the request node is the updated public key belonging to the request node in the alive state by using the scheme provided by the embodiment, and the ip of the request node is verified by using the embodiment to determine the illegal node that is not reported by the request node, so that a better verification effect may be obtained, and the security of the process of generating the new block in the federation block chain is further ensured.
In another implementation manner of this embodiment, the process of verifying the IP address may be further performed before the obtaining of the block generation request initiated by the requesting node in the federation block chain.
For example, before step S308, the method provided in this embodiment may further include: a current node sends a node starting request to a central node of the alliance block chain, wherein the node starting request comprises an IP address of the current node; receiving a starting request feedback message returned by the central node, wherein the starting request feedback message is generated by the central node according to the consistency verification of the IP address of the current node and the IP address of the node in a pre-stored IP white list and the verification result of the validity verification of the IP address of the current node; and if the verification result indicates that the verification is successful, the current node performs node starting operation.
The validity of the current node can be ensured by verifying the IP address of the current node when the current node is started, so that the actions of verifying the validity of the public key updated by the request node to the central node, and the like, which are executed by the current node are effective, the safety of a block generation process is ensured, and the safety of a block chain of the alliance is improved.
In another implementation manner of this embodiment, the process of verifying the IP address may also be performed in the process of verifying the validity of the public key updated by the requesting node to the central node of the federation blockchain.
For example, in this embodiment, step S310 may include: the current node sends the validity verification request to a central node of the alliance block chain, wherein the validity verification request comprises an IP address of the current node; receiving a verification request feedback message returned by the central node, wherein the verification request feedback message is generated by the central node according to a verification result of the validity of the public key updated by the request node after verifying that the IP address of the current node is consistent with the IP address of the current node in a pre-stored IP white list and the IP address of the current node is valid; and the current node determines the validity of the public key updated by the request node according to the verification request feedback message.
When the current node verifies the validity of the public key of the request node to the central node, the IP address of the current node is verified, and the validity of the current node can be ensured, so that the action of verifying the validity of the public key updated by the request node to the central node, which is executed by the current node, is effective, the safety of a block generation process is ensured, and the safety of a block chain of the alliance is improved.
Example four
The present embodiment is based on the solution of the first embodiment or the second embodiment, and further improves the solution.
The solution provided in this embodiment is to add other security mechanisms, such as a traffic monitoring mechanism, on the basis of the first or second embodiment. Specifically, since the federation blockchain is for a specific group, such as an enterprise in a certain industry, the node request traffic of the federation blockchain has a business rule corresponding to the specific group.
In this embodiment, as shown in fig. 4, the method further includes:
s402, comparing the flow of the request node with a preset flow threshold of the request node.
In this embodiment, the traffic threshold may be determined when the federation blockchain is established, and the determined traffic threshold may be an initial traffic threshold. During the usage of the federation blockchain, the traffic threshold may be updated to better conform to the evolution of the federation blockchain.
In this embodiment, the traffic of the request node may be monitored in real time by the management module of the central node, and the alarm information is also generated by the management module of the central node.
S404, if the flow of the request node is larger than the flow threshold of the request node, alarm information is generated. And ending the process.
S406, if the flow of the request node is smaller than the flow threshold of the request node, determining that the request node is normal.
The following steps, as described in example one, may then continue.
S408, acquiring a block generation request initiated by the request node in the block chain of the alliance.
S410, verifying the validity of the public key updated by the request node to a central node of the block chain of the alliance, so as to verify the signature of the block content data according to the valid public key.
And S412, if the signature of the block content data passes the verification, enabling the requesting node to generate the requested new block.
The execution of the above steps S408-S412 is as described in the first embodiment, and is not described herein again.
The alarm information may include traffic data of the requesting node, a traffic threshold for comparison, and the like. In this embodiment, whether the traffic of the requesting node is normal is detected by setting a traffic threshold, which may assist in determining the security of the requesting node.
It should be noted that, in this embodiment, the above steps S402 to S404 are combined with the scheme in the first embodiment, and executed before the step S102 (step S408 in this embodiment) is performed as an example, but it should be understood by those skilled in the art that, in practical application, the execution of the steps S402 to S404 in this embodiment may also be executed before a new block is generated after the signature verification in the step S106 in the first embodiment (step S412 in this embodiment) is passed, or the steps S302 to S306 are executed in parallel with the steps S308 to S312, which is not limited in this embodiment.
Of course, in this embodiment, the above steps S402-S406 may also be combined with the second embodiment, and the above steps S402-S404 may be executed before step S202, or may be executed before generating a new block after the signature verification in step S212 in the second embodiment passes, or the steps S302-S306 and the steps S202-S210 are executed in parallel, which is not limited in this embodiment.
Through the process, the real-time monitoring of the flow of the request node is realized.
Optionally, in this embodiment, after the generating alarm information if the traffic of the requesting node is greater than the traffic threshold, the method further includes:
and S414, determining whether the flow of the request node meets a preset condition or not according to the alarm information.
The preset condition is used for indicating that the flow of the nodes in the block chain of the alliance is in a normal growth state. Go to step S416 to execute.
And S416, if the flow of the request node meets the preset condition, determining that the request node is normal. Execution may proceed to step S408.
That is, the reason why the traffic exceeds the traffic threshold is caused by the normal service growth of the node, and in order to adapt to the normal service, the traffic threshold of the requesting node may be adjusted according to the current traffic of the requesting node.
And S418, if the flow of the request node does not meet the preset condition, determining that the request node is abnormal. And ending the process.
I.e., the requesting node may be an illegitimate node, the I P address of the requesting node may be removed from the I P white list at this point.
Through steps S414-S418, it can be determined whether the traffic of the request node meets the preset condition, so that the growth reason of the traffic of the request node can be distinguished, the accuracy of the result of determining that the request node has an abnormality can be improved, and the probability of determining a normal node as an abnormal node is reduced.
After the embodiment is combined with the first embodiment or the second embodiment, it may be determined that the public key of the requesting node is the updated public key belonging to the requesting node in the alive state through the scheme provided by the embodiment, and it may be determined whether the requesting node is abnormal through monitoring whether the real-time traffic of the requesting node exceeds the traffic threshold, so that a better verification effect may be obtained, and thus, the security of the process of generating a new block in the federation block chain is further ensured.
EXAMPLE five
The embodiment of the invention also provides a computer readable medium, wherein the computer storage medium stores a readable program, the readable program is applied to a block chain of the federation, the block chain of the federation comprises a plurality of nodes, and each node updates a public key and a private key of the node at regular time according to an instruction of a central node in the block chain of the federation; the readable program includes: the instruction is used for acquiring a block generation request initiated by a request node in the block chain of the alliance, wherein the block generation request carries a signature of block content data of a new block to be generated, and the signature of the block content data is signed by a private key updated by the request node; instructions for verifying, to a central node of the federation blockchain, validity of the public key updated by the requesting node to verify a signature of the block content data according to the valid public key; instructions for causing the requesting node to generate the requested new tile after the tile generation request reaches consensus in the federation tile chain if signature verification of the tile content data passes.
Optionally, each node periodically updates its public key and private key by the following readable program: the instruction is used for enabling the current node to obtain a key updating instruction sent by the central node at regular time, wherein the key updating instruction carries a public key and a private key which are generated by the central node and used for updating; and the instruction is used for enabling the current node to obtain the public key and the private key which are generated by the central node and used for updating according to the key updating instruction so as to update the public key and the private key of the current node at regular time.
Optionally, the instructions for verifying validity of the public key updated by the requesting node to a central node of the federation blockchain to verify the signature of the block content data according to the valid public key include: instructions for sending a verification request to the central node and obtaining a verification result fed back by the central node; if the public key of the request node carried by the verification request is determined to be valid according to the verification result, verifying the signature of the block content data according to the current public key of the request node; or, rejecting to process the block generation request if the public key of the request node carried by the verification request is determined to be invalid according to the verification result.
Optionally, after the instructions for generating a new chunk, the readable program further comprises: the instruction is used for acquiring a new block generation notification message sent by the request node, wherein the new block generation notification message carries information of a generated new block, the information of the new block comprises a signature of content data of the new block, and the signature of the content data of the new block is signed by a private key of the request node; instructions for verifying the validity of the public key of the requesting node to a central node of the federation blockchain, to verify the signature of the new block according to the valid public key updated by the requesting node; instructions for generating a notification message in response to the new block to update the federation block chain and local block data with the generated information for the new block if the signature verification for the new block passes.
Optionally, before the instruction for obtaining a chunk generation request initiated by a requesting node in the federation chunk chain, or after the instruction for signature verification of chunk content data passes, the readable program further includes: instructions for obtaining and verifying whether the IP address of the request node is consistent with the IP address of the request node in a pre-stored IP white list, and verifying the validity of the IP address of the request node; instructions for denying processing the block generation request if the block generation request is inconsistent or the IP address of the requesting node is invalid; instructions for continuing to process the block generation request if consistent and the IP address of the requesting node is valid, such that the requesting node generates the requested new block;
alternatively, the first and second electrodes may be,
prior to the instructions for obtaining a block generation request initiated by a requesting node in the federation blockchain, the readable program further comprises: instructions for causing a current node to send a node start request to a central node of the federation blockchain, wherein the node start request includes an IP address of the current node; the instruction is used for receiving a starting request feedback message returned by the central node, wherein the starting request feedback message is generated by the central node according to the consistency verification of the IP address of the current node and the IP address of the node in a pre-stored IP white list and the verification result of the validity verification of the IP address of the current node; an instruction for performing a node start operation by the current node if the verification result indicates that the verification is successful;
alternatively, the first and second electrodes may be,
the instructions for verifying validity of the public key updated by the requesting node to a central node of the federation blockchain include: sending the validity verification request to a central node of the alliance block chain by the current node, wherein the validity verification request comprises an IP address of the current node; the instruction is used for receiving a verification request feedback message returned by the central node, wherein the verification request feedback message is generated by the central node according to a verification result of the validity of the public key updated by the request node after the central node verifies that the IP address of the current node is consistent with the IP address of the current node in a pre-stored IP white list and the IP address of the current node is valid; instructions for causing the current node to determine validity of the public key updated by the requesting node according to the verification request feedback message.
Optionally, before the instruction for obtaining a chunk generation request initiated by a requesting node in the federation chunk chain, or after the instruction for signature verification of chunk content data passes, the readable program further includes: instructions for comparing the traffic of the requesting node to a preset traffic threshold of the requesting node; and generating alarm information if the flow of the request node is greater than the flow threshold of the request node.
Optionally, after the instruction for generating alarm information if the traffic of the requesting node is greater than the traffic threshold, the readable program further includes: determining whether the traffic of the request node meets a preset condition according to the alarm information, wherein the preset condition is used for indicating that the traffic of the nodes in the block chain of the alliance is in a normal growth state; if the flow of the request node meets a preset condition, determining that the request node is normal, and adjusting the flow threshold of the request node according to the current flow of the request node; or, an instruction for determining that the requesting node is abnormal and removing the IP address of the requesting node from an IP white list if the traffic of the requesting node does not meet a preset condition.
Optionally, the block content data includes a block header, a block body, and a hash value, the block body includes a plurality of operation instructions, the block header includes the hash values of the operation instructions, a value of a root of a mesh tree formed by the operation instructions, a timestamp for generating the current block, and a hash value of a previous block adjacent to the current block, and the hash value included in the block data is generated based on the block header and the block body.
Optionally, each of the plurality of operation instructions includes an operation type, a table name, and JSON-based content.
Through the computer-readable medium of this embodiment, the requesting node updates its own public key and private key at regular time, and after acquiring the block generation request initiated by the requesting node, by verifying the validity of the public key of the requesting node to the central node, it can be determined that the public key of the requesting node is the updated public key belonging to the requesting node in a alive state (i.e., the first public key is valid), so that the signature of the block content data of the new block to be generated included in the block generation request generated by the requesting node can be verified according to the valid public key of the requesting node, and the security of the block generation process in the federation block chain can be ensured, so as to improve the security of the federation block chain. It should be noted that, according to the implementation requirement, each component/step described in the embodiment of the present invention may be divided into more components/steps, and two or more components/steps or partial operations of the components/steps may also be combined into a new component/step to achieve the purpose of the embodiment of the present invention.
The above-described method according to an embodiment of the present invention may be implemented in hardware, firmware, or as software or computer code storable in a recording medium such as a CD ROM, a RAM, a floppy disk, a hard disk, or a magneto-optical disk, or as computer code originally stored in a remote recording medium or a non-transitory machine-readable medium downloaded through a network and to be stored in a local recording medium, so that the method described herein may be stored in such software processing on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware such as an ASIC or FPGA. It will be appreciated that the computer, processor, microprocessor controller or programmable hardware includes memory components (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code that, when accessed and executed by the computer, processor or hardware, implements the block generation methods described herein. Further, when a general-purpose computer accesses code for implementing the tile generation method illustrated herein, execution of the code transforms the general-purpose computer into a special-purpose computer for performing the tile generation method illustrated herein.
Those of ordinary skill in the art will appreciate that the various illustrative elements and method steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present embodiments.
The above embodiments are only for illustrating the embodiments of the present invention and not for limiting the embodiments of the present invention, and those skilled in the art can make various changes and modifications without departing from the spirit and scope of the embodiments of the present invention, so that all equivalent technical solutions also belong to the scope of the embodiments of the present invention, and the scope of patent protection of the embodiments of the present invention should be defined by the claims.
Claims (9)
1. A block generation method is applied to a block chain of alliances and is characterized in that the block chain of alliances comprises a plurality of nodes, and each node updates a public key and a private key of the node at regular time according to an instruction of a central node in the block chain of alliances;
the block generation method comprises the following steps:
acquiring a block generation request initiated by a request node in the block chain of the alliance, wherein the block generation request carries a signature of block content data of a new block to be generated, and the signature of the block content data is signed by a private key updated by the request node;
verifying the validity of the public key updated by the request node to a central node of the block chain of the alliance so as to verify the signature of the block content data according to the valid public key;
if the signature of the block content data passes verification, enabling the requesting node to generate a requested new block after the block generation request reaches a consensus in the federation block chain;
wherein, each node updates its own public key and private key regularly through the following modes:
the current node regularly acquires a key updating instruction sent by the central node, wherein the key updating instruction carries a public key and a private key which are generated by the central node and used for updating;
and the current node acquires the public key and the private key which are generated by the central node and used for updating according to the key updating instruction so as to update the public key and the private key of the current node at regular time.
2. The method of claim 1, wherein the verifying validity of the public key updated by the requesting node to a central node of the federation blockchain to verify the signature of the block content data according to the valid public key comprises:
sending a verification request to the central node, and acquiring a verification result fed back by the central node;
if the public key of the request node carried by the verification request is determined to be valid according to the verification result, verifying the signature of the block content data according to the current public key of the request node;
or if the public key of the request node carried by the verification request is determined to be invalid according to the verification result, the block generation request is refused to be processed.
3. The method of claim 1, wherein after said generating the new block, the method further comprises:
acquiring a new block generation notification message sent by the request node, wherein the new block generation notification message carries information of a generated new block, the information of the new block comprises a signature of content data of the new block, and the signature of the content data of the new block is signed by a private key of the request node;
verifying the validity of the public key of the request node to a central node of the alliance block chain so as to verify the signature of the new block according to the valid public key updated by the request node;
and if the signature of the new block passes the verification, responding to the new block generation notification message to update the alliance block chain and the local block data by using the generated information of the new block.
4. The method of claim 1,
before the obtaining of the chunk generation request initiated by the requesting node in the federation chunk chain, or after the signature verification of the chunk content data passes, the method further includes:
acquiring and verifying whether the IP address of the request node is consistent with the IP address of the request node in a pre-stored IP white list or not, and verifying the validity of the IP address of the request node; if the block generation request is inconsistent or the IP address of the request node is invalid, refusing to process the block generation request; if the IP addresses of the request nodes are consistent and valid, continuing to process the block generation request so that the request nodes generate the requested new blocks;
alternatively, the first and second electrodes may be,
before the obtaining a block generation request initiated by a requesting node in the federation block chain, the method further comprises: a current node sends a node starting request to a central node of the alliance block chain, wherein the node starting request comprises an IP address of the current node; receiving a starting request feedback message returned by the central node, wherein the starting request feedback message is generated by the central node according to the consistency verification of the IP address of the current node and the IP address of the node in a pre-stored IP white list and the verification result of the validity verification of the IP address of the current node; if the verification result indicates that the verification is successful, the current node performs node starting operation;
alternatively, the first and second electrodes may be,
the verifying the validity of the public key updated by the requesting node to the central node of the federation blockchain includes: the current node sends the validity verification request to a central node of the alliance block chain, wherein the validity verification request comprises an IP address of the current node; receiving a verification request feedback message returned by the central node, wherein the verification request feedback message is generated by the central node according to a verification result of the validity of the public key updated by the request node after verifying that the IP address of the current node is consistent with the IP address of the current node in a pre-stored IP white list and the IP address of the current node is valid; and the current node determines the validity of the public key updated by the request node according to the verification request feedback message.
5. The method according to claim 1, wherein before the obtaining of the chunk generation request initiated by the requesting node in the federation chunk chain, or after the signature verification of the chunk content data passes, the method further comprises:
comparing the flow of the request node with a preset flow threshold of the request node;
and if the flow of the request node is larger than the flow threshold of the request node, generating alarm information.
6. The method of claim 5, wherein after generating alarm information if the traffic of the requesting node is greater than the traffic threshold, the method further comprises:
determining whether the flow of the request node meets a preset condition or not according to the alarm information, wherein the preset condition is used for indicating that the flow of the nodes in the block chain of the alliance is in a normal growth state;
if the flow of the request node meets the preset condition, determining that the request node is normal, and adjusting the flow threshold of the request node according to the current flow of the request node;
or if the flow of the request node does not meet the preset condition, determining that the request node is abnormal, and removing the IP address of the request node from an IP white list.
7. The method according to claim 1, wherein the block content data includes a block header, a block body, and a hash value, the block body includes a plurality of operation instructions, the block header includes the hash value of the operation instructions, a value of a root of a Merkle tree formed by the operation instructions, a timestamp for generating a current block, and a hash value of a previous block adjacent to the current block, and the block data includes the hash value generated based on the block header and the block body.
8. The method of claim 7, wherein each of the plurality of operation instructions comprises an operation type, a table name, and JSON-enabled content.
9. A computer-readable medium, wherein the computer-readable medium stores a readable program, and the readable program is applied to a federation blockchain, where the federation blockchain includes a plurality of nodes, and each node periodically updates its public key and private key according to an instruction of a central node in the federation blockchain;
the readable program includes:
the instruction is used for acquiring a block generation request initiated by a request node in the block chain of the alliance, wherein the block generation request carries a signature of block content data of a new block to be generated, and the signature of the block content data is signed by a private key updated by the request node;
instructions for verifying, to a central node of the federation blockchain, validity of the public key updated by the requesting node to verify a signature of the block content data according to the valid public key;
instructions for causing the requesting node to generate a new chunk requested after the chunk generation request agrees in the federation chunk chain if signature verification of the chunk content data passes;
wherein, each node updates its own public key and private key regularly through the following modes:
the current node regularly acquires a key updating instruction sent by the central node, wherein the key updating instruction carries a public key and a private key which are generated by the central node and used for updating;
and the current node acquires the public key and the private key which are generated by the central node and used for updating according to the key updating instruction so as to update the public key and the private key of the current node at regular time.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811312692.8A CN109543456B (en) | 2018-11-06 | 2018-11-06 | Block generation method and computer storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811312692.8A CN109543456B (en) | 2018-11-06 | 2018-11-06 | Block generation method and computer storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109543456A CN109543456A (en) | 2019-03-29 |
| CN109543456B true CN109543456B (en) | 2021-07-09 |
Family
ID=65844528
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811312692.8A Active CN109543456B (en) | 2018-11-06 | 2018-11-06 | Block generation method and computer storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109543456B (en) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110175467A (en) * | 2019-04-25 | 2019-08-27 | 平安科技（深圳）有限公司 | Signature file store method, device and computer equipment based on block chain |
| CN110176998A (en) * | 2019-05-17 | 2019-08-27 | 北京众享比特科技有限公司 | A kind of common recognition method, apparatus, equipment and the storage medium of proof of work |
| CN112187462B (en) * | 2019-07-04 | 2022-04-29 | 北京新唐思创教育科技有限公司 | Data processing method and device, electronic equipment and computer readable medium |
| CN110535654B (en) * | 2019-07-23 | 2021-09-14 | 平安科技（深圳）有限公司 | Block chain based parallel system deployment method and device and computer equipment |
| CN110535848B (en) * | 2019-08-22 | 2022-07-26 | 腾讯科技（深圳）有限公司 | Information storage method and device |
| CN110955721B (en) * | 2019-10-23 | 2022-12-06 | 金蝶软件（中国）有限公司 | Block link point state maintenance method and device, computer equipment and storage medium |
| CN111953671B (en) * | 2020-07-31 | 2022-08-26 | 中国工商银行股份有限公司 | Dynamic honey net data processing method and system based on block chain |
| CN112487102B (en) * | 2020-12-15 | 2024-03-19 | 深圳前海微众银行股份有限公司 | Block chain data processing method and device and electronic equipment |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107005574A (en) * | 2016-12-23 | 2017-08-01 | 深圳前海达闼云端智能科技有限公司 | Block generation method and device and block chain network |
| CN108235799A (en) * | 2017-12-27 | 2018-06-29 | 深圳达闼科技控股有限公司 | Block generation method, device, storage medium and block chain network |
| CN108416589A (en) * | 2018-03-08 | 2018-08-17 | 深圳前海微众银行股份有限公司 | Connection method, system and the computer readable storage medium of block chain node |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2015175854A2 (en) * | 2014-05-15 | 2015-11-19 | Cryptyk, Inc. (Trading As Bitsavr Inc.) | System and method for digital currency storage, payment and credit |
| CN106411503B (en) * | 2016-11-28 | 2019-11-08 | 中国银行股份有限公司 | The bookkeeping methods and system, ballot and accounting nodes of block chain ballot accounting mode |
| CN106780033A (en) * | 2016-12-16 | 2017-05-31 | 杭州云象网络技术有限公司 | A kind of digital ticket transaction system construction method based on alliance's chain |
| CN107078910B (en) * | 2016-12-23 | 2021-02-05 | 深圳前海达闼云端智能科技有限公司 | Method, device, node, signature device and system for generating block chain block |
| US10355869B2 (en) * | 2017-01-12 | 2019-07-16 | International Business Machines Corporation | Private blockchain transaction management and termination |
| CN107171806B (en) * | 2017-05-18 | 2020-04-10 | 北京航空航天大学 | Mobile terminal network key negotiation method based on block chain |
| CN108600272B (en) * | 2018-05-10 | 2020-08-04 | 阿里巴巴集团控股有限公司 | Block chain data processing method, device, processing equipment and system |
| CN108647968A (en) * | 2018-05-10 | 2018-10-12 | 阿里巴巴集团控股有限公司 | A kind of block chain data processing method, device, processing equipment and system |
-
2018
- 2018-11-06 CN CN201811312692.8A patent/CN109543456B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107005574A (en) * | 2016-12-23 | 2017-08-01 | 深圳前海达闼云端智能科技有限公司 | Block generation method and device and block chain network |
| CN108235799A (en) * | 2017-12-27 | 2018-06-29 | 深圳达闼科技控股有限公司 | Block generation method, device, storage medium and block chain network |
| CN108416589A (en) * | 2018-03-08 | 2018-08-17 | 深圳前海微众银行股份有限公司 | Connection method, system and the computer readable storage medium of block chain node |
Non-Patent Citations (1)
| Title |
|---|
| 基于区块链基于区块链_智能合约和物联网的供应链原型系统;叶小榕等;《科技导报》;20171231;第35卷(第23期);论文第5-6页第5章节 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109543456A (en) | 2019-03-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109543456B (en) | Block generation method and computer storage medium | |
| CN109670801B (en) | Digital encryption money transfer method for block chain | |
| CN112583596B (en) | Complete cross-domain identity authentication method based on block chain technology | |
| CN110365483B (en) | Cloud platform authentication method, client, middleware and system | |
| US9602499B2 (en) | Authenticating a node in a communication network | |
| CN108696356B (en) | Block chain-based digital certificate deleting method, device and system | |
| US10461941B2 (en) | Data structure for use as a positive list in a device, method for updating a positive list and device | |
| CN111800262B (en) | Digital asset processing method and device and electronic equipment | |
| CN104980449B (en) | The safety certifying method and system of network request | |
| CN111815321A (en) | Transaction proposal processing method, device, system, storage medium and electronic device | |
| CN108075895B (en) | Node permission method and system based on block chain | |
| WO2020001417A1 (en) | Certificate renewal method, apparatus, system, medium, and device | |
| CN113872990A (en) | VPN network certificate authentication method and device based on SSL protocol and computer equipment | |
| CN111711607B (en) | Block chain-based flow type micro-service trusted loading and verifying method | |
| CN106912049B (en) | Method for improving user authentication experience | |
| CN111104655B (en) | BMC login method and related device | |
| GB2541461A (en) | Prioritising SIP messages | |
| CN109274674B (en) | Block chain heterogeneous consensus method with high security and terminal | |
| US10057252B1 (en) | System for secure communications | |
| CN113987445A (en) | User login method and device of USB-KEY, computer equipment and storage medium | |
| JP2023553593A (en) | Device management method using blockchain network, related devices and computer programs | |
| CN113645196A (en) | Internet of things equipment authentication method and system based on block chain and edge assistance | |
| US10447688B1 (en) | System for secure communications | |
| WO2020155022A1 (en) | Method, apparatus and device for authenticating tls certificate and storage medium | |
| CN112469035A (en) | Security activation and control method and communication system for remote equipment of Internet of things |
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 |