CN111190862B

CN111190862B - Method for realizing block chain

Info

Publication number: CN111190862B
Application number: CN201911384949.5A
Authority: CN
Inventors: 黄柏; 邱少师; 姚佑贤
Original assignee: Guangzhou Thinker Technology Co ltd
Current assignee: Guangzhou Thinker Technology Co ltd
Priority date: 2019-12-28
Filing date: 2019-12-28
Publication date: 2023-06-30
Anticipated expiration: 2039-12-28
Also published as: CN111190862A

Abstract

The invention relates to the field of blockchains, and discloses a method for realizing blockchains, which comprises a client data uplink flow, wherein the client data uplink flow comprises the following steps: the client uploads a file to be stored to an IPFS system to obtain a HASH value FH of the file; the client calculates the HASH value FH of the file, and signs the HASH value FH of the file, the TIME at the current TIME and the HASH value UH of the user to obtain a file signature US; the client sends the HASH value FH, the file signature US, the current TIME TIME, the user HASH value UH and the blockchain ID information of the file to the center, and requests to establish the blocknodes; when the client monitors that the block chain addition is successful, the client downloads the newly added block node; and (5) ending. The invention has safer data, unified central uplink, no bifurcation, and can control the block chain growth speed, thereby being beneficial to improving the concurrent uplink speed.

Description

Method for realizing block chain

Technical Field

The invention relates to the field of blockchains, in particular to a method for realizing a blockchain.

Background

The blockchain has the following characteristics: the distributed storage is realized, and the system robustness is high; the record cannot be tampered, so that the security is high; the record discloses a traceable root. Based on these features, blockchains were first applied to billing of transactions in virtual currency, also resulting in the explosion of the mining machine market. However, the blockchain is not equal to virtual currency, which can be applied in many ways.

The current search for the extremely "decentralised" blockchain technique has the following problems that limit its application. The rules of the blockchain result in that the data they store must be stored in plaintext; because only plaintext is stored, other people can prove the content of the stored data of the blockchain; if stored in an encrypted form, it cannot prove what the content is; blockchain publishing on the public network can result in some sensitive data leakage; when a plurality of people issue information simultaneously, competition exists, so that some information issue fails; the real-time performance of the block chain data update is poor.

Disclosure of Invention

Aiming at the defects in the prior art, the invention provides the block chain realization method which has safer data, unified central uplink, no bifurcation, can control the block chain growth speed and is beneficial to improving the concurrent uplink speed.

The technical scheme adopted for solving the technical problems is as follows: the implementation method for constructing the blockchain comprises a client data uplink flow, wherein the client data uplink flow comprises the following steps:

a1 Uploading a file to be stored to an IPFS system by a client to obtain a HASH value FH of the file;

a2 The client calculates the HASH value FH of the file, and signs the HASH value FH of the file, the current TIME TIME and the user HASH value UH to obtain a file signature US;

a3 The client sends the HASH value FH of the file, the file signature US, the current TIME, the user HASH value UH and blockchain ID information to a center, requesting to establish a blocknode;

a4 Monitoring whether the adding of the blockchain is successful or not by the client, if so, executing the step A5); otherwise, executing the step A6);

a5 The client downloads the newly added block node and executes the step A7);

a6 The client performs exception handling and returns to the step A3);

a7 Ending).

The method for realizing the block chain further comprises a center data uplink process, wherein the center data uplink process comprises the following steps of:

b1 The center receives a request for adding block nodes;

b2 The hub synchronizes files requiring an upper blockchain from the IPFS system to local;

b3 Searching user information by the center, and checking the file signature US by using the user information;

b4 Judging whether the file signature US is legal or not, if so, executing the step B6); otherwise, executing the step B5);

b5 Returning error information to the user, informing the user to perform exception handling, and executing the step B10);

b6 The center combines the file signature US and the HASH value PH of the previous block, calculates a signature by using a private key of the center to obtain a private key signature BS, and executes the step B7);

b7 The center writes the block node file into the IPFS system to obtain a HASH value of the block node;

b8 The center returns the HASH value of the block node successfully added to the user;

b9 The center broadcasts a change message of the blockchain, and a subscriber updates the blockchain from the IPFS system according to the received message;

b10 Ending).

The implementation method of the blockchain further comprises a key changing flow, wherein the key changing flow comprises the following steps:

c1 A pair of new key pairs is generated at regular time;

c2 Writing the new public key and the old public key into the IPFS system to obtain a corresponding HASH value;

c3 Signing a file in the IPFS system using an old private key;

c4 Transmitting a request for a uplink to the hub, the hub linking the signed file to a public key chain;

c5 A new private key is recorded with which the subsequent signing takes place.

The implementation method of the blockchain further comprises an adding user flow, wherein the adding user flow comprises the following steps of:

d1 Before adding the user, firstly acquiring the information of the added user, wherein the information of the added user comprises the public key of the added person;

d2 Storing the information of the added user to the IPFS system to obtain a HASH value of a new file; the information of the added user comprises a HASH of the user;

d3 Signing the new file using the private key of the added user;

d4 Request to uplink data to the user chain;

d5 After the user chain is successful, notifying the added user, and the added user links own data.

The implementation method of the blockchain further comprises a user deleting process, wherein the user deleting process comprises the following steps of:

e1 Acquiring information of the deleted user before deleting the user;

e2 Storing the information of the deleted user to the IPFS system to obtain a HASH value of a new file; the deleted user information comprises a HASH of the user;

e3 Signing the new file using its own private key;

e4 Request to uplink data to the failure chain;

e5 Judging whether the center has the right to delete or not, if so, executing the step E6); otherwise, executing the step E7);

e6 Notifying the deleted user that the deleted user can not request the data to be uplink after the failure link on the data is successful;

e7 Ending).

In the implementation method of the blockchain, the user can be deleted by the user or the creator of the user or the upper creator of the creator.

The implementation method of the block chain has the following beneficial effects: the client is arranged to upload the file to be stored to the IPFS system to obtain the HASH value FH of the file; the client calculates the HASH value FH of the file, and signs the HASH value FH of the file, the current TIME TIME and the user HASH value UH to obtain a file signature US; the client sends the HASH value FH, the file signature US, the current TIME TIME, the user HASH value UH and the blockchain ID information of the file to the center, and requests to establish the blocknodes; when adding the block chain successfully, the client downloads the newly added block node; the distributed storage is realized, so that the data is safer; the center unifies the uplink, the bifurcation condition can not occur, and the block chain growth speed can be controlled; the data needing to be uplinked are independently stored in one file of the IPFS, and the block node file only stores the HASH value and the signature of the IPFS file, so that the speed of concurrent uplinking is improved.

Drawings

In order to more clearly illustrate the embodiments of the invention or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a flow chart of a client data uplink flow in one embodiment of a blockchain implementation method of the present invention;

FIG. 2 is a flow chart of the center data-up process in the embodiment;

FIG. 3 is a flow chart of a key change procedure in the embodiment;

FIG. 4 is a flow chart of the user adding process in the embodiment;

fig. 5 is a flowchart of the user deleting process in the embodiment.

Detailed Description

The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

In an embodiment of the method for implementing a blockchain of the present invention, the method for implementing a blockchain includes a client data uplink flow, and a flowchart of the client data uplink flow is shown in fig. 1. In fig. 1, the client data uplink flow includes the following steps:

step S11, the client uploads the file to be stored to the IPFS system to obtain HASH value FH of the file: in this step, the client first uploads the file to be stored to the IPFS system to obtain the HASH value FH of the file.

Step S12, the client calculates the HASH value FH of the file, and signs the HASH value FH of the file, the current TIME and the user HASH value UH to obtain a file signature US: in this step, the client calculates the HASH value FH of the file, and signs the HASH value FH of the file, the current TIME and the user HASH value UH to obtain the file signature US.

Step S13, the client sends the HASH value FH, the file signature US, the current TIME TIME, the user HASH value UH and the blockchain ID information of the file to the center, and requests to establish the blocknodes: in this step, the client sends information such as HASH value FH, file signature US, current TIME, user HASH value UH, and blockchain ID of the file to the center, and requests to establish the blocknodes.

Step S14, the client monitors whether the adding of the blockchain is successful or not: in the step, the client monitors whether the adding of the blockchain is successful, and if yes, the step S15 is executed; otherwise, step S16 is performed.

Step S15, the client downloads the newly added block nodes: if the judgment result of the above step S14 is yes, the present step is executed. In this step, the blockchain addition is successful, and the client downloads the newly added blocknode. After the present step is performed, step S17 is performed.

Step S16, the client performs exception handling: if the result of the above step S14 is negative, the present step is executed. In this step, the block is added with an exception, the client performs exception handling, and the step is completed and returns to step S13. After the present step is performed, step S17 is performed.

Step S17 ends: in this step, the process is ended.

The invention adopts distributed storage, so that the data is safer; the center unifies the uplink, the bifurcation condition can not occur, and the block chain growth speed can be controlled; the data which needs to be uplinked is independently stored in one file of the IPFS, and the block node file only stores the HASH value and the signature of the IPFS file, so that the speed of concurrent uplinking is improved.

In this embodiment, the method for implementing the blockchain further includes a central data uplink process, where the central data uplink process includes the following steps:

step S201, the center receives a request for adding a block node: in this step, the hub receives a request to add a block node.

Step S202 centers synchronizing the files requiring the upper blockchain from the IPFS system to local: in this step, the hub synchronizes the files requiring the upper blockchain from the IPFS system to the local.

Step S203, the center searches the user information, and verifies the file signature US using the user information: in this step, the center searches for user information and verifies the file signature US using the user information.

Step S204 judges whether the file signature US is legal: in this step, it is determined whether the file signature US is legal, and if yes, step S206 is executed; otherwise, step S205 is performed.

Step S205 returns error information to the user, and informs the user to perform exception handling: if the result of the step S204 is negative, that is, the signature US is not legal, the step is executed. In this step, an error message is returned to the user, informing the user of performing the exception handling. After the present step is performed, step S210 is performed.

Step S206, the center combines the file signature US and the HASH value PH of the previous block, and calculates the signature by using the private key to obtain a private key signature BS: in this step, the center combines the file signature US and the HASH value PH of the previous block, and calculates the signature using its own private key to obtain the private key signature BS. After the present step is performed, step S207 is performed.

Step S207, the center writes the block node file to the IPFS system to obtain the HASH value of the block node: in this step, the center writes the block node file to the IPFS system to obtain the HASH value of the block node.

Step S208, the center returns the HASH value of the block node which is successfully added to the user: in this step, the center returns the HASH value of the block node that was successfully added to the user.

Step S209, the center broadcasts a change message of the blockchain, and the subscriber updates the blockchain from the IPFS system according to the received message: in this step, the hub broadcasts a change message of the blockchain, and the subscriber updates the blockchain from the IPFS system according to the received message. After the present step is performed, step S210 is performed.

Step S210 ends: in this step, the process is ended.

In this embodiment, the implementation method of the blockchain further includes a key changing flow, and a flow chart of the key changing flow is shown in fig. 3. In fig. 3, the key change procedure includes the following steps:

step S31 generates a new key pair at regular time: in this step, to resist hacking, the participant periodically generates a new key pair.

Step S32, writing the new and old public keys into the IPFS system to obtain corresponding HASH values: in this step, the participant writes the new and old public keys into the IPFS system to obtain the corresponding HASH value.

Step S33 signs the file in the IPFS system using the old private key: in this step, the participant signs the file in the IPFS system using the old private key.

Step S34 sends a request for a uplink to the center, which links the signed file to the public key chain: in this step, the participants send a request for a upload to the center, which uploads the signed file in the IPFS system to the public key chain.

Step S35 records the new private key, and the subsequent signature is performed using the new private key: in this step, the participant records a new private key, and the subsequent signing is performed using the new private key.

In this embodiment, the implementation method of the blockchain further includes adding a user flow, and a flowchart of the adding user flow is shown in fig. 4. In fig. 4, the adding user flow includes the following steps:

step S41, before adding the user, first, the information of the added user is acquired, where the information of the added user includes the public key of the added person: in this step, the information of the added user is first acquired before the user is added, and the information of the added user includes the public key of the added person.

Step S42, saving the information of the added user to the IPFS system to obtain the HASH value of the new file: in this step, the information of the added user is saved to the IPFS system, and the HASH value of the new file is obtained, where the information of the added user includes the HASH of the user.

Step S43 signs the new file using the private key of the added user: in this step, the new file is signed using the private key of the added user.

Step S44 requests that the data be uplink to the user chain: in this step, the request is to uplink data to the user chain.

Step S45, after the user links successfully in the data, notifying the added user, and the added user links own data: in this step, after the user links the data successfully, the added user is notified that the added user can link the own data.

In this embodiment, the implementation method of the blockchain further includes deleting the user flow, and a flowchart of the deleting the user flow is shown in fig. 5. In fig. 5, the deleting user flow includes the following steps:

step S51 obtains information of the deleted user before deleting the user: in this step, the information of the deleted user is first acquired before the user is deleted.

Step S52, the deleted user information is stored in the IPFS system to obtain the HASH value of the new file: in this step, the deleted user information is saved to the IPFS system to obtain the HASH value of the new file, where the deleted user information includes the HASH of the user.

Step S53 signs the new file using its own private key: in this step, the new file is signed using the deleted user's own private key.

Step S54 requests that the data be uplink to the failure chain: in this step, the request is to uplink the data to the failing chain.

Step S55, the center judges whether the right is deleted: in the step, the center judges whether the deletion is authorized or not, and if yes, the step S56 is executed; otherwise, step S57 is performed. It should be noted that, in this embodiment, only the user himself or the creator of the user or the creator of the creator may delete the user (multiple levels may be skipped).

Step S56, after the data uplink is successful, notifying the deleted user that the deleted user can not request the data uplink any more: if the judgment result of the above step S55 is yes, the present step is executed. In this step, after the data uplink is successful, the deleted user is notified that the deleted user can not request the data uplink any more. After the present step is performed, step S57 is performed.

Step S57 ends: in this step, the process is ended.

According to the invention, a message pushing system is added, so that the subscriber updates the block information more timely; the user chain and the failure chain are added, so that the user can be effectively managed; the public key chain is added, so that the secret key can be changed regularly, and the violent cracking is effectively resisted; only HTTP/MQTT service and IPFS system are required to be built, realization is simple, the internal block chain of enterprises/industries is convenient to build, and the block chain popularization is facilitated.

The traditional blockchain technology pursues extremely 'decentralization', which makes the application very difficult; the present invention adopts a comparatively mediocre approach, and by combining "centralization" and "decentralization", the blockchain technique can be more effectively utilized to realize some applications.

The present invention still uses IPFS to achieve distributed storage of data; the data is unified and uplink by the center, so that the bifurcation of the block chain can be prevented, and the growth speed of the block chain can be controlled; the user data is stored in an IPFS file separately, and only HASH value and signature of the file are stored on the block node, namely only HASH value of the user file is hung on the block node, but not the whole content; a message push MQTT platform is added, and change messages of the block chain are broadcast, so that the instantaneity of the system is improved; the user chain and the failure chain are added to record which users are added and which users are reduced, so that the users can be managed; the public key chain is added to record the change condition of the public key, so that participants (users and centers) can frequently replace own secret keys, and the violent cracking can be effectively resisted.

a. Blockchain specification

The invention adds a user chain, a dead chain and a public key chain besides the data chain for recording the transaction. The user chain is used to record which users are present in the overall system, as well as the information of the users. The failure chain records which users have failed. The failed user cannot add data to the chain (can write data to the IPFS system, but cannot be booted and acknowledged; the data before the time of the failure start that has been booted is still considered valid). The public key chain records the public and private key change condition of the user. If any of the participants fails to verify the data signature of a user, the modified public key may be used for verification.

a1, for user chain description, using the user chain to store user data at least comprises the following contents:

a11, user ID

a12, creator HASH

a13, user name

a14, user public key

Wherein a11 refers to the ID of the user, such as an ID card number or other certificate numbers; a12 is used to locate creator information in the IPFS; a13 is used for recording the name of the user; a14 is used to record the user's initial public key and to verify the data published by this user. If the user's public key cannot be found on the public key chain, then this public key should be used to sign the data.

a2, for the failure link description, the failure link is used for storing the failure user, and the failure user at least comprises the following contents:

a21, user HASH

a22 and executive HASH

a23 time to failure

a24 cause of failure

Wherein a21 is used to locate this user's data in the IPFS; a22 is used to locate the information of the person who disabled this user in the IPFS, the executor may be the user itself, or the creator or an ancestor of the creator (creator of creator); a23 is used to record the time of onset of failure (including this time point); a24 is used to record the failure cause.

a3, for the description of the public key chain, the public key chain is used for storing the user public key change record, which at least comprises the following contents:

a31, user HASH

a32, user original public key

a33 user present public key

a34, public key change time

Wherein a31 is used to locate this user's data in the IPFS; a32 represents the original public key; a33 represents the modified public key; a34 represents the public key change time.

b. Block node description

The block chain is composed of block nodes, each block node is a file and is used for storing the information of the node on the chain and the front and back nodes, storing the positioning information of the user data file associated with the block node, storing the time stamp generated by the user data, storing the positioning information of the user and storing the signature of the node. In general, if this node is found, then the user data hanging on this node can be found.

One block node contains the following:

b1, last block node HASH value PH

b2, the file name NH of the next block node

b3, HASH value FH of the file hanging on the current node

b4 TIME stamp of user data

b5, user HASH value UH

b6 node signature BS

Wherein b1 is used to locate the previous block in the IPFS, the null value being represented as the first block in the chain, denoted by PH; b2 points to the file name of the next node and is used for locating the next node and is expressed by NH; b3 is used to locate the user file hanging on this node in IPFS, denoted FH; b4 is the TIME of user data storage; b5 data used to locate the user in IPFS; b6 is a signature of the node data, denoted BS, to prevent tampering of the stored data.

The next node name calculation method:

NH＝BS

the storage space of each node can be reduced by using the signature BS of the node as the file name of the next node, so that the calculation amount is reduced.

The node signature BS calculating method comprises the following steps:

US＝RSA_ENC(PRIVATE_KEY2,FH+TIME+UH)，

BS＝RSA_ENC(PRIVATE_KEY1,US+PH)，

wherein US represents user generated signature data, BS represents center generated signature data, rsa_enc represents encryption algorithm of RSA, privatekey 1 represents PRIVATE KEY of center, privatekey 2 represents PRIVATE KEY of user, FH represents HASH value of stored content, and TIME represents storage timestamp.

The calculation method of the BS is described as that firstly, the user key is used for encrypting data such as HASH and time stamp of the stored content to obtain US, and then the central key is used for encrypting the US and the HASH value of the previous node to obtain the BS.

The signature BS verification method comprises the following steps:

US＝RSA_DEC(PUBLIC_KEY1,BS)-PH,

FH+TIME+UH＝RSA_DEC(PUBLIC_KEY2,US)，

wherein US represents user generated signature data, BS represents center generated signature data, rsa_dec represents a decryption algorithm of RSA, public_key1 represents a PUBLIC KEY of the center, public_key2 represents a PUBLIC KEY of the user, FH represents HASH value of the stored content, and TIME represents a storage TIME stamp. If the calculated parameters such as FH are correct, the signature is valid.

c. Uplink description

In the invention, the user can store own information on the IPFS system in the form of a file, but if the HASH value of the user file is to be stored on the blockchain, the user needs to request the center to realize the unified uplink, namely the center unifies the uplink, so that the possibility of bifurcation of the blockchain is avoided, and meanwhile, the growth speed of the blockchain can be effectively controlled. For example: if a user is found to frequently request uplink data in a short period of time, an error message is returned to the user, requiring the user to wait for a period of time before making the uplink request.

The data uplink is realized by sending a uplink request to the center, and the uplink request data comprises the following contents:

c1: user HASH

c2: blockchain ID

c3: block chain end node HASH

c4: HASH of file hanging on current node

c5: TIME stamp of user data

c6: user file content signature US

Wherein c1 is used to locate this user's data in the IPFS; c2 is used to specify the blockchain of the uplink; c3 is the last node of the user's local current blockchain; c4 is used to locate the content of the suspended data in the IPFS, denoted by FH; c5 is the time the user generated the data; c6 is a signature of the user file content, denoted US, for verifying the validity of the data to the center.

After receiving the request data, the center checks the validity of FH and the signature US, if the FH and the signature US are legal, a block node is established to a designated chain, and then an addition confirmation is returned. If the center considers that the parameter is wrong, returning rejection; after the requester receives the rejection, the error should be corrected and the request is reinitiated.

In practical application, under the condition of low requirement, the following alternative scheme can be adopted: 1) The uplink data is not stored separately, but is stored directly on the block node file; 2) The invention uses different methods of calculating signatures; 3) The non-HTTP/MQTT technology is used for realizing the central unified uplink function; 4) Distributed storage is implemented using a non-IPFS file system.

In summary, in this embodiment, the center unifies the uplink, so as to technically avoid the problem of blockchain bifurcation; the MQTT and other technologies are adopted to broadcast the block chain change information in real time, so that the real-time performance of the system is provided; a special signature calculation method is adopted; managing users using a user chain and a dead chain; the key pair change is implemented using a public key chain. The invention can easily build the blockchain in enterprises or industries, reduce the risk brought by publishing sensitive data to the external network, and facilitate the popularization of the blockchain.

The foregoing description of the preferred embodiments of the invention is not intended to be limiting, but rather is intended to cover all modifications, equivalents, alternatives, and improvements that fall within the spirit and scope of the invention.

Claims

1. The block chain implementation method is characterized by comprising a client data uplink flow, wherein the client data uplink flow comprises the following steps:

a5 The client downloads the newly added block node and executes the step A7);

a6 The client performs exception handling and returns to the step A3);

a7 Ending).

2. The method of claim 1, further comprising a center-to-data-chaining procedure, the center-to-data-chaining procedure comprising the steps of:

b1 The center receives a request for adding block nodes;

b10 Ending).

3. The method of claim 1, further comprising a key change procedure, the key change procedure comprising the steps of:

c1 A pair of new key pairs is generated at regular time;

c3 Signing a file in the IPFS system using an old private key;

c5 A new private key is recorded with which the subsequent signing takes place.

4. The method of claim 1, further comprising adding a user flow, the adding a user flow comprising the steps of:

d3 Signing the new file using the private key of the added user;

d4 Request to uplink data to the user chain;

5. The method of claim 1, further comprising deleting the user flow, the deleting the user flow comprising the steps of:

e1 Acquiring information of the deleted user before deleting the user;

e3 Signing the new file using its own private key;

e4 Request to uplink data to the failure chain;

e7 Ending).

6. The method of claim 5, wherein the user himself or the creator of the user or the creator's upper creator can delete the user.