CN110750808B - A bill processing method, device and storage medium device - Google Patents

Abstract

The embodiment of the invention discloses a bill processing method, a bill processing device and a storage medium device. The bill processing method comprises the following steps: receiving a bill acquisition request sent by a first terminal, wherein the bill acquisition request comprises bill information; generating a bill for the first terminal according to the bill information; processing the bill according to the first private key use right of the first terminal and the intelligent contract to obtain a first digital signature; and sending the bill and the first digital signature to a second terminal corresponding to a second terminal identifier included in the bill information, so that the second terminal obtains the bill. By adopting the embodiment of the invention, the service node equipment can generate the bill for the first terminal under the condition that the private key of the first terminal is not obtained and only the private key use right of the first terminal is obtained, so that the security of the private key of the first terminal can be improved.

Description

A bill processing method, device and storage medium device

Technical Field

The present application relates to the field of communication technology, and in particular to a bill processing method, device and storage medium device.

Background technique

At present, many enterprises authorize the bill generation operation to a third-party service provider, namely the bill service provider, and the bill service provider generates bills for the enterprise based on the bill information sent by the enterprise.

After the enterprise authorizes the bill service provider, it will send the enterprise's private key to the bill service provider. After the bill service provider generates a bill for the enterprise, it will use the enterprise's private key to process the bill, encrypt the bill and indicate that the generated bill has been approved by the enterprise. However, this method has the risk of leakage of the enterprise's private key.

Summary of the invention

The embodiments of the present invention provide a bill processing method, device and storage medium device. The implementation of the present invention can improve the security of private keys.

In a first aspect, an embodiment of the present invention provides a bill processing method, the method comprising:

Receive a ticket acquisition request sent by a first terminal, the ticket acquisition request including ticket information; generate a ticket for the first terminal according to the ticket information; process the ticket according to the first private key usage right and the smart contract of the first terminal to obtain a first digital signature; send the ticket and the first digital signature to a second terminal corresponding to a second terminal identifier included in the ticket information, so that the second terminal obtains the ticket.

In this technical solution, the business node device generates a ticket for the first terminal based on the ticket information from the first terminal, and then encrypts the ticket based on the first private key usage right of the first terminal and the smart contract, and sends the encrypted ticket to the second terminal corresponding to the second terminal identifier included in the ticket information. During the entire ticket generation process, the business node device does not obtain the private key of the first terminal, but only obtains the right to use the first private key of the first terminal, which can improve the security of the private key of the first terminal.

In a second aspect, the present invention provides a bill processing device, the device comprising:

A receiving module, configured to receive a ticket acquisition request sent by the first terminal, wherein the ticket acquisition request includes ticket information;

A generating module, used for generating a ticket for the first terminal according to the ticket information;

A processing module, configured to process the bill according to the first private key usage right of the first terminal and the smart contract to obtain a first digital signature;

The sending module is used to send the ticket and the first digital signature to the second terminal corresponding to the second terminal identifier included in the ticket information, so that the second terminal obtains the ticket.

In a third aspect, an embodiment of the present invention provides a bill processing device, characterized in that it includes a processor and a memory, and the processor and the memory are interconnected, wherein the memory is used to store a computer program, and the computer program includes program instructions, and the processor is configured to call the program instructions to execute the method of the first aspect.

In a fourth aspect, the present invention provides a computer storage medium, characterized in that the computer storage medium stores a computer program, the computer program includes program instructions, and when the program instructions are executed by a processor, the processor executes the method of the first aspect.

By implementing the example of the present invention, the service node device generates a ticket for the first terminal when only obtaining the first private key usage right of the first terminal, and encrypts the ticket according to the first private key usage right and the smart contract. This method can improve the security of the private key of the first terminal. If the first terminal updates the private key of the first terminal, the private key usage right corresponding to the private key will also become invalid. At this time, the service node device can send an update request to the first terminal to request the update of the second private key usage right corresponding to the first terminal after the private key is updated, or the service node device receives the second private key usage right sent by the first terminal at intervals of a first preset period. This method enables the service node device to obtain the corresponding private key usage right after the private key is updated even if the first terminal updates the private key of the first terminal. At the same time, the service node device can generate a ticket for the first terminal according to the target ticket information containing the same second terminal identifier in the ticket information or the target ticket information with the highest credit rating of the second terminal corresponding to the second terminal identifier in the ticket information, which can improve the efficiency of the service node device in generating tickets.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the background technology, the drawings required for use in the embodiments of the present invention or the background technology will be described below.

In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the background technology, the drawings required for use in the embodiments of the present invention or the background technology will be described below.

Figure 1 is a schematic diagram of the current process of blockchain electronic invoice generation;

FIG2 is a schematic diagram of the architecture of a bill processing system provided by an embodiment of the present invention;

FIG3 is a schematic diagram of a flow chart of a bill processing method provided by an embodiment of the present invention;

FIG4 is a schematic flow chart of another bill processing method provided by an embodiment of the present invention;

FIG5 is a schematic diagram of a flow chart of another bill processing method provided by an embodiment of the present invention;

FIG6 is a schematic diagram of the structure of a bill processing device provided by an embodiment of the present invention;

FIG. 7 is a schematic diagram of the structure of another bill processing device provided in an embodiment of the present invention.

Detailed ways

The embodiments of the present invention are described below in conjunction with the accompanying drawings in the embodiments of the present invention.

At present, the generation process of blockchain electronic invoices is shown in Figure 1. Enterprise A authorizes the bill generation operation to the bill service provider. When the seller (Enterprise A) and the buyer (Enterprise B) conduct a transaction, transaction information is generated. Enterprise A needs to issue an invoice to Enterprise B based on the transaction information. At this time, Enterprise A sends the bill information generated based on the transaction information and the private key of Enterprise A to the bill service provider. The bill service provider generates a bill for Enterprise A based on the bill information, and then uses the private key of Enterprise A to process the bill, encrypt the bill, and allow the generation of the bill to be recognized by Enterprise A. Finally, the processed bill is sent to the buyer Enterprise B, so that Enterprise B obtains the bill. During the bill generation process, the bill service provider can obtain the private key of Enterprise A, and there is a risk that the private key of Enterprise A will be leaked.

The embodiment of the present invention proposes a bill processing method, device and storage medium device. In this method, the first terminal authorizes the bill generation operation to the business node device in the blockchain network. When the first terminal and the second terminal complete the transaction, and the first terminal needs the business node device to generate a bill for it, the first terminal sends a bill acquisition request to the business node device. The bill acquisition request includes bill information. The business node device generates a bill for the first terminal according to the bill information, and processes the bill according to the first private key usage right of the first terminal and the smart contract to obtain a first digital signature. Finally, the bill and the first digital signature are sent to the second terminal corresponding to the second terminal identifier included in the bill information, so that the second terminal obtains the bill. In this way, the business node device only obtains the right to use the private key of the first terminal, but does not obtain the private key of the first terminal. There is no risk of the private key of the first terminal being leaked, which can improve the security of the private key.

In the process of bill processing, taking the first terminal as the seller, the second terminal as the buyer, and the business node device as the bill service provider as an example, the bill service provider can issue an invoice for the seller. When the seller and the buyer complete the transaction, the seller needs to issue an invoice for the buyer. At this time, the bill service provider can help the seller to implement the invoicing operation. Therefore, the seller sends a bill acquisition request to the bill service provider, and the bill acquisition request includes bill information; the bill service provider issues an invoice for the seller based on the bill information, and processes the bill based on the seller's private key usage rights and smart contracts to obtain the first digital signature; finally, the bill service provider sends the bill and the first digital signature to the buyer so that the buyer can obtain the bill. In this invoice issuance process, the bill service provider only obtains the seller's private key usage rights, but does not obtain the seller's private key, so the security of the private key can be improved.

Blockchain is a new application model of computer technologies such as distributed data storage, consensus mechanism and encryption algorithm. It is essentially a decentralized database. Blockchain can be composed of multiple serial transaction records (also known as blocks) that are connected and protected by cryptography. The distributed ledger connected by blockchain allows multiple parties to effectively record transactions and can permanently check the transactions (cannot be tampered with).

In the bill processing process of the present application, the business node device on the blockchain stores a smart contract, and the bill can be processed through the smart contract and the private key usage right of the first terminal to obtain the first digital signature. Among them, a smart contract is a computer protocol designed to disseminate, verify or execute a contract in an information-based manner, allowing trusted transactions without a third party, which are traceable and irreversible. A smart contract is a set of commitments defined in digital form, including an agreement on which the contract participants can execute these commitments, and is a piece of code written on the blockchain.

In order to better understand the bill processing method, device and storage medium device disclosed in the embodiments of the present invention, the architecture of the system to which the embodiments of the present invention are applicable is first described below.

Please refer to Figure 2, which is a schematic diagram of the architecture of a bill processing system provided by an embodiment of the present invention. As shown in Figure 2, the system is composed of a first terminal 201, a second terminal 202 and a blockchain network 203. The blockchain network 203 includes a business node device 2031 and a consensus node device 2032. There can be multiple consensus node devices in the blockchain network. The consensus node device is used to process the notification information from the business node device on the chain, and the business node device is used to generate a bill for the first terminal. The first terminal and the second terminal are outside the blockchain network, do not participate in the chain process, and do not store information in the blockchain network. The system architecture shown in Figure 2 is for example only and does not constitute a limitation on the embodiments of the present invention.

Among them, the first terminal can be a terminal device used by the seller during the transaction process, and the second terminal can be a terminal device used by the buyer during the transaction process. Optionally, the first terminal can be a terminal device used by the buyer during the transaction process, and the second terminal can be a terminal device used by the seller during the transaction process. For the convenience of description, unless otherwise specified, the first terminal in the embodiment of the present invention is a terminal device used by the seller during the transaction process, and the second terminal is a terminal device used by the buyer during the transaction process.

The first terminal and the second terminal may include, but are not limited to, smart phones (such as Android phones, iOS phones, etc.), tablet computers, portable personal computers, smart wearable devices and other devices, and these terminal devices have functions such as network communication.

Based on the above description, the embodiment of the present invention proposes a bill processing method as shown in FIG3 . The bill processing method may include S301-S308:

S301: The first terminal sends a ticket acquisition request to a service node device, where the ticket acquisition request includes ticket information.

Specifically, after the first terminal and the second terminal complete the transaction, the first terminal needs to provide a ticket to the second terminal based on the transaction information. At this time, the first terminal sends a ticket acquisition request to the business node device so that the business node device generates a ticket for the first terminal. The ticket acquisition request includes ticket information, and the ticket information includes relevant information of the issuer and the recipient, such as the company, tax number, unit address, telephone number, etc. of the issuer and the recipient.

S302: The service node device generates a ticket for the first terminal according to the ticket information.

After the service node device receives the ticket acquisition request from the first terminal, indicating that the first terminal has a ticket acquisition requirement, the service node device generates a ticket for the first terminal according to the ticket information included in the ticket acquisition request.

In one implementation, before the service node device generates a ticket for the first terminal based on the ticket information, the service node device verifies the ticket acquisition request, which includes the identity information of the sender of the ticket acquisition request. The service node device's verification of the ticket acquisition request may include: verifying the identity of the sender of the ticket acquisition request, that is, verifying the identity of the first terminal, thereby improving the credibility of the ticket acquisition request. Specifically, the service node device uses the public key created by the first terminal to verify the ticket acquisition request. If the verification is successful, it indicates that the sender of the ticket acquisition request is the first terminal that sent the ticket acquisition request, and the service node device successfully verifies the ticket acquisition request. In this way, it is helpful to improve the credibility of the ticket acquisition request, that is, to improve the credibility of the ticket information and the right to use the first private key.

S303: The service node device generates notification information, where the notification information includes the generation time of the ticket, the node identifier of the service node device, and the terminal identifier of the first terminal.

Specifically, after the business node device generates a ticket for the first terminal, the business node device generates notification information, which includes the generation time of the ticket, the node identifier of the business node device and the terminal identifier of the first terminal. The notification information is used to notify the consensus node device to process the notification information on the chain, so that the notification information is stored in a distributed data manner in the form of blocks.

In one implementation, the notification information includes the generation time of the ticket, the node identifier of the business node device, the terminal identifier of the first terminal, and the ticket information, so that the consensus node device not only stores the participants and time in the ticket generation process, but also processes the ticket information on the chain and stores it on the consensus node device to prevent it from being tampered with, thereby providing verifiable evidence for subsequent ticket issues.

S304: The service node device sends the notification information to the consensus node device.

After the service node device generates the notification information, it sends the notification information to the consensus node device so that the consensus node device processes the notification information on the chain.

S305: The consensus node device verifies the notification information.

After receiving the notification information, the consensus node device verifies the notification information. The notification information includes the identity information of the sender of the notification information. The verification of the notification information by the consensus node device may include: verifying the identity of the sender of the notification information, that is, verifying the identity of the business node device, thereby improving the credibility of the notification information. Specifically, the consensus node device uses the public key created by the business node device to verify the notification information. If the verification is successful, it indicates that the sender of the notification information is the business node device that sent the notification information, and the consensus node device successfully verifies the notification information. In this way, it is helpful to improve the credibility of the notification information.

In one implementation, after the consensus node device successfully verifies the notification information, it sends the notification information to each consensus node device so that each consensus node device verifies the notification information. Only when the consensus node device successfully verifies the notification information, the notification information is sent to each consensus node device in the blockchain network, which can improve the credibility of the notification information. Each consensus node device in the blockchain network verifies the notification information and sends the verification result of the notification information to the consensus node device receiving the notification information in the form of a notification information verification response.

Specifically, the verification of notification information by each consensus node device is the same as the verification method of notification information by the above-mentioned consensus node device, which will not be repeated here. Regardless of whether the verification result of the notification information by the consensus node device is passed or failed, each consensus node device can send a verification response of the notification information to the consensus node device receiving the notification information. Among them, the verification results for the notification information contained in the notification information verification response from each consensus node device in the blockchain network can be independent of each other.

The consensus node device that receives the notification information obtains the verification result of the notification information based on the verification response of the notification information, and then determines whether the notification information has passed the verification of the blockchain network, that is, the verification result of the bill information is jointly determined based on the verification response of the notification information returned by each consensus node device in the blockchain network. In this way, all consensus node devices in the blockchain network can participate in the verification process for the notification information, which is conducive to improving the credibility of the notification information.

In one implementation, if the number of verification results of each consensus node device for verification of the notification information is greater than a preset threshold, the consensus node device receiving the notification information determines that the notification information has passed the verification of the blockchain network. For example, the preset threshold is 50% of the number of consensus node devices in the blockchain network. If the blockchain network consists of 45 consensus node devices, 26 consensus node devices have a verification result of passing the verification of the notification information, and the number of verification results of the consensus node devices in the blockchain network for the notification information is greater than the preset threshold, the consensus node device determines that the notification information has passed the verification of each consensus node device in the blockchain network.

S306: If the notification information is successfully verified, the consensus node device processes the notification information on the chain.

Specifically, if the consensus node device successfully verifies the notification information, it processes the notification information on the chain to generate a block including the notification information, so that the notification information is stored in a distributed data form in the form of blocks, making it difficult to be tampered with. Each time the business node device generates a bill, it sends the notification information about the bill to the consensus node device. The consensus node device processes the notification information on the chain, and can record the time and information of each time the business node device generates a bill for the first terminal, which can provide a traceable basis for subsequent non-recognition issues.

In one implementation, if the notification information includes ticket information, the consensus node device processes the notification information on the chain so that the ticket information is also distributed and stored in the form of blocks, which can provide verifiable evidence for subsequent ticket issues.

S307: The business node device processes the bill according to the first private key usage right and the smart contract to obtain a first digital signature.

In one implementation, after the first terminal is authorized by the service node device, the first terminal sends the first private key usage right of the first terminal to the service node device, the first private key usage right corresponds to the private key of the first terminal, and the first private key usage right is used by the service node device to encrypt the ticket. Optionally, when the first terminal has a ticket acquisition requirement for the first time, the first terminal sends a ticket acquisition request to the service node device, and the ticket acquisition request includes ticket information and the first private key usage right of the first terminal.

After the service node device generates a bill for the first terminal, it processes the bill according to the first private key usage right and the smart contract to obtain a first digital signature. The smart contract contains a program code for processing the bill according to the private key usage right. The service node device calls the program code, and proves through the first private key usage right that the service node device can use the private key of the first terminal, and can call the private key of the first terminal internally to process the bill. During this processing, the service node device does not obtain the private key of the first terminal, but only calls the private key internally through the first private key usage right. The private key is unknown to the service node device. This process can protect the private key of the first terminal from being leaked.

S308: The service node device sends the ticket and the first digital signature to the second terminal corresponding to the second terminal identifier included in the ticket information.

The business node device obtains the first digital signature, indicating that the ticket is processed successfully, and then sends the ticket and the first digital signature to the second terminal corresponding to the second terminal identifier included in the ticket information, so that the second terminal obtains the processed ticket and can use the public key of the first terminal to decrypt the ticket to obtain the ticket.

In the embodiment of the invention, the business node device can only use the private key usage right of the first terminal to encrypt the ticket without obtaining the private key of the first terminal, which can improve the security of the private key of the first terminal. After the business node device generates a ticket for the first terminal, the consensus node device can store the time and participants of each ticket generation by the business node device, which can provide traceable evidence for subsequent problem handling.

Please refer to FIG. 4 , which is a flow chart of another bill processing method provided by an embodiment of the present invention. The method is applied to a service node device, and the method includes but is not limited to S401 - S410 .

S401: The service node device receives a ticket acquisition request message sent by a first terminal, where the ticket acquisition request message includes ticket information.

When the first terminal has a ticket acquisition demand, the first terminal sends a ticket acquisition request to the service node device, and then the service node device receives the ticket acquisition request sent by the first terminal, where the ticket acquisition request includes ticket information.

S402: If there are multiple ticket information, the service node device determines target ticket information containing the same second terminal identifier in the multiple ticket information.

In one implementation, a ticket acquisition request received by the service node device includes multiple ticket information, so the number of ticket information is multiple.

In one implementation, one acquisition request received by the service node device includes one ticket information. If multiple ticket acquisition requests are received from the first terminal, the number of ticket information is multiple.

A plurality of ticket information may include different second terminal identifiers. Similarly, a plurality of ticket information may also include the same second terminal identifier. When the number of ticket information is multiple, the service node device determines the target ticket information that includes the same second terminal identifier among the plurality of ticket information. For example, the ticket information received by the service node device is ticket information A, ticket information B, ticket information C, and ticket information D. The second terminal identifiers included in ticket information A, ticket information B, ticket information C, and ticket information D are terminal identifier 1, terminal identifier 2, terminal identifier 3, and terminal identifier 2, respectively. Ticket information A and ticket information D include the same second terminal identifier. Then, the service node device determines that the target ticket information that includes the same second terminal identifier is ticket information A and ticket information D.

In an implementation manner, if the second terminal identifiers included in the multiple ticket information do not have the same second terminal identifier, the service node device determines that the target ticket information does not exist in the multiple ticket information.

S403: The service node device generates a ticket for the first terminal according to each target ticket information.

After the service node device determines the target ticket information among the multiple ticket information, it generates multiple tickets for the first terminal according to each target ticket information, and the recipient of each ticket is the second terminal corresponding to the second terminal identifier included in the target ticket information. By generating tickets according to the target ticket information, the service node device can give priority to providing tickets to the second terminal containing the same second terminal identifier in the ticket information, which can improve the invoicing efficiency of the service node device.

In one implementation, if the service node device determines that the target ticket information does not exist in the multiple ticket information, multiple tickets are generated for the first terminal according to a preset rule and each ticket information, where the preset rule is a pre-set rule. For example, if the preset rule is a receiving time priority principle, the service node device generates multiple tickets for the first terminal according to the time sequence of receiving each ticket information.

S404: The service node device generates notification information, where the notification information includes the generation time of the ticket, the node identifier of the service node device, and the terminal identifier of the first terminal.

S405: The service node device sends the notification information to the consensus node device, so that the consensus node device processes the notification information on the chain.

The specific details of steps S404-S405 in the embodiment of the present application can refer to the execution process of steps S303-S304 in the above embodiment, and will not be repeated in the embodiment of the present invention.

S406: The business node device processes the bill according to the first private key usage right and the smart contract.

In one implementation, after the first terminal is authorized by the service node device, the first terminal sends the first private key usage right of the first terminal to the service node device, the first private key usage right corresponds to the private key of the first terminal, and the first private key usage right is used by the service node device to encrypt the ticket. Optionally, when the first terminal has a ticket acquisition requirement for the first time, the first terminal sends a ticket acquisition request to the service node device, and the ticket acquisition request includes ticket information and the first private key usage right of the first terminal.

After the service node device generates multiple bills for the first terminal, it processes each bill according to the first private key usage right and the smart contract to obtain multiple first digital signatures. The smart contract contains program code for processing the bill according to the first private key usage right. The service node device calls the program code, and proves that the service node device can use the private key of the first terminal through the first private key usage right, and can call the private key of the first terminal internally to process each bill and encrypt each bill.

During this process, the service node device still does not obtain the private key of the first terminal, but only calls the private key internally through the first private key usage right. The private key is still unknown to the service node device, which can protect the security of the private key of the first terminal.

S407: If the ticket processing fails, the service node device sends an update request to the first terminal, where the update request is used to request an update of the right to use the first private key.

The service node device processes multiple bills according to the first private key usage right and the smart contract. If the processing fails, it indicates that the first terminal has updated the private key of the first terminal. At this time, the first private key usage right corresponding to the private key of the first terminal is invalid, so the service node device cannot use the first private key usage right. The service node device sends an update request to the first terminal, requesting to update the first private key usage right corresponding to the first terminal after the private key is updated.

S408: The service node device receives the second private key usage right sent by the first terminal, where the second private key usage right is obtained by the first terminal by updating the private key of the first terminal.

After the first terminal receives the update request sent by the business node device, it will send the second private key usage right corresponding to the updated private key to the business node device. Therefore, the business node device receives the second private key usage right sent by the first terminal. The second private key usage right is obtained by the first terminal by updating the private key of the first terminal.

S409: The business node device processes the bill according to the second private key usage right and the smart contract to obtain a second digital signature.

After receiving the latest second private key usage rights, the service node device encrypts each bill according to the second private key usage rights and the smart contract to obtain multiple second digital signatures. The smart contract contains program code for processing bills according to the private key usage rights. The service node device calls the program code and processes the bill by internally calling the private key of the first terminal through the first private key usage rights.

In this process, the service node device does not obtain the private key of the first terminal, but only calls the private key internally through the first private key usage right, and the private key is unknown to the service node device. This process can prevent the private key of the first terminal from being leaked.

S410: The service node device sends the ticket and the second digital signature to the second terminal corresponding to the second terminal identifier included in the target ticket information.

The service node device sends each ticket and each second digital signature to the second terminal corresponding to the second terminal identifier included in the target ticket information, so that the second terminal receives each ticket and decrypts each second digital signature using the public key created by the first terminal to obtain multiple tickets.

In an embodiment of the present invention, the number of ticket information is multiple, and the service node device can preferentially generate tickets for the first terminal based on the target ticket information with the same second terminal identifier contained in the multiple ticket information, which can improve the efficiency of the service node device in generating tickets. At the same time, if the service node device fails to process the ticket information according to the first private key usage right of the first terminal, it can send an update request to the first terminal to obtain the second private key usage right corresponding to the first terminal after the private key is updated, and then process the ticket according to the second private key usage right. This method allows the service node device to encrypt the ticket only using the private key usage right corresponding to the updated private key after the first terminal updates the private key. In this method, the first terminal can update the private key of the first terminal from time to time, which can improve the security of the private key.

Please refer to FIG. 5 , which is a schematic flow chart of another bill processing method provided by an embodiment of the present invention, the method including but not limited to S501 - S511 .

S501: The service node device receives a ticket acquisition request message sent by a first terminal, where the ticket acquisition request message includes ticket information.

The specific details of step S501 in the embodiment of the present application may refer to the execution process of step S401 in the above embodiment, and will not be repeated in the embodiment of the present invention.

S502: If there are multiple ticket information, the service node device determines multiple second terminals corresponding to the second terminal identifiers included in each ticket information.

A ticket acquisition request received by the service node device includes multiple ticket information, and the number of ticket information is multiple. Optionally, a ticket acquisition request received by the service node device includes a ticket information, and multiple ticket acquisition requests sent by the first terminal are received, and the number of ticket information is multiple.

Each ticket information includes a second terminal identifier. If there are multiple ticket information, the service node device determines multiple second terminals corresponding to the second terminal identifiers included in each ticket information through the second terminal identifiers included in each ticket information.

S503: The service node device obtains the total number of transactions and the number of successful transactions of each second terminal within a preset period.

Each second terminal can conduct transactions with the first terminal multiple times, and each transaction with the first terminal will generate a transaction record. The transaction status of each second terminal with the first terminal may be a successful transaction or a failed transaction. The service node device obtains the total number of transactions and the number of successful transactions corresponding to each second terminal with the first terminal through the second terminal identifier included in each ticket information within a preset period. The preset period is a second preset period, and the second preset period is pre-set.

S504: The service node device determines the credit level of each second terminal according to the total number of transactions and the number of successful transactions of each second terminal.

Specifically, the service node device determines the transaction success rate of each second terminal according to the total number of transactions and the number of successful transactions of each second terminal, and then determines the credit level of each second terminal according to the transaction success rate of each second terminal.

For example, the second terminals corresponding to the second terminal identifiers included in the multiple bill information are second terminal A, second terminal B, and second terminal C. The number of transactions of second terminal A is 26, and the number of successful transactions is 17. The number of transactions of second terminal B is 12, and the number of successful transactions is 4. The number of transactions of second terminal C is 45, and the number of successful transactions is 31. Then, the transaction success rate of second terminal A is 65.4%, the transaction success rate of second terminal B is 33.3%, and the transaction success rate of second terminal C is 68.9%. If the credit ratings of the three second terminals are sorted by capital letters, A represents the second terminal with the highest credit rating, and the credit ratings of second terminal A, second terminal B, and second terminal C are B, C, and A, respectively. The credit rating ranking of the second terminal can also be expressed in other ways, such as numbers, etc., which are not limited here.

S505: The service node device determines a target second terminal identifier corresponding to the highest credit level among the credit levels.

After the service node device determines the credit level of each second terminal, it determines the target second terminal identifier corresponding to the highest credit level among the credit levels. For example, the credit levels of each second terminal determined by the service node device are as shown in S504, and the credit levels of the second terminal A, the second terminal B, and the second terminal C are B, C, and A, respectively. The second terminal C has the highest credit level among the three second terminals, and it is determined that the target second terminal identifier corresponding to the highest credit level among the credit levels is the terminal identifier of the second terminal C.

S506: The service node device generates a ticket for the first terminal according to the ticket information corresponding to the target second terminal identifier.

Specifically, the service node device determines the ticket information according to the target second terminal identifier, and then generates a ticket for the first terminal according to the determined ticket information.

In one implementation, the number of ticket information corresponding to the target second terminal identifier is one, and the service node device generates a ticket for the first terminal according to the determined ticket information.

In one implementation, there are multiple ticket information corresponding to the target second terminal identifier, and the service node device generates multiple tickets for the first terminal according to the multiple ticket information determined.

In this method, the service node device generates a bill according to the bill information corresponding to the target second terminal identifier of the second terminal with the highest credit rating, so that the service node device preferentially provides bills to the second terminal with the highest credit rating. The probability of successful transactions between the second terminal with a high credit rating and the first terminal is greater than that of the second terminal with a low credit rating. The service node device preferentially provides bills to the second terminal with a high credit rating, which can reduce the number of tax refunds caused by subsequent transaction failures.

S507: The service node device generates notification information, where the notification information includes the generation time of the ticket, the node identifier of the service node device, and the terminal identifier of the first terminal.

S508: The service node device sends the notification information to the consensus node device, so that the consensus node device processes the notification information on the chain.

The specific details of steps S507-S508 in the embodiment of the present application can refer to the execution process of steps S404-S405 in the above embodiment, and will not be repeated in the embodiment of the present invention.

S509: The service node device receives the second private key usage right sent by the first terminal at every preset period.

The service node device receives the second private key usage right sent by the first terminal at every preset period, the preset period is a first preset period, the first preset period is pre-set, and the second private key usage right is obtained by the first terminal by updating the private key of the first terminal.

The service node device automatically receives the second private key usage right sent by the first terminal at every first preset period, so that the private key usage right used each time is the private key usage right corresponding to the latest private key from the first terminal.

S510: The business node device processes the bill according to the second private key usage right and the smart contract to obtain a second digital signature.

S511: The service node device sends the ticket and the second digital signature to the second terminal corresponding to the second terminal identifier included in the target ticket information.

For details of steps S510-S511 in the embodiment of the present application, reference may be made to the execution process of steps S409-S410 in the above embodiment, which will not be described in detail in the embodiment of the present invention.

In an embodiment of the present invention, the business node device can generate a ticket for the first terminal based on the credit level of the second terminal corresponding to the second terminal identifier included in the ticket information, and give priority to the ticket information corresponding to the second terminal with the highest credit level. The business node device can receive the second private key usage right from the first terminal at every preset period, so that the private key usage right possessed is the private key usage right obtained by the first terminal after updating the private key of the first terminal, and thus the ticket processing will not fail due to the invalidation of the private key usage right.

Please refer to FIG. 6, which is a schematic diagram of the structure of a bill processing device provided in an embodiment of the present invention. The bill processing device can be used in the steps performed by the service node device in the embodiments shown in FIG. 3 to FIG. 5. The bill processing device 60 may include:

The receiving module 601 is used to receive a ticket acquisition request sent by the first terminal, where the ticket acquisition request includes ticket information;

A generating module 602, configured to generate a ticket for the first terminal according to the ticket information;

A processing module 603 is used to process the bill according to the first private key usage right of the first terminal and the smart contract to obtain a first digital signature;

The sending module 604 is used to send the ticket and the first digital signature to the second terminal corresponding to the second terminal identifier included in the ticket information, so that the second terminal obtains the ticket.

In one implementation, the processing module 603 is further configured to send an update request to the first terminal through the sending module 604 if the bill processing fails according to the first private key usage right and the smart contract, and the update request is used to request to update the first private key usage right;

The receiving module 601 is further configured to receive a second private key usage right sent by the first terminal, where the second private key usage right is obtained by the first terminal by updating the private key of the first terminal;

The processing module 603 is further used to process the bill according to the second private key usage right and the smart contract to obtain a second digital signature;

The sending module 604 is further configured to send the ticket and the second digital signature to a second terminal corresponding to the second terminal identifier included in the ticket information, so that the second terminal obtains the ticket.

In one implementation, the receiving module 601 is further configured to receive, at intervals of a first preset period, a second private key usage right sent by the first terminal, where the second private key usage right is obtained by the first terminal by updating the private key of the first terminal;

The processing module 603 is further used to process the bill according to the second private key usage right and the smart contract to obtain a second digital signature;

The sending module 604 is further configured to send the ticket and the second digital signature to a second terminal corresponding to the second terminal identifier included in the ticket information, so that the second terminal obtains the ticket.

In one implementation, after the generation module 602 generates a ticket for the first terminal according to the ticket information, the generation module 602 is further used to generate notification information, the notification information including the generation time of the ticket, the node identifier of the service node device and the terminal identifier of the first terminal;

The sending module 604 is also used to send the notification information to the consensus node device, so that the consensus node device processes the notification information on the chain.

In one implementation, there are multiple ticket information, and the processing module 603 is further used to determine target ticket information containing the same second terminal identifier among the multiple ticket information;

The generating module 602 is further configured to generate a ticket for the first terminal according to each target ticket information.

In one implementation, the processing module 603 is further used to determine multiple second terminals corresponding to the second terminal identifiers included in each ticket information;

The processing module 603 is further used to determine the credit rating of each second terminal;

The processing module 603 is further used to determine the target second terminal identifier corresponding to the highest credit level among the credit levels;

The generating module 602 is further configured to generate a ticket for the first terminal according to the ticket information corresponding to the target second terminal identifier.

In one implementation, the processing module 603 is further configured to obtain the total number of transactions and the number of successful transactions of each second terminal within the second preset period;

The processing module 603 is further configured to determine the credit rating of each second terminal according to the total number of transactions and the number of successful transactions of each second terminal.

Each module in the device shown in Fig. 6 can be separately or all merged into one or several other modules to constitute, or some of the modules can also be split into multiple smaller modules in function to constitute, which can achieve the same operation without affecting the realization of the technical effects of the embodiments of the present application. The above modules are divided based on logical functions. In practical applications, the function of a module can also be realized by multiple modules, or the function of multiple modules can be realized by one module. In other embodiments of the present application, other modules may also be included. In practical applications, these functions can also be implemented with the assistance of other modules, and can be implemented by the collaboration of multiple modules, which is not limited in the present application.

Please refer to Figure 7, which is a structural diagram of another bill processing device provided by an embodiment of the present invention. The bill processing device 70 includes a processor 701, a memory 702, and a communication interface 703. The processor 701, the memory 702, and the communication interface 703 are connected via one or more communication buses.

The processor 701 is configured to support the bill processing device to perform the corresponding functions of the service node device of the embodiments shown in Figures 3 to 5. The processor 701 can be a central processing unit (CPU), a network processor (NP), a hardware chip or any combination thereof.

The memory 702 is used to store program codes, etc. The memory 702 may include a volatile memory, such as a random access memory (RAM); the memory 702 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD) or a solid-state drive (SSD); the memory 702 may also include a combination of the above-mentioned types of memory.

The communication interface 703 is used to receive and send data. For example, the communication interface 703 is used to receive a ticket acquisition request sent by the first terminal, or the communication interface 703 is used to send the ticket and the first digital signature to the second terminal corresponding to the second terminal identifier included in the ticket information.

In the embodiment of the present invention, the bill processing device 70 includes multiple communication interfaces, wherein the communication interface for sending data and the communication interface for receiving data may not be the same communication interface.

The processor 701 may call the program code stored in the memory 702 to perform the following operations:

The communication interface 703 receives a ticket acquisition request sent by the first terminal, where the ticket acquisition request includes ticket information;

The processor 701 generates a ticket for the first terminal according to the ticket information;

The processor 701 processes the bill according to the first private key usage right of the first terminal and the smart contract to obtain a first digital signature;

The processor 701 sends the ticket and the first digital signature to the second terminal corresponding to the second terminal identifier included in the ticket information through the communication interface 703, so that the second terminal obtains the ticket.

In one implementation, the processor 701 may further perform the following operations:

If the processor 701 fails to process the bill according to the first private key usage right and the smart contract, the processor 701 sends an update request to the first terminal through the communication interface 703, where the update request is used to request to update the first private key usage right;

The processor 701 receives, through the communication interface 703, the second private key usage right sent by the first terminal, where the second private key usage right is obtained by the first terminal by updating the private key of the first terminal;

The processor 701 processes the bill according to the second private key usage right and the smart contract to obtain a second digital signature;

The processor 701 sends the ticket and the second digital signature to the second terminal corresponding to the second terminal identifier included in the ticket information through the communication interface 703, so that the second terminal obtains the ticket.

In one implementation, the processor 701 may further perform the following operations:

At intervals of a first preset period, the processor 701 receives, through the communication interface 703, the second private key usage right sent by the first terminal, where the second private key usage right is obtained by the first terminal by updating the private key of the first terminal;

The processor 701 processes the bill according to the second private key usage right and the smart contract to obtain a second digital signature;

The processor 701 sends the ticket and the second digital signature to the second terminal corresponding to the second terminal identifier included in the ticket information through the communication interface 703, so that the second terminal obtains the ticket.

In one implementation, after the processor 701 generates a ticket for the first terminal according to the ticket information, it may further perform the following operations:

The processor 701 generates notification information, where the notification information includes the generation time of the ticket, the node identifier of the service node device, and the terminal identifier of the first terminal;

The processor 701 sends the notification information to the consensus node device through the communication interface 703, so that the consensus node device processes the notification information on the chain.

In one implementation, if the amount of ticket information is multiple, the processor 701 may further perform the following operations:

The processor 701 determines target ticket information including the same second terminal identifier among the multiple ticket information;

The processor 701 generates a ticket for the first terminal according to each target ticket information.

In one implementation, if the amount of ticket information is multiple, the processor 701 may further perform the following operations:

The processor 701 determines a plurality of second terminals corresponding to the second terminal identifiers included in each ticket information;

The processor 701 determines the credit rating of each second terminal;

The processor 701 determines the target second terminal identifier corresponding to the highest credit level among the credit levels;

The processor 701 generates a ticket for the first terminal according to the ticket information corresponding to the target second terminal identifier.

In one implementation, the processor 701 may further perform the following operations:

The processor 701 obtains the total number of transactions and the number of successful transactions of each second terminal within the second preset period;

The processor 701 determines the credit rating of each second terminal according to the total number of transactions and the number of successful transactions of each second terminal.

An embodiment of the present invention also provides a computer-readable storage medium that can be used to store computer software instructions used by the service node device in the embodiments shown in Figures 3 to 7, which includes a program designed for executing the service node device in the above embodiments.

The computer-readable storage medium includes but is not limited to a flash memory, a hard disk, and a solid-state drive.

The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims (9)

1. A ticket processing method, wherein the method is applied to service node equipment, and the method comprises:

receiving a bill acquisition request sent by a first terminal, wherein the bill acquisition request comprises bill information;

generating a bill for the first terminal according to the bill information;

generating notification information, wherein the notification information comprises the generation time of the bill, the node identifier of the service node equipment and the terminal identifier of the first terminal;

sending the notification information to a consensus node device so that the consensus node device can perform uplink processing on the notification information;

invoking an intelligent contract, and determining that the service node equipment is authorized to use the private key of the first terminal through the first private key use right of the first terminal;

Calling a private key of the first terminal through the intelligent contract to process the bill to obtain a first digital signature;

And sending the bill and the first digital signature to a second terminal corresponding to a second terminal identifier included in the bill information, so that the second terminal obtains the bill.

2. The method according to claim 1, wherein the method further comprises:

If the bill processing fails according to the first private key use right and the intelligent contract, an update request is sent to the first terminal, wherein the update request is used for requesting to update the first private key use right;

Receiving a second private key use right sent by the first terminal, wherein the second private key use right is obtained by updating the private key of the first terminal by the first terminal;

processing the bill according to the second private key use right and the intelligent contract to obtain a second digital signature;

And sending the bill and the second digital signature to a second terminal corresponding to a second terminal identifier included in the bill information, so that the second terminal obtains the bill.

3. The method according to claim 1, wherein the method further comprises:

Receiving a second private key use right sent by the first terminal every first preset period, wherein the second private key use right is obtained by updating a private key of the first terminal by the first terminal;

processing the bill according to the second private key use right and the intelligent contract to obtain a second digital signature;

And sending the bill and the second digital signature to a second terminal corresponding to a second terminal identifier included in the bill information, so that the second terminal obtains the bill.

4. A method according to any one of claims 1-3, wherein the number of ticket information is a plurality, and the generating a ticket for the first terminal based on the ticket information comprises:

determining target bill information containing the same second terminal identifier in the bill information;

and generating a bill for the first terminal according to each target bill information.

5. A method according to any one of claims 1-3, wherein the number of ticket information is a plurality, and the generating a ticket for the first terminal based on the ticket information comprises:

determining a plurality of second terminals corresponding to the second terminal identifiers contained in the bill information;

determining the credit rating of each second terminal;

Determining a target second terminal identifier corresponding to the highest credit level in the credit levels;

and generating a bill for the first terminal according to the bill information corresponding to the target second terminal identifier.

6. The method of claim 5, wherein the determining the credit rating of each second terminal comprises:

Acquiring the total transaction times and the successful transaction times of each second terminal in a second preset period;

And determining the credit level of each second terminal according to the total transaction times and the successful transaction times of each second terminal.

7. A bill handling apparatus, comprising:

The receiving module is used for receiving a bill acquisition request sent by the first terminal, wherein the bill acquisition request comprises bill information;

The generation module is used for generating a bill for the first terminal according to the bill information; generating notification information, wherein the notification information comprises the generation time of the bill, the node identifier of service node equipment and the terminal identifier of the first terminal;

The sending module is used for sending the notification information to the consensus node equipment so that the consensus node equipment can perform uplink processing on the notification information;

the processing module is used for calling the intelligent contract and determining that the service node equipment is authorized to use the private key of the first terminal through the first private key use right of the first terminal; calling a private key of the first terminal through the intelligent contract to process the bill to obtain a first digital signature;

the sending module is further configured to send the ticket and the first digital signature to a second terminal corresponding to a second terminal identifier included in the ticket information, so that the second terminal obtains the ticket.

8. A ticket processing apparatus comprising a processor and a memory, the processor and memory being interconnected, wherein the memory is adapted to store a computer program comprising program instructions, the processor being configured to invoke the program instructions to perform the method of any of claims 1-6.

9. A computer storage medium storing a computer program comprising program instructions which, when executed by a processor, cause the processor to perform the method of any of claims 1-6.