Method for Obtaining Information of Real Transaction Submitter in Blockchain Smart Contract

Abstract

The present invention relates to a method for obtaining information of the real transaction submitter in a blockchain smart contract, including: submitting the public key of the business system authentication service to the blockchain ledger in advance; the user logs in and obtains a token, submits a transaction to the business system, and the business system verifies the token; the business system transparently transmits the token, and after assembling it with the business transaction data, sends them to the blockchain application together; the blockchain application continues to transparently transmit to the blockchain network, and finally executes the smart contract on the blockchain endorsement node and the accounting node; if the token carries a payload, the smart contract directly parses the token to obtain the payload; if the token does not carry a payload, the business system authentication service is called to obtain the payload using the token; the public key is used to parse and verify the signature validity in the token again, and if the verification passes, the user name of the transaction submitter is recognized as the real submitter, and the transaction is submitted to the blockchain ledger. This solution can obtain information of the real transaction submitter and improve the authenticity of the blockchain application records.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and particularly to a method for obtaining information of the real transaction submitter in a blockchain smart contract. Background Art

[0002] With the development of blockchain technology, in addition to the anonymous and public public chain technology, currently more and more enterprises and industries have introduced private chain or consortium chain technology based on smart contracts, which is real-name and not publicly or semi-publicly available, mainly for recording transaction data within an enterprise or within an industry by utilizing the distributed and immutable characteristics of blockchain technology (any transaction processing can be understood as a transaction).

[0003] Many people in the same industry understand blockchain as a "distributed ledger", similar to the role of a database. Currently, generally, the data (transactions) that need to be recorded on the blockchain are prepared by an external system and then submitted to the smart contract. Then, through processes such as endorsement, sorting, and broadcasting by the smart contract, they are finally submitted to each accounting node (the node where the blockchain ledger is located) in the blockchain network for recording. Since the data on the blockchain is immutable, a problem will arise, that is, how to ensure that the identity of the data record submitter is real. If not ensured, then the wrong submitter identity may be recorded in the blockchain ledger and cannot be tampered with, and the transactions recorded by the blockchain application will be questioned.

[0004] To solve this problem, there are the following existing methods:

[0005] Method 1: Use an external application system to verify the user identity, and then the blockchain directly records the data records submitted by the external application without further verification, and directly records the existing data into the blockchain ledger, such as data provided by authoritative departments such as the vehicle management department and the housing management department.

[0006] The disadvantages of this method are obvious. The blockchain does not use the smart contract to verify the transaction, but unconditionally trusts the data of the external application system. When the external application system makes a mistake or is maliciously tampered with, it cannot be detected.

[0007] Method 2: The blockchain issues an identity to the external application system. No matter what data the external application submits, it is recorded as the data record submitted by this identity.

[0008] The disadvantages of this method are also obvious. The submitter of all transactions recorded by the blockchain is not the operator, but "a certain external application system". When it is necessary to trace the transaction, it can only be traced back to the submission system, and the real operator cannot be traced.

[0009] Method 3: The blockchain needs to correspond to an external application system and synchronously establish an equal number of user identities. When the external application system submits data, the blockchain selects the same user identity as that on the external application system for recording.

[0010] This method seems to be okay, but in fact, the synchronous establishment, synchronous enabling and disabling, synchronous modification, and synchronous cancellation of users are all relatively complex logics; and there is still no effective verification of the identity of the submitter. Summary of the Invention

[0011] The technical problem to be solved by the present invention is: to provide a new way to obtain the information of the real transaction submitter in the blockchain smart contract; in the blockchain smart contract, use the same verification materials and verification logic as the external application system to independently verify the identity of the operator of the business system, truthfully reflect the operator information, and record the operator information together with the submitted data into the blockchain ledger.

[0012] According to the technical solution of the present invention, the present invention provides a method for obtaining the information of the real transaction submitter in the blockchain smart contract, including:

[0013] Step 1, submit the public key corresponding to the private key used by the business system authentication service of the institution to be operated in advance as the initialization data of the smart contract in the blockchain network to the blockchain ledger;

[0014] Step 2, the user logs in to the business system authentication service and obtains the token of the business system, submits a transaction to the business system, and the business system verifies the token;

[0015] Step 3, the business system transparently transmits the token of the transaction submitter and assembles it with the business transaction data and then sends it to the blockchain application;

[0016] Step 4, the blockchain application continues to transparently transmit the business transaction data containing the token of the transaction submitter to the blockchain network, and finally execute the smart contract on the blockchain endorsement node and the accounting node;

[0017] Step 5, when executing the smart contract in the blockchain network, parse the token; when parsing the token, first parse the institution name from the payload in the token, then obtain the public key of the institution submitted in Step 1 from the blockchain ledger, and use the public key to parse and verify the signature validity in the token again. If the verification passes, trust the content in the payload of this token, and recognize the user name of the transaction submitter as the real submitter, and submit the transaction to the blockchain ledger.

[0018] Further, it further includes Step Six. When conducting a lifecycle maintenance transaction, the lifecycle maintenance transaction is regarded as an ordinary business transaction. The smart contract uses the same method to verify the token signed by the private key and finally submits it to the accounting node to be recorded in the blockchain ledger.

[0019] Preferably, in Step Three, after assembling the business transaction data and before accessing the blockchain application, it further includes using the private key of the business system to perform a secondary signature on the assembled transaction data.

[0020] Further, after Step Four S4 and when executing to the smart contract, first use the public key of the business system to verify the validity of the token signature for the entire assembled transaction data. After the verification passes, then proceed to Step Five.

[0021] Further, if there are multiple business systems corresponding to the same set of blockchain networks, before each business system conducts a business transaction, two pairs of public and private key pairs are generated. The private keys are respectively held by the authentication service of the business system and the business system itself, and the public keys are all submitted to the blockchain ledger for recording.

[0022] In one embodiment, Step Two includes:

[0023] The user logs in to the authentication service of the business system. After the authentication service of the business system verifies the user information, it uses the private key to sign the token. The token contains a signature and is returned to the user.

[0024] The user carries this token and submits a transaction to the business system.

[0025] The business system first intercepts the submitted transaction request and uses the public key pre-distributed by the authentication service of the business system to verify the signature in the token. Only if the verification passes, will it continue with the subsequent Step Three.

[0026] Compared with the prior art, the beneficial technical effects of the present invention are as follows:

[0027] The present invention uses smart contracts to treat ordinary business transactions and public key management transactions equally. In both cases, the identity of the transaction submitter needs to be independently verified in the blockchain smart contract, and the identity obtained through independent verification is submitted as a record to the blockchain ledger. In summary, the present invention mainly utilizes signature and signature verification mechanisms (including the use of asymmetric encryption, hashing algorithms, and digital signature technologies), the automatic isolation execution feature of smart contracts in the blockchain (ensuring that the execution process is not interfered with by the outside world, there is no disagreement with the execution logic, and execution is carried out when the conditions are met), the feature that the data in the blockchain ledger cannot be tampered with (the public key has been submitted to the blockchain ledger), and the distributed feature of the blockchain (the data that the trusted parties have successfully submitted and recorded in the blockchain ledger), thereby ensuring that the identity of the data record submitter is real, improving the authenticity of the records in the blockchain application program, and solving the problems of message tampering prevention and message non-repudiation in the transaction chain from the business system to the blockchain system, as well as the problems that the joint audit method cannot meet the consistency and integrity of the content uploaded to the chain. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 is a flowchart of the method according to an embodiment of the present invention.

[0029] Figure 2 is a flowchart of the method according to another embodiment of the present invention.

[0030] Figure 3 is a flowchart of the method of the prior art solution. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0031] First, it needs to be supplemented and explained that the "accounting node" described in the present invention refers to a physical machine, virtual machine, or docker container, which is equivalent to a computer, and the responsibility of this computer is to keep accounts; and the "blockchain ledger" described in the present invention exists on each accounting node and is consistent. The blockchain ledger is a set of files in which the recorded transaction data exists on the accounting node.

[0032] Moreover, the token described in the present invention generally refers to JWT (JSON Web Token). A JWT consists of three parts: Header, Payload, and Signature. The Header contains information such as the signature algorithm and the token type; the Payload is used to store the actual data to be transmitted, generally including the token number, username, user roles, expiration time, effective time, etc.; the Signature is signed by the token issuer using the private key held alone by itself and the signature algorithm identified in the Header for the hash values of the first two parts to prevent data tampering. Any program holding the public key corresponding to the private key can verify the signature part in the token. If the verification passes, it can prove that the token was indeed issued by the issuer and has not been tampered with.

[0033] Furthermore, the signature described in the present invention (i.e., digital signature, also known as public key digital signature) is a digital string that can only be generated by the sender of the information and cannot be forged by others. This digital string is also a valid proof of the authenticity of the information sent by the sender of the information. It is a method similar to an ordinary physical signature written on paper, but is implemented using techniques in the field of public key cryptography for authenticating digital information. A set of digital signatures usually defines two complementary operations, one for signing and the other for verification. Digital signature is the application of asymmetric key encryption technology and digital digest technology.

[0034] Taking the existing method 2 described in the background art above as an example, please refer to Figure 3 , and this method 2 specifically includes the following steps.

[0035] 1. First, the user logs in to the authentication service of the business system by means of username, password, or biometric identification, etc. After the authentication service of the business system verifies the username, password, or biometric information, it issues a token (token) using the private key. The token contains a signature and is returned to the user.

[0036] 2. The user carries this token and submits a transaction to the business system (sends a transaction submission request to the business system). The business system first intercepts the transaction submission request and uses the public key pre-distributed by the authentication service of the business system to verify the signature in the token. The private key and the public key are a pair of keys of an asymmetric encryption algorithm. The public key can verify the token signed by the private key. If the verification passes, the business system recognizes this token and can also confirm that the transaction submitter (the user submitting the transaction) is a real user authenticated by the authentication system.

[0037] 3. The blockchain network takes the business system as a client and also pre-assigns blockchain member identity information to it. It should be noted that here the identity information is assigned to the business system, rather than directly to the transaction submitter.

[0038] 4. The business system uses the pre-assigned blockchain member identity information to connect to the blockchain application, allowing the blockchain application to proxy it to send transaction data (i.e., the data of the transaction submitted by the user) to the blockchain network, execute the smart contract. The blockchain application proxy finds a sufficient number of endorsing nodes for this transaction data for endorsement, then collects a sufficient number of endorsed transaction read-write sets, packs and sends them to the sorting node, waits for the sorting node to sort and generate a block and then broadcasts it to the accounting node (the node where the blockchain ledger is located), and waits for the blockchain ledger to complete verification and accounting, completing this complete process.

[0039] In the process of the smart contract obtaining transaction data mentioned above, the problem encountered is that the token in the business system cannot be passed to the smart contract, and the smart contract cannot verify the validity of the business system token, so it cannot confirm the identity of the transaction submitter recorded in the blockchain ledger. It cannot independently verify the authenticity of the data uploaded to the chain. Therefore, here it can only unconditionally trust the verification result of the business system, and trust that the business system itself and during the transmission process, the transaction data and the identity of the transaction submitter have not been tampered with.

[0040] One of the improvements made by the present invention on this basis is that its main idea is to expand the scope of action of the business system token to cover the entire business system and the blockchain system. Please refer to Figure 1 , and specifically includes the following steps.

[0041] Step S1: First, submit the public key corresponding to the private key of the business system authentication service of the institution to be operated in advance as the initialization data of the smart contract in the blockchain network to the blockchain ledger.

[0042] Step S2: The user logs in to the business system authentication service and obtains the token of the business system, and submits a transaction to the business system. The business system verifies the token. This part of the process is the same as the aforementioned existing method, that is, specifically including:

[0043] Step S21: The user logs in to the authentication service of the business system. After the authentication service of the business system verifies the user information, it signs and issues a token using the private key. The token contains a signature and returns the token to the user.

[0044] Step S22: The user carries this token and submits a transaction to the business system (sends a transaction submission request to the business system).

[0045] Step S23: The business system first intercepts the submitted transaction request and uses the public key pre-distributed by the authentication service of the business system to verify the signature in the token. If the verification passes, the subsequent steps are continued.

[0046] Step S3: The business system transparently transmits the token of the transaction submitter (the user who submits the transaction) and assembles the business transaction data (assembles the user token and the business transaction data), and then sends them together to the blockchain application.

[0047] Step S4: The blockchain application continues to transparently transmit the business transaction data containing the token of the transaction submitter to the blockchain network (the corresponding blockchain node), and finally executes the smart contract on the blockchain endorsement node and the accounting node.

[0048] Step S5: When the smart contract is executed in the blockchain network (the corresponding blockchain node), the token is parsed. It should be noted that this solution is only implemented and introduced in detail for the case where the token carries the payload for the time being. If the token does not carry the payload, generally speaking, the institution information can be obtained by calling the authentication service of the business system using the token, so as to obtain the payload. However, the actual situation will be more complex and will not be introduced in detail here;

[0049] Specific steps for parsing the token are, for example, first parse the institution name from the payload in the token, then obtain the public key of the institution pre-archived in the blockchain ledger (submitted in Step S1), and use this public key to parse and verify the validity of the signature in the token again (signature verification). If the verification passes, trust the content of the payload in this token, and identify the username of the transaction submitter as the real submitter, and submit the transaction to the blockchain ledger.

[0050] Step S6 can also be carried out when needed. If lifecycle maintenance transactions are required, that is, replacing, revoking the public keys corresponding to the private keys used by the authentication services of each existing institution or adding new institutions, only need to regard these lifecycle maintenance transactions as ordinary business transactions. The smart contract also uses the same method as above to verify the token signed by the private key, and finally submit it to the accounting node to be recorded in the blockchain ledger.

[0051] Furthermore, please refer to Figure 2 , and the present invention preferably further includes the following improvements:

[0052] In addition to authenticating the identity of the transaction submitter, the identity of the business system also needs to be authenticated. Therefore, a public-private key pair needs to be generated in advance. The private key is saved by the business system itself, and the public key is used to verify the identity of the operator in the same way as for ordinary business transactions, and the public key of the business system is submitted to the blockchain ledger for accounting.

[0053] In step S3, after assembling the business transaction data and before accessing the blockchain application, the private key of the business system is used to perform a secondary signature on the assembled transaction data again.

[0054] After step S4, when executing the smart contract, first use the public key of the business system to verify the validity of the token signature for the entire assembled transaction data. After the signature verification passes, then proceed to step S5 to verify the signature of the transaction submitter's identity.

[0055] It should be noted that if there are multiple business systems corresponding to the same set of blockchain networks, the method of the present invention can also be adopted. It only requires each business system to generate two pairs of public-private key pairs before executing business transactions. The private keys are respectively held by the authentication service of the business system and the business system itself, and the public keys are all submitted to the blockchain ledger for recording and backup through the above-mentioned step S6 (or step S1). The solution of the present invention adopts asymmetric encryption. The symmetric encryption algorithm uses the same secret key for encryption and decryption, while the asymmetric encryption algorithm requires two keys for encryption and decryption, which are the public key (public key, abbreviated as public key) and the private key (private key, abbreviated as private key).

[0056] The process and principle of asymmetric encryption are as follows:

[0057] 1. Party B generates a pair of keys (public key and private key) and makes the public key public to other parties.

[0058] 2. Party A, who obtains the public key, uses the key to encrypt the confidential information and then sends it to Party B.

[0059] 3. Party B then decrypts the encrypted information with the private key it saves. Party B can only decrypt the information encrypted by the corresponding public key with its dedicated key (private key).

[0060] During the transmission process, even if an attacker intercepts the transmitted ciphertext and obtains Party B's public key, the ciphertext cannot be cracked because only Party B's private key can decrypt the ciphertext.

[0061] Similarly, if Party B wants to reply with encrypted information to Party A, then Party A needs to first publish its public key to Party B for encryption, and Party A itself keeps its private key for decryption. When sending a message, the sender uses a hash function to generate a message digest from the message text, and then encrypts this digest with the sender's private key. This encrypted digest will be sent to the recipient together with the message as the digital signature of the message. The recipient first calculates the message digest from the received original message using the same hash function as the sender, and then uses the public key to decrypt the digital signature attached to the message. If the two digests are the same, then the recipient can confirm that the message is from the sender.

[0062] Digital signatures have two functions: one is to determine that the message was indeed signed and sent by the sender, because others cannot forge the sender's signature; the other is to determine the integrity of the message, because the characteristic of a digital signature is that it represents the characteristics of the file. If the file changes, the value of the digital digest will also change, and different files will get different digital digests. A digital signature involves a hash function, the recipient's public key, and the sender's private key.

[0063] The key improvement of the present invention is to use smart contracts to treat ordinary business transactions and public key management transactions equally. In both cases, the identity of the transaction submitter needs to be independently verified in the blockchain smart contract, and the identity obtained through independent verification is submitted as a record to the blockchain ledger. And there is almost no transformation of the original business system. Generally speaking, the present invention mainly utilizes the signature and signature verification mechanisms (including the use of asymmetric encryption, hash algorithms, and digital signature technologies), the automatic isolation execution characteristics of smart contracts in the blockchain (ensuring that the execution process is not interfered by the outside world, there is no objection to the execution logic, and it will be executed when the conditions are met), the characteristic that the data in the blockchain ledger cannot be tampered with (the public key has been submitted to the blockchain ledger), and the distributed characteristic of the blockchain (trusting the data submitted by all parties), thereby ensuring that the identity of the submitter of the data record is real, improving the authenticity of the records of blockchain application programs, and solving the problems of message anti-tampering and message anti-repudiation in the transaction chain from the business system to the blockchain system, as well as the problems that the joint audit method cannot meet the consistency and integrity of the content uploaded to the chain.

Claims

1. A method for obtaining information of the real transaction submitter in a blockchain smart contract, characterized in that, Including: Step 1: Submit the public key corresponding to the private key used for the business system authentication service of the mechanism to be operated in advance as the initialization data of the smart contract in the blockchain network to the blockchain ledger; Step 2: The user logs in to the business system authentication service and obtains the token of the business system, submits a transaction to the business system, and the business system verifies the token; Step 3: The business system transparently transmits the token of the transaction submitter, and after assembling it with the business transaction data, sends them together to the blockchain application; Step 4: The blockchain application continues to transparently transmit the business transaction data containing the token of the transaction submitter to the blockchain network, and finally executes the smart contract on the blockchain endorsement node and the accounting node; Step 5: When executing the smart contract in the blockchain network, parse the token; when parsing the token, first parse the organization name from the payload in the token, then obtain the public key of the organization submitted in Step 1 from the blockchain ledger, use this public key to parse and verify the signature validity in the token again. If the verification passes, trust the content in the payload of this token, and identify the username of the transaction submitter as the real submitter, and submit the transaction to the blockchain ledger; Step 6: When performing a lifecycle maintenance transaction, regard the lifecycle maintenance transaction as an ordinary business transaction. The smart contract uses the same method to verify the token signed by the private key and finally submits it to the accounting node to be recorded in the blockchain ledger.

2. The method for obtaining information of the real transaction submitter in the blockchain smart contract according to claim 1, wherein In Step 3, after assembling the business transaction data and before accessing the blockchain application, it also includes using the private key of the business system to perform a secondary signature on the assembled transaction data.

3. The method for obtaining information of the real transaction submitter in the blockchain smart contract according to claim 2, wherein, After Step 4, when executing the smart contract, first use the public key of the business system to verify the token signature validity of the entire assembled transaction data; after the verification passes, then proceed to Step 5.

4. The method for obtaining information of the real transaction submitter in the blockchain smart contract according to any one of claims 1-3, characterized in that, If there are multiple business systems corresponding to the same set of blockchain networks, before each business system executes a business transaction, generate two pairs of public and private key pairs. The private keys are respectively held by the authentication service of the business system and the business system itself, and the public keys are all submitted to the blockchain ledger for record and backup.

5. The method for obtaining information of the real transaction submitter in the blockchain smart contract according to any one of claims 1-3, characterized in that, Step 2 includes: The user logs in to the authentication service of the business system. After the authentication service of the business system verifies the user information, it uses the private key to sign the token. The token contains a signature and returns the token to the user; The user carries this token and submits a transaction to the business system; The business system first intercepts the submitted transaction request, and uses the public key pre-distributed by the authentication service of the business system to verify the signature in the token. If the verification passes, it continues with the subsequent Step 3.

Images